Claudeに接続できない？Clashで直すタイムアウト対策ガイド

Claudeに接続できないときに最初に確認すること

Clashを有効にしているのにClaudeの画面が開かない、ログイン後に読み込みが終わらない、メッセージ送信時だけタイムアウトするという場合、原因はノードそのものとは限りません。Clashでは、クライアントの動作モード、ルールのマッチ順、DNSの解決経路、TUNの取り込み状態、選択したノードの品質が連動しています。どれか1つが適切でないだけでも、一般的なウェブサイトは表示できるのに特定のサービスだけ接続できない状態になります。

まず、ブラウザで複数の通常サイトを開き、Clashのプロキシ経由で通信できているか確認します。すべてのサイトが開かないなら、サブスクリプション、プロキシグループ、システムプロキシ、ノード接続を先に確認してください。通常サイトは開くのにClaudeだけがタイムアウトする場合は、対象ドメインがDIRECTへ送られている、DNS解決に失敗している、ノードの出口地域やIP品質が適していない、といった原因を優先します。

設定を一度に変更しない

原因を切り分けるときは、モード、DNS、ルール、ノードを同時に変更しないでください。1項目ずつ変更してからページを再読み込みし、Clashの接続ログとブラウザの挙動を比較すると、どの変更が効果を持ったのか判断しやすくなります。

症状別に見る主な原因

Claudeに接続できない現象は、表示されるエラーや発生するタイミングによって、確認すべき場所が異なります。次の表を使って、最初の調査対象を絞り込みましょう。

症状	優先して確認する項目	考えられる原因
ページ自体が開かない	モード、システムプロキシ、ノード	Clashが接続を取り込んでいない、またはノードが切断されている
ログイン画面から先に進まない	ルール、Cookie、DNS	認証関連のドメインがDIRECTになっている、名前解決が不安定
送信時に長時間待たされる	ノード品質、出口地域、TCP接続	遅延やパケットロスが大きく、長いHTTPS通信を維持できない
ブラウザは動くがデスクトップアプリは失敗する	TUN、プロセス単位のルール	アプリがシステムプロキシを使わず、Clashの対象外になっている
Clashのログに対象通信がない	取り込み経路、DNS、アプリ設定	通信がClashを迂回している、またはキャッシュ済みの別経路を使っている

「タイムアウト」は、サーバーが完全に停止していることを意味しません。DNS応答を受け取れない、TLS接続を最後まで確立できない、接続後のストリーミング通信が途中で切れる場合も、ブラウザには似たエラーとして表示されます。そのため、まずClashのログでDNS、TCP、TLSのどこまで進んだかを確認することが重要です。

モードとルールを確認する:Claudeの通信を確実にプロキシへ送る

Clashの「グローバル」「ルール」「DIRECT」の選択は、問題の切り分けに大きく影響します。通常運用ではルールモードが便利ですが、ルールの記述やプロバイダーの更新に問題があると、対象通信が直接接続へ流れることがあります。まず短時間だけグローバルモードに切り替え、現在選択中のプロキシグループへすべての通信を送ってテストしてください。

Clash Verge、Clash Verge Rev、Clash for Windowsなどの画面で、プロファイルが正常に読み込まれていることを確認します。ノード一覧が空、または全ノードにエラー表示がある場合は、ルールより先にサブスクリプションを更新します。
プロキシグループで、応答時間が短く安定したノードを1つ選びます。自動選択グループを使う場合も、原因調査中は固定ノードにして結果を比較してください。
モードを一時的にグローバルへ変更し、ブラウザを完全に終了してから再起動します。既存の接続プールやDNSキャッシュが残ると、変更が反映されたように見えないことがあります。
Claudeを再度開き、Clashのログで関連するHTTPS通信が選択したプロキシグループに入っているか確認します。DIRECT、REJECT、タイムアウトのいずれになっているかを記録します。
グローバルで改善した場合はルールモードへ戻し、対象ドメインをプロキシグループへ送るルールを、国内サイト用のDIRECTルールより前に置きます。

ルールは上から順番に評価され、最初に一致した行で処理が止まります。対象をプロキシへ送るルールを追加しても、その前に広すぎる DOMAIN-KEYWORD、GEOSITE、GEOIP、または一括DIRECTルールがあれば、追加した行には到達しません。Claudeのサービス本体だけでなく、認証、API、静的コンテンツなどに使われる関連ドメインも同じポリシーへ送る必要があります。

rules:
  - DOMAIN-SUFFIX,service.example,PROXY
  - DOMAIN-SUFFIX,auth.example,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上のドメインは説明用の例です。実際の設定では、サービス提供元が案内する最新の対象ドメインを使用し、存在しないドメインを無制限に追加しないでください。広いキーワード指定は無関係なサイトまでプロキシへ送る可能性があるため、可能なら DOMAIN-SUFFIX または管理しやすいルールセットを使います。

DNSとTLSを切り分ける:名前解決がタイムアウトを起こす場合

対象ドメインの名前解決がローカルDNSで失敗したり、誤ったアドレスを返したりすると、ノードが正常でも接続できません。ClashのDNS設定で enable: true になっているか、DNSのリッスンポートが他のアプリと競合していないかを確認します。fake-ipを使用している環境では、名前解決の結果として 198.18.0.0/16 の範囲が表示されることがあります。これは実サーバーのIPではなく、Clashが元のドメインを保持して振り分けるためのアドレスです。

mihomo系のプロファイルでは、通常の名前解決用 nameserver と、外部経路での解決に使う fallback を役割分担させる構成がよく使われます。設定を大きく変える前に、現在のDNSログで対象ドメインの問い合わせが成功しているかを確認してください。DNS問い合わせ自体がログに現れない場合は、ブラウザのセキュアDNSや別のVPNがClashを迂回している可能性があります。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.example/dns-query
    - tls://1.1.1.1:853
  fallback:
    - https://fallback.example/dns-query

これは構造を示すサンプルであり、実際には利用中の環境で到達できるDNSサーバーを指定します。DoHやDoTを利用する場合、サーバー名を解決するための default-nameserver も必要になることがあります。DNSを変更した後は、ブラウザの内部DNSキャッシュ、OSのDNSキャッシュ、ClashのDNSキャッシュを順番に消去し、同じ条件で再試行してください。

TLSエラーとDNSエラーを混同しない

Clashのログに「resolve failed」や名前解決失敗が出るならDNSを調べます。「connection reset」「handshake timeout」「i/o timeout」が出る場合は、ノードの出口品質、経路上のパケットロス、サーバー側とのTLS接続を調べます。ログの最終状態を見てから設定を変更すると、不要なDNS変更を避けられます。

ノード品質を確認する:速度だけで判断しない

Claudeのようにログイン、画面表示、長時間の応答ストリームを組み合わせるサービスでは、単純な速度テストの数値だけではノードの適性を判断できません。重要なのは、TCP接続が安定していること、TLSハンドシェイクが毎回完了すること、数分間の通信を維持できることです。短いpingが成功していても、HTTPS接続の途中で切断されるノードは実用に向きません。

固定ノードで比較する。自動選択を使うと測定中に出口が変わるため、同じノードを選択してページ表示、ログイン、送信の3段階を比較します。
遅延と損失を別々に見る。遅延が120ms程度でも安定していれば利用できる場合があります。反対に、遅延が低くても接続が頻繁に切れるノードはタイムアウトの原因になります。
出口地域を確認する。サービス側の地域判定やIP評価により、ある出口では接続できても別の出口では認証や送信に失敗することがあります。
同じプロバイダーの別ノードを試す。1台だけ失敗するならノード障害の可能性が高く、すべて失敗するならルール、DNS、クライアント設定を疑います。
接続数を増やしすぎない。複数端末や複数アプリで同じ低品質ノードを共有すると、帯域制限や同時接続制限に達して切断されることがあります。

TUNモードを使う:ブラウザ以外の通信も取り込む

ブラウザでは接続できるのに、デスクトップ版クライアントや別のアプリからClaudeを利用すると失敗する場合、アプリがシステムプロキシを使っていない可能性があります。システムプロキシはHTTPやHTTPSの設定に従うアプリだけを対象にしますが、独自のネットワーク処理を行うアプリ、UDPを使う補助通信、プロキシ設定を持たないアプリは迂回することがあります。

mihomoカーネルを搭載したClashクライアントでは、TUNを有効にすると仮想ネットワークインターフェースで端末全体の通信を取り込みやすくなります。基本設定は次のような形です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

設定名や対応項目はクライアントとmihomoのバージョンによって異なるため、画面上のTUN設定を優先してください。Windowsではサービスモードや管理者権限、macOSではネットワーク拡張の許可、AndroidではVPN接続の許可が必要です。TUNをオンにした後も、別のVPN、企業ネットワークのフィルター、セキュリティソフトのHTTPS検査が同時に動作していないか確認します。複数の仮想ネットワークが競合すると、DNSループや経路の不安定化が起こります。

TUNは最後の切り分けに使う

TUNを有効にすれば必ず改善するわけではありません。ブラウザのシステムプロキシだけで解決できる問題にTUNを追加すると、LANアクセス、ゲーム、社内システムなど別の通信へ影響が出ることがあります。まずグローバルモードと固定ノードで基本経路を確認し、対象アプリがClashを迂回していると判明した場合にTUNを試してください。

再発を防ぐための確認手順

設定を修正した後は、同じノードと同じネットワークで、ページ表示、ログイン、メッセージ送信の順に確認します。各段階でClashのログを保存しておくと、再発時に前回との差分を比較できます。特に確認したいのは、対象通信がPROXYグループに入っていること、DNS解決が成功していること、接続先が途中でDIRECTへ変わっていないことです。

Clash以外のVPNやプロキシを終了し、プロファイルを有効化します。
固定ノードを選び、グローバルモードで通常サイトとClaudeの接続を確認します。
改善したらルールモードへ戻し、対象ドメインのルールが一括DIRECTより前にあることを確認します。
DNSログと接続ログを確認し、名前解決失敗とTLSタイムアウトを区別します。
ブラウザ以外のアプリだけが失敗する場合に限り、TUNを有効化して権限とDNSハイジャックを確認します。

それでもすべてのノードで同じタイミングに失敗する場合は、クライアントのバージョン、mihomoカーネル、サービス側の障害、ネットワーク事業者による制限を確認します。逆に、特定のノードや特定の出口地域だけで失敗するなら、設定を複雑にするより、安定した別ノードへ切り替える方が早く解決できることがあります。Clashの問題解決では、グローバルで経路を証明し、ルールで再現し、DNSとTUNを最後に調整する順番が有効です。