Clashノードに接続できない・タイムアウトする場合の確認手順｜サブスクリプションからDNSまで

まず「タイムアウト」が発生した層を確認する

ClashクライアントにTimeoutと表示されても、ノード自体が無効になったとは限りません。サブスクリプションの取得、設定の読み込み、ノードとのハンドシェイク、DNSクエリ、ルール判定、システムプロキシの転送、TUNルーティングなど、似た症状が発生する箇所は複数あります。まず障害の範囲を記録してから順に確認すると、設定をすぐ削除したり再インストールしたりするより、早く解決できることが多いです。

最初に、次の3つを切り分けます。サブスクリプションを更新できるか、ノードの遅延テストに結果が出るか、ブラウザーや他のアプリから対象サイトにアクセスできるかです。3つはそれぞれ経路が異なります。更新失敗は、サブスクリプションURL、ネットワーク入口、証明書の時刻に関係することが多く、すべてのノードが同時にタイムアウトする場合は、現在のネットワーク制限、DNS、コアの停止、テスト先への到達不能などが考えられます。一部のノードだけ失敗するなら、ノードの回線、ポート、プロトコル設定の問題に近いでしょう。

第1段階：サブスクリプションの有効性と設定の読み込み結果を確認

サブスクリプションは設定の取得元であり、ノードそのものではありません。サブスクリプションURLの期限切れ、アカウント状態の変化、ダウンロード結果がログインページになること、サーバー側の一時的なエラーなどにより、クライアントが空の内容や不正な形式を受け取る場合があります。この場合、ノードをテストし続けても意味がありません。まず、クライアントが解析可能なYAML設定を実際に取得できているか確認します。

更新時刻とエラーメッセージを確認する

1. 設定またはサブスクリプションの画面で最終更新時刻を確認し、今回の更新が本当に成功したか確かめます。
2. クライアントにHTTPステータスコードが表示される場合は、401、403、404、429、5xxのいずれかを記録します。各コードは認証、URL、レート制限、サーバー障害などを示し、対処方法も異なります。
3. サブスクリプション名の下にプロキシノードとプロキシグループが存在し、空の設定だけが表示されていないことを確認します。
4. 更新後、現在の設定をもう一度選択し、ClashコアがYAML解析エラーを報告していないことを確認します。

設定の解析失敗は、インデント、重複フィールド、認識できないプロキシタイプ、またはクライアントのコアバージョンがサブスクリプション内のフィールドに対応していないことが原因になりがちです。Clash Meta（mihomo）用の設定は、該当フィールドに対応したクライアントで読み込む必要があります。Clashの従来コアとmihomoでは機能範囲が異なるため、クライアントの外観や名称だけで互換性を判断できません。

設定を手動編集した場合は、まずサーバー側の元のサブスクリプションに戻して比較します。YAMLではスペースで階層を表すため、Tab、誤ったインデント、コピー時に混入した記号などで読み込みに失敗することがあります。クライアント管理のサブスクリプションでは、キャッシュファイルを直接編集しても次回更新時に上書きされる可能性があります。カスタムルールは、クライアントが対応するオーバーライド、拡張、設定統合の場所に記述してください。

第2段階：ノード、ポート、現在のネットワークへの到達性を確認

ノードの遅延テストでは通常、指定したノード経由でテストURLにアクセスし、応答時間を測定します。テスト失敗は、DNS名前解決、TCP接続、TLSハンドシェイク、プロキシプロトコルのハンドシェイク、対象ページの応答など、さまざまな段階で発生します。クライアントによってはTimeoutとしか表示されないため、具体的な箇所を特定するにはログも必要です。

まず相互テストを行う

• 同じサブスクリプションから、地域と入口が異なるノードを3〜5個選び、1つのノードだけをテストしないようにします。
• 同じ端末で自宅のネットワークとスマートフォンのテザリングを切り替えます。テザリングでは使えるのに元のネットワークですべてタイムアウトする場合は、元のネットワークのDNS、ルーティング、ポート制限、ゲートウェイ設定を重点的に確認します。
• 同じネットワーク上で別の端末を使ってテストします。1台だけ失敗する場合、原因は通常、その端末の権限、プロキシ設定、ファイアウォールにあります。
• クライアントで遅延テスト先を変更できる場合は、安定したHTTPSアドレスを選んで再テストします。1つのテストサイトに到達できないだけなら、ノードが無効とは限りません。

