この記事で分かること

Claude Code がつながらない、処理が始まっても途中で止まる、または一定時間が経過すると timeout と表示される場合、Clash が起動しているだけでは通信経路が正しく整っているとは限りません。特に開発者向け CLI は、ブラウザのように OS のシステムプロキシを自動利用せず、HTTPS_PROXY などの環境変数だけを参照することがあります。そのため、ブラウザでは Claude が開けるのに、ターミナルで実行した Claude Code だけが失敗するという現象が起こります。

本稿では、2026 年時点の一般的な Clash Verge Rev と Mihomo 系コアを前提に、Claude Code の接続タイムアウトを切り分けます。Clash の動作モード、プロキシポート、ルール分流、ターミナルの環境変数、TUN の使い分けを順番に確認し、最後に curl と Clash のログで実際の通信経路を検証します。設定をむやみに変更するのではなく、どの段階で止まっているかを確認しながら進めることが目的です。

Claude Code のタイムアウトで最初に見る症状

同じ「つながらない」でも、原因の層は異なります。認証前に止まるのか、API へ接続した後に止まるのか、ストリーミング中に切れるのかを区別すると、Clash 側を調整すべきか、Claude Code 側やアカウント側を確認すべきか判断しやすくなります。

見える症状 疑うポイント 最初の確認
起動直後から接続できない ターミナルがプロキシを使っていない、または API ドメインが DIRECT に流れている env | grep -i proxy と Clash ログ
認証は進むが推論開始で停止する 認証用ホストと API ホストのルールが分かれている api.anthropic.com の接続記録
短いリクエストは成功するが長い処理で切れる ストリーミング、Keep-Alive、上流ノードの安定性 タイムアウトまでの時間とログの切断理由
ブラウザは使えるが Claude Code だけ失敗する ブラウザと CLI のプロキシ設定が別になっている シェルの環境変数とプロキシポート

なお、HTTP 401 や 403 が返っている場合は、単純なネットワークタイムアウトとは限りません。API キー、ログイン状態、利用権限、組織ポリシーなどを確認する必要があります。一方、名前解決の失敗、TLS 接続の途中停止、接続拒否、長時間待機後のタイムアウトなら、まず通信経路を調べるのが合理的です。

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

最初に Clash Verge Rev を開き、プロファイルが読み込まれていること、コアが停止していないこと、使用するプロキシグループに実際のノードが選択されていることを確認します。プロファイルをインポートしただけで、Clash のプロセスが動作しているとは限りません。画面上で「実行中」「接続済み」などの状態を確認し、テスト機能があれば選択中のノードに対して遅延測定を行います。

次に、Clash の混合ポートまたは HTTP ポートを確認します。代表的な例は 7890、SOCKS ポートは 7891 ですが、ポート番号はプロファイルやユーザー設定によって異なります。数字を推測して環境変数へ設定すると、別のアプリが使用しているポートへ接続してしまうことがあるため、Clash の設定画面に表示された値をそのまま使ってください。

モードは、まずRuleを選ぶのが無難です。Global ならほぼすべての通信を選択ノードへ送れるため検証には便利ですが、国内サービス、社内 Git、ローカルネットワークまで迂回してしまう可能性があります。Rule では対象ドメインだけをプロキシへ送れるため、Claude Code を動かしながら他の開発通信への影響を抑えられます。

TIP：検証中は、Clash のログを表示した状態で Claude Code を一度だけ実行してください。API リクエストに対応するホスト名、使用されたポリシー、DIRECT／代理の別が確認できれば、設定変更の効果を比較しやすくなります。

ターミナルへプロキシを正しく渡す

システムプロキシをオンにしても、CLI が自動的にそれを利用するとは限りません。Claude Code を起動するシェルに、Clash の混合ポートを HTTP プロキシとして渡してみます。macOS や Linux の一時的な設定例は次のとおりです。

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
export NO_PROXY=127.0.0.1,localhost,::1

Windows の PowerShell では、次のように現在のセッションへ設定できます。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"
$env:NO_PROXY="127.0.0.1,localhost"

ここで重要なのは、7890 を自分の Clash 画面に表示されたポートへ置き換えることです。設定後に同じターミナルで env | grep -i proxy、PowerShell なら Get-ChildItem Env:*proxy* を実行し、値が反映されているか確認します。IDE の統合ターミナルを使っている場合、外部ターミナルの設定ファイルを読み込まないことがあります。設定を変更した後は、ターミナルや IDE を開き直してから試してください。

NO_PROXY は慎重に設定します。localhost や 127.0.0.1 は通常そのままで構いませんが、広すぎるドメインを追加すると Claude の API 通信まで直接接続になり、原因を再び作ってしまいます。また、環境変数の大文字・小文字を両方要求する HTTP クライアントもあるため、必要に応じて http_proxy と https_proxy も同じ値に揃えます。

curl で経路を小さく検証する

Claude Code 全体を何度も実行する前に、同じターミナルから HTTPS 接続だけを確認します。-I はヘッダー取得を試みるオプション、-v は名前解決、プロキシ接続、TLS ハンドシェイクの詳細を表示するオプションです。

curl -Iv --proxy http://127.0.0.1:7890 https://api.anthropic.com/

レスポンスコードが 401 や 404 でも、Clash ログにリクエストが現れ、TLS 接続が完了しているなら、少なくともネットワーク経路は成立している可能性があります。反対に、Clash のログに何も出ない場合は、ポート番号が違う、環境変数が別のターミナルへ設定されている、または Claude Code が独自のネットワーク実装を使用していることを疑います。証明書エラーが出る場合は、企業ネットワークの TLS 検査、時刻ずれ、独自 CA、Node.js やランタイムの証明書設定も確認してください。

