Clashのノードがタイムアウトして接続できないときの対処法：この順番なら最短で解決

まず切り分ける：全ノードのタイムアウトか、一部ノードだけか

調査を始める前に、遅延テストを何度も繰り返すのはやめましょう。ノードのタイムアウトは結果を示すだけで、ノードが無効になったとは限りません。購読の期限切れ、現在のネットワーク障害、システム時刻のずれ、DNSの異常、ポートの競合、設定パラメータの非互換なども timeout と表示されます。まず障害の範囲を確認すると、その後の確認を短時間で進められます。

全ノードがタイムアウト

同じ購読に含まれる香港、日本、米国など異なる地域のノードが同時にタイムアウトする場合は、共通部分を優先して確認します。共通部分には、購読の状態、直接接続、Clashコアの稼働状況、システムプロキシまたはTUNの確立状況、現在のネットワークによるプロトコル制限などがあります。数十個のノードが同時に故障する可能性は、ローカル環境全体の異常より通常は低いものです。

任意のプロキシグループに切り替えても、すべてのノードが timeout と表示される。
遅延テストが5～10秒待った後、すべて失敗する。
ログに「ネットワークに到達できない」「DNS解決に失敗」「接続が拒否された」といった内容が連続して出る。
Clashを終了すると、通常のウェブページも直接接続で開けない。

一部のノードだけがタイムアウト

同じ購読内に45 ms、120 msなどの遅延を返すノードが残っているなら、クライアントコア、基本ネットワーク、購読形式はおおむね利用可能です。この場合は問題のあるノード自体を確認します。サーバー停止、ポート変更、プロトコルパラメータの変更、現在の通信事業者による経路遮断、またはヘルスチェック先にそのノードから到達できない可能性があります。

現象	優先して確認する層	次の手順
すべてのノードが同時にタイムアウト	購読、直接接続、コアの稼働状態	この記事の手順に沿って最初から確認
同じ地域の一部ノードだけタイムアウト	ノードサーバーと地域回線	同じ地域の別ノードで相互テスト
遅延は正常だがウェブページが開かない	ルール、プロキシグループ、DNS、システムプロキシ	リクエストが実際に通った出口を確認
Wi-Fiではタイムアウトするが、スマホのテザリングでは正常	ルーター、LANのDNS、通信事業者の経路	テザリングの結果を残し、現在のネットワークを確認

手順1：購読が有効で、設定が更新済みか確認する

まずクライアントの購読または設定ページを開きます。一般的な入口は「購読」「設定」「Profiles」「設定管理」などです。現在の設定の更新日時、残り通信量、有効期限を確認してください。クライアントによってメニュー名は多少異なりますが、「設定」→「購読管理」または「Profiles」→ 現在の設定 →「更新」のような経路を探します。

購読の有効期限が切れておらず、残り通信量が0 GBではないことを確認する。
購読を手動で一度更新し、成功または失敗のメッセージを記録する。
更新に成功したら、その設定を再読み込みする。古い設定を表示したままにしない。
プロキシグループを開き、ノード一覧が実際に更新されたことを確認する。
購読URLを公開の速度測定サイトやスクリーンショットに貼り付けない。

購読の更新に失敗したときの判断方法

更新時にHTTP 401または403が表示される場合、購読の認証情報が無効、リンクがリセットされた、またはサーバー側でアクセスが制限されている可能性があります。HTTP 404はアドレスが存在しないことを示します。5xxが続く場合は、購読サービス側の一時的な障害を疑います。「connection timeout」と表示された場合は、購読URLへ直接接続できるかを確認してください。多くのクライアントは設定更新に直接接続を使うためです。

更新に成功しても、ノードのパラメータが有効とは限りません。設定の詳細を開き、ノード数が異常に0になっていないか、新しい設定が古いproviderキャッシュを参照していないか確認します。プロキシプロバイダーを使う設定には、次のような構造が含まれることがあります。実際のノード一覧はメイン設定ではなくproviderファイルから読み込まれます。

proxy-providers:
  provider-main:
    type: http
    url: "購読URL"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600 は3600秒ごとに更新を試みる設定です。ヘルスチェックの interval: 600 は600秒ごとに確認します。メイン設定を更新してもproviderキャッシュが古いままだと、無効になったノードが表示され続けることがあります。クライアントのプロキシプロバイダーページで手動更新してから、コアを再起動してください。

手順2：プロキシを無効にして直接接続を確認する

