トラブルシューティング 約 10 分

Clash ノードがタイムアウトして接続できない｜7つの確認手順

ノードのタイムアウトはノード自体が原因とは限りません。購読の更新、DNS 解決、ポート競合、システムプロキシ、ルール一致、カーネルログ、ネットワーク環境の7項目を順に確認し、原因を特定します。

ノード一覧の遅延が timeout と表示される、接続時に「プロキシサーバーに接続できません」と出る、ブラウザがずっと読み込み中のままページが開かない——この3つはユーザーから見ればどれも「ノードのタイムアウト」ですが、原因はまったく異なります。多くの人はまずノードを切り替えようとしますが、何十個試しても timeout のままです。原因はノード側にはないからです。

以下の7つの項目は「クライアント内部から外部回線へ」の順に並んでいます。各ステップには、すぐ実行できる確認操作と判断基準を用意しました。順番どおりに進め、途中を飛ばさないでください。前のステップの結果が、次のステップを実行すべきかどうかを決めます。

まず4種類のタイムアウトを見分ける

作業を始める前に、一度分類しておきましょう。同じ timeout でも、どの段階で起きているかが分かれば、調べる範囲を前もって絞り込めます。

症状 考えられる原因 優先して確認する項目
すべてのノードで遅延テストが timeout になる 購読の失効、DNS 解決の失敗、ローカルポートの競合 手順1 → 2 → 3
一部のノードだけ timeout になる そのノードが停止している、または一時的に利用不可 手順1
遅延は数値が出るのに、ブラウザでページが開けない システムプロキシが有効になっていない、ルールが REJECT に一致 手順4 → 5
特定のアプリだけタイムアウトし、他のアプリは正常 そのアプリがシステムプロキシを参照しない、振り分けルールが対象外 手順4 → 5

判断は簡単です。遅延テストはカーネル自身の疎通確認経路を通り、ブラウザはシステムプロキシまたは TUN 仮想 NIC を通ります。前者が失敗するならカーネルからノードまでの区間に問題があり、前者が正常で後者が失敗するなら、トラフィックの引き受けかルール振り分けに問題があります。

手順1：購読の更新とノード情報の有効期限

購読リンクには有効期限と通信量の上限があります。期限が切れてもクライアントは通常エラーを出さず、ノード一覧の遅延がすべて timeout になるだけです。だから最初にやるべきはノードの切り替えではなく、手動での購読更新です。

具体的な操作手順

  1. クライアントの「購読」または「設定」ページを開き、現在使用中のプロファイルを見つけて「更新」を実行します。「再読み込み」だけでは不十分です。再読み込みはローカルの古いファイルを読むだけで、ノード情報は変わりません。
  2. 更新後、ノード数が 0 になっていないこと、一覧にノード名と遅延の列が表示されていることを確認します。
  3. 生成された設定ファイルを開き、proxies セクションのノードの server フィールドが有効なドメインまたは IP のままか確認します。プロバイダがノードのドメインを変更すると、古い設定は丸ごと使えなくなります。

コマンド1つで購読リンクを検証する

curl -sI -o /dev/null -w '%{http_code}\n' "あなたの購読リンク"

200 が返ればアドレスにアクセスできています。403、404、410 は購読アドレスが失効しているか、再取得が必要な状態です。200 が返っても設定の中身が空の場合は、通信量の使い切りが一般的です。

購読を取得できてもノードが使えるとは限らない

一部のプロバイダは通信量を使い切った後も、基本フィールドだけを含む設定ファイルを返します。クライアントは正常に読み込め、ノードも表示されますが、接続はすべてタイムアウトします。この場合はプロバイダの管理画面で残り通信量と有効期限を確認してください。

手順2：DNS 解決とノードのドメイン

ノードのドメイン解決の失敗は timeout の頻出原因で、「ノードが落ちた」と誤解されがちです。Clash カーネルは独自の dns セクションでノードのドメインを解決しており、システム DNS とは別系統の設定です。システム DNS を変えてもカーネルに反映されないことがあります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:      # mihomo 専用：ノードのドメイン解決に使用
    - https://1.1.1.1/dns-query

proxy-server-nameserver は mihomo（Clash Meta）で追加されたフィールドで、「ノードのドメイン解決」という処理だけを信頼できる DNS に任せ、中国本土の DNS が汚染された IP を返して TCP ハンドシェイクの段階でタイムアウトするのを防ぎます。オリジナルの Clash カーネルにはこのフィールドがなく、nameserver-policy でノードのドメインごとにサーバーを指定するしかありません。

確認方法

  • nslookup ノードのドメイン と nslookup ノードのドメイン 1.1.1.1 を実行し、2つの結果に大きな差があれば DNS 汚染が疑われます。
  • カーネルログに [DNS] resolve xxx failed が出る、または同じドメインを繰り返し再試行している場合は、解決の問題だと確定できます。
  • fake-ip モードを使用している場合、接続一覧の宛先アドレスが 198.18.x.x と表示されるのは正常な動作で、故障ではありません。

手順3：ポートの競合とローカル待ち受け

カーネルは既定で 7890（mixed-port、HTTP と SOCKS の混合）、7892（redir-port）、7893（tproxy-port）を待ち受け、制御インターフェースは既定で 127.0.0.1:9090 です。どれか1つでもポートが使われていると、カーネルの起動に失敗したり一部しか起動しなかったりしますが、クライアントの画面には「実行中」と表示されたままのことがあります。

ポートの使用状況を確認するコマンド

  • Windows：netstat -ano | findstr :7890 で PID を取得し、タスクマネージャーでどのプロセスかを確認します。
  • macOS：lsof -i :7890
  • Linux：ss -lntp | grep 7890

対処方法は2つ

  1. ポートを占有しているプロセスを終了してカーネルを再起動します。よくある占有元は、前回終了しきらなかったカーネルプロセス、他のプロキシソフト、ローカルポートを待ち受ける開発ツールなどです。
  2. 設定の mixed-port を変更し（例：7897）、システムプロキシ、ブラウザ拡張、コマンドラインツールのプロキシポートも同時に変更します。
設定だけ変えてシステムプロキシを変えないと複合的な不具合になる

カーネルは実際には 7897 で待ち受けているのに、システムプロキシは 7890 を指したまま——これが「ノードの遅延テストは正常なのにブラウザはすべてタイムアウト」という症状です。ノードの問題に見えますが、実際はポートの不一致です。

手順4：システムプロキシと TUN が本当にトラフィックを引き受けているか

カーネルが動いているからといって、トラフィックが引き受けられているとは限りません。システムプロキシと TUN は別の方式なので、確認の前にどちらを使っているかを把握しておきます。

システムプロキシの確認箇所

  • Windows：「設定」→「ネットワークとインターネット」→「プロキシ」で「プロキシサーバーを使用する」がオンになっていること、アドレスが 127.0.0.1 で、ポートが設定の mixed-port と一致していることを確認します。
  • macOS：「システム設定」→「ネットワーク」→ 現在のネットワークサービス →「詳細」→「プロキシ」で、HTTP と HTTPS の両方にチェックが入り、同じポートを指していることを確認します。
  • Linux：GNOME なら「設定」→「ネットワーク」→「ネットワークプロキシ」。ターミナルのコマンドラインツールは別途 http_proxy 環境変数の設定が必要です。

TUN モードの確認箇所

TUN には管理者または root 権限が必要で、多くのクライアントはシステムサービスをインストールして実現します（Clash Verge Rev の「サービスモード」、Clash for Windows の Service Mode）。有効にしたらルーティングテーブルで確認できます。

  • Linux / macOS：ip route に TUN 仮想 NIC と 198.18.0.0/16 のルートエントリが表示されるはずです。
  • Windows：route print に TUN アダプターに対応するルートが表示されるはずです。

コマンド1つで経路全体が通っているか判断する

curl -x http://127.0.0.1:7890 -o /dev/null -s -w '%{http_code} %{time_total}s\n' https://www.gstatic.com/generate_204
  • 204 が返り、所要時間が数百ミリ秒以内：カーネル、ノード、ルールの経路は正常で、問題はシステムプロキシの設定か特定のアプリにあります。
  • 000 が返る、または長時間応答がない：カーネル側で通っていないので、手順1に戻って確認し直します。
比較項目 システムプロキシ TUN モード
引き受ける範囲 システムプロキシ設定を参照するアプリ すべての TCP / UDP トラフィック
必要な権限 一般ユーザーで可 管理者 / root、またはシステムサービスのインストール
DNS の処理 多くの場合システム DNS のまま カーネルの dns セクションで一括処理
よくある問題 アプリがシステムプロキシを参照しない、ポートの不一致 サービス未インストール、ルート未登録

手順5：ルールの一致と振り分け結果

ルールは上から順に短絡評価され、最初に一致したルールがその接続の行き先を決めます。ルールの記述ミスやルールセットの未更新も、同じくタイムアウトとして現れます。

rules:
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

よくある3つの記述ミス

  • MATCH を途中に書く：すべてのトラフィックに一致するため、その後に書いたルールは永遠に実行されません。
  • IP-CIDR に no-resolve を書き忘れる：接続ごとに DNS 解決が走り、解決が遅いか失敗すると全体がタイムアウトとして現れます。
  • 対象ドメインが REJECT に一致する、または DIRECT に落ちていて、その直連自体が現在のネットワークで遮断されている。

どのルールに一致したかを確認する方法

Dashboard の「接続」ページを開くと、各接続に対応する「ルール」と「プロキシチェーン」の2列が確認できます。カーネルログにも [TCP] 1.2.3.4:443 → match GEOIP,CN => DIRECT のような記録が出力されます。ある接続が REJECT に一致している場合、ブラウザ側ではすぐにエラーになるのではなく、リクエストがずっと応答なしのままになります。

手順6：カーネルログと遅延テストの方法

ログレベルは既定で info です。タイムアウトを調べるときはまず debug に上げ、問題をもう一度再現して、ログがどの段階で止まるかを見ます。

log-level: debug
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true
  • unified-delay: true：遅延を完全なハンドシェイクの所要時間で計算するため、数値が実際の体感に近くなり、どの種類のノードがタイムアウトしているかも分かりやすくなります。
  • tcp-concurrent: true：同じドメインに対して複数の IP を同時に疎通確認し、一部の IP に到達できないだけで全体がタイムアウトするのを防ぎます。
  • external-controller：Dashboard の接続先アドレスです。設定するとブラウザでローカルパネルを開き、リアルタイムのログと接続一覧を確認できます。

ログの4つの重要行

ログの抜粋 意味 戻る手順
dial tcp 1.2.3.4:443: i/o timeout カーネルからノードへのハンドシェイク失敗 手順1〜3
[DNS] resolve xxx failed ノードのドメイン解決失敗 手順2
match GEOIP,CN => DIRECT の後に応答なし 直連になったが、直連がネットワークで遮断されている 手順5
listen tcp 127.0.0.1:7890: bind: address already in use ポートが他のプロセスに占有されている 手順3
遅延テストのアドレスを統一する

テストアドレスを https://www.gstatic.com/generate_204 に固定します。クライアントごとに既定のテストアドレスは異なるため、統一しておくと各プラットフォームの遅延値を比較でき、デバイスをまたいだ照合もしやすくなります。

手順7：ネットワーク環境と回線品質

ここまでの6項目はすべて端末側で、最後の項目は回線側です。判断は簡単で、同じ設定をスマホのテザリングに切り替えて一度テストします。

  • 公共 Wi-Fi、学内ネットワーク、社内ネットワークは、外向きポートの遮断や SNI への干渉を行うことがよくあります。同じ設定がテザリングでは正常で、現在のネットワークではすべてタイムアウトするなら、ネットワーク側の制限とほぼ断定できます。
  • システム時刻のずれ：VMess などのプロトコルはタイムスタンプに依存し、90 秒以上ずれるとハンドシェイクが失敗し、症状は同じく timeout になります。Linux / macOS では date -u で標準時刻と比較し、Windows では w32tm /resync で再同期します。
  • IPv6 優先：ノードのドメインに A と AAAA の両方のレコードがあり、ローカルの IPv6 に到達できない場合、一部のクライアントは先に IPv6 を試してからフォールバックするため、最初のパケットがタイムアウトしたように見えます。設定に ipv6: false を追加して検証できます。
  • MTU とルーター：一部の PPPoE 環境では TUN の MTU を 9000 から 1500 以下に下げる必要があります。下げないと大きなパケットが破棄され、「ページは開けるのに動画やダウンロードがずっと止まる」という症状になります。

7つの手順の早見表

順序 手順 確認方法 判断基準
1 購読の更新 curl -sI "購読リンク" 200 が返り、ノード数が 0 でない
2 DNS 解決 nslookup ノードのドメイン 1.1.1.1 既定の解決結果と一致する
3 ポートの競合 netstat -ano | findstr :7890 他のプロセスがそのポートを使用していない
4 システムプロキシ / TUN curl -x http://127.0.0.1:7890 … 204 が返る
5 ルールの一致 Dashboard の「接続」ページ 一致したルールとプロキシが想定どおり
6 カーネルログ log-level: debug dial timeout と DNS 失敗の記録がない
7 ネットワーク環境 スマホのテザリングで再テスト テザリングでは正常に戻る

調査中にやってはいけない3つのこと

  1. 設定変更とテストを同時に進めない。1回につき1項目だけ変更し、保存してカーネルを再起動してから再現します。そうしないと、どの変更が効いたのか判断できません。
  2. ノードの切り替えで原因究明を代用しない。すべてのノードがタイムアウトするなら、問題はクライアントかローカル回線にあり、ノードを変えても結果は変わりません。
  3. 購読が生成した設定ファイルを直接編集しない。次回の購読更新で変更は上書きされます。カスタム内容はクライアントの拡張設定や Merge オーバーレイに書いてください。

この7つの手順を一通りたどれば、ほとんどのタイムアウト問題は具体的な箇所にたどり着きます。購読、DNS、ポート、引き受け方式、ルール、ログ、ネットワーク環境のいずれかです。まず特定してから修正するほうが、ノードを片っ端から試すよりずっと速く解決します。

調査の前にクライアントとカーネルのバージョンを確認する

本記事で扱う proxy-server-nameserver、unified-delay、tcp-concurrent の3つのフィールドは mihomo カーネルが必要です。オリジナルの Clash カーネルはメンテナンスが終了しており、フィールドが効かない場合はまずカーネルの種類を確認し、ログと照らし合わせて項目ごとに調べてください。

ダウンロードページへ インストールガイドを見る

Clash をダウンロード