pingの結果を、そのままプロキシノードの状態とみなさないでください。サーバーがICMPに応答しなくても、プロキシプロトコルが使うTCPまたはUDPポートは利用できる場合があります。反対に、サーバーへpingが通っても、該当するプロキシポートが開いているとは限らず、認証やプロトコルのハンドシェイクが成功したことも意味しません。

TCPとUDPの問題を切り分ける

通常のウェブページは主にTCPとTLSを使用しますが、一部のゲーム、音声通話、QUIC、DNSではUDPが使われます。ウェブページは開けるのに特定のアプリだけタイムアウトする場合、ノードやプロトコルが利用可能なUDP転送に対応していないか、TUNのUDPルーティングが機能していない可能性があります。まず通常のHTTPSページでTCPプロキシを確認し、その後UDPが必要なアプリを個別に検証して、2種類の問題を混同しないようにします。

特定のネットワークだけですべてのノードが同時に失敗し、ネットワークを切り替えるとすぐ復旧する場合、ノードを1つずつ削除する必要は通常ありません。まずルーターを再起動し、ネットワークを切断して再接続し、他のVPN、アクセラレーター、セキュリティソフトのネットワークフィルタリング機能が有効になっていないか確認します。複数のツールが同時に仮想NICを作成したりルーティングテーブルを変更したりすると、データが想定したClashインターフェースに入らないことがあります。

第3段階：システム時刻と証明書検証環境を調整

プロキシ接続、サブスクリプションのダウンロード、HTTPSアクセスでは、TLS証明書の検証が行われることがあります。システムの日付、タイムゾーン、時刻に大きなずれがあると、証明書がまだ有効でない、または期限切れと判定されます。クライアントログにcertificate、x509、handshakeなどの文字が現れることもあれば、単に接続失敗として表示されることもあります。

1. システムの「日付と時刻を自動的に設定」機能を有効にします。
2. タイムゾーンが現在地と一致していることを確認します。手動で選択したUTCオフセットには特に注意してください。
3. 今すぐ同期を1回実行し、Clashクライアントを完全に終了してから再起動します。
4. 端末が組織のポリシーで管理されている場合は、時刻同期サービスが接続できることを確認し、システムの証明書ストアが正常かどうかも確認します。

デュアルブート端末、長時間スリープしていたノートPC、初期化後のスマートフォン、長期間ネットワークに接続していなかった端末では、時刻が大きくずれやすくなります。時刻を調整した後は、ブラウザーのページを更新するだけでなく、サブスクリプションを再更新してノードをテストしてください。

第4段階：DNS名前解決、Fake-IP、汚染キャッシュを確認

DNS障害では、ノードの遅延はときどき正常なのにドメインを開くとタイムアウトする、既知のIPアドレスには応答するのにドメインでは失敗する、ログにlookup、resolve、nameserver、context deadline exceededが連続して現れる、といった症状がよく見られます。ClashのDNSモジュールは、プロキシノードサーバーのドメインを解決することも、ルール分岐の対象ドメインを処理することもあります。そのためDNSエラーは複数の段階に影響します。

まずシステムDNSが機能するか確認する

プロキシを終了するか、システムプロキシを一時的に無効にしてから、OS標準のツールで一般的なドメインを検索します。このコマンドは名前解決でアドレスが返るかを確認するためのもので、サイトへのアクセスが必ず完了することを示すものではありません。

nslookup www.example.com

検索自体がタイムアウトする場合は、ネットワークに再接続し、システムDNSキャッシュを更新するか、ルーターと端末のネットワーク設定でDNSアドレスを確認します。システムの検索は正常なのにClashログのDNS検索が失敗する場合は、設定内のdns、nameserver、fallback、proxy-server-nameserverなどのフィールドが現在のコアに対応しているか確認します。

Fake-IPモードの適用範囲を理解する

mihomoで一般的な拡張DNSモードにはfake-ipとredir-hostがあります。Fake-IPでは、まずアプリに予約アドレスを返し、コアがドメインとの対応関係を保持して、その後の振り分けを行います。予約アドレスが表示されても、必ずしも名前解決エラーではありません。確認すべきなのは、リクエストがClashに取り込まれているか、対応関係が存在するか、対象ドメインがルールに従って正しい出口を選んでいるかです。

一部のLAN機器の検出、社内ネットワークのドメイン、プリンターのアドレス、実際のDNS応答値に依存するプログラムは、Fake-IPに直接対応させるのに適していません。必要に応じてFake-IPの除外ルールを設定するか、LAN内のドメインに指定DNSサーバーを使用します。除外範囲はできるだけ明確にし、広すぎるワイルドカードでドメイン対応やルーティングの効果を損なわないようにします。

