最初に確認：ターミナルの通信はClashに届いているか
ブラウザーでは接続できるのにClaude Codeだけがタイムアウトする場合、すぐにノード障害と判断せず、通信がどこを通っているかを確認しましょう。macOSのシステムプロキシを有効にしても、ターミナルで起動したコマンドがその設定を自動的に使うとは限りません。ターミナルアプリやCLIがシステム設定を参照せず、独自のプロキシ設定や環境変数を使うことがあるためです。
通信の経路は、概ね「Claude Code → ターミナルの環境変数またはシステムプロキシ → Clashのローカルポート → Clashのルールとプロキシグループ → 接続先」という順に整理できます。どの段階で失敗しているかを分けると、ルールを変更するべきか、ポートやDNSを確認するべきか判断しやすくなります。
- ブラウザーもClaude Codeも接続できない：Clashの稼働状態、選択中のノード、プロキシグループ、接続先サービスの利用状況を確認します。
- ブラウザーは接続できるがCLIは失敗する：ターミナルのプロキシ環境変数と、Claude Codeを起動したプロセスがその設定を引き継いでいるかを確認します。
- Clashの接続一覧にリクエストが出ない：CLIがローカルプロキシを使っていない、設定したポートが違う、または名前解決や接続がClashより前の段階で止まっている可能性があります。
- 接続一覧に記録があり、失敗ログも出る：適用ルール、出力先、DNSの結果、接続エラーの内容を確認します。
ターミナルにClashのローカルプロキシを指定する
Clashクライアントの設定画面で、HTTPプロキシまたは混合ポートの待ち受けアドレスと番号を確認します。以下では例として 127.0.0.1:7890 を使います。実際のポートが異なる場合は、必ずクライアントに表示されている値に置き換えてください。SOCKS専用ポートをHTTPプロキシのポートとして指定するのは避けます。
macOSやLinuxのzsh、bashでは、Claude Codeを起動するターミナルで次のように環境変数を設定します。HTTPS接続でも、HTTPプロキシ方式で接続する場合のURLスキームは http:// です。これは接続先がHTTPSであることと、ローカルプロキシへの接続方式が別の設定であるためです。
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1
claudeこれらの設定は、そのシェルから起動するプロセスに引き継がれます。ターミナルを閉じると設定が消える一時的な確認には適しています。毎回設定したい場合は、利用中のシェルに応じて ~/.zshrc または ~/.bashrc などへ追加し、設定ファイルを再読み込みするか、新しいターミナルを開きます。共有端末では、プロキシの認証情報を含む設定を不用意に保存しないでください。
WindowsのPowerShellでは、同じポートを例に次のように設定できます。値は現在のPowerShellセッションだけに適用されます。
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
claudeHTTP_PROXYやHTTPS_PROXYなどの環境変数への対応は、CLIや依存ライブラリのバージョン、起動方法によって異なることがあります。設定したのに通信が変わらない場合は、まず同じターミナルでプロキシを指定した疎通確認を行い、次にClaude Codeの実行ログと、そのバージョンの設定方法を確認してください。画面から起動したターミナルと、別のアプリから起動したプロセスでは、環境変数の引き継ぎ方が異なることもあります。
ローカルポートとHTTPS接続を別々に試す
macOSやLinuxでは、次のコマンドでローカルのHTTPプロキシを通した接続を確認できます。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://api.anthropic.com/接続先がエラーのHTTPステータスを返しても、DNS解決、プロキシ接続、TLS通信の一部が成立している場合があります。ここではClaude Codeの認証やAPI処理が成功したかではなく、指定した経路で接続できるかを調べています。タイムアウトする場合は、Clashのポート番号、クライアントの稼働状態、選択中の出力先を順に確認します。
Clashのモード・ルール・ノードを確認する
ターミナルがClashのポートへ接続できても、接続先への経路が正しいとは限りません。ルールモードでは、接続先のドメインなどに一致したルールが指定するDIRECTまたはプロキシグループへ通信が渡ります。グローバルモードは通常、選択中のグローバルグループに通信を渡しますが、そのグループでDIRECTが選ばれていれば直接接続になります。モード名だけで通信経路を判断せず、実際の接続記録を確認してください。
- Clashのプロキシ画面で、意図したモードとプロキシグループを選びます。自動選択グループの場合は、実際に選択されたメンバーも確認します。
- Claude Codeから接続を試し、Clashの「Connections」または「接続」画面でリクエストが記録されるか確認します。
- 記録された接続先、適用ルール、ポリシー、出力先を確認します。意図しないDIRECTや別のグループに進んでいる場合は、設定のルール順と対象ドメインを見直します。
- Clashのログで、名前解決失敗、接続タイムアウト、TLS関連のエラーなど、失敗した段階を確認します。ログにトークンや認証情報が含まれる可能性があるため、共有前に必ず伏せてください。
接続先ドメインをルールで分ける場合は、まず接続一覧に実際に現れたドメインを確認し、必要な範囲だけを設定します。サービスの構成や認証経路は変更されることがあるため、推測したドメインを一括で登録したり、無関係な通信まで広くプロキシへ送ったりするのは避けましょう。既存のプロファイルを編集する場合は、サブスクリプション更新で変更が上書きされないかも確認します。
| 見える状態 | 優先して確認する項目 | 次の操作 |
|---|---|---|
| Clashに接続記録がない | 環境変数、ポート番号、Claude Codeの起動元 | 同じターミナルでcurlを実行し、ローカルポートへの接続を確認 |
| DIRECTとして記録される | 適用ルール、ルールの順序、現在のモード | 対象ドメインに一致するルールとポリシーを確認 |
| プロキシ経由だがタイムアウトする | 選択中のノード、ノードの到達性、ログのエラー | 別の利用可能なノードで同じ接続先を再確認 |
| HTTP応答はあるが認証で失敗する | アカウント、ログイン状態、サービスの利用条件 | ネットワークと分けて認証・アカウント状態を確認 |
ノードの遅延テストに成功しても、Claude Codeの接続先まで問題なく到達できるとは限りません。遅延テストは指定URLへの軽量な通信を測るもので、別のドメイン、認証、長時間の通信まで保証するものではありません。複数ノードで同じ失敗が起きる場合は、ノードを次々に変更する前に、Clashの接続記録とターミナル側のプロキシ設定を切り分けます。
DNSとTUNの重複を見直し、原因を絞り込む
プロキシ指定後も接続に失敗する場合は、DNSの結果と、どの段階で名前解決が行われるかを確認します。アプリやライブラリによって、ドメイン名をローカルで解決してからプロキシへ渡す場合と、プロキシ側に名前解決を任せる場合があります。ClashのDNS設定、プロファイルのルール、ノードの種類、CLIの実装によって経路が変わるため、「ブラウザーで解決できる」ことだけではターミナル側のDNSが正常とは限りません。
Clashのログに名前解決エラーがある場合は、まずログに示されたドメイン、使用されたDNS、タイムアウトの有無を確認します。DNS設定を変更すると他のアプリやローカルネットワークにも影響するため、複数の項目を同時に変えないでください。一つだけ変更して再接続し、結果を比較すると原因を追いやすくなります。
TUNモードは、システムプロキシや環境変数を参照しないアプリの通信を取り込む選択肢です。ただし、TUNを有効にしただけでClaude Codeのすべての通信が望ましいノードに送られるわけではありません。ルール、DNS、権限、ルート設定が引き続き関係します。最初の切り分けでは、ターミナルの環境変数による明示的なプロキシ指定を試し、それで通信がClashに記録されるか確認してから、TUNの必要性を判断すると整理しやすくなります。
- ブラウザーは接続できるがcurlは失敗する：curlに指定したポートとプロキシ方式を確認し、Clashの接続一覧にリクエストが出るか調べます。
- curlは接続できるがClaude Codeは失敗する：同じターミナルから起動しているか、環境変数が引き継がれているか、CLIのバージョンがプロキシ設定に対応しているかを確認します。
- 接続先は記録されるがTLSエラーになる：システム時刻、証明書関連のエラー、ネットワーク上のTLS検査や中間装置の有無を確認します。証明書検証を無効にして回避する設定は使わないでください。
- 設定変更後に接続が二重に見える：システムプロキシ、環境変数、TUN、ほかのVPNやプロキシツールが同時に経路を変更していないか確認します。