ブラウザや既稿の Claude 記事と違う「Claude Code CLI が壊れる」理由

ブラウザで claude.ai を開く場合、macOS／Windows のシステムプロキシを尊重しやすく、タブ内の認証フローも同じ経路に乗りがちです。Claude Code のようにシェルから起動するツールは、親プロセスの環境変数、コンテナ／WSL／リモート SSH、CI ジョブなどコンテキストが分かれた瞬間にプロキシ設定が継承されない場面が少なくありません。Clash が TUN によりカーネル側から覆う場合と、単に mixed-port に環境変数で向けるだけの場合では、出口の一貫性がまったく違います。

既稿の Claude ウェブと Messages API は anthropic.com と claude.ai を横断して束ねることが中心で、典型はブラウザや SDK からの呼び出しです。Claude Code CLI はその上に、端末だけ開く OAuth 用のコールバックやデバイスフローの待ち時間、モデルメタデータ取得のバースト、ときには更新チェックが重なります。ホストの束ね方は土台として同じでも、「どのフェーズでログに何が出るか」は CLI のほうが読み取りやすい反面、ブラウザだけ成功している罠にハマりやすいです。

まず Clash のライブ接続で、失敗ウィンドウの数十秒だけ SNI と選択ポリシーを並べてください。api.anthropic.com だけ赤字なのか、認証ドメインと交互に落ちるのか、claude.ai の静的パスだけ遅いのかをメモすると、OAuth・API・CDN のどれが経路だけ割れているかがはっきりします。サービス側の恒久障害を疑う前に、この階層分けの方がコストが低いことが多く、チーム内の再現ログ共有にも向きます。

ℹ 観測のコツ：問題が出ているターミナルから短いウィンドウだけ計測し、成功している別シェルと環境変数の差分を並べます。ALL_PROXY と NO_PROXY にローカル例外が紛れていないか、企業 PAC がターミナルにだけ効いていないかも合わせて見ます。OAuth 完了直後にだけ失敗するなら、トークン保存パスやキーチェーンは CLI のドキュメントを正にし、ネットワーク以外の要因も切り分けます。

ターミナルが踏むレイヤー：OAuth・API・claude.ai・コンソール・静的 CDN

実運用でまとめやすい層は次のとおりです。(1) アカウントとトークン——ブラウザへ飛ぶ OAuth、console.anthropic.com 周辺の管理操作、実装により増える認証補助ホスト。バージョンとリージョンにより名前は変わるため、自分のログを正にします。(2) モデル応答と課金まわりの API——多くが api.anthropic.com を軸に、将来のサブドメインやステータス用ホストが増えることもあります。(3) チャット UI とヘルプ——claude.ai 配下の読み込みが挟まると、ブラウザ連携の診断と見え方が似通います。(4) 管理 UI——組織ポリシーやキー管理で console.anthropic.com が単独に出ると、Web は動くのに CLI の組織ログインだけ詰まる、という分割が起きます。(5) 静的 CDN——スクリプトやアセット、場合によりサードパーティのエッジに見える名前空間。ここが誤遮蔽や直結のボトルネックだと、画面は中途半端に出るのに裏の API だけタイムアウトと誤解されやすいです。

「API だけタイムアウト」は層 (2) が別出口にいる典型ですが、(1)(3)(4)(5) のどれかが先に詰まっていると、(2) に到達する前に長い待ちに見えます。逆に (2) だけ通っていても、OAuth のコールバックが (1) で止まれば完了しません。ひとつの安定した出口を Anthropic 関連の束に割り当て、必要なら DOMAIN 行で絞り込むと読みやすいです。公式が新しい CDN を足したら、開発者ドキュメント と自分の接続ログを突き合わせて追記します（仕様確認用であり、接続の合法性は利用者の責任です）。

YAML での概念的な束ね方（例）

ポリシー名は自分の構成に置き換えてください。断片は出発点であり、丸写しではありません。増えた名前はログで足し、範囲が広すぎると国内向け一般サイトまで巻き込みます。

Illustrative rules fragment — verify against your logs

rules:
  - DOMAIN-SUFFIX,anthropic.com,ANTHROPIC_CODE_STABLE
  - DOMAIN-SUFFIX,claude.ai,ANTHROPIC_CODE_STABLE
  - DOMAIN,api.anthropic.com,ANTHROPIC_CODE_STABLE
  - DOMAIN,console.anthropic.com,ANTHROPIC_CODE_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

DOMAIN-SUFFIX,anthropic.com は api.anthropic.com や将来サブドメインをまとめますが、開始時は DOMAIN 中心にしてから徐々に拡張する運用が安全です。リストの並べ替えと更新の型は ルール分流のベストプラクティス を参照してください。許可されていないサービスへの迂回には使わないでください。

DOMAIN-SUFFIX とルール順：MATCH より上で揃える

Clash は一行目から順に評価し、最初に当たった行で出口が決まります。広告ブロック用ルールや大きな拒否リスト、広すぎる GEOIP が Anthropic 系ホストを先に片付けていたり、CDN を誤って直結／拒否していたりすると、ブラウザだけ別プロファイルで結果だけ見えている状態になります。開発者向けブロックセットを入れているプロファイルほど、この誤遮蔽を疑う価値があります。

「昨日まで Claude Code が動いた」なら、(a) ルールプロバイダの自動更新で順序が変わった、(b) 更新取得自体がプロキシループで詰まり古いリストのまま、(c) サブスクリプション更新後にノード品質だけが劣化——の三通りを順に見ます。購読とノード保守 と タイムアウトと TLS の読み方 をセットにすると切り分けが速くなります。

システムプロキシ／TUN／HTTPS_PROXY の取りこぼし

開発者環境では、ブラウザ用に Clash のシステムプロキシをオンにしている一方、ターミナルだけ HTTPS_PROXY を設定していなかった、WSL／Docker だけ別ブリッジにいる——といったパターンが珍しくありません。Docker／ターミナル向け記事 の構成と突き合わせ、すべてのプロセスが同じ Clash アップストリームに到達できるかを確認してください。

TUN はPOSIX 環境への注入漏れを減らす一方、企業 VPN やホスト側の複数 NIC と競合することがあります。TUN の深掘り を読み、「システムプロキシに切り替えるとだけ直る」のか、「TUN が必要なのか」を短時間で A/B します。両方を同時に誤って二重に載せないよう注意してください。

DNS・fake-ip が原因の「名前は返るが止まる」

fake-ip を使っていると、アプリには合成アドレスが返り実解決は後段になります。このとき DOMAIN 規則と DNS の順序理解が食い違うと、名前解決は一瞬でも TCP が進まず API タイムアウト にしか見えません。CLI はブラウザよりキャッシュ層が薄く、結果としてログに残るほうが素直です。

社内ネットワークで分割 DNS を使っていると、公開向けとは別のアドレスに誘導され、認証だけ失敗することがあります。IT の案内がある場合は順守しつつ、「家のクリーンな回線では再現しない」事実だけでも切り分け材料になります。一般的な確認は FAQ も参照してください。

Claude のブラウザと Messages API 向け記事 は UI と API の横断分流が中心で、本稿はターミナルで動く Claude Code と OAuth 連鎖に焦点を当てます。OpenAI Codex CLI の CDN 分流記事 や Gemini CLI、OpenCode CLI と考え方は似ていますが、ベンダーごとに並ぶホストが違うため単純な丸写しは通用しません。Cursor のログイン記事 のように「開発者ツールのタイムアウト」でも対象名前空間は別です。自分が触っているスタックに合った記事だけを精読し、他は辞書程度の参照にとどめると安全です。

⚠ コンプライアンス：サービス規約や法的制限、アクセス許可されていない環境での利用を前提にした迂回は説明対象ではありません。職場のセキュリティ方針に従ってください。

許可環境でのチェックリスト

  1. この CLI と Clash で Anthropic に接続することが契約およびポリシー上許されているか確認した。
  2. 失敗ウィンドウの接続ログから、OAuth・api・claude.ai・console・静的 CDN に分類してホスト名を列挙した。
  3. それらが広域ブロックリストより上の行へ載っていることを確認した。
  4. ブラウザとターミナルで HTTPS_PROXY／TUN／システムプロキシの差を A/B した。
  5. fake-ip 利用時は nameserver と DOMAIN 規則の整合を読み直した。
  6. 購読とルール更新がループせず成功することをログで確認した。
  7. 問題が残るときだけノード総入れ替えやベンダーダウン確認に進んだ。

メモだけで済ませず、設定ファイルの変更点を短文で残すと数日後の自分が助かります。チームで展開する場合も同様で、レビュアが「どのサフィックスをいつ足したか」を追えると再現切り分けが速くなります。

よくある質問

簡単な質疑を並べました。FAQPage の構造化データは <head> にあります。

ブラウザの claude.ai は動くのに Claude Code CLI だけ止まりますがなぜですか。

ブラウザはシステムプロキシを尊重しやすく、CLI は環境変数やカーネル捕捉に依存しがちです。api.anthropic.com と claude.ai および静的 CDN が別出口に割れると、片方だけタイムアウトに見えます。

Claude のウェブと API 向け記事と何が違いますか。

既稿はブラウザ中心の横断分流が主で、本稿はターミナル上の Claude Code における OAuth 連鎖と CLI 特有のプロキシ取りこぼしを深掘りします。ルールの骨格は共通でも、切り分けの着眼点が異なります。

静的 CDN は DIRECT の方が速いですか。

地域や ISP で差があります。静的ホストだけ止まるなら API と同じ出口へ寄せ、DNS と証明書の整合を優先すると再現しにくいことが多いです。

api.anthropic.com だけを DOMAIN で書き分けたいです。

ログに基づき DOMAIN から始め、増えたサフィックスを徐々に DOMAIN-SUFFIX へ拡張するのが安全です。anthropic.com 全体を広く巻き込むと無関係なページまで同じポリシーになります。

まとめ

Claude Code CLI は単一ホストとの会話というより、OAuth・Messages API・claude.ai・コンソール・静的 CDN の短い連鎖です。MATCH まで届いているか、認証と API と CDN が同じ出口か、DNS がルール設計と同じ視点か——この三通りを押さえると、ノード性能やベンダ障害を疑うより先に体感が変わることがあります。2026 年もエンドポイントは増減するため、黒箱の単一プリセットよりログを読んで増分更新するモデルのほうが持続します。

一部の単一チャネル VPN やブランド固定クライアントは、どの名前が増えたか観測しづらく、開発者がターミナルで待たされる原因を特定しにくい面があります。Clash はドメインベースでルールプロバイダを差し替えやすく、上流リストが不透明でも自分で順序と例外を足せます。この透明性があるからこそ、許可環境でのセルフサービスにも向きます。

Clash V.CORE はその設計語彙に沿って UI とログを並べやすく、「CLI のどのフェーズが詰まっているか」を短いセッションで切り分けやすいです。黒箱より出口とログが追える構成に寄せると、同僚との再現議論も早くなります。Clash を無料ダウンロードし、自分のワークステーションだけで検証するところから始めてください。OAuth だけ別経路だった、という発見はすぐログに現れます。