2026 年版：Claude Code のタイムアウトを Clash で切る——Anthropic API と端末プロキシの分流実務

なぜ Claude Code だけ「いつまでも待つ」のか

2026 年、ターミナルやエディタから動かす AI コーディング支援のなかで Claude Code に注目が集まっています。一方で相談板やコミュニティでは、「ブラウザで Claude の画面は開けるのに、Claude Code だけが長く待って失敗する」「Anthropic API への最初のハンドシェイクで止まる」といった報告も珍しくありません。原因の多くは単一ノードの「弱さ」だけではなく、ターミナル プロキシがブラウザと別経路のまま残っていること、そして Clash の分流ルールやDNSが、その別経路と整合していないことにあります。

本稿は、既存の ChatGPT／Claude 一般向け分流や Cursor IDE 向け分流と役割を分け、CLI 中心の Claude Code から見た接続の切り分けに焦点を当てます。ホスト名はサービス側のアップデートで増減し得るため、最終判断は必ず公式のネットワーク案内と、ご自身の環境で Clash が記録した実ホストを優先してください。勤務先のセキュリティ方針や利用規約に反しない範囲での利用が前提です。

注意：本稿は設定の出発点であり、Anthropic の利用規約、API キーの取り扱い、企業プロキシや SSL インスペクションのポリシーを代替するものではありません。社内ガイドが先にある場合はそちらを優先してください。

ChatGPT／Claude 一般記事・Cursor 記事との違い

ChatGPT／Claude 向けの記事では、ブラウザやデスクトップアプリから anthropic.com や claude.ai に届く経路を主に扱いました。Cursor 向けは cursor.sh などエディタ固有のドメイン束が主役です。これに対し Claude Code は、多くの場合 Node.js ランタイム上で動き、Anthropic API（代表例として api.anthropic.com）へ何度も往復します。したがって「ブラウザ用ルールだけ整備しても CLI が抜ける」「システムプロキシは有効なのにターミナルだけ別ルート」というギャップが前面に出やすいのが特徴です。

さらに OpenRouter 経由でモデルを選ぶ構成や、社内ミラーの npm レジストリだけ通して本体取得は成功するが API だけ失敗する、といったパターンでは、分流の対象ドメインが「チャット UI」とはズレます。ここではまず Anthropic 直結の経路を安定させ、そのうえで補助的な依存（パッケージ取得や Git ホスト）をログに沿って足す流れが扱いやすいです。

Anthropic 側でよく登場するホストの束ね方

公式ドキュメントやコミュニティのトラブルシュートでは、少なくとも api.anthropic.com への HTTPS、anthropic.com 本体や claude.ai 周辺、ログインやコンソール用途で console.anthropic.com が挙がることがあります。静的アセットや計測、フィーチャーフラグ系で追加のサブドメインが混ざるケースもあるため、実際にClaude Codeを動かした数分間の接続一覧を保存してから DOMAIN-SUFFIX を決めると安全です。

Clash／Mihomo では、初期のたたき台として DOMAIN-SUFFIX,anthropic.com を専用グループへ載せる構成がよく使われます。ただしサフィックスを広げすぎると、不要なトラフィックまで同じ出口に乗り、遅延診断が曖昧になることがあります。運用初期は「接続ログに現れた名前をルールへ追記する」サイクルのほうが、意図しないサービスを巻き込みにくいです。

プロキシグループの切り方（API 重視）

実務では CLAUDE_API のようなラベルで、ストリーミングや長めのリクエストに強いノードを集めたグループを用意し、一般ブラウジングや巨大 RULE-SET のデフォルト出口とは分けると切り分けが楽になります。url-test で定期遅延テストする運用にすると、出口の劣化に気づきやすくなります。ノードの географ だけを切り替えて A/B するのも、単一障害点の切り分けとして有効です。

企業プロキシや中継装置が HTTP/2 のサーバー推送やストリームをバッファリングし、CLI からの長めの応答だけ遅延する事例は他製品でも報告されています。経路として「透過的な TLS」と「互換モード／HTTP/1.1 フォールバック」が選べる場合は、社内規程の範囲で試す価値があります。

ルール評価順：巨大 RULE-SET に埋もれない

分流ルールは YAML 上では上から順に評価され、最初の一致で終わります。ファイル末尾に DOMAIN-SUFFIX,anthropic.com,CLAUDE_API を追記したつもりが、上段の GEOIP やサードパーティの RULE-SET に先に飲み込まれている——というのは典型的なミスです。設計の共通枠組みは ルール分岐の詳解ガイドと同じく、具体的な DOMAIN 行を締めの行より上へ置くことです。GUI で追加するときは、挿入位置が先頭か末尾かで結果が変わる点に注意してください。

YAML の骨格例（サンプル）

キーやインデントは利用中のコアと GUI のスキーマに合わせてください。ここでは概念だけ示します。

proxy-groups:
  - name: CLAUDE_API
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇯🇵 低遅延
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,api.anthropic.com,CLAUDE_API
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE_API
  - DOMAIN-SUFFIX,claude.ai,CLAUDE_API

実際にはコンソールや CDN 名がログに出たら行を足します。逆に「全部 PROXY に投げる」だけの単純化は、別ホストまで同じ遅いノードに載せて症状を悪化させることがあるため、ログを見ながら調整してください。

ターミナル プロキシ：環境変数が効く理由