ノードサーバーのドメインは個別に解決する必要がある

プロキシノードのサーバーフィールド自体がドメインの場合、コアはプロキシ接続を確立する前にそのドメインを解決する必要があります。この問い合わせを、まだ接続されていないプロキシ経由に設定すると、循環待機が発生する可能性があります。mihomoにはプロキシサーバーのドメインを解決するためのDNS設定機能がありますが、具体的なフィールドは現在のコアバージョンに合わせる必要があります。確認時は、ログがノードサーバーのドメイン解決段階で止まり続けていないか確認します。

第5段階：システムプロキシ、ルールモード、TUNの取り込み範囲を確認

ノードは使えるのにアプリがプロキシを経由しない場合、取り込み方法に問題があることが多いです。Clashのシステムプロキシスイッチは、OSのプロキシ設定に従うプログラムへHTTPまたはSOCKSの入口を提供します。一部のゲーム、コマンドラインプログラム、ストアアプリ、独自のネットワークスタックを実装したソフトウェアは、システムプロキシを無視することがあります。TUNモードは仮想NICとルーティングによってより多くの通信を取り込みますが、追加の権限が必要で、他のVPNや仮想NICとも衝突しやすくなります。

まずルールモードでプロキシグループの選択を検証する

Ruleモードでは、通信が設定内のルールを上から順に照合し、一致した時点で該当するプロキシグループへ送られます。ノード自体が使えても、ルールによって対象ドメインがDIRECT、REJECT、または有効なノードが選択されていないプロキシグループへ送られると、アクセスは失敗します。接続履歴またはログを開き、対象ドメインがどのルールに一致したか、最終的にどのプロキシグループとノードが使われたかを確認します。

Globalモードでは大部分の通信を指定したプロキシグループへ送れるため、診断には適していますが、ルールの確認の代わりにはなりません。Globalでは使えるのにRuleでは使えない場合は、ルールの順序、ルールセットの読み込み状態、プロキシグループの選択を確認します。両方のモードで失敗する場合は、ノード、DNS、ローカルポートの確認に戻ります。

システムプロキシの確認手順

1. Clashコアが実行中であり、クライアントウィンドウが開いているだけの状態ではないことを確認します。
2. システムプロキシが有効になっていること、OSのプロキシアドレスがローカルの待受ポートを指していることを確認します。
3. 設定内のmixed-port、port、socks-portがクライアントに表示される値と一致していることを確認します。
4. ブラウザーに個別にインストールまたは設定した別のプロキシ入口を無効にし、リクエストが古いポートへ転送されないようにします。
5. 対象アプリを再起動します。プログラムによっては、起動時にしかシステムプロキシ設定を読み込みません。

TUNモードの確認手順

1. クライアントに仮想NICの作成、ルーティングの変更、ネットワークサービスのインストールに必要なシステム権限が付与されていることを確認します。
2. 他のVPN、仮想マシン用ネットワークツール、アクセラレーターを一時的に終了してから、TUNを再度有効にします。
3. システムに該当する仮想NICが表示されているか確認し、デフォルトルートが他のプログラムによって繰り返し上書きされていないことを確認します。
4. TUNを有効にした後にネットワーク全体が切断された場合は、まずTUNを無効にしてネットワークを復旧し、DNSハイジャック、ルート除外項目、インターフェースの自動選択を確認します。
5. LANアクセスに異常がある場合は、プライベートアドレスを直接接続すべきか、LANのセグメントが誤ってプロキシへ送られていないかを確認します。

システムプロキシは使えるのにTUNが使えない場合、ノードと基本的なプロキシプロトコルには問題がないことが多く、権限、仮想NIC、ルーティング、DNSの取り込みを重点的に確認します。TUNは使えるのにシステムプロキシが使えない場合は、ローカルの待受ポート、システムプロキシアドレス、アプリがプロキシ設定を読み込むかどうかを確認します。

第6段階：ローカルの待受ポート、ファイアウォール、ポート競合を確認

Clashコアは、HTTP、SOCKS、mixedの各ポートをローカルで待ち受ける必要があります。別のプロセスがポートを使用していると、コアの起動に失敗したり、自動終了したりすることがあります。ローカルのセキュリティポリシーがプログラムの待受やネットワーク接続を阻止している場合、クライアント画面は表示されていてもリクエストは完了しません。

