CC Proxy Detector

Claude Code プロキシ中継站のバックエンド送信元を検出し、混合チャネル検出と偽装防止識別に対応しています。

検出フロー

1. ターゲット中継站のアドレスと API Key を確認
2. 検出モード（単一モデル / 複数モデルスキャン）を選択
3. scripts/detect.py を実行
4. レポートを分析し、フィンガープリント マトリックスと照らし合わせて手動で検証

使用方法

# 単一モデル自動検出
python3 scripts/detect.py

# 複数モデルスキャン（推奨、混合チャネル検出）
python3 scripts/detect.py --scan-all --rounds 2

# モデルリスト指定
python3 scripts/detect.py --scan-models "claude-opus-4-6,claude-sonnet-4-5-20250929"

# アドレスとキー指定
python3 scripts/detect.py --base-url https://your-proxy.com --api-key sk-xxx

# JSON 出力 + 保存
python3 scripts/detect.py --scan-all --json --output report.json

環境変数：ANTHROPIC_BASE_URL（中継站アドレス）、ANTHROPIC_AUTH_TOKEN または FACTORY_API_KEY（キー）。

依存関係：pip install requests

バックエンド送信元の全体像

すべての Claude アクセスは最終的に 3 つのバックエンドのいずれかに到達します。様々なツールがこれらのバックエンドをリバースエンジニアリングしています。

送信元	バックエンド	説明
Anthropic API	Anthropic	公式 API Key または Max サブスクリプション
Claude Code Max	Anthropic	OAuth 認証、CLIProxyAPI を通じて API Key に変換可能
Kiro	AWS Bedrock	AWS AI IDE、モデルプリフィックス kiro-
Factory Droid	Anthropic/Bedrock	BYOK をサポート、バックエンドは設定に依存
Antigravity	Google Vertex AI	Google Cloud Code、googleapis.com を経由
Windsurf	Bedrock/不明	Codeium AI IDE、内部チャネル不明
Warp	不明	AI ターミナル、内部チャネル不明

検出ディメンション

スクリプトは各モデルに対して tool_use プローブ + thinking プローブ + ratelimit 動的検証を送信し、以下のフィンガープリントを収集します。

フィンガープリント	Anthropic 公式	Bedrock/Kiro	Vertex/Antigravity
tool_use id	toolu_	tooluse_	tooluse_ / tool_N
message id	msg_<base62>	UUID / msg_<UUID>	msg_<UUID> / req_vrtx_
thinking sig	len 200+	len 200+ / 切り詰め	claude# プリフィックス
model 形式	claude-*	kiro-* / anthropic.*	claude-*
service_tier	あり	なし	なし
inference_geo	あり	なし	なし
ratelimit hdr	あり（動的削減）	なし	なし
cache_creation	ネストオブジェクト	なし	なし

レポートの読み方

スクリプトは自動的にスコア付けして判定を出しますが、自動スコアリングは中継站の偽装で騙される可能性があります。手動検証の要点：

真の Anthropic を確認する鉄則の組み合わせ：

• inference_geo が存在 + ratelimit remaining が動的削減 + toolu_ プリフィックス

偽装を識別するキーポイント：

• ratelimit remaining が固定不変（例：常に 299000）→ ヘッダー偽造
• inference_geo が欠落 → 中継站がこのフィールドを偽造していない
• すべてのポジティブ フィンガープリントが通過しても必ず何らかのフィールドが欠落 → 極度に疑わしい

偽造可能と判明しているフィールド：toolu_ プリフィックス、service_tier、ratelimit ヘッダー（静的値）、cache_creation ネストオブジェクト

最も偽造しにくい：ratelimit remaining の動的削減（中継站が配額カウントシステムを維持する必要がある）

異常な動作（リバースエンジニアリングされたチャネルの手がかり）

フィンガープリント フィールドの他に、リバースエンジニアリングされたチャネルは頻繁に実行時異常を示し、補助的な判定基準として使用できます：

• tool_use ペアリングエラー：Each tool_use block must have a corresponding tool_result block — 中継站が tool ID を書き直してもペアリングチェーンを破壊した
• 断続的な HTTP 500：中継站のフォーマット変換パイプラインが特定のモデル/機能の組み合わせで失敗
• モデル可用性のギャップ：一部のモデルは利用可能で一部は不可能 — 中継站がモデル ID の一部のみをマップした
• レイテンシが高く変動が大きい：中継一跳で 1～3s の追加遅延、P99 テール遅延が顕著
• thinking/streaming 異常：中継站が SSE イベントまたは thinking ブロックを正しく転送していない
• マルチモーダル/画像読み込み失敗：画像データが中継時に失われたかバックエンドがサポートしていない、画像読み込みが空コンテンツを返す
• Write 大量コンテンツエラー：中継站がリクエスト/レスポンスボディサイズに制限がある、特定行数以上への書き込み時に失敗
• WebFetch ブロック：中継站のネットワークポリシーが外部ドメインへのアクセスを制限
• ツールパラメータ検証異常：一部のツール（TaskList など）でパラメータ検証エラーが発生、中継站のフォーマット変換が不完全

参考資料

• 3 つの送信元フィンガープリント マトリックスと既知チャネル検出事例：references/fingerprint-matrix.md を参照
• 履歴検出レポート JSON：references/*.json