Claude Codeが接続できない？Clashのタイムアウト対策

Claude Code が Clash 経由でタイムアウトする理由

Claude Code をターミナルから実行したときだけ「接続できない」「応答が返らない」「API timeout になる」という場合、Claude 側の障害だけを疑うのは早すぎます。ブラウザ版 Claude が開けていても、CLI は同じ通信経路を使うとは限りません。ブラウザは macOS や Windows のシステムプロキシを参照しやすい一方、Claude Code はシェルの環境変数、Node.js の HTTP クライアント、SSH セッション、WSL、Dev Container などの影響を受けます。

Clash の GUI でシステムプロキシを有効にしていても、ターミナルがその設定を自動的に継承するとは限りません。さらに、ANTHROPIC_BASE_URL、HTTPS_PROXY、HTTP_PROXY、ALL_PROXY、NO_PROXY などに古い値が残っていると、Clash を通る通信と直接接続の通信が混在します。その結果、ログイン画面は開くのに認証完了後で止まる、短いプロンプトは返るのに大きなコンテキストでタイムアウトする、といった分かりにくい症状になります。

Claude Code の通信は、大きく認証、モデル API、npm や更新確認、外部ツール連携の層に分けて考えると整理しやすくなります。どれか一つだけ別ルールへ落ちたり、ノード切り替えの途中で TLS セッションが切れたりすると、画面には単純な「timeout」しか表示されないことがあります。まずは「Claude Code 全体が壊れている」と決めつけず、どの段階で接続が止まっているかを分けて確認してください。

最初に確認する Clash のモードとプロキシポート

最初の確認は、Clash のモードとポート番号です。Rule モードを使っている場合、Claude Code 関連のドメインが想定したプロキシグループへ送られているかを確認します。Global モードへ一時的に切り替えて成功するなら、ノードそのものよりもルールの順序やドメイン定義に問題がある可能性が高くなります。逆に Global モードでも接続が出ない場合は、ターミナルが Clash を見ていないか、選択中のノードが利用できない可能性があります。

次に、Clash の設定画面で mixed-port または HTTP プロキシポートを確認します。一般的な設定では 7890 や 7897 が使われますが、クライアントやプロファイルによって異なります。SOCKS5 ポートだけが開いている環境で、ターミナルへ HTTP プロキシの値を設定すると失敗することがあります。反対に、SOCKS5 用のポートへ http:// を指定しても正しく動作しません。番号だけでなく、プロトコルの種類まで一致させてください。

Clash Verge、Clash Verge Rev、Mihomo Party などでは、GUI の「システムプロキシ」と「TUN モード」が別の機能として表示されます。システムプロキシは対応アプリが OS 設定を参照した場合に有効で、TUN はより低いネットワーク層で通信を捕捉します。Claude Code がシステムプロキシを継承しない環境では、TUN が有効なほうが再現性は高くなります。ただし、他の VPN やセキュリティソフトと同時に有効にすると経路が競合するため、検証時は一つずつ切り替えてください。

ターミナルの環境変数と Claude Code の接続経路をそろえる

Claude Code を実行するシェルで、プロキシ環境変数を確認します。値を表示するときは、ユーザー名やパスワード、購読 URL のトークンが含まれていないか注意してください。共有ログには秘密情報をそのまま貼らず、ホストとポートだけを残すのが安全です。

env | grep -iE 'http_proxy|https_proxy|all_proxy|no_proxy|anthropic'

たとえば Clash の mixed-port が HTTP プロキシとして動作しているなら、現在のシェルだけに次のような値を設定してテストできます。実際のポートは自分の Clash 画面に表示された番号へ置き換えてください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

SOCKS5 を使う場合は、Clash が対応している形式に合わせて socks5://127.0.0.1:7891 などを指定します。HTTP と SOCKS5 を同時に設定すると、アプリや依存ライブラリによって採用される値が変わる場合があるため、最初は一種類に統一するほうが分かりやすいです。設定後は、いったん Claude Code のプロセスを終了してから新しいシェルで起動してください。すでに起動している Node プロセスは、後から変更した環境変数を受け取りません。

NO_PROXY に広すぎる値が入っている場合も注意が必要です。*、大きなドメイン範囲、社内ネットワーク用のテンプレートが残っていると、外部 API までプロキシ除外になることがあります。逆に、ローカルの認証コールバックや localhost までプロキシへ送ると、ログイン後の戻り処理が失敗することがあります。外部 API とローカルコールバックを分けて考え、不要な古い変数は一度外してから再テストしてください。

WSL、Dev Container、リモート SSH を使う場合は、ホスト側の 127.0.0.1 がそのままゲスト側の localhost になるとは限りません。コンテナから見た localhost はコンテナ自身であり、ホスト上の Clash へ接続できない構成があります。この場合はホストの到達可能なアドレス、Docker のネットワーク設定、ファイアウォールの許可範囲を確認します。TUN がホスト側で有効でも、コンテナ内の名前解決や独自ネットワークが別経路になる点を忘れないでください。

ルール、DNS、ノードを順番に切り分ける実践手順

ここでは設定を一度に大量変更せず、観測できる差分を残しながら復旧します。まず Clash の接続ログを開き、Claude Code を起動した直後に増える接続先を記録します。実装や認証方式によってホスト名は変わるため、インターネット上の固定リストをそのまま信じるより、手元のログと公式ドキュメントを優先してください。API ホスト、認証ホスト、パッケージ配布ホストが別々のルールへ落ちていないかを見ることが重要です。