多くの OS でブラウザは「システムプロキシ設定」を参照しますが、Unix 系シェルで動く Claude Code は、起動したプロセスが HTTP_PROXY／HTTPS_PROXY／ALL_PROXY などを読むかどうかに依存します。Clash Verge 系で システムプロキシをオンにしても、ターミナルに変数が注入されていなければ、Node はプロキシを知らないまま直結を試み、タイムアウトや意図しない経路が再現します。

対策の基本は、(1) Clash の mixed ポート（例: 7890）を http://127.0.0.1:7890 形式で HTTPS_PROXY に設定する、(2) ローカルホストや社内イントラを誤ってプロキシに送らないよう NO_PROXY を整える、(3) 設定を書いたあとそのシェルから Claude Code を起動し直す、の三点です。シェル設定ファイル（.zshrc など）へ恒久的に書くか、セッション単位で export するかは運用に合わせてください。

ヒント：同じマシンで curl -I https://api.anthropic.com が通るかを、プロキシ有り／無しで比較すると、CLI 側の経路ズレを短時間で可視化できます。証明書エラーが出る場合は社内インスペクションの影響も疑ってください。

TUN とシステムプロキシ：どちらを優先するか

TUN モードは OS より下のレイヤでトラフィックを取り込み、プロセスごとの環境変数差をまとめやすい反面、ルーティングや他 VPN との併用で競合が出やすいです。一方 システムプロキシ＋環境変数は、アプリごとの挙動差が残ります。ブラウザだけ直すのか、CLI まで含めて揃えるのかで最適解が変わります。細部は TUN モード完全ガイドや、ブラウザ限定と全体代理の整理として グローバルモードとブラウザのみの記事を併読すると理解が早いです。

Windows では WSL とホスト側でプロキシの見え方がズレる例、macOS ではターミナル起動元（ターミナルアプリ／IDE 統合）で環境変数が引き継がれない例があります。症状が「IDE 内だけ」「WSL 内だけ」に閉じるときは、そのコンテキストに変数を足す必要があります。

DNS・Fake-IP：名前解決をルールと矛盾させない

DNS が Clash の想定とズレていると、YAML のドメイン行は正しそうでも実接続は別経路に落ちます。ブラウザだけ Secure DNS、CLI は OS のリゾルバ——といった二重構成は開発者端末で珍しくありません。Fake-IP を使うプロファイルでは、ドメインルールと IP ルールの境界が頭の中で一本化されていないと、「ダッシュボード上はマッチしたのに体感が違う」状態になりやすいです。

構成変更のあとは OS の DNS キャッシュのクリアと、Claude Code プロセスの再起動をセットで行うと、再現率が下がることが多いです。購読の geosite／geoip を更新する手順は 手動更新ガイドも参照してください。

実務フロー（接続一覧を味方にする）

  1. Claude Code を通常利用し、Anthropic API 呼び出しが発生したタイミングで Clash の接続ログを開き、実際に出たホスト名をメモする。
  2. CLAUDE_API など用途別の proxy-groups を定義し、上記ホストを DOMAIN／DOMAIN-SUFFIX 行で、そのグループへ必ず流れる位置に書く。
  3. ターミナルに HTTPS_PROXY=http://127.0.0.1:7890（実際の mixed ポート番号に置換）を設定し、同一シェルで Claude Code を起動して再試行する。混在経路を直したいときは TUN も検討する。
  4. 依然としてタイムアウトする場合は、ノード地域の A/B、HTTP/2 経路、社内プロキシの例外リストを順に疑う。
  5. 落ち着いたらルールをコメント付きで整理し、将来の自分・チームが読める形に残す。

よくある質問

ブラウザは通るのに Claude Code だけ失敗する

上記のとおり、ブラウザと ターミナル プロキシの前提がズレているケースが最多です。環境変数と 分流ルールの両方を点検してください。

ルールを足したのに挙動が変わらない

評価順序かDNSです。外部 RULE-SET より上に具体的な行があるか、Fake-IP とリゾルバが矛盾していないかを確認します。

npm install は成功するのに実行時だけ API が落ちる

パッケージレジストリと Anthropic API は別ホストです。レジストリ用のルールだけ整っていても、api.anthropic.com 行が欠けていると再現します。

まとめ

2026 年の AI コーディング環境では、Claude Code のような CLI ツールが Anthropic API へ頻繁に接続する一方で、ブラウザ向けの設定だけでは端末代理が空振りしやすいのが現実です。Clash で 分流ルールを書き、HTTP_PROXY 系の環境変数と TUN／システムプロキシの役割分解、DNS とルール順をセットで揃えると、「ログでは届いていそうなのに待ち続ける」症状の切り分けがかなり速くなります。

ところで、汎用 VPN や単一ボタンの「常時プロキシ」系ツールは手軽ですが、IDE・CLI・ブラウザごとに別ホストへ大量並列するトラフィックを、用途別の出口へ振り分ける細かさには欠けがちです。設定がブラックボックスになり、タイムアウト時に「どのドメインがどこへ出たか」を自分で説明しにくいこともあります。ClashSource は Clash／Mihomo 系クライアントの入手とドキュメントを一か所に揃え、ルールとログを読みながらチューニングできる流れを重視しています。チームや個人で、ターミナルからの AI 利用を安定させたい場合は、手順を追いやすい ダウンロードページから環境に合うクライアントを選び、本文のチェックリストと合わせて試してみてください。