トラブル対処 読了目安 12分

Clashのノードがタイムアウトして接続できないときの切り分け手順

ローカルネットワーク、購読状態、ノードの可用性、プロキシモード、DNS、システムファイアウォールの順に接続タイムアウトを切り分けます。

Clashでノードがタイムアウトしても、ある接続または遅延テストが制限時間内に有効な応答を受け取れなかったことを示すだけで、ノード自体の停止を直接意味するわけではありません。原因は、ローカルネットワークの入口、購読設定、ノードサーバー、プロキシグループの選択、DNS解決、システムプロキシ、TUNルーティング、ファイアウォールのいずれの層でも発生します。複数の設定を同時に変更すると、元の障害箇所が新しい変数に隠れ、かえって切り分けに時間がかかります。

接続経路に沿って層ごとに確認するのがおすすめです。まず端末が直接インターネットへ接続できることを確認し、次に設定が実際に更新されているかを確かめます。その後、ノードとプロトコル、プロキシモードとルールの適用状況を確認し、最後にDNS、TUN、ポート競合、セキュリティソフトを調べます。各手順の結果を記録すれば、「どのサイトも開けない」という状態を、ネットワーク層・設定層・転送層のいずれかに絞り込めます。

1. タイムアウトが発生している層を切り分ける

「タイムアウト」は単一のエラーではありません。クライアント画面の遅延テスト、ブラウザーの読み込み失敗、ログに記録された接続タイムアウトでは、異なる経路を検証している可能性があります。クライアントによっては指定したHTTPまたはHTTPSアドレスで遅延を測定します。このテストにはDNS、TCP接続、TLSハンドシェイク、HTTP応答が含まれ、ICMP Pingとは異なります。テスト先に一時的に接続できなくても、ノードが他のリクエストを転送できる場合があります。

よくある症状と初期判断

クライアントの画面と実際のカーネル状態も分けて確認する必要があります。GUIクライアントは設定管理とシステム連携を担い、Clash Meta（現在は主にmihomoとして保守）などのカーネルがルール照合、プロトコル接続、転送を処理します。画面が動作していても、カーネルが正常に起動しているとは限りません。ログに設定解析エラー、リスニングポートの作成失敗、権限エラーがある場合は、まずカーネルを復旧してからノードをテストします。

2. ローカルネットワークの入口とシステムの基本状態を確認する

システムプロキシを無効にし、TUNを停止したうえで、普段安定しているWebサイトへ直接アクセスします。直接接続も失敗するなら、現在の原因がClashだけとは限りません。Wi-Fiの認証が完了しているか、有線インターフェースがアドレスを取得しているか、モバイルホットスポットにデータ通信があるか、会社や学校のネットワークでWeb認証が必要かを確認します。公共ネットワークの認証ページは、通常まず直接接続して開く必要があります。プロキシや暗号化DNSが認証ページの表示を妨げることもあります。

  1. 他のVPN、ネットワーク高速化ツール、パケットキャプチャーツール、仮想ネットワークアダプターソフトを一時的に終了し、複数のプログラムがデフォルトルートやDNSを同時に変更しないようにします。
  2. 現在のネットワークに再接続し、システムが有効なIPアドレス、デフォルトゲートウェイ、DNSサーバーを取得していることを確認します。
  3. 端末の日付、時刻、タイムゾーンを確認します。時刻が大きくずれるとTLS証明書の検証に失敗し、購読の更新失敗やHTTPS接続エラーとして現れることがあります。
  4. 自宅の固定回線とスマートフォンのテザリングをそれぞれテストします。同じ設定がテザリングでは使えて固定回線では使えない場合、原因はルーター、通信事業者の経路、またはLANのポリシーに近いと考えられます。
  5. クライアントを再起動した後、カーネルの起動ログを確認し、HTTP、SOCKS、またはmixedのリスニングポートが作成されていることを確かめます。

ネットワークを切り替えた後は、古いインターフェースやルートが一時的に残ることがあります。特に有線からWi-Fiへ、会社のネットワークからホットスポットへ切り替えた場合、TUNが自動認識した出口インターフェースが更新されていない可能性があります。この場合はまずTUNを無効にし、システムのルーティングが安定するまで待ってから再度有効にします。クライアントに「カーネルを再起動」や「設定を再読み込み」がある場合は、それらを優先し、同じ購読を何度もインポートする必要はありません。

3. 購読状態と設定が実際に反映されているか確認する