まずクライアントログでaddress already in use、bind、permission denied、connection refusedなどを探します。address already in useは通常ポート競合を示します。127.0.0.1へのアクセスでconnection refusedが表示される場合は、該当ポートでサービスが待ち受けていない可能性があります。リモート接続でrefusedが出る場合は、ノード側のポートが閉じているか、サーバーが明示的に拒否している可能性があります。

設定で7890をmixedポートとして使用している場合は、次のリクエストでローカルのプロキシ入口を確認できます。実行時には、ポートをクライアントに現在表示されている値へ変更してください。

curl -x http://127.0.0.1:7890 https://www.example.com/ -I

このリクエストが成功すれば、コマンドラインプログラムがローカルのプロキシポートへ接続し、HTTPSリクエストを1回完了できたことを示します。それでもブラウザーが失敗する場合は、ブラウザーのプロキシ、証明書の警告、拡張機能の設定を確認します。ローカルポートへすぐ接続できないと表示される場合は、遠隔ノードを変更し続けるのではなく、まずコアの状態とポートの待受を確認します。

ファイアウォール確認のポイント

• 現在のClashクライアントとコアプログラムが、現在のネットワーク種別へのアクセスを許可されていることを確認します。
• クライアントの更新後は実行ファイルのパスが変わることがあるため、システムファイアウォールのルールを再確認します。
• 組織や学校のネットワークでは、一部の外向きポートが制限されている可能性があります。スマートフォンのテザリングで切り分けてください。
• ルーターのペアレンタルコントロール、アクセス制御、DNSフィルタリングも、ノードサーバーやサブスクリプションURLに影響します。
• 「LAN接続を許可」を有効にしたときだけ異常が発生する場合は、待受アドレスとLANのファイアウォールルールを確認します。ローカルプロキシポートを信頼できないネットワークに公開しないでください。

第7段階：ログで失敗した段階を特定し、最小構成で再テスト

ログの価値は、失敗がどの段階で発生したかを確認できる点にあります。ログレベルを一時的にinfoまたはdebugへ変更して問題を1回再現し、その後は元のレベルに戻して大量の記録が長時間残らないようにします。ログを共有する前に、サブスクリプションURL、認証情報、ノードの認証情報、個人のアクセス履歴が含まれる可能性のある内容を隠してください。

最小構成のテスト経路を作る

1. 正常に読み込める元のサブスクリプション設定を1つ保存します。
2. 利用可能であることを確認したノードを1つと、安定したHTTPSテスト先を1つ選びます。
3. まずTUNを無効にし、システムプロキシだけでブラウザーのアクセスを確認します。
4. システムプロキシが通ったら、Ruleモードを有効にしてルールの一致を確認します。
5. 最後にTUNを有効にし、システムプロキシを読み込まないアプリをテストします。
6. 各手順でログの変化を記録し、障害が見つかったら新しい変数を追加しないようにします。

この順序により、問題を設定の取得元、リモートノード、ドメイン名前解決、ローカルプロキシ、システム全体の取り込みという5つの範囲に分けられます。最小構成でも複数のネットワークですべてのノードがタイムアウトする場合は、サブスクリプションサービスの提供元にノードの状態とプロトコル設定を確認してください。元の設定だけが失敗する場合は、DNS、ルール、オーバーライド、TUNフィールドを重点的に比較します。

ノードのタイムアウト確認リスト

Clashのノードに接続できない場合は、次の固定手順で確認します。前の項目が正常だと確認してから次へ進めば、通常はクライアントを何度も再インストールする必要はありません。

1. 端末自体が通常のウェブサイトへ直接接続でき、現在のネットワークが切断されていないことを確認します。
2. サブスクリプションの更新が成功し、設定にノードとプロキシグループが存在し、コアの読み込みでYAMLエラーが出ていないことを確認します。
3. 複数のノードをテストし、別のネットワークまたは別の端末でも相互検証します。
4. 時刻とタイムゾーンの自動同期を有効にし、TLS証明書の検証異常を切り分けます。
5. システムDNS、ClashのDNS、ノードサーバーのドメイン解決をそれぞれ確認します。
6. プロキシグループの選択、ルールの一致、プロキシモードが想定どおりか確認します。
7. まずシステムプロキシを検証し、その後TUNの権限、仮想NIC、ルーティングを個別に確認します。
8. ローカルの待受ポートを確認し、ポート競合とファイアウォールの制限に対処します。
9. ログのキーワードから失敗した段階を特定し、最小構成で再テストします。