Claude 用ルールを確認し、DIRECT 漏れを防ぐ

Rule モードでは、api.anthropic.com が意図したプロキシグループへ送られているかを確認します。ルールの順番は重要で、対象ドメインより前に広いルールがあると、後から追加したルールへ到達しません。たとえば対象ドメインを PROXY にしたつもりでも、その上に DOMAIN-SUFFIX,anthropic.com,DIRECT のような指定があれば、Claude の通信は直接接続へ流れます。

設定例の考え方は次のようになります。実際のプロファイルでは、既存のプロキシグループ名に合わせてください。

rules:
  - DOMAIN,api.anthropic.com,PROXY
  - DOMAIN-SUFFIX,anthropic.com,PROXY

API 本体以外のホストは、最初から推測で大量に追加するのではなく、Clash のログに現れた名前を基準にします。認証や補助処理で別ホストが使われる場合、API だけを PROXY にしても「ログインはできるが処理が始まらない」「初回だけ成功して更新時に失敗する」といった分裂が起こります。逆に、すべての google.com や CDN を一括で迂回すると、不要な通信まで別経路になり、速度やプライバシーの面で管理しにくくなります。

注意：購読更新でルールが上書きされる構成では、手動編集だけに頼らないでください。設定画面の拡張ルール、覆写、またはプロファイルの管理機能を使い、更新後も api.anthropic.com のマッチ先が変わっていないか確認します。

環境変数で解決しない場合に TUN を使う

環境変数を正しく設定しても Claude Code が Clash のログに現れない場合、アプリがプロキシ環境変数を読んでいない可能性があります。Node.js、Go、Rust などで作られた CLI は実装によって対応範囲が異なり、HTTP_PROXY は読んでも SOCKS を読まない、あるいは独自の接続処理を行うことがあります。このような場合の次の候補が TUN モードです。

TUN は仮想ネットワークインターフェースを作り、アプリケーションがプロキシ設定を持っていなくても、OS の通信を Clash のコアへ取り込む方式です。Clash Verge Rev で TUN を有効にする場合は、管理者権限、ネットワーク拡張、VPN 権限などを求められることがあります。macOS ではシステム設定の承認、Windows ではドライバーや管理者権限が関係するため、表示された許可内容を確認してから有効化してください。

  1. まず Clash の Rule モード、使用ノード、DNS が正常であることを確認します。
  2. 社内 VPN、別の VPN、仮想マシンのネットワーク制御を一時的に停止し、経路の競合を減らします。
  3. Clash Verge Rev の TUN を有効にし、必要な権限を承認します。
  4. Clash ログに Claude 関連の接続が表示され、対象ルールへマッチすることを確認します。
  5. 動作確認後、社内サイトやローカル開発環境が開けるか、DNS と社内ネットワークに副作用がないかを調べます。

TUN は強力ですが、常時オンにすれば必ず最適になるわけではありません。Docker、WSL、仮想マシン、企業 VPN、ゲーム用アンチチートなどと競合することがあります。また、全通信を取り込む設定では、国内サービスや社内リソースまでプロキシへ送られる場合があります。Claude Code だけを対象にしたいなら、環境変数と Rule を優先し、TUN は「プロキシ設定を無視するプロセスを救うための切り分け手段」として利用するのが扱いやすいです。

改善しないときの確認順序

設定を変えてもタイムアウトが続く場合は、次の順番で一つずつ元に戻しながら確認します。複数の値を同時に変更すると、どの変更が効いたのか分からなくなるためです。

  • Clash のコア：停止、クラッシュ、プロファイル読み込み失敗がないかを確認します。
  • ノード：遅延だけでなく、長時間接続やストリーミングに耐えられるかを比較します。
  • ポート：Clash の現在の混合ポートと、ターミナルに設定した値が一致しているか確認します。
  • ルール：API ドメインが DIRECT、REJECT、または意図しないグループへ流れていないか確認します。
  • DNS：名前解決が別のネットワークへ漏れていないか、IPv6 経路だけが失敗していないかを見ます。
  • ランタイム：Claude Code の更新、Node.js や証明書ストア、シェルの起動設定を確認します。
  • アカウント：401、403、429 などが返る場合は、ネットワークではなく認証・権限・レート制限を調べます。

特に IPv4 では成功するのに IPv6 で待機する環境では、DNS 応答後の接続先選択が原因になることがあります。Clash の DNS 設定、TUN のスタック方式、OS の IPv6 設定を変更する前に、別のネットワークやテザリングで同じコマンドを試すと、ローカル回線固有の問題かどうかを判断できます。会社や学校のネットワークでは、プロキシや AI サービスの利用が規約で制限されている場合もあるため、管理者の案内を優先してください。

一般的な VPN アプリは、アプリ単位の除外や細かなドメインルールが分かりにくく、ブラウザ以外の CLI では環境変数との組み合わせに手間がかかることがあります。一方、Clash は Rule のマッチ結果をログで追跡し、プロキシポート、環境変数、TUN を段階的に選べるため、Claude Code のような長時間 API 通信でも「どこまで経路に乗っているか」を説明しながら調整できます。もしターミナルの接続先を自分で確認でき、端末全体への影響を抑えつつ安定化したいなら、Clash を導入してこの記事の順序で設定を検証してみてください。

Clash を無料でダウンロードして、快適なネット体験を →