Claude CodeをClashで使う設定ガイド｜CLI接続を安定化
2026年現在、DeepSeek は世界中で最も注目される AI モデルの一つとなりました。しかし、その急速な普及に伴い、ユーザーは頻繁に「接続タイムアウト」や「サーバー応答なし」といった問題に直面しています。特にプロキシツール Clash を使用している環境では、誤ったルーティング設定や DNS の不一致が原因でアクセスが遮断されることが少なくありません。本記事では、DeepSeek のアクセス障害を根本から解決するための Clash 設定術を徹底解説します。
Claude CodeのCLI接続にClashを使う理由
Claude Codeは、ターミナルからファイルを読み取り、コードを作成・修正し、テストやレビューまで進められる開発ツールです。ブラウザだけで使うサービスとは異なり、ログイン、モデルへのリクエスト、更新確認、補助的な認証通信などがCLIから発生します。そのため、ブラウザでは正常に接続できるのに、Claude Codeだけがタイムアウトする、認証画面を開けない、モデル呼び出しが途中で止まるという問題が起こることがあります。
Clashを組み合わせると、ターミナルの通信を指定したプロキシ経由に固定しながら、通常の国内サイトや社内ネットワークは直接接続に戻す構成を作れます。すべての通信を無条件に遠回りさせるのではなく、必要なドメインだけをルールで選択できる点が大きな利点です。開発者にとっては、接続経路を変更したあともGit、パッケージレジストリ、社内サーバーへのアクセスを個別に調整しやすくなります。
ただし、Clashの画面で「システムプロキシ」を有効にしただけでは、すべてのCLIアプリが自動的にプロキシを使うとは限りません。ターミナルプログラムの多くは、OSのプロキシ設定ではなく、HTTP_PROXY、HTTPS_PROXY、またはアプリ固有の環境変数を参照します。まずこの違いを理解しておくと、原因不明の接続エラーを効率よく切り分けられます。
Clash側で先に確認する設定
Claude Codeを設定する前に、Clashクライアント自体が正常に動作しているかを確認します。WindowsではClash Verge Rev、macOSではClash Verge RevやClashX系、LinuxではMihomoを利用する構成が一般的です。画面の名称はクライアントごとに異なりますが、必要な項目はほぼ共通しています。
事前チェック：次の項目を上から順番に確認してください。
- 有効なプロファイルが読み込まれており、ノード一覧が表示されている。
- プロキシグループで、実際に利用できるノードが選択されている。
- Clashの混合ポート、通常は
7890や7897が待ち受け状態になっている。 - モードが一時的な確認に適した
Global、またはルール分岐を使うRuleになっている。 - Clashの接続ログに、リクエストが表示される。
最初のテストでは、原因を単純化するために一時的にGlobalモードを選ぶ方法が便利です。GlobalモードでClaude Codeが動き、Ruleモードで失敗する場合は、ノードそのものではなく、ルールの順序やドメイン分類が原因である可能性が高くなります。動作確認が終わったら、普段の利用ではRuleモードに戻し、必要な通信だけをプロキシへ送る構成に調整します。
また、Clashのポート番号は必ず自分のクライアント画面で確認してください。クライアントによって既定値が異なるほか、混合ポートではHTTPとSOCKSの両方を受け付けても、HTTPプロキシとして環境変数に指定する場合はURL形式を正しく書く必要があります。
ターミナルにClashのプロキシを適用する
Claude CodeのCLI通信を安定させる基本は、ターミナルのプロセスにClashのプロキシ情報を渡すことです。macOSやLinuxでは、現在のシェルで次のように設定できます。ポート番号は自分のClashクライアントに合わせて変更してください。
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890すべてのアプリがALL_PROXYを解釈するとは限らないため、まずはHTTP_PROXYとHTTPS_PROXYを設定する方法が無難です。大文字の変数を読まないプログラムに備え、必要であれば小文字の変数も同じ値にします。
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"この設定は、そのターミナルウィンドウを閉じると失われます。毎回設定するのが面倒な場合は、zshなら~/.zshrc、bashなら~/.bashrcに追加し、保存後にsource ~/.zshrcまたは該当する読み込みコマンドを実行します。ただし、会社のネットワークや共有端末では、プロキシ設定を常時有効にするとGitや社内サービスまで意図せず経由することがあります。最初は一時設定で動作を確認し、適用範囲を決めてから永続化してください。
Windows PowerShellでは、次のように現在のセッションだけへ設定できます。
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7890"GitHub Enterprise、社内Git、ローカル開発サーバーなどをプロキシから除外したい場合は、NO_PROXYを利用します。除外対象は環境に合わせて追加してください。
export NO_PROXY=localhost,127.0.0.1,::1,.example.local注意
プロキシURLに認証情報を含めたり、設定をそのまま公開リポジトリへ保存したりしないでください。また、APIキーをシェル履歴、スクリーンショット、デバッグログに残さないようにします。キーが表示された可能性がある場合は、サービス側で速やかに無効化して再発行してください。
Claude Codeの認証と接続を設定する手順
Clashの接続が確認できたら、Claude Codeを起動します。利用形態によって、ブラウザを使ったログイン方式とAPIキーを使う方式が分かれます。組織の契約や管理ポリシーがある場合は、まず管理者が指定する認証方法を優先してください。非公式の中継サービスや出所の不明なAPIエンドポイントを設定すると、認証情報やソースコードを第三者へ送信する危険があります。
- Clashを起動し、利用するプロファイルとノードを選択します。
- ターミナルでプロキシ環境変数を設定し、Claude Codeを起動します。
- ログインを求められたら、表示された認証手順に従ってブラウザで認証します。
- 認証後、プロジェクトディレクトリへ移動し、簡単なコード確認やテスト実行を依頼します。
- Clashの接続ログで、リクエストがプロキシ経由になっているか、失敗していないかを確認します。
APIキーを利用する環境では、キーをコマンドラインの引数に直接書くより、公式ドキュメントで案内されている環境変数や認証保存方法を使うほうが安全です。シェルの履歴に秘密情報が残ると、同じPCを使う別ユーザーやバックアップ環境から漏れる可能性があります。CI環境で使用する場合も、リポジトリの設定ファイルではなく、CIサービスの暗号化されたSecret機能を利用してください。
| 症状 | 確認する場所 | 考えられる原因 |
|---|---|---|
| ログイン画面が開かない | Clashログ、ブラウザ | CLIだけプロキシ未設定、認証ドメインのルール不足 |
| モデル呼び出しがタイムアウトする | 接続ログ、ノード遅延 | ノードの不安定、HTTPS_PROXYのポート間違い |
| Gitや社内サイトまで遅くなる | Rule設定、NO_PROXY | Globalモード、または除外ルールの不足 |
| 認証後もCLIが未ログインになる | 使用中のシェル、認証保存先 | 別ユーザーで実行、権限やホームディレクトリの違い |
接続テストでは、いきなり大きなリポジトリの解析を依頼せず、短いリクエストから始めます。最初にバージョン表示、次に小さなファイルの説明、その後にテスト実行という順番にすると、認証、API通信、ローカルファイル操作のどこで失敗したかを分けて確認できます。
Ruleモード、TUNモード、DNSの使い分け
CLIを常時使う場合、プロキシ環境変数だけで運用するか、ClashのTUNモードで端末の通信をまとめて捕捉するかを選びます。環境変数方式は影響範囲が明確で、開発プロジェクトごとにオン・オフしやすい点が魅力です。一方、アプリが独自のネットワークライブラリを使い、環境変数を参照しない場合には通信が直送されることがあります。
TUNモードは、環境変数に対応していないアプリも含めてOSレベルで通信をClashへ渡しやすい方式です。ただし、管理者権限、仮想ネットワークアダプター、他のVPNとの競合が関係するため、設定を有効にした直後はルーティングを慎重に確認してください。Docker、WSL、仮想マシン、企業VPNを同時に使用している場合は、TUNの導入によって経路が変わることがあります。
Ruleモードでは、認証やモデル通信に必要なドメインが誤ってDIRECTへ送られないこと、逆にローカル開発環境がプロキシへ流れないことが重要です。サブスクリプションが提供するルールをそのまま使う場合でも、最終的なMATCHの出口を確認してください。Clashの接続ログは、実際にどのルールとポリシーグループが選ばれたかを調べる最も有効な手がかりです。
切り分けのコツ
まずGlobalモードとプロキシ環境変数の組み合わせで最小構成を作り、Claude Codeが動くことを確認します。次にRuleモードへ戻し、失敗した通信のドメインとルールを比較します。最後にNO_PROXY、TUN、DNS設定を一つずつ追加すれば、複数の設定を同時に変更して原因が分からなくなる事態を避けられます。
DNSについても、CLIの名前解決がClashを迂回していないか確認します。特にTUNを使う場合、OS、ブラウザ、Clash内蔵DNSが別々の経路を持つと、同じドメインでも結果が一致しないことがあります。fake-ipでローカルサービスが使えなくなった場合は、ローカルドメインやプライベートアドレスをfake-ipの除外対象にする、または一時的にredir-hostへ切り替えて挙動を比較すると判断しやすくなります。
接続できないときの実践的な確認順
Claude Codeのエラーだけを見ていると、認証、プロキシ、DNS、ノード障害を混同しがちです。次の順序で確認すると、不要な再インストールを避けられます。
- Clashのコアが稼働しているかを確認し、ノードの遅延テストと接続ログを見ます。
- ターミナルで環境変数を表示し、ポート番号やプロトコルの誤りがないか確認します。秘密情報を含む変数は画面へ出力しないでください。
- 別のHTTPSサイトやパッケージレジストリへアクセスし、CLI全体がプロキシを使えるか試します。
- Globalモードで再試行し、成功するならRuleのマッチ順と最終出口を調べます。
- 同じノードに接続が集中していないか確認し、別ノードで比較します。
- TUN、企業VPN、Docker、セキュリティソフトのネットワーク保護を一時的に切り分けます。
「接続が拒否された」というエラーならローカルポートやClashの待ち受けを、「名前解決に失敗した」ならDNSとルールを、「TLS handshake」や証明書関連のエラーなら時刻、証明書検証、プロキシ経路を優先して調べます。システム時刻が大きくずれているとHTTPS認証に失敗するため、OSの日時も確認してください。証明書検証を無効化する設定は安全性を下げるので、恒久的な対策として使うべきではありません。
設定を変更したあとは、ターミナルを再起動して環境変数を読み直し、Clashのログを一度クリアしてから再現テストを行います。ログに機密性の高いURLやトークンが含まれる場合は、共有前に必ずマスクしてください。問題が解決したら、成功したノード、モード、ポート、除外設定を簡単に記録しておくと、ネットワークを変えたときの復旧が速くなります。
ブラウザ拡張だけでプロキシを切り替える方法は導入が簡単な反面、ターミナルやバックグラウンドプロセスには適用されず、アプリごとに設定を繰り返す必要があります。また、単純な全体VPN方式では、社内Gitやローカル開発環境まで遠回りして速度低下やアクセス制限が発生することがあります。Clashなら、HTTP・SOCKS・TUNを環境に合わせて選び、RuleとNO_PROXYでClaude Codeの通信だけを安定した出口へ送る設計が可能です。CLIの接続状況をログで確認しながら細かく調整したい方は、Clashを無料でダウンロードして、現在の開発環境で試してみてください。