この記事で分かること
Clash の画面では「接続済み」なのに、Claude Code だけが接続エラーやタイムアウトになることがあります。ブラウザで Web サイトが開けても、ターミナルから起動した CLI が同じプロキシ設定を使っているとは限りません。Claude Code を実行するシェルの環境変数、Clash のルールが選んだ経路、利用中のノードは、それぞれ別に確認する必要があります。
この記事では、Clash Verge Rev など Mihomo 系クライアントを例に、まず接続エラーの種類を整理し、次にターミナルへプロキシを設定し、Clash のログで実際の経路を確かめる方法を説明します。環境変数を設定しても通信が直らない場合は、TUN モードを試す条件と注意点も確認します。クライアントや OS によってメニュー名、ポート番号、環境変数の扱いが異なるため、画面上の名称は利用中のバージョンに読み替えてください。
最初にエラーの種類と発生タイミングを確認する
設定を変更する前に、Claude Code がどの段階で止まるかを記録します。起動直後に認証画面へ進まないのか、ログイン後の質問送信で失敗するのか、応答が始まったあとに途中で切れるのかで、確認する場所が変わります。可能ならエラー文をそのまま控え、発生時刻と、同じターミナルから他の HTTPS サイトへ接続できるかも記録してください。設定を一度にいくつも変更すると、改善した原因を特定しにくくなります。
- 接続タイムアウト：ターミナルにプロキシ設定が渡っていない、対象通信が DIRECT に送られている、またはノードや上流経路が応答していない可能性があります。
- 認証やログインで失敗：API への通信とは別に、認証関連の通信が失敗していることがあります。ブラウザでログインできるかだけでは、CLI 側の経路までは判断できません。
- TLS や証明書のエラー：プロキシの経路、端末の時刻、企業ネットワーク上の TLS 検査など、複数の原因が考えられます。証明書検証を無効化して回避するのではなく、まずエラー全文と経路を確認してください。
- 一時的に成功して再び失敗：ノードの混雑、異なるターミナルが別の設定を読んでいること、古いプロセスが以前の接続を維持していることなどが考えられます。
「Clash が接続済み」という表示は、クライアントが起動し、選択したプロファイルを読み込んでいることの目安です。Claude Code のリクエストがそのプロキシを通ったことまでは保証しません。アプリの接続状態、ターミナルの設定、Clash の通信ログを分けて調べるのが、無駄な再インストールを避ける近道です。
ターミナルのプロキシ環境変数を確認する
ブラウザは OS のシステムプロキシを利用できても、CLI は別の設定を参照することがあります。Claude Code を起動したターミナルで、まずプロキシ関連の環境変数が存在するかを確認しましょう。macOS や Linux では、次のコマンドで現在のシェルに設定された値を表示できます。
env | grep -i proxy何も表示されない場合、システムプロキシを有効にしただけでは、ターミナルへ設定が渡っていない可能性があります。Clash の HTTP プロキシポートを確認してから、実際の番号に置き換えて設定します。以下の 7890 は例であり、すべてのプロファイルやクライアントで同じとは限りません。
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"ポート番号は Clash の設定画面やプロファイルにある HTTP ポート、混合ポートなどの項目と照合してください。SOCKS ポートしか利用できない構成では、プロキシの種類に合った URL が必要です。HTTP 用のポートに SOCKS の URL を指定するなど、方式とポートの組み合わせを取り違えると、環境変数が表示されていても接続は成功しません。
Windows の PowerShell では、現在のウィンドウだけに設定する場合、次のように記述できます。恒久設定にする前に、まず一時設定で動作を確かめると、以前の環境へ戻しやすくなります。
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"設定したあと、同じターミナルで環境変数を確認し、そこから Claude Code を起動してください。すでに起動していたプロセスや別のターミナルには、新しい値が反映されないことがあります。IDE 統合ターミナル、通常のターミナル、SSH セッションは別々のシェル設定を読む場合があるため、実際に Claude Code を実行する場所で確認するのが重要です。
NO_PROXY を設定している場合は、その値も見直します。この変数に広い範囲のホストやドメインを登録すると、本来プロキシへ送る通信まで除外されることがあります。原因を切り分ける間は、不要な除外設定を一時的に外し、問題が改善するか確認してください。社内サービスやローカルホストへの接続に必要な除外まで消すと別の問題が起きるため、変更前の値を保存しておきましょう。
Clash のログとルールで実際の経路を調べる
環境変数が正しく見えているのに Claude Code が失敗する場合は、Clash の接続ログを開き、失敗を再現した時刻の通信を確認します。ホスト名、接続先、マッチしたルール、選択されたポリシー、接続結果を順に見ます。Claude Code の通信では api.anthropic.com が関係することがありますが、認証や補助機能など別のホストが使われる可能性もあります。固定のドメイン一覧をそのまま入れるより、手元のログに現れたホストを基準にするほうが確実です。
- 通信がログに現れない：Claude Code が別の設定を使っている、プロキシ変数が認識されていない、またはプロセスがプロキシ設定を参照しない経路で通信している可能性があります。
- 対象ホストが DIRECT になる：現在のルールが意図したポリシーを選んでいるか確認します。プロファイルのルール順序やルールモードも見直してください。
- PROXY に送られるが失敗する：別のノードへ切り替えて再テストし、ノード側の混雑や接続状態を切り分けます。複数のノードを短時間に切り替えるより、変更を一つずつ試すほうが比較しやすくなります。
- 認証関連など別のホストが失敗する：そのホストに適用されたルールも確認します。API 本体だけを PROXY にしても、必要な関連通信が別経路なら、ログインや初期化の段階で止まることがあります。
設定変更後は、ルールを編集しただけで終わらせず、該当ルールが有効なプロファイルに適用されているか確認します。プロファイルの更新で手動変更が上書きされる構成もあるため、変更箇所と反映状態を確認してください。ルールの追加が必要な場合も、まずログ上のホスト名とルールのマッチ結果を照合し、影響する通信を必要な範囲に限定します。
curl を使う場合は、同じシェルからプロキシ経由の接続を試し、詳細出力で接続先まで進んでいるかを確認できます。API への単純なリクエストは認証情報がないため、HTTP 401 などが返ることがあります。それだけでプロキシ失敗とは判断せず、DNS 解決、接続、TLS のどの段階まで到達したかを見てください。認証情報や API キーをコマンド履歴、ログ、公開チャットへ貼り付けないように注意しましょう。
TUN モードを試すべきケースと注意点
環境変数とルールを確認しても通信がログに現れず、Claude Code がプロキシ設定を参照していない可能性が高い場合は、TUN モードを切り分け手段として試せます。TUN は OS のネットワーク経路から通信を取り込み、アプリごとのプロキシ対応に依存しにくくする機能です。Clash の画面に「接続済み」と出るだけで CLI の通信が見えないケースでは、プロセスが環境変数を無視しているのかを判断する材料になります。
ただし、TUN はターミナル専用の設定ではなく、ほかのアプリの通信経路にも影響し得ます。管理者権限や仮想ネットワークインターフェースが必要な場合があり、企業 VPN、セキュリティソフト、別のプロキシアプリと競合することもあります。利用中のネットワークや組織のポリシーを確認し、必要な許可がない端末では有効にしないでください。DNS の設定やローカルネットワークへの経路が変わることもあるため、開始前に現在の状態を控えておきます。
試すときは、まず既存の VPN や別のトンネル機能を停止できるか確認し、Clash の TUN を有効にしてから Claude Code を再起動します。Clash のログに通信が現れるようになり、同じノードで接続できるなら、アプリが通常のプロキシ設定を使っていなかった可能性があります。改善しない場合は TUN を無効に戻し、ルール、ノード、DNS、上流ネットワークを改めて切り分けてください。TUN を常時有効にすることが唯一の解決策とは限りません。
よくある質問
ブラウザは使えるのに Claude Code だけ失敗するのはなぜですか？
ブラウザと CLI が異なるプロキシ設定を参照している可能性があります。ブラウザが OS のシステムプロキシを使う一方で、ターミナルの Claude Code には HTTP_PROXY や HTTPS_PROXY が渡っていないケースがあります。実際に Claude Code を起動するシェルで環境変数を確認し、Clash のログに対象通信が現れるかを見てください。
プロキシのポート番号は 7890 にすればよいですか？
7890 は説明用の例で、利用中の Clash 設定と一致するとは限りません。クライアントのポート設定やプロファイルを確認し、HTTP、混合、SOCKS のどのポートを使うかを合わせます。ポートだけでなく、環境変数に指定した URL の方式も対応させてください。
テストで 401 が返った場合も接続失敗ですか？
必ずしもそうではありません。認証情報なしのリクエストに対して 401 が返る場合、サーバーまで到達して応答を受け取れていることがあります。接続タイムアウトや TLS エラーとは分けて考え、ログと詳細出力で通信がどこまで進んだかを確認してください。API キーなどの秘密情報をテスト用のコマンドへ不用意に含めないことも大切です。
最初から TUN を有効にしてもよいですか？
まずはターミナルの環境変数と Clash のルールを確認し、それでも通信がプロキシへ届かない場合に TUN を試すのが安全です。TUN は他アプリや VPN に影響することがあるため、組織管理端末では管理者のポリシーを優先してください。テスト後は必要性を判断し、使わない場合は無効に戻します。
ほかの CLI 用プロキシ設定はシェルやアプリごとに手作業が増え、どの経路を使っているか分かりにくくなることがあります。一方、Clash はターミナルの環境変数とルールをログで照合でき、ノード切り替えや TUN の適用も段階的に試せます。Claude Code の通信だけが不安定なときも、原因を環境・ルール・ノードに分けて確認しやすくなります。各 OS のクライアントを比較したい場合は、利用環境に合うものをダウンロードページで確認してください。