Clashのノードがタイムアウト・接続できないときの原因と対処法｜購読から出口まで順番に確認

まず症状を切り分ける：速度テストのタイムアウト、プロキシ接続の失敗、Webサイトの表示エラー

Clashでノードがタイムアウトしても、ノードのサーバーが停止したとは限りません。通常、遅延テストではノード経由でテスト先にリクエストを送ります。その結果は、ローカルネットワーク、ノードへの接続、プロキシのハンドシェイク、出口での名前解決、テスト先サイトの状態に左右されます。どこか1つでも失敗すれば、タイムアウトと表示されることがあります。まず失敗した段階を特定し、該当する設定だけを見直しましょう。DNSやポート、コアを次々に変更するのは避けてください。

Clashは、コアと設定を取り巻くエコシステムの総称です。クライアントは画面表示、サブスクリプション管理、システムプロキシなどを担います。Clash Metaは後にmihomoという名称になりました。クライアントによってメニューの場所、設定のマージ方法、コアの対応機能は異なります。トラブルシューティングでは、サブスクリプションのファイルだけで判断せず、実際に稼働しているコアのログと有効な設定を確認してください。

第1段階：サブスクリプションの更新成功と設定の有効化を確認する

まず、新しい設定がクライアントに読み込まれていることを確認してから、ノードの利用可否を調べます。サブスクリプションの更新成功、設定の解析成功、その設定への切り替えは、それぞれ別の操作です。リモートのサブスクリプション更新に失敗すると、クライアントがローカルのキャッシュを使い続けることがあります。ノード一覧に表示されているだけでは、今回の更新が成功したとは言えません。

1. 更新日時と結果を確認します。現在のクライアントで、使用中のサブスクリプションまたは設定を開いて更新し、HTTPステータスコードやエラー内容を記録してください。メニュー名はクライアントによって異なります。また、自動更新の間隔を直近の更新成功時刻と混同しないようにしましょう。
2. 取得した内容が設定ファイルか確認します。HTTP 200はリクエストの成功を示すだけです。ログインページや通信量超過の案内ページでも、ステータスコードが200になることがあります。ログにYAMLの解析エラーが出ている場合は、インデントをむやみに削るのではなく、まず取得した内容の種類を確認してください。
3. 設定が選択され、再読み込みされていることを確認します。切り替え後、ポリシーグループに想定したノードが表示されるか確認してください。ログに未対応フィールド、プロキシグループの不足、名前の重複、未対応のプロキシタイプがないかも確認します。
4. メイン設定とノードプロバイダーを区別します。proxy-providersを使用する設定では、ノードを取得する処理も別に行われます。メイン設定の更新が完了しても、プロバイダーからの取得が成功したとは限りません。

サブスクリプションの取得にプロキシが必要な場合は？

古いノードが使えず、サブスクリプションの更新もそのノード経由に設定されていると、更新できない状態に陥ることがあります。まず、現在のネットワークからサブスクリプションのドメインへ直接接続できるか確認します。クライアントに更新時のプロキシ設定があれば、一時的に利用可能と確認済みの経路へ切り替えてください。メイン設定のproxy-providersによる取得と、クライアント自身のサブスクリプション取得では仕組みが異なる場合があります。それぞれのログを確認しましょう。

トークンを含むサブスクリプションURLを、公開されている診断サイトに貼り付けないでください。サポートを依頼する場合は、ステータスコード、機密情報を伏せたエラー内容、更新時刻のみを伝えます。サブスクリプションURL全体が認証情報として機能することがあります。

第2段階：ローカルネットワークと接続先の切り替えによる違いを確認する

すべてのノードが突然使えなくなった場合は、まず共通して使うローカルの通信経路を確認します。システムプロキシとTUNを一時停止し、現在のネットワークから通常どおり直接アクセスできるWebページを開いてみてください。基本的なインターネット接続もできない場合は、Wi-Fi、有線LAN、認証ポータル、ルーターを先に確認します。テスト後は、必要なプロキシ設定を元に戻してください。

• ネットワーク認証を確認：ホテル、学校、公共のWi-Fiでは、先にブラウザーでログインが必要な場合があります。プロキシを有効にしていると、認証ページが正しく開かないことがあります。
• システム時刻を確認：日付、タイムゾーン、時計が大きくずれていると、証明書の有効期間を検証できない場合があります。システムの自動時刻設定を有効にしてから、TLSを使うノードを再テストしてください。
• 一時的にスマートフォンのテザリングへ切り替える：同じ端末、設定、ノードを使い、ネットワークだけを変更します。テザリングでは使えて元のネットワークでは失敗する場合は、元のネットワークのDNS、外向き通信の制限、IPv6経路を優先して調べてください。
• 複数のツールによる制御を避ける：ほかのVPN、プロキシクライアント、通信フィルタリングツールを一時終了し、複数のツールが同時にルートを変更しないようにします。トラブルシューティングのために、システムファイアウォールを長期間無効にしないでください。

テザリングでのテストは原因の範囲を絞るのに役立ちますが、それだけで通信事業者によるブロックを証明することはできません。モバイル通信と固定回線では、名前解決の結果、IPv4／IPv6の出口、経路が異なることがあります。遅延テストを繰り返すより、2回のテスト結果の違いを記録しましょう。

第3段階：待ち受けポートとアプリからコアへの通信を確認する

リモートノードを調べる前に、ローカルのプロキシ接続先が使えることを確認します。ポートの競合、コアの起動失敗、システムプロキシが古いポートを参照していることが原因で、アプリが「プロキシに接続できない」状態になる場合があります。以下はローカルの接続先フィールドの例です。待ち受けの関係を示すもので、ノード設定を含む完全な設定ではありません。

# 現在の設定のトップレベルにマージしてください。同じ名前のキーを重複して定義しないでください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付けます。この例ではポートに7890を使用しています。external-controllerはコントロール用のインターフェースであり、ブラウザー向けのプロキシ接続先ではありません。よく使われるコントロール用ポート9090を、アプリのHTTPプロキシ設定に指定しないでください。

7890を使用しているプロセスを確認する

WindowsではPowerShellで待ち受けの記録を確認し、表示されたプロセスIDから使用中のプログラムを特定できます。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOSではシステム標準のlsof、Linuxではssを使えます。プロセスの詳細を確認するには、適切な権限が必要な場合があります。

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

別のプロキシプロセスがポートを使用している場合は、まずどちらのプロセスがサービスを提供しているか確認し、重複しているプロセスを停止するかポートを変更します。ポートを変更した後は、システムプロキシとアプリの設定も合わせて更新してください。ログにaddress already in useと表示される場合は、まず待ち受けの競合を解消します。ノードを変更する必要はありません。

システムプロキシ設定を介さず、ローカルの接続先を明示してテストする

curl --noproxy "" -x http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

Windows PowerShellでは、上記のcurlをcurl.exeと記述してください。同名のエイリアスが設定されている環境での誤動作を防げます。--noproxy ""は、今回のリクエストでプロキシの除外リストをクリアします。5秒で接続待ちを打ち切り、15秒でリクエスト全体をタイムアウトさせます。

127.0.0.1:7890に接続できない場合は、まずコアと待ち受けポートを確認してください。200や301などのHTTPレスポンスを受け取った場合、今回のリクエストに応答があったことは分かりますが、接続ログで最終的なポリシーを確認する必要があります。ルールによってDIRECTで接続されている場合もあるため、レスポンスコードだけでプロキシノードが使えると判断しないでください。

第4段階：ノードのドメインと接続先ドメインの名前解決を切り分ける

DNSを調べるときは、まず「どのドメインの名前解決に失敗したか」を確認します。ノードのserverにドメイン名が指定されている場合、コアはノードへの接続前に名前解決を行います。接続先のWebサイトでも、別途名前解決が発生することがあります。ノードのアドレスの名前解決失敗と、Webサイトのドメインの名前解決失敗を、同じ原因として扱うことはできません。

• ノードのドメインで失敗：ログにlookup、no such host、名前解決のタイムアウトなどが記録されることがあります。まずシステムのツールでノードのドメインを検索し、AレコードやAAAAレコードが返るかを記録してから、コアの実際のログと比較します。
• 接続先のドメインで失敗：ノードとのハンドシェイクが成功していても、その後のリクエストが名前解決の失敗で中断することがあります。ローカル、コアのDNS、サーバー側の出口のどこで失敗したか確認してください。
• IPv6経路だけに問題がある：ログで実際に接続しているアドレスがIPv4かIPv6か確認します。システムの名前解決が成功していても、そのアドレスファミリーの通信経路が使えるとは限りません。また、コアが同じリゾルバーを使っているとも限りません。

以下は、mihomoでノードのドメインに専用のリゾルバーを使う場合の設定項目の関係を示しています。現在のコアが該当フィールドに対応している必要があります。この例は汎用的なDNS設定の推奨例ではありません。既存のdnsマッピングに統合し、同じ階層に2つ目のdnsを記述しないでください。

dns:
  enable: true
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserverは、プロキシノードのドメイン名を解決するための設定です。例にあるリゾルバーのアドレスが現在のネットワークから使えるとは限らないため、到達可能であることを確認したリゾルバーを選んでください。すでにDoH、Fake-IP、ドメインごとのリゾルバー設定を使っている場合は、既存の構成を維持し、障害に直接関係する箇所だけを変更します。

第5段階：プロトコル設定とコアの対応範囲を照合する

同じアドレスとポートでTCP接続できても、プロキシプロトコルのハンドシェイクが完了するとは限りません。ローカルの接続先が正常で、ノードのアドレスも解決できているのに、特定の種類のノードだけが失敗する場合は、プロトコルへの対応状況とサーバーの設定を確認します。旧バージョンのClashコアとmihomoでは、対応するプロトコルが異なります。クライアント画面にノード名が表示されていても、実行中のコアでそのプロトコルを使えるとは限りません。

まず、現在のコア向けにサービス提供元が用意した設定を取得してください。ノード名からプロトコルを推測したり、理解できないパラメーターを手動で削除したりしないでください。サブスクリプション変換を使っている場合は、変換先が実際に使用するコアに合っているか確認します。互換性のない変換では、トランスポートや認証の項目が失われることがあります。

TCPの到達性テストだけで分かるのは一部の情報

WindowsのTest-NetConnectionでは、指定したアドレスとポートへのTCP接続を確認できます。-ComputerNameの後を設定ファイルにある実際のノードドメインに、-Portの後を実際のポート番号に置き換えてください。このTCPテストの結果で、Hysteria2などUDPベースのプロトコルが使えると判断しないでください。

TCPテストが成功しても、その時点でポートへの接続を確立できたことしか分かりません。パスワード、TLS、プロキシのトランスポートは失敗する可能性があります。逆に、ノードがICMPに応答しないことも珍しくありません。pingのパケットロスだけで、プロキシサービスが使えないとは判断できません。

第6段階：サーバーの障害、出口の制限、速度テスト先の異常を確認する

サーバーや出口の調査に移るのは、それまでの各段階に問題がないと確認できてからです。同じノードで接続先を変えるテストと、同じ接続先でノードを変えるテストを組み合わせます。1つの遅延テスト先だけを繰り返し確認するのは避けてください。

1. 同じノードで2つの接続先を試す：通常のWebサイトにはアクセスできるのに、遅延テストだけが失敗する場合は、クライアントに設定されたテストURL、必要なレスポンス、タイムアウトのしきい値を確認します。テスト先の障害は、ノードの障害を意味しません。
2. 別のノードで同じ接続先を試す：特定の出口だけが失敗する場合、その出口から接続先までの経路、接続先によるアクセス制限、サーバー側の名前解決に問題がある可能性があります。
3. アカウントの状態を確認する：有効期限、残り通信量、同時接続できる端末数、サービス提供元からのメンテナンス告知を確認してください。サブスクリプションを取得できても、プロキシアカウントの通信量が残っているとは限りません。
4. 個人情報を伏せた証拠をサービス提供元に送る：障害の発生時刻とタイムゾーン、ノードの識別情報、コアのバージョン、エラーの種類、ネットワークを切り替えた結果、接続先のドメインを伝えてください。パスワード、UUID、サブスクリプションURL全体、設定ファイル全体は送らないでください。

connection refusedは、接続が明示的に拒否されたことを示します。ポートでサービスが待ち受けていない場合や、中間機器が接続を拒否した場合によく見られます。i/o timeoutは、ネットワーク操作が制限時間内に完了しなかったことを示します。接続、ハンドシェイク、読み書きのどの段階で起きたか、ログと合わせて確認してください。EOFはデータストリームの終了を示しますが、それだけでは認証失敗かリモート側からの切断かは特定できません。

ノード経由で通常のWebサイトを開けるのに、特定のプラットフォームで403、CAPTCHA、地域制限が表示される場合は、接続先サイトと出口の関係を調べます。接続タイムアウトを延ばしてもアプリケーション層の制限は解決しません。また、ローカルポートの障害として扱うべきではありません。

復旧確認：実際の通信が想定したポリシーを通っているか確認する

トラブルシューティングの完了条件は、リクエストが成功し、通信経路が想定どおりであることです。遅延の数値が緑色になることではありません。ルールモードでは、クライアントがルールに従ってポリシーを選択します。一方、ノードテストでは指定したノードを直接テストすることが多く、実際の通信経路が異なる場合があります。接続画面または実行ログで、接続先ドメイン、適用されたルール、最終的に使われたノードを確認してください。

• ブラウザーでは失敗するが、プロキシを明示したリクエストは成功する：システムプロキシのポート、ブラウザー独自のプロキシ設定、拡張機能による通信制御、プロキシ除外リストを確認します。既存の接続が以前の経路を再利用している場合があるため、関連する接続を閉じてから再度リクエストしてください。
• ブラウザーは使えるが、ターミナルでは失敗する：ターミナルのツールがシステムプロキシを参照するとは限りません。まずこの記事のcurl -xを使った明示的なプロキシ接続で確認し、その後、ツールがサポートするプロキシ環境変数を設定するか判断してください。
• さらに多くのアプリの通信をプロキシ経由にする必要がある：TUNを使うと、システムプロキシを参照しない一部の通信も処理できますが、権限、ルーティング、DNS設定に依存します。TUNを有効にしても、期限切れのサブスクリプション、誤ったパスワード、使えなくなったノードは修復されません。
• ログレベルを一時的に変更した場合：調査後はlog-levelを通常使用するinfoまたは元の設定に戻してください。アクセス先の情報を含む大量のログを長期間残さないようにします。