購読の更新成功という表示は、クライアントが何らかのダウンロード処理を完了したことを示すだけで、取得内容が有効なClash設定であるとは限りません。購読URLの期限切れ、サーバーからのログインページ返却、ネットワーク認証ページによる応答の置き換え、現在のクライアントとの購読形式の非互換などにより、ノード一覧が空になったり、古いキャッシュが使われ続けたりします。

まず購読の更新日時、設定ファイル名、ノード数を確認します。ノード名、プロキシグループ、ルールがサーバー側の最近の変更と一致しない場合は、手動で更新してログを確認します。YAML解析エラーの一般的な原因は、インデントの誤り、コロンの後のスペース不足、文字列内の特殊文字の引用漏れ、現在のカーネルが対応していないフィールドの参照です。

購読の確認手順

  1. 購読URLがまだ有効で、アカウントに紐づくサービスの期限切れや停止がないことを確認します。
  2. 直接接続で一度更新します。直接接続で更新できない場合は、利用可能なプロキシ経由でも試し、購読サーバーへのアクセス経路を切り分けます。
  3. 応答内容が設定テキストであり、HTMLのログインページ、エラーページ、ゲートウェイの認証ページではないことを確認します。
  4. クライアントで実際に有効化されているのが更新直後の設定であり、過去の設定、サンプル設定、別のローカルファイルではないことを確認します。
  5. 設定を再読み込みした後、プロキシグループの選択を確認します。グループ内のノード名が変わると、以前の選択がリセットされたり、利用できない項目を指したりすることがあります。

公開ログ、スクリーンショット、フォーラムへの投稿に、完全な購読URL、ノードのパスワード、UUID、証明書フィールド、アクセストークンを載せないでください。これらは接続認証情報です。トラブル対処に必要なのは通常、プロトコルの種類、サーバーがドメイン名かどうか、ポート範囲、トランスポート方式、TLSの状態、エラーの種類だけです。

インポート後にカーネルを起動できない場合は、読み込みに成功する直前の設定へ一時的に戻し、クライアントとネットワーク環境が正常であることを確認してから、2つの設定の差分を比較します。設定ファイルを大幅に削除・変更する前には、元のコピーを保存してください。ルールセット、プロキシプロバイダー、外部リソースのダウンロード失敗によって、設定の読み込みがエラー状態で止まることもあります。

4. ノード、プロトコルパラメーター、サーバー経路を検証する

ローカルネットワークと設定が正常だと確認できたら、具体的なノードを調べます。まず同じ購読から、地域と入口の異なるノードを2〜3個選んでテストします。特定のノードだけ失敗する場合は、そのノードをプロキシグループから一時的に除外できます。同じサーバーの複数ポートがすべて失敗する場合は、サーバーの停止、入口ドメインの名前解決異常、ネットワーク経路の遮断などが考えられます。

ノードのパラメーターは、アドレスとポートだけでなく、サーバー側と全体として一致している必要があります。プロトコルによっては、パスワード、UUID、暗号化方式、TLS、SNI、ALPN、トランスポート層、WebSocketパス、gRPCサービス名、Reality関連パラメーターにも依存します。1つでもフィールドが一致しなければ、TCP接続後にハンドシェイクがタイムアウトしたり、接続が切断されたりすることがあります。

ログのキーワードから発生段階を特定する

ノードサーバーのアドレス自体がドメイン名の場合、Clashはまずそのドメインを解決してからプロキシ接続を確立します。この処理に、まだ確立していない同じプロキシ経路に依存するDNSを使うと、起動時の依存関係が発生します。mihomo設定のproxy-server-nameserverはプロキシサーバーのドメイン名解決に利用できますが、設定が必要かどうかは現在のDNS構成とカーネルのバージョンに応じて判断してください。

IPv6も個別に検証する必要があります。ネットワークがIPv6アドレスを取得できても、安定したIPv6出口がない場合があります。DNSがAAAAレコードを返すと、利用できない経路を待ち続けてタイムアウトすることがあります。トラブル対処中は、クライアントDNSでのIPv6応答を一時的に無効にするか、IPv6に明確に対応したネットワークへ切り替えて比較します。原因を確認したら、IPv4優先を維持するか、IPv6ルーティングを修正するかを決めます。

5. プロキシモード、プロキシグループ、ルールの適用状況を確認する

ノードが利用可能でも、トラフィックが必ずそのノードを通るとは限りません。Clashのルールモードでは、上から順にルールを照合し、マッチした後に対応するプロキシグループまたはアクションへ渡します。対象ドメインが先にあるDIRECTルールにマッチしていれば、別のプロキシノードへ切り替えても結果は変わりません。トラブル対処では接続履歴を開き、対象ドメイン、対象IP、マッチしたルール、出力ポリシー、実際のノードを確認します。