Clashは現在のネットワークを使ってプロキシサーバーへの接続を確立します。基盤となるネットワークが切断されていれば、すべてのノードがタイムアウトします。まずクライアントで「システムプロキシ」を無効にし、TUNモードを使っている場合はTUNも一時的に無効にします。ブラウザーを完全に終了してから再起動し、普段直接接続できるウェブサイトを開いてください。

最小構成で2種類のテストを行う

システムプロキシとTUNを無効にし、現在のWi-Fiで直接接続のウェブサイトを開く。
Clashの設定は変えず、パソコンまたはスマートフォンをモバイルホットスポットに切り替えて、同じノード群をテストする。

現在のWi-Fiではすべてタイムアウトするのに、スマホのテザリングではすぐ復旧する場合、たとえばノードの遅延がtimeoutから80～250 msになる場合は、原因は元のネットワーク、ルーター、または通信事業者の経路にあり、Clashの設定ではありません。まずONUまたはルーターを再起動し、ルーターの接続状態とDNS設定を確認します。そのうえで、ネットワーク管理者に出口制限が有効になっていないか確認してください。

Windowsでは、ターミナルを開いて基本的な接続テストも実行できます。ここで確認するのはローカルネットワークとDNSであり、プロキシノードの速度ではありません。

ping 1.1.1.1
nslookup example.com

ping がブロックされていても、必ずしもネットワーク断とは限りません。ただし、ドメイン名の解決に失敗し、ブラウザーの直接接続でもウェブページを開けない場合は、まずネットワークを修復してください。macOSとLinuxでは同じコマンドをターミナルで使えます。一部のシステムでは nslookup の代わりに dig example.com を使用します。

公衆Wi-Fiで追加確認すること

ホテル、空港、学校のネットワークには認証ページが用意されていることがあります。Wi-Fiに接続してオンラインに見えても、実際にはブラウザーでログインが必要です。プロキシを無効にして通常のHTTPページへアクセスし、認証画面にリダイレクトされるか確認してください。認証が完了するまで、Clashからの接続は遮断またはリダイレクトされ、すべてのノードがタイムアウトすることがあります。

手順3：システム時刻を合わせ、コアとローカルポートを確認する

システム時刻のずれはハンドシェイクを妨げる

TLS証明書の検証には日付と時刻が使われます。システム時刻が数分、場合によっては数時間ずれていると、購読リクエスト、WebSocket TLS、gRPC TLSなどの暗号化接続に失敗することがあります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」をオンにして、「今すぐ同期」をクリックします。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、自動設定を有効にします。

同期後はクライアントを完全に終了し、再起動してください。ノードを切り替えるだけでは不十分です。古い接続やDNSキャッシュがコアプロセスに残っている可能性があります。ログに certificate has expired、not yet valid、handshake failure が出ている場合は、時刻と証明書チェーンを重点的に確認します。

Clashまたはmihomoコアが稼働しているか確認する

グラフィカルインターフェースが開いていても、コアプロセスが正常とは限りません。「設定」→「コア」または「設定」→「Clashコア」を開き、状態が実行中か確認します。Clash Metaの後継コアであるmihomoを採用したクライアントでは、ログやプロセス名にmihomoと表示されることがあります。コアの起動に何度も失敗する場合は、最後の再試行メッセージではなく、ログに出た最初の error を確認してください。

ポートの競合を確認する

一般的なローカルHTTP／SOCKS混在ポートは 7890、コントロールポートは 9090 です。実際の値は現在のYAMLとクライアント設定に従ってください。よくある設定例は次のとおりです。

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule
log-level: info

別のプロキシプログラムが7890を使用していると、Clashがそのポートを待ち受けできないことがあります。Windowsではターミナルで次を実行します。

netstat -ano | findstr :7890
netstat -ano | findstr :9090

macOSまたはLinuxでは次を実行します。

lsof -nP -iTCP:7890
lsof -nP -iTCP:9090

古いプロセスがポートを使用していることが分かったら、まず古いプロキシプログラムを終了するか、「設定」→「ポート設定」でmixed portを未使用のポート（例：7891）に変更します。変更後はシステムプロキシにも新しいポートを反映させてください。YAMLだけを変更してシステムプロキシを更新しないと、ブラウザーは古い127.0.0.1:7890へ接続し続けます。

手順4：ノードのプロトコルパラメータと設定の互換性を確認する

購読が有効で、直接接続も正常、コアも稼働している場合に、ノードのパラメータを確認します。ノード名からプロトコルを推測して手入力しないでください。サーバーから配信された内容を基準に、サーバーアドレス、ポート、UUIDまたはパスワード、トランスポート方式、TLS、SNI、ALPN、Realityパラメータを重点的に確認します。

