Claudeに接続できないとき、最初に見るポイント
Claudeのページが開かない、ログイン画面から先へ進まない、会話の送信後にタイムアウトする——こうした症状がClashを使っているときに起きても、原因が必ずしも同じとは限りません。ノードの通信品質、Clashのルール、ブラウザーやアプリがプロキシを使っているか、DNSの応答など、複数の要素が関係します。
切り分けでは、設定を一度にいくつも変更せず、ノードの疎通 → システムプロキシ → ルールモード → DNSやTUNの順で確認するのが効率的です。たとえば、ノードを変えた直後に直るなら経路やノードの問題が疑われます。ブラウザーだけ失敗し、ほかのアプリは通信できるなら、ブラウザーのプロキシ設定や拡張機能も確認対象です。
本稿ではClash Verge RevやMihomo系クライアントを例に、Claudeへの通信がどの段階で止まるのかを調べる方法を紹介します。画面上の項目名はクライアントやバージョンによって異なりますが、確認する考え方は共通です。なお、サービス側の障害、アカウントの状態、利用地域や組織のネットワークポリシーが原因の場合もあります。Clashの設定を変える前に、別のネットワークでも同じ症状が出るかを見ておくと判断材料になります。
症状からノード・ルール・アプリを切り分ける
まず、Claudeのどの操作で失敗するのかを具体的に記録します。「接続できない」だけでは原因を絞れません。トップページは表示されるのにログインで止まるのか、会話一覧までは開くが送信だけ失敗するのか、画面全体が読み込み中のままなのかを確認しましょう。発生時刻と表示されたエラーも控えておくと、Clashの接続ログと照合しやすくなります。
- Claude以外のサイトも開けない：Clashが停止している、ノードに接続できない、またはシステムプロキシの設定が残っている可能性があります。最初にクライアントの稼働状態と選択中のノードを確認します。
- 一般のサイトは開くが、Claudeだけ失敗する：Claude関連の通信がDIRECTに振り分けられている、必要な接続先が現在のルールに含まれていない、あるいは選択中ノードからの接続が不安定な可能性があります。
- ブラウザーでは使えるがデスクトップアプリでは失敗する：アプリがOSのシステムプロキシを参照していない、別のプロキシ設定を持っている、またはアプリを起動した時点のネットワーク設定を保持していることがあります。
- ログインはできるが会話の送信が止まる：ページ表示とAPI通信で接続先が異なる場合があります。失敗した操作の直後にClashの接続ログを開き、接続先ホスト、ルール、送信先ポリシーを確認してください。
- 短時間で成功と失敗が入れ替わる：ノードの混雑、複数のプロキシアプリの競合、DNS応答の差、長時間維持された接続などが考えられます。毎回別の設定を試すのではなく、同じ操作で再現するかを見ます。
ClashのログにClaude関連の接続が現れない場合は、通信がClashを通っていない可能性があります。逆に、接続ログがあり、想定と違うポリシー名やDIRECTが表示されるなら、ルールの優先順位やモードを優先して調べます。ログに表示されたホスト名は、設定を追加する前に正確に控えてください。
最初の確認：ノードとシステムプロキシ
最初にClashのメイン画面で、コアが起動していること、プロファイルが読み込まれていること、利用するプロキシグループにノードが選択されていることを確認します。遅延テストに成功しても、実際のClaudeへの接続が保証されるわけではありません。遅延テストはテスト先への応答を示すものであり、Claude関連ホストへの到達性やサービス側の応答までは判定しないためです。
次に、ノードを一つだけ別のものに切り替え、同じブラウザー・同じ操作で再試行します。切り替えるたびに、接続ログと画面の結果をセットで記録してください。複数のノードを短時間に次々と試すと、ブラウザーの既存セッションやDNSキャッシュが残り、どの変更が効いたのか分かりにくくなります。比較するときは、同じページを再読み込みし、必要ならブラウザーを完全に終了してから起動し直します。
ノードを選択しても接続ログがDIRECTのままなら、ノードの性能より先にルールモードとルールの一致を確認します。Clash Verge Revなどでは、システムプロキシの切り替えとTUNの切り替えが別々に用意されていることがあります。システムプロキシを有効にしたつもりでも、実際には無効だったり、他のVPNやプロキシアプリが設定を書き換えていたりするケースがあります。OSのネットワーク設定で現在のプロキシ状態も確認しましょう。
問題を調べる間は、別のVPN、別のClashクライアント、ブラウザーのプロキシ拡張機能を同時に動かさないでください。複数のソフトがプロキシや仮想ネットワークを管理すると、通信経路が重なり、ログと実際の経路が一致しないように見えることがあります。確認のため一時停止したソフトは、テスト後に必要な状態へ戻してください。
手順：ルールモードでClaudeの通信を確認する
設定を変更する前に、現在のモード、選択中のノード、失敗した時刻をメモします。プロファイルを直接編集する場合は、元の内容を保存しておきましょう。購読プロファイルは更新時に手動変更が上書きされることがあるため、恒久的なルール追加が必要なら、クライアントが提供するオーバーライドやマージ設定を使えるか確認してください。
- ルールモードにする：グローバルモードではなく、ルールモードを選択します。ほかの通信を含めて全体の挙動が変わる設定は、調査の第一段階では避けます。
- システムプロキシを確認する：クライアントのシステムプロキシを有効にし、Claudeを開いて失敗する操作を一度だけ行います。利用中のOSやアプリがこの設定を参照するかも考慮してください。
- 接続ログを絞る：操作直後のログで、接続先に
claude.aiやapi.anthropic.comなどが表示されるかを探します。これらは確認の出発点であり、すべての環境で必要なホストを網羅する一覧ではありません。 - マッチしたルールを読む：ログに表示されるルール種別と送信先を確認します。意図せずDIRECTへ進んでいるなら、使用中プロファイルのルール順序やポリシーグループの割り当てを調べます。
- 小さく修正して再試行する：ログで実際に確認したホストだけを対象に、既存のルール形式に合わせて適切なプロキシグループへ送ります。設定例をそのまま貼り付けるのではなく、手元のグループ名が一致することを確認してください。
Mihomo系の設定では、たとえば次のようなドメインルールが使われます。Claudeというポリシー名は説明用の例なので、実際には設定内に存在するプロキシグループ名へ置き換えます。利用中のプロファイルが別の形式や管理方式を採用している場合は、その形式を優先してください。
rules:
- DOMAIN,claude.ai,Claude
- DOMAIN,api.anthropic.com,Claudeこの例を追加しても、他のホストやアプリ内通信まで必ず解決するわけではありません。ログに追加の接続先が現れた場合は、まずそのホストが失敗した操作と関係しているかを確認します。無関係なドメインを広くまとめてプロキシへ送ると、ほかのサービスの挙動やプライバシー、通信速度に影響することがあります。追加後はログに期待したルール名が出るか、同じ操作が成功するかの両方を確認しましょう。
ルール変更で改善しない場合は、変更を元に戻して別のノードを一つずつ試します。ルールを追加した直後に接続先が見つからなくなった場合は、YAMLのインデント、カンマ、グループ名、ルールの順番を確認してください。設定変更のたびにコアを再読み込みする必要があるクライアントもあります。
DNS・TUNを確認し、原因を再発防止につなげる
ログ上では意図したルールに一致し、選択したノードにも送られているのに接続できない場合は、DNSを確認します。DNSの問題では、画面が読み込み中のままになる、特定のホストだけ解決できない、ネットワークを切り替えた後に挙動が変わる、といった形で表れることがあります。ClashのDNS設定を変更する前に、クライアントのログに名前解決の失敗が出ているか、OS側のDNS設定や別のDNSアプリが介在していないかを見ます。
端末のDNSキャッシュやブラウザーの接続状態が残っている場合もあるため、プロファイルを変更したあとにブラウザーを再起動し、同じ条件で試してください。DNS設定を複数同時に変更すると、どの変更で改善したか判断できなくなります。まず現在の設定を記録し、変更は一項目ずつ行います。組織管理端末では、ネットワーク管理者が指定したDNSやプロキシを無断で変更しないようにしてください。
TUNは、アプリがシステムプロキシを参照しない場合などに、OSのネットワーク層で通信を扱う選択肢です。ただし、通常のシステムプロキシより影響範囲が広く、管理者権限、ネットワーク拡張、VPNや企業向けセキュリティソフトとの競合が関係します。ブラウザーのClaudeだけを確認する段階で、いきなりTUNを有効にする必要はありません。まずルールとシステムプロキシを確認し、特定アプリだけが経路を外れていると分かったときに、クライアントの説明を確認してテストします。
問題が解決したら、最終的に有効なモード、プロファイル、ノード、変更したルールを記録しておくと、次回の更新後にも比較できます。プロフィールの更新で手動ルールが消えた場合に備えて、変更をどこへ追加したかも控えてください。どのノードでも同じエラーが続き、Clashのログにも想定外の振り分けがないなら、サービス側の状態、アカウント、ブラウザーのCookieや拡張機能、管理ネットワークの制限へ調査範囲を広げます。
プロキシアプリによっては、全通信を一括で切り替えるだけで、どのホストがどの経路を通ったかを追いにくい場合があります。Clashではルールと接続ログを照合し、Claudeの通信だけを対象に原因を整理できます。ノードをやみくもに変更するより、まずログで経路を確かめたい方は、対応するClashクライアントを比較して利用環境に合うものを選んでください。