Claude Codeの通信エラーを減らすClash設定とターミナル接続ガイド

ブラウザは使えるのに Claude Code だけ通信に失敗する理由

ブラウザで Claude のページを開けても、ターミナルから実行した Claude Code が同じ通信経路を使っているとは限りません。ブラウザは OS のシステムプロキシ設定を参照することが多い一方、CLI は起動したシェルの環境変数、実行ユーザー、コンテナや SSH の有無などに左右されます。Clash の画面でシステムプロキシを有効にしただけでは、ターミナルの通信まで自動的にそのプロキシへ送られるとは限りません。

通信の失敗も、ひとまとめに「Clash がつながらない」と考えると原因を見失いやすくなります。たとえば、認証ページは開くのに CLI の認証処理が完了しない、ログイン後にモデルへのリクエストだけがタイムアウトする、応答の途中でストリームが切れる、という症状はそれぞれ確認箇所が異なります。まずは問題が発生した操作と時刻を記録し、その直後に Clash の接続ログで接続先ホスト、適用されたルール、選択されたプロキシグループを見比べてください。

なお、Clash のポート番号やプロキシグループ名はクライアントやプロファイルによって異なります。以下の例では 7890 を HTTP 混合ポートとして使いますが、実際には Clash Verge、Clash Verge Rev、Mihomo などの設定画面で有効なポートを確認し、自分の環境に合わせて置き換えてください。ネットワーク管理者がいる環境では、そのネットワークの利用ルールや Anthropic の利用条件も先に確認しましょう。

Clash のプロファイルとポートを確認する

最初に、いま有効になっているプロファイルを確認します。購読を複数登録している場合、編集した YAML と実際に読み込まれている設定が違うことがあります。クライアントのプロファイル一覧でアクティブな項目を選び、更新日時や表示されているノードが意図したものかを確かめてください。購読元の設定ファイルを直接編集すると、次回更新で変更が消える場合があります。独自ルールを加えるときは、利用中のクライアントで対応しているローカルオーバーライドやマージ機能を使うのが安全です。

次に、設定画面で HTTP ポートまたは Mixed Port の値を調べます。Mixed Port は一般に HTTP と SOCKS の両方の接続を受け付けますが、ポート番号は固定ではありません。アプリによっては 7890、7897 など異なる値が設定されているため、例をそのままコピーせず、実際に待ち受けている番号を使います。ポートを変えたあとにターミナルを開きっぱなしにしている場合は、環境変数を設定し直してから再試行してください。

ルールモードを使っている場合、接続先がどのルールに一致するかも確認します。Claude Code のモデル通信で api.anthropic.com がログに現れた場合は、まずその接続が意図したプロキシグループへ送られているかを見ます。認証やアカウント関連のホストは、契約形態やバージョン、認証フローによって異なることがあります。見慣れないホストを一括でルールに追加するのではなく、実際の接続ログと利用中の Claude Code の案内を確認してから判断してください。

ルールの順番にも注意が必要です。Clash は基本的に上からルールを評価するため、対象ドメインより先に広いルールが一致すると、後ろに書いた個別ルールは使われません。例として、観測した API ドメインを特定のグループへ割り当てる場合は、広い MATCH より前に置きます。プロファイルの更新でルールが書き換わる可能性がある場合は、変更前のコピーを保存し、再読み込み後に実際のルール表示と接続ログの両方で反映を確認しましょう。

ターミナルに HTTP プロキシを設定する

システムプロキシだけでターミナルが通信しない場合は、Claude Code を起動するシェルにプロキシ環境変数を設定します。次の例は macOS や Linux の Bash、Zsh で使う一時設定です。7890 は Clash の実際の HTTP または Mixed Port に置き換えてください。ポートを確認できたら、変数を設定した同じターミナルから Claude Code を起動します。

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
claude

PowerShell では次のように設定できます。これは現在の PowerShell ウィンドウだけに有効なため、別のターミナルを開いたときに設定が引き継がれない場合があります。まず一時設定で動作を確かめ、問題が解消したあとで、必要に応じてユーザー環境変数として保存する方法を検討してください。共有端末や会社の PC では、永続化する前に管理ポリシーを確認しましょう。

$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"
claude

変数を設定してもつながらない場合は、まず値に余計な空白や引用符が混ざっていないか、ポートが正しいかを確認します。Clash が停止している、HTTP リスナーが無効、別アプリが同じポートを使用している、といった状態では、環境変数だけを設定しても接続できません。Clash 側でポートが LISTEN 状態であることを確認したうえで、Claude Code を起動したターミナルから再テストしてください。

NO_PROXY や no_proxy に広い値が入っていると、対象ホストがプロキシを迂回することがあります。以前に設定した開発環境用の値が残っていないか調べ、必要な除外先だけを指定してください。逆に、ローカルサービスまでプロキシへ送ってしまうと、開発サーバーや社内の名前解決に影響する場合があります。変更前後の値を控えておけば、検証後に元の環境へ戻しやすくなります。

システムプロキシと TUN のどちらを使うか

システムプロキシは、アプリが OS のプロキシ設定を参照する場合に扱いやすい方式です。ブラウザと一部のデスクトップアプリだけを通したいときや、まず小さな変更で接続を確認したいときに向いています。ただし、すべての CLI が OS の設定を読むわけではありません。その場合は前節のように、起動元のシェルへ環境変数を設定する必要があります。