比較のため、短時間だけグローバルプロキシモードへ切り替えることもできます。グローバルモードでは使えるのにルールモードで失敗するなら、ルールの順序、ルールセットの読み込み、プロキシグループの選択を重点的に確認します。両方のモードで失敗するなら、原因はノード、DNS、システムプロキシ、ネットワークの入口に近いと考えられます。テスト後は元のモードに戻し、すべてのトラフィックが長時間想定外の経路を通らないようにしてください。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上の例は基本的な照合順序を示しています。特定ドメインのルールを先に置き、次に地域IPのルールを置き、最後にMATCHでそれまでにマッチしなかった接続を処理します。広範囲の直接接続ルールを特定のプロキシルールより前に置くと、後続のルールは実行されません。リモートルールセットを使う場合は、ルールセットがダウンロードされ、解析まで完了していることも確認します。

プロキシグループ名も一致している必要があります。ルールが指すグループが存在し、グループ内に利用可能なノードまたは有効な別のプロキシグループが含まれていなければなりません。自動選択グループは通常、定期的なテスト結果に基づいてノードを選びますが、テスト先に接続できないと誤判定することがあります。トラブル対処中は、実際のアクセスで検証済みのノードを手動選択し、自動選択による変動を排除できます。

6. DNS解決、fake-ip、暗号化DNSを確認する

DNSの障害は、ノードテストには結果があるのにドメインへのアクセスが待機し続ける、またはブラウザーに名前解決エラーが表示される一方でIPアドレスには接続できる、といった形で現れます。ClashのDNSモジュールはクエリを引き受け、設定に応じて実IPまたはfake-ipを返します。システムDNS、ブラウザーのセキュアDNS、クライアントDNSを同時に有効にすると問い合わせ経路が分岐しやすいため、まずリクエストを実際に処理している箇所を確認する必要があります。

DNS切り分けのポイント

  1. ログにDNSクエリのタイムアウト、名前が存在しないというエラー、上流サーバーへの接続不能がないか確認します。
  2. ブラウザー独自のセキュアDNSを一時的に無効にし、ブラウザーがシステムプロキシとシステムDNSに従うようにして、余分な経路を減らします。
  3. 設定のnameserverが現在のネットワークから到達可能か確認します。暗号化DNSのドメイン自体にも、利用可能なブートストラップ解決が必要です。
  4. fake-ipを使用している場合は、対象アプリが対応しているか確認し、LAN機器、システムサービス、実IPを必要とするドメインが正しく処理されることを確かめます。
  5. OSとブラウザーのDNSキャッシュを削除してから再テストし、古いレコードが設定変更を隠さないようにします。
dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

この設定例はフィールドの関係を説明するためのもので、すべてのネットワークにそのまま適用すべきではありません。上流サーバーの例に安定して接続できないネットワークもあり、企業ネットワークでは社内ドメインの解決に内部DNSが必要な場合もあります。実際の設定では、現在のネットワークから到達でき、利用環境に適したサーバーを選んでください。IPv6を無効にするとアクセスが回復する場合は、IPv6のルーティングを引き続き確認すべきであり、すべてのノード障害をDNSのせいにしてはいけません。

fake-ipモードでは、予約済みアドレスプールからマッピングアドレスを返し、カーネルがドメイン名を復元してルールを適用します。LAN内検出、固定されたDNS、特殊なネットワーク検査に依存するプログラムでは、フィルター対象への追加が必要になる場合があります。redir-hostモードは実際の解決結果を返すため互換性の経路が異なりますが、上流DNSの品質により強く左右されます。拡張モードを切り替えるとキャッシュと接続状態が変わるため、テスト時はカーネルを再起動して接続をやり直してください。

7. システムプロキシ、リスニングポート、ファイアウォールを確認する

ブラウザーは通常システムプロキシを読み込みますが、アプリによっては独自のHTTPまたはSOCKS設定だけをサポートし、システムプロキシをまったく参照しないものもあります。まず、クライアントに表示されるリスニングポートとOSのプロキシ設定が一致しているか確認します。たとえばクライアントがmixedポートで待ち受けている場合、システムプロキシが古い設定のポートを指したままになっていないか確認してください。

他のプロセスがポートを使用していると、カーネルの起動に失敗したり、別のポートへ切り替わったりします。ログにアドレスが使用中というエラーがある場合は、該当プロセスを終了するかリスニングポートを変更し、システムプロキシも合わせて更新します。システムプロキシを管理するClashクライアントを2つ同時に起動しないでください。プロキシアドレスやバイパスリストが互いに上書きされる可能性があります。