1. ブラウザや他の CLI を閉じる：同時通信を減らし、Claude Code を単独で実行します。Clash のログを消去または時間で区切り、対象通信だけを見やすくします。
2. Global モードで試す：Global モードで成功するなら、選択ノードと基本ポートは機能しています。Rule モードへ戻し、Claude 関連の接続が MATCH や DIRECT に入っていないか確認します。
3. ルールの順序を確認する：広い GEOIP、広告ブロック、地域別ルールが、Claude のドメインより上にないか確認します。Clash は通常、上から最初に一致したルールを採用するため、下部へ行を追加するだけでは効果がないことがあります。
4. ノードを一つだけ変更する：現在のノードから別の安定したノードへ切り替え、同じプロンプトを試します。複数ノードを同時に変更すると、ルール問題と品質問題を分けられません。
5. DNS を確認する：名前解決が遅い、IPv6 だけ失敗する、Fake-IP とアプリの相性が悪い場合があります。DNS 設定を変更したら、キャッシュを消去し、同じ条件で再試行します。

YAML を手動編集する場合は、まずバックアップを作成し、ルールを小さく追加します。たとえば概念上は次のように、観測した API ホストを専用グループへ送ります。実際のホスト名やグループ名は自分のログと契約環境に合わせて変更してください。

rules:
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE_STABLE
  - DOMAIN-SUFFIX,claude.ai,CLAUDE_STABLE
  - MATCH,FINAL

ここで重要なのは、存在を確認していないドメインを推測で大量追加しないことです。ルールが広すぎると、画像 CDN、分析サービス、社内リソースまで同じ出口へ送られ、かえって認証状態や速度の問題を増やします。変更後はプロファイルを再読み込みし、選択中の設定が本当にアクティブかを確認してください。購読更新でローカル追記が消えるクライアントもあるため、持続化の方法も併せて確認します。

TLS、ストリーミング、更新処理で残る問題

短い応答は成功するのに、長い回答やツール実行で止まる場合は、単純な到達性よりもストリーミング接続の安定性を疑います。長時間接続では、ノードの瞬断、アイドルタイムアウト、HTTP/2 の処理、経路途中の CDN などが影響します。Clash のログで接続が確立したあと一定時間で切れていないか、同じホストへ再接続を繰り返していないかを見ます。

TLS エラーが出る場合は、時刻のずれ、証明書検証を変更する設定、古いコア、セキュリティソフトによる HTTPS 検査を確認します。証明書検証を無効にする設定は、一時的な診断以外では推奨できません。Claude Code のトークンやソースコードを扱う環境では、通信の安全性を下げて「通ったように見せる」より、正規の証明書チェーンと信頼できるノードへ戻すことを優先してください。

npm 経由のインストールや更新だけが失敗する場合は、API 接続とパッケージ取得を別に調べます。registry.npmjs.org、GitHub、リリース CDN などが異なるルールへ入り、Claude の API は成功している可能性があります。逆に npm の設定へ古い proxy や https-proxy が残っていると、Clash の環境変数と競合します。どちらを正とするか決め、不要な古い設定を削除してから再度インストールを試してください。

よくある質問

ブラウザ版 Claude は動くのに Claude Code だけ失敗するのはなぜですか？

ブラウザが OS のシステムプロキシを利用していても、Claude Code のターミナルが同じ値を継承しているとは限りません。まず同じシェルでプロキシ環境変数と Clash の接続ログを確認し、必要なら mixed-port を明示して再起動してください。WSL やコンテナでは localhost の意味も変わります。

Global モードでは直りますが、Rule モードではタイムアウトします。

これはルール順、ドメインの不足、または誤った DIRECT 判定を示すことが多いです。Global モードで使われたノードを確認したうえで、Claude Code の実行中に表示される接続先をログから拾い、専用グループへ送るルールを MATCH より上へ置きます。

TUN を有効にすれば必ず解決しますか？

TUN はプロキシを継承しないアプリを捕捉しやすくしますが、ノード障害、DNS、ルールミス、他 VPN との競合までは解決しません。まずシステムプロキシで基本経路を確認し、それでも CLI だけが漏れる場合に TUN を追加する順番が安全です。

ノードを変えると一時的に直る場合、何を疑うべきですか？

その場合は元のノードの混雑、経路品質、TLS 相性、地域制限などが候補です。同じ設定で複数回試し、ノードごとの接続時間と切断位置を比べてください。自動選択グループが頻繁にノードを切り替えると認証セッションが不安定になることもあるため、診断中は一つのノードに固定します。

Claude Code のタイムアウト対策では、ブラウザ連携だけを簡単に扱える VPN クライアントや、CLI ごとに別のプロキシ設定を要求するツールよりも、Clash のライブ接続、ルール判定、ノード選択、TUN と環境変数を一つの画面で確認できる構成が実務的です。特に複数の CLI や開発環境を使う場合、Clash V.CORE ならプロファイルと接続ログをもとに経路を再現しやすく、今回のような「ブラウザは通るのにターミナルだけ止まる」問題も段階的に切り分けられます。別の GUI では設定場所が分散したり、クライアント更新でラベルが変わったりすることもあるため、安定したプロキシ管理環境を整えたい方は、実際の端末に合う Clash V.CORE をダウンロードして試してみてください。