まず押さえる：CLIの不調は「モデル」より先に経路を疑う
Claude Code のような公式 CLI は、発行された資格情報やセッショントークンを使って Anthropic の API エンドポイントへ長めの HTTPS セッションを張ります。体感として「遅い」と感じる場合も、実際には 帯域不足ではなく TCP コネクションの再試行や 途中の RST、あるいは 証明書検証まで辿り着く前の名前解決失敗が原因であることが珍しくありません。まずはネットワークのレイテンシを一般サイトで測り、問題をコードに押し付ける前に 接続ログでホスト名の列挙から始めてください。
なぜブラウザは通るのにターミナルだけ失敗するのか
多くのブラウザは システムプロキシ設定を尊重しますが、npm や社内製スクリプト、言語ランタイム付属の HTTP クライアントは既定でプロキシを通しません。Claude Code 自体が内部でどのスタックを呼ぶかは更新で変わり得るため、ここでは「ターミナルに出したコマンドが経由すべき出口」という一般論に立ちます。結果として、ブラウザだけ希望ノードを通り、CLI が直結や不安定回線に出て行く、という 経路の非対称が起きます。これは単一のドメイン規則で直る場合もあれば、認証フローだけ別ホストへ跳ぶ場合もあります。症状を再現する最小コマンドを一つ決め、ログでその瞬間に現れる FQDN をメモする習慣をつけると、以降の調整が速くなります。
第1の一手：TUNでターミナルも同じ分流に載せる
HTTP や SOCKS の手動指定に頼らず、OS のルーティングテーブルから機器全体のトラフィックを仮想 NIC に流すのが TUN の役割です。Clash Verge Rev などの GUI クライアントでは TUN を有効化するだけで、ブラウザと ターミナルが同じ内核のルールエンジンに乗りやすくなります。初回は管理者権限、ネットワーク拡張、あるいはヘルパーデーモンの承認を求められるため、途中で止まったように見えても実際は権限待ち、というケースに注意してください。Windows と macOS の具体的なクリック順は Clash Verge Rev の TUN モード完全ガイドに譲り、ここでは「CLI を捕捉する目的で TUN を優先する」という方針だけ強調します。
実務のコツ：TUN とシステムプロキシを二重に有効にしすぎると、ログの読み取りが難しくなることがあります。まず TUN 単体で再現操作を試し、問題が残る場合だけ環境変数補強を足すと切り分けが早いです。
分流ルール：ログで見えた名前をDOMAIN-SUFFIXに落とす
Anthropic 周辺では api.anthropic.com や claude.ai、企業・ドキュメント系の anthropic.com、認証やコンソールのための別サブドメインが混在しがちです。固定の「必須ドメイン一覧」は保守が追いつかないため、ブログ上ではログ優先を推します。接続ログに出たホストを DOMAIN-SUFFIX で拾い、宛先を実際に使っている プロキシグループ名へマッピングしてください。GEOIP だけに頼ると CDN エッジの所在地で意図と違うノードに着地することがあるため、困っているホストを個別に指定する方が CLI のタイムアウト対策として再現性が高いです。
# Example sketch: point observed Anthropic hosts to your policy group
rules:
- DOMAIN-SUFFIX,anthropic.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,claude.ai,YOUR_PROXY_GROUP
YOUR_PROXY_GROUP は購読プロファイル内の実名に置き換えてください。すでに海外向けの広いルールセットを読み込んでいる場合でも、そのルールが本当に意図したポリシー階層へ流れているかは必ずログで確認してください。名前の typo は「とにかくタイムアウトだけが続く」典型原因です。
DNSとFakeIP：ルール評価と名前解決のズレを潰す
分流が「設定したのに効かない」ように見えるとき、実際にはアプリケーションが OS リゾルバを通じて別経路の DNS を使っており、得られた 実 IP がルールの想定と食い違っていることがよくあります。Clash Meta（Mihomo）系で fake-ip を使う場合、返る仮想アドレスとルール評価の順序を意識しないと、一見ランダムな失敗が出ます。細かいパラメータは Meta コア DNS リーク防止ガイドに譲りますが、CLI タイムアウトの際は「DNS が一瞬だけ別の値を返した」のか「プロキシチェーンの途中で詰まった」のかを切り分けることが重要です。TUN と DNS ハイジャックを組み合わせるときは、他製品のフィルタや社内エージェントと競合していないかも合わせて確認してください。
環境変数とツールチェーンの補助：TUNの隙間を埋める
TUN が有効でも、まれに特定のバイナリだけが独自の証明書ストアや固定のネットワークスタックを持ち、想定外の経路へ出ることがあります。その場合は HTTPS_PROXY や ALL_PROXY をシェルプロファイルに追加し、リッスンしている mixed-port や SOCKS ポートに合わせます。社内では NO_PROXY に社内サフィックスを列挙し、不要な往復だけを直結させる運用もあります。Windows で WSL を併用するなら、別稿の WSL2 と Clash のポート連携も参照し、ホスト側 TUN とゲスト側ルールが二重にならないよう注意してください。
最短ワークフロー：ログ起点で迷わない順序
- Clash を Rule モードにし、購読とポリシー階層が読み込めているか確認する。
- 症状が出る CLI 操作を一つに絞り、実行直後の 接続ログから FQDN を控える。
- TUN を有効化し、同じ操作を繰り返してログの変化を比較する。
- 不足している
DOMAIN-SUFFIXや順序を整え、MATCH に吸い込まれる前に意図したルールへ流れるか確認する。 - DNS と FakeIP を見直し、他製品のリゾルバ干渉が無いかを切り分ける。
- 必要なら環境変数でプロキシ透過を補強し、認証と API 呼び出しをもう一度試す。
注意：利用契約・学校規程・企業ポリシーによってはプロキシや経路変更が禁止されることがあります。適用法と社内ガイドラインを確認のうえ、許可された環境でのみ設定を変更してください。
よくある質問
ブラウザの Claude は速いのに CLI だけタイムアウトするのはなぜ？
ブラウザは OS のプロキシ設定を尊重しやすい一方、CLI はデフォルトで直結する実装が多いです。TUN はここをまとめて塞ぎやすく、まず経路の非対称を疑ってください。
ルールを足しても改善しない
DNS が期待と違う値を返し、ルール評価が実際の転送経路とズレている可能性があります。FakeIP や DoH の競合、海外ポリシーとの順序をログで再確認してください。
職場の管理端末でも試せる？
MDM やゼロトラストでブロックされている場合は手順どおりに進みません。情報システムの許可範囲内で検証してください。
まとめ
Claude Code のような CLI 主体の AI 開発では、ブラウザと違ってプロキシを無視する経路が残りやすく、結果として認証や API がタイムアウトしたように見えます。Clash の TUN でターミナルも同じ分流に載せ、ログを見ながら Anthropic 系ホストを DOMAIN-SUFFIX で拾い、DNS と FakeIP の整合を取れば、再現性の高い安定運用に近づきます。手動で設定ファイルを逐一編集し、一行ミスで全体が不通になる汎用ツールより、GUI でプロファイルとルールの可視化、ノード切替、更新導線がそろったクライアントの方が詰まりどころの発見が早い場面も多いです。まだ試していない方は 無料で Clash をダウンロード し、本文の順序どおりにログを取りながら TUN と DNS を整えてください。