システムファイアウォールやエンドポイントセキュリティポリシーが、新しいカーネルのネットワークアクセス、ローカルポートの待ち受け、TUN仮想インターフェースを阻止することがあります。クライアント更新後はカーネル実行ファイルのパスが変わり、以前の許可ルールが一致しなくなる場合があります。システムのセキュリティ設定で現在のプログラムパスとネットワーク権限を確認し、ログでブロック時刻とテスト時刻が一致するか確かめてください。

8. TUNモードを有効にすると接続できない場合の対処

TUNモードは仮想ネットワークインターフェースを介して、より多くのシステムトラフィックを取り込みます。システムプロキシを読み込まないアプリや、透過転送が必要な場面に適しています。一方、システムプロキシよりもルーティング、DNS、権限に関する変数が多いため、通常のシステムプロキシが使えることを確認してから有効にしてください。システムプロキシモードでも接続できない状態でTUNを有効にすると、切り分ける層が増えるだけです。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

mihomoでよく使われるTUN設定には自動ルートや出口インターフェースの検出が含まれますが、対応するフィールドはカーネルのバージョンとクライアントの実装に依存します。有効化後は、仮想インターフェースが正常に作成されたか、デフォルトルートが生成されたか、出口インターフェースが正しく認識されたかを確認します。Windowsでは必要な権限が求められる場合があり、macOSではネットワーク拡張の承認が必要になることがあります。LinuxではTUNデバイス、Capability権限、ポリシールーティングが関係します。

有効化直後にネットワークが切断された場合は、まずTUNを無効にして基本ネットワークを復旧し、他のVPNや仮想ネットワークアダプターを終了します。カーネルを再起動し、ネットワークを取り込むツールは1つだけ有効にしてください。スリープ復帰、ネットワーク切り替え、ダイヤルアップの再接続後に問題が起きた場合は、TUNまたはカーネルを再起動して、現在のインターフェースに基づくルートを再生成します。

LANのバイパス範囲も確認します。プリンター、ルーターの管理画面、ローカルサービスは通常直接接続が必要です。誤って取り込むと「ネットワーク全体が壊れた」ように見えても、実際にはプライベートアドレスがプロキシへ送られているだけかもしれません。一方、バイパス範囲が広すぎると、対象アプリがプロキシを完全に迂回することもあります。アプリの画面だけで判断せず、接続ログでトラフィックがカーネルに入っているか確認してください。

9. 最小限の変数で最終検証する

層ごとの確認が終わったら、最小限のテスト構成で検証します。正常に読み込める設定、手動で選んだノード、明確なプロキシモード、安定した対象サイト、1種類のネットワーク入口を用意します。まずブラウザーで確認し、その後TUNが必要なアプリを検証します。毎回1つの変数だけを変更し、変更前後の結果を記録してください。

  1. TUNを無効にしてシステムプロキシだけを有効にし、ブラウザーのリクエストが接続ログに現れることを確認します。
  2. 既知の利用可能なノードを手動で選択し、テスト中に自動プロキシグループが切り替わらないようにします。
  3. ルールモードとグローバルモードをそれぞれテストし、ルールの適用が原因かどうかを判断します。
  4. 失敗したリクエストのドメイン、対象アドレス、マッチしたルール、プロキシグループ、出力ノード、エラー発生時刻を確認します。
  5. 別のネットワークへ切り替えて同じテストを繰り返し、現在の固定回線やLANに関連する障害かどうかを判断します。
  6. 基本プロキシが安定してからTUNを有効にし、仮想インターフェース、ルート、DNSが想定どおり変化しているか確認します。

障害情報を提出する場合は、OSのバージョン、クライアントのバージョン、mihomoまたはその他のカーネルのバージョン、設定の入手元の種類、ネットワーク環境、再現手順、機密情報を伏せたログ断片を含めます。ログはエラー前後の文脈を残しつつ、購読URL、認証情報、ノードの認証情報を削除してください。「ノードがタイムアウトした」の4文字だけでは、通常どの層の障害か判断できません。

切り分けの全体手順は、直接接続の可否 → カーネルの起動状態 → 購読と設定の読み込み → ノードのプロトコルパラメーター → プロキシグループとルールの適用 → DNS問い合わせ経路 → システムプロキシとポート → ファイアウォールと権限 → TUNルーティング、の順にまとめられます。接続経路に沿って進めるほうが、クライアントを何度も再インストールしたり、設定を無作為に切り替えたりするより、再現可能な結論に到達しやすくなります。

Clashをダウンロード