TUN は仮想ネットワークインターフェースを使い、環境によってはアプリごとのプロキシ設定に依存せず通信を捕捉できます。コンテナや複数の開発ツールを含めて経路をそろえたいときに便利ですが、管理者権限、OS のネットワーク拡張、DNS 設定、他の VPN との競合などを考慮しなければなりません。初めて切り分ける段階では、TUN と環境変数を同時に変更せず、一方ずつ試してどの設定が効いたかを明確にしましょう。

すでに TUN を有効にしているのにターミナル接続が不安定なときは、TUN の状態だけで解決したと判断せず、Clash の接続ログに Claude Code の通信が実際に現れるかを確認します。ログに対象ホストが出ない場合は、別のネットワーク名前空間、WSL、コンテナ、SSH 先でコマンドを実行していないかを見直してください。たとえばホスト側の Clash を有効にしても、リモートサーバー上で動く Claude Code の通信はサーバー側から出ていくため、同じ設定がそのまま適用されるとは限りません。

通信エラーを症状別に切り分ける

原因調査では、同じ操作を何度も繰り返すより、症状を小さく分けて一回ずつ試す方が効率的です。まず Clash の接続ログを消去するか、時刻を記録してから Claude Code を起動し、ログイン、モデルへの入力、応答の受信を別々に観察します。失敗したときは、エラーメッセージだけでなく、接続先ホストとその時点で選ばれたルールも控えてください。

1. Clash 自体の疎通を確認：クライアントが起動し、プロファイルが読み込まれ、選択したノードが利用可能かを確認します。ポートの設定値も、シェルに指定した値と照合します。
2. 環境変数を確認：Claude Code を起動する同じシェルで、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY の値を確認します。親ターミナルと子プロセスで環境が違う場合もあります。
3. ライブ接続を照合：ログインやモデルへの入力を一度行い、接続先が Clash に現れるか、想定したグループへ送られているかを見ます。別のグループや DIRECT に一致するなら、ルールの順番とプロファイルを再確認します。
4. エラーの種類を分ける：接続拒否や名前解決失敗はローカル設定を、TLS エラーは証明書検査や中間ネットワークを、認証エラーはアカウントやトークンを、それぞれ別に調べます。
5. 一度に一項目だけ変更：環境変数、ルール、ノード、TUN をまとめて切り替えず、変更内容と結果を記録します。成功した場合も、どの変更が効いたかを残しておくと再発時に役立ちます。

タイムアウトが続くときは、単に「速度が遅い」と結論づける前に、接続が始まらないのか、認証後に止まるのか、ストリーミングの途中で切れるのかを区別します。Clash のログで SYN 接続や TLS ハンドシェイクの段階から失敗しているなら、ポート、ノード、名前解決を優先して確認します。HTTP の応答が返っているのに認証拒否となる場合は、プロキシ経路よりもアカウントの状態、認証情報、利用可能なモデルを確認する方が適切です。

応答開始後にだけ切断される場合は、長時間接続の維持、ノードの安定性、別の VPN やセキュリティ製品による干渉を調べます。短いテストでは成功しても、長い生成で失敗することがあるため、毎回同じ入力と同じ接続条件で比較してください。複数の端末で同時に問題が起きる場合はサービス側の状態も確認し、特定の端末だけで起きるなら、その端末のシェル環境、DNS、Clash のルールに調査範囲を絞ります。

日常運用で設定を安定させる

安定した構成を保つには、接続確認に使った条件を簡潔に記録しておくことが大切です。OS とシェル、Clash クライアントとコアの種類、使用ポート、プロキシ方式、選択したグループ、エラー発生時刻を残せば、更新後に挙動が変わったとき比較できます。購読プロファイルが自動更新される構成では、更新前後のルール差分を確認し、手動の追記が失われていないかも定期的に見ましょう。

シェル設定へ環境変数を恒久的に追加する場合は、意図しないターミナルやプロジェクトにも適用されないかを考えます。まずは作業用のターミナルだけで一時設定を試し、不要になったら値を解除します。VS Code の統合ターミナル、IDE のタスク、Docker コンテナ、リモート SSH はそれぞれ別の環境として扱い、ホスト側で成功した設定が自動的に引き継がれると思い込まないことが重要です。

また、接続ログやサポート用の診断情報を共有するときは、購読 URL、認証トークン、ユーザー名、内部ホスト名などを伏せてください。問題の再現に必要なのは、通常、時刻、エラー種別、対象ホスト、使用したルールとグループです。機密情報を含む完全なログを公開する必要はありません。組織のネットワーク制限やサービス利用条件を回避するためではなく、許可された接続を安定させる目的に限って設定を調整しましょう。

最後に、別の AI コーディング CLI で成功した設定を Claude Code にそのまま流用するのは避けてください。ツールごとに認証方式、環境変数の読み取り方、接続先ホスト、長時間応答の扱いが異なるため、同じ端末でも挙動は変わります。Clash の画面だけで完結する設定ではターミナルの差を見落としやすい一方、Claude Code の環境変数だけに頼るとプロファイルやルールの誤りを見逃すことがあります。両者を一緒に確認し、CLI の接続状況を追いやすくしたい方は、Clash V.CORE の対応クライアントと設定を確認して、ダウンロードページから自分の環境に合うものを選んでください。