タイムアウトを招きやすいパラメータの違い

server と port：サーバー移転後も古いアドレスまたはポートを使っている。
network：サーバーはWebSocketを使用しているのに、クライアントがTCP直接接続として扱っている。
servername または sni：TLSハンドシェイクで誤ったドメイン名を使っている。
ws-opts.path：WebSocketパスの先頭スラッシュがない、または古い値のままになっている。
grpc-opts.grpc-service-name：gRPCサービス名がサーバー側と一致していない。
Realityパラメータ：public-key、short-id、servernameが一致していない。
UDP：ノードでUDPが有効になっていないのに、UDPを必要とするリクエストに使っている。

古いClashコアが新しいフィールドに対応していない場合、設定の読み込み時に直接エラーが出たり、非互換のノードがスキップされたりします。Reality、Hysteria2、TUICなどを含む設定では、対応するプロトコルをサポートしたmihomoバージョンを使用しているか確認してください。バージョンが古い場合は、クライアント内蔵の「設定」→「コア」→「コアを更新」から更新し、更新後に設定を再読み込みします。

ログに unsupported proxy type、field not found、または設定解析エラーが出ている場合、問題は設定読み込み層で発生しており、まだノード接続層には到達していません。この段階で遅延テストを繰り返しても意味がありません。まずコアの互換性または購読形式を修正してください。

ヘルスチェックのタイムアウトは、すべてのウェブサイトが利用できないことを意味しない

クライアントの遅延テストは通常、HTTP 204を返す軽量ページなど、指定されたURLへアクセスします。テスト先だけがノードの出口、DNS、現在のネットワークによって制限されることがあります。テストURLを一時的に別の安定したHTTPSアドレスへ変更して相互確認できますが、大容量ファイルのダウンロードURLはヘルスチェックに使わないでください。通信量とテスト時間が増加します。

ノードが実際に使えるか判断するには、ヘルスチェックの遅延、ログの接続結果、実際のウェブリクエストの3項目を同時に確認します。1回の5000 msタイムアウトは、そのテストが制限時間内に完了しなかったことを示すだけです。3回連続でタイムアウトし、実際のリクエストも失敗した場合に、ノードまたは回線の障害である可能性が高くなります。

手順5：システムプロキシ、TUN、DNSの層を確認する

システムプロキシモード

システムプロキシモードは、システムのプロキシ設定に従うアプリを主に制御します。まずクライアントの「設定」→「システムプロキシ」を開き、一度無効にしてから再度有効にします。プロキシアドレスが 127.0.0.1 で、ポートがmixed portと一致していることも確認してください。ブラウザー拡張、他のプロキシソフト、手動のPAC設定がシステム設定を上書きすることがあります。調査中はこれらの追加入口を一時的に無効にします。

ノードテストは正常なのに、特定のアプリだけネットワークに接続できない場合、原因は通常ノードにはありません。そのアプリがシステムプロキシを読み取るか、独自にプロキシポートを指定していないかを確認します。まずブラウザーで検証し、問題のアプリと結果を比較してください。

TUNモード

TUNモードは仮想ネットワークインターフェースを通じて、より多くの通信を制御します。通常は管理者権限が必要です。有効化に失敗すると、クライアントログにinterface、route、permission、deviceに関するエラーが出ることがあります。Windowsでは管理者権限でクライアントを起動します。macOSで初めて有効にする場合は、ネットワーク拡張またはVPN構成の許可が必要です。システム内に別のVPNがある場合は、ルーティングテーブルや仮想NICの競合を避けるため、先に完全終了してください。

TUNを調べるときは二分法を使います。TUNを無効にし、システムプロキシだけを有効にします。ブラウザーが復旧した場合、ノード自体は利用可能で、問題はTUNの権限、ルート、DNSに絞られます。両方のモードでタイムアウトする場合は、ノードと回線の層を引き続き確認します。

DNS異常を見分ける方法

ノードの遅延は正常なのにドメイン名を入力すると開けず、既知のIPアドレスへ直接アクセスすると応答がある場合は、DNSを確認します。mihomoの設定には dns.enable、nameserver、fallback、fake-ip などのフィールドがあります。元の設定を理解しないまま、すべてのDNS項目を同時に変更しないでください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

ポート1053も未使用である必要があります。TUNとfake-ipを使っている場合は、TUNを無効にしてから再テストし、古いルートやキャッシュの影響を避けます。Windowsでは ipconfig /flushdns を実行してシステムDNSキャッシュを消去できます。macOSではネットワークまたはシステムを再起動してから再テストします。キャッシュの消去は補助的な対処であり、誤った上流DNS設定は修正できません。

手順6：最後にノードを切り替え、ログで結論を確認する

ここまでの共通部分がすべて正常になってから、ノードの切り替えに進みます。まず同じ地域から異なるノードを2～3個選び、各ノードを約10秒間隔で3回ずつ連続テストします。一度に数十個のノードをテストしないでください。同時ヘルスチェックによってネットワーク速度制限が発動したり、ログが読みにくくなったりします。

ノードAを選び、遅延を測定して実際のウェブページを1つ開く。
同じ地域のノードBを選び、同じ操作を繰り返す。
別地域のノードCに切り替え、地域回線の問題かどうかを判断する。
さらにスマホのテザリングへ切り替え、異なるネットワークでの比較結果を1組残す。

自宅の固定回線ではノードA、Bがタイムアウトし、スマホのテザリングでは正常な場合、原因は現在の通信事業者の経路にある可能性が高いです。同じノードが両方のネットワークでタイムアウトし、同じ購読内の他ノードが正常なら、ノードサーバーまたはポートの問題が疑われます。両方のネットワークで全地域のノードがタイムアウトする場合は、購読とプロトコルパラメータの層に戻って再確認してください。

ログで確認するキーワード

i/o timeout：接続または読み書きが制限時間内に完了しなかった。
connection refused：対象アドレスには到達できたが、該当ポートが接続を拒否した。
network is unreachable：ローカルのルートまたはネットワークインターフェースから対象へ到達できない。
no such host：ドメイン名の解決に失敗した。
TLS handshake timeout：TLSハンドシェイクがタイムアウトした。回線、SNI、時刻、サーバー側を確認する。
authentication failed：認証パラメータが一致していない、または認証情報が無効になっている。

ログレベルはまず info を使用します。情報が不足するときだけ一時的に debug へ切り替え、1回再現したら戻してください。ログを共有する前に、購読URL、UUID、パスワード、トークン、サーバー認証情報、個人のネットワーク情報を削除します。

よくある誤判断と最短の対処ルート

誤判断1：timeoutを見てすぐ再インストールする

再インストールでリセットできるのはクライアントのファイルだけです。購読の期限切れ、サーバー停止、通信事業者の経路、システム時刻のずれは直せません。元のログを失い、問題の特定が難しくなることもあります。まず必要な設定をエクスポートしてから、基本的な層別チェックを行ってください。

誤判断2：遅延の数字が小さければ必ず接続できる

遅延テストが反映するのは、特定のテストリクエストだけです。40 msのヘルスチェックが正常でも、目的のウェブサイトにアクセスできるとは限らず、ルールがそのノードへリクエストを送るとも限りません。ウェブページが開けない場合は接続ログを開き、ドメインがどのルールに一致し、どのプロキシグループに入り、最終的にどのノードが選ばれたかを確認します。

誤判断3：実際の選択先を確認せず、プロキシグループだけを切り替える

ルールモードでは、リクエストはまずルールに一致し、その後指定されたプロキシグループへ進みます。「ノード選択」というグループを手動で切り替えても、対象ドメインが別の「自動選択」グループに一致することがあります。ログにはDOMAIN-SUFFIX、MATCHなどのルール結果が表示されるはずです。調査中は一時的にグローバルモードで相互テストできますが、完了後は元のルールモードに戻してください。

10分で確認するチェックリスト

1分目：すべてのノードがタイムアウトするのか、一部だけか確認する。
2分目：購読の有効期限、残り通信量、更新日時を確認する。
3分目：プロキシとTUNを無効にし、直接接続を確認する。
4分目：スマホのテザリングに切り替えてネットワークを比較する。
5分目：システム時刻を同期し、コアを再起動する。
6分目：7890などのローカルポートが使用中でないか確認する。
7分目：ログに出た最初のエラーを確認する。
8分目：プロトコル、TLS、SNI、トランスポートパラメータを確認する。
9分目：TUNを無効にし、システムプロキシだけで再テストする。
10分目：異なる地域のノードを選び、最終的な相互テストを行う。

この手順の要点は、まずすべてのノードに共通する部分を確認し、その後で個別ノードを調べることです。全ノードのタイムアウトでは購読、ネットワーク、コア、ポートを優先し、一部だけのタイムアウトではノードサーバー、プロトコルパラメータ、回線を優先します。各手順の結果を残しておけば、同じ障害が再発したときに該当する層へ直接進めます。