1. ノードのタイムアウト・サブスクリプション更新失敗・通信未経由を切り分ける

Timeoutが表示されても、すぐにクライアントを再インストールしないでください。ノードの遅延テストに失敗した場合、指定時間内にテストが完了しなかったことしか分かりません。サブスクリプションを更新できない、ブラウザーがプロキシを使っていない、接続先ノードに到達できない、というのはそれぞれ別の問題です。症状を切り分けてから、根拠に基づいて対処しましょう。

ほかのプロキシやVPNをいったん停止し、使用中のクライアント名・バージョン、コアのバージョン、現在の設定名を控えます。Clashは、プロキシコアと設定エコシステムを指す一般的な呼び方です。現在のクライアントの多くはmihomoを採用しており、これは旧Clash.Metaから発展したコアです。対応プロトコルや設定項目はコアごとに異なります。特定のクライアントのメニューや機能を、すべての製品に共通するものとして扱わないでください。

症状最初に確認する箇所判断のポイント
サブスクリプションの更新時に401、403が返るサービス提供元のアカウントと利用権限リクエストが拒否された状態で、ノードサーバーのタイムアウトとは限らない
すべてのノードテストがTimeoutになる設定の読み込み状態、ネットワーク、DNS共通の依存要素に問題がある可能性が高い
特定のノードだけタイムアウトするそのノードのアドレス、ポート、サービス稼働状況同じ端末でほかのノードは使える
遅延テストは成功するが、ブラウザーで開けないシステムプロキシ、ルール、接続ログテストの成功だけでは、アプリの通信がコアを経由したとは限らない
Webページは開けるが、遅延テストに失敗するテストURLとタイムアウト時間テスト先に到達できない、またはアクセスが制限されている可能性がある

2. 端末のネット接続・システム時刻・サブスクリプションを確認する

まずネットワークのログイン画面と時刻のずれを確認する

  1. クライアントのシステムプロキシとTUNを一時的にオフにして、プロキシなしでアクセスできるWebサイトを試します。大学やホテル、公共Wi-FiでWeb認証が必要な場合は、先にログインを済ませてください。
  2. Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認して「今すぐ同期」をクリックします。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認してください。
  3. 現在のWi-Fiをスマートフォンのテザリングに切り替え、設定とノードはそのままで再テストします。ネットワークを変えて復旧した場合に限り、ローカルネットワーク経路やネットワークポリシーに問題がある可能性が高まります。

システム時刻が大きくずれていると、TLS証明書の検証に失敗したり、時刻に依存する認証に影響したりすることがあります。ログにcertificate has expiredまたはcertificate is not yet validと表示されたら、まず端末の時刻と証明書の有効期間を確認してください。証明書検証を無効にして問題を隠すのは避けましょう。connection refusedは通常、接続を明示的に拒否された状態で、接続を待ち続けるタイムアウトとは異なります。

サブスクリプションの更新と有効化を確認する

Clash Verge Revの一般的な画面を例に説明します。「サブスクリプション」を開いて現在のサブスクリプションカードを選び、更新を実行します。その後、設定が選択中であることを確認してください。ボタンの場所はバージョンによって異なる場合があります。更新結果、更新日時、ノード一覧に想定どおりの変化があるかを確認しましょう。新しいファイルがダウンロードされても、読み込みに成功したとは限りません。設定の構文に誤りがある場合、以前の有効な設定が引き続き使われることもあります。

  • 401または403が返る：サービス提供元のアカウント、有効期限、サブスクリプションURLが再発行されていないかを確認します。HTTPステータスコードだけで、プランの期限切れとは断定できません。
  • 200が返るのにインポートでエラーになる：応答の内容がログイン画面やエラー説明、不対応形式ではなく、利用可能なClash YAML設定かどうかを確認します。
  • ノードは表示されるが、すべて使えない：古い設定が端末に残っていても、アカウントの期限切れとともにノード名が自動で消えるとは限りません。サービス提供元のアカウントページで残り通信量と有効期限を確認してください。
  • プロキシ経由の更新に失敗する：クライアントにサブスクリプション更新用プロキシの設定がある場合、「使えないノードに接続しないと更新できない」という状態になっていないか確認します。現在のネットワーク環境に応じて、直接接続での更新も試してください。

サブスクリプションURLにはアクセストークンが含まれていることがよくあります。URL全体を公開フォーラムやスクリーンショット、ログの添付ファイルに載せないでください。再インポートが必要な場合は、サービス提供元のアカウントページから現在有効なURLをコピーし、比較できるよう元の設定も残しておきましょう。

3. ローカルポートとコアの待ち受け状態を確認する

アプリは実際に待ち受けているポートへ接続する必要があります。以下では127.0.0.1:7890を例にしますが、7890がすべてのクライアントの固定デフォルト値というわけではありません。クライアントの設定または現在有効な設定でmixed-port、port、socks-portを確認し、コマンドのポートを実際の値に置き換えてください。external-controllerは管理用インターフェースであり、Webプロキシのポートとしては使えません。

Windows：待ち受けポートとプロセスを確認する

PowerShellを開き、次のコマンドを実行します。1つ目はローカルTCP接続が確立できるかを確認し、2つ目は待ち受けプロセスのIDを表示します。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

TcpTestSucceeded : Trueは、そのポートに接続できることを示すだけです。「タスクマネージャー」→「詳細」でPIDを検索し、対応するプロセスを確認してください。PIDが別のプロキシソフトに属していれば、ポート競合の可能性があります。待ち受けがない場合は、リモートノードを変更する前に、コアの起動や設定の読み込みエラーを確認しましょう。

macOSとLinux：同じ待ち受けポートを確認する

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

# Linux
ss -lntp 'sport = :7890'

システム権限によっては、プロセス情報を確認できない場合があります。ログにaddress already in useと表示されたら、ポートを使用中の古いプロセスを終了するか、プロキシポートを7893などの未使用ポートに変更してください。変更後は、システムプロキシ、ブラウザー拡張機能、ターミナルのプロキシ環境変数も同じ値に更新します。YAMLだけを変更しても不十分です。

4. 明示的なプロキシ接続でシステムプロキシとノードの問題を切り分ける

ローカルポートに接続できたら、プロキシを明示してリクエストを1回実行します。このテストでは「アプリがシステムプロキシを参照しているか」という不確定要素を回避できますが、クライアントの現在のモードやルールの影響は受けます。特定のノードを調べる場合は、一時的にグローバルモードに切り替えて対象ノードを選択し、テスト後に元のルールモードへ戻してください。

# Windows PowerShell；古い環境で同名のエイリアスを避けるため、curl.exeを使用
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

ここでの5秒は接続タイムアウトの上限、15秒はリクエスト全体の上限であり、実測遅延ではありません。このコマンド例では、ポートがHTTPプロキシに対応している必要があります。実際の入口がSOCKSのみの場合は、対応するポートとsocks5h://プロトコルを使ってください。example.comはテスト先の例です。結果に問題がある場合は、利用できることを確認済みの別のHTTPSサイトでも試してください。

  • 127.0.0.1に接続できないと表示される：ローカルの待ち受け状態を確認してください。この段階ではリモートノードは関係ありません。
  • 200 Connection establishedしか表示されない：HTTPプロキシがトンネル確立の応答を返したことを示すだけです。TLS接続と最終的なWebサイトの応答まで完了したか、続けて確認してください。
  • 最終的なHTTP応答が返る：このリクエストの通信経路が少なくとも機能したことを示します。403や405が返った場合も、Webサイト側のアクセス制限と接続タイムアウトを区別してください。
  • 明示的なプロキシ接続は成功するのに、ブラウザーでは失敗する：ブラウザー拡張機能、システムプロキシの例外リスト、アプリ独自のプロキシ設定を優先して確認します。

システムプロキシのスイッチとOSの設定を一致させる

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートがクライアントの設定と一致するか確認します。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続の「詳細」→「プロキシ」を開き、WebプロキシとセキュアWebプロキシを確認します。提供元が不明な自動プロキシスクリプトと手動プロキシ設定を同時に使わないでください。

クライアントの「接続」と「ログ」を開いた状態でWebページを再読み込みします。該当する接続がまったく記録されない場合、通信がコアに入っていないか、ブラウザーの既存接続が再利用されている可能性があります。ページを閉じて開き直し、再度確認してください。記録があり、宛先がDIRECTなら、プロキシノードの障害と決めつけず、適用されたルールを確認しましょう。

5. DNSの名前解決失敗とfake-ipの経路問題を切り分ける

DNSの確認は2段階に分けます。1つ目は「ノードサーバーのホスト名を名前解決できるか」、2つ目は「Webサイトのドメイン名がどう解決されるか」です。ノードのアドレス自体を解決できない状態でWebサイトを切り替えて試しても意味はありません。Webサイトの名前解決に問題があっても、すべてのノードが壊れているとは限りません。

ログからドメイン名とエラー発生段階を確認する

クライアントのログを開き、接続エラーを確認できるログレベルに一時的に設定して、失敗した操作をもう一度行います。エラーに記録されたドメイン名、ポート、時刻を控えてください。no such hostは通常、名前解決の失敗を示します。i/o timeoutは、前後のログを確認し、DNS問い合わせ、リモート接続、プロトコルのハンドシェイクのどの段階で発生したかを判断します。最後に表示されたTimeoutだけを切り出しても、情報が足りないことがよくあります。

# Windows：システムの名前解決経路を確認
Resolve-DnsName example.com

# macOS / Linux：nslookupが使える場合
nslookup example.com

これらのコマンドで主に確認できるのは、システムが使用する名前解決経路です。mihomo内蔵DNSの結果と一致するとは限りません。システムでは名前解決できるのにコアで失敗する場合は、ブラウザーのキャッシュを何度も消すのではなく、現在有効な設定のdnsセクション、DNSサーバーへの到達性、ノードのホスト名解決設定を確認してください。

fake-ipアドレスはノードサーバーのアドレスではない

fake-ipモードでは、コアが設定されたアドレスプールから合成アドレスを割り当てます。よくあるアドレスプールの例は198.18.0.1/16です。アプリがこの範囲のアドレスを取得しても、DNSが改ざんされたとは限りません。コアは対応するマッピングからドメイン名を復元し、ルール判定と接続処理を行います。実際にこの範囲を使うかどうかは、現在の設定を確認してください。

  • TUNをオフにしても、アプリが合成アドレスにアクセスする：以前のDNSキャッシュが残っている可能性があります。関連アプリを終了し、元の名前解決経路に戻してからアプリを起動し直してください。Windowsではipconfig /flushdnsを実行して、システムのDNSキャッシュを消去できます。
  • 特定のLANアプリだけで問題が起きる：実IPアドレス、LAN内のデバイス検出、独自DNSに依存していないか確認します。すべてのドメインを例外にするより、対象ドメインだけをfake-ipの例外にするほうが管理しやすくなります。
  • 暗号化DNSに切り替えてからタイムアウトする：DNSサービス自体に接続できるか、サービスのドメイン名を解決するために別のDNSが必要かを確認してください。暗号化DNSでも、すべてのネットワークから利用できるとは限りません。

比較する場合は、バックアップした設定で、クライアントとコアが対応する別のDNSモードに一時的に切り替えます。その後、設定を読み込み、アプリを再起動してテストしてください。変更は一度に1項目だけにします。リモートサブスクリプションの更新で直接編集した内容が上書きされることがあります。恒久的な修正は、クライアントの上書き・マージ機能を使ってください。設定項目の詳細は設定リファレンスを参照してください。

6. TUN・ほかのVPN・ネットワーク制御の競合を個別に確認する

システムプロキシは正常でTUNだけが動かない場合は、まず通信の経路を確認します。TUNは仮想ネットワークインターフェースとルーティングで通信を処理するため、システムプロキシとは適用範囲が異なります。有効にしても、期限切れのサブスクリプションや停止中のリモートサーバーは直りません。テスト中はほかのVPN、通信高速化ツール、同種の仮想ネットワークアダプターを一時停止し、複数のプログラムがデフォルトルートやDNSを同時に変更しないようにしてください。

  1. TUNをオフにしてシステムプロキシは有効のまま、前のセクションにある明示的なプロキシリクエストを実行します。成功すれば、ローカルのプロキシ入口と選択したノードで、少なくとも今回のリクエストを完了できたと判断できます。
  2. システムプロキシをオフにしてからTUNを有効にし、通常のブラウザーで同じテスト用Webサイトにアクセスします。同時に接続ログも確認してください。
  3. 2つ目のテストに失敗した場合は、サービスが未インストール、権限不足、仮想インターフェースの作成失敗などのメッセージがクライアントに表示されていないか確認します。デスクトップクライアントでは、該当するシステムサービスのインストールや起動が必要な場合があります。
  4. 元のスイッチ設定に戻し、クライアント終了後もネットワークが正常に復旧することを確認してから、TUNを使い続けるか判断してください。

Androidでは通常、同じユーザー環境でシステムのVPNサービスを使えるアプリは1つだけです。別のVPNを起動すると、既存の接続が置き換えられる場合があります。iOSのネットワーク拡張機能も、システムとクライアントの実装上の制約を受けます。スマートフォンでは、デスクトップの7890ポート確認手順をそのまま試すのではなく、システムのVPN状態とクライアントログを確認してください。

TUN使用時に、大きなWebページやアップロード、動画だけが止まり、小さなリクエストは正常な場合に限り、経路MTU、UDP対応、特定プロトコルの問題を調べます。出所不明のMTU値をそのまま設定しないでください。まず再現する接続先、通信の種類、ネットワーク環境を記録し、設定を1つずつ比較してテストしましょう。

7. 最後にリモートノードと遅延テストの接続先を確認する

ローカルの待ち受け、通信の経由、DNSについて確認できたら、ノードに到達できるかを調べます。同じ端末、同じネットワーク、同じWebサイトを使い、ノードだけを切り替えてください。あるノードでは連続して失敗し、別のノードでは連続して成功する場合、問題は失敗したノードか、そのノードまでのネットワーク経路にある可能性が高くなります。

遅延テストの結果だけでは、通信全体の正常性は分からない

クライアントの遅延テストでは通常、ノード経由で指定URLにアクセスします。テストURL、タイムアウトのしきい値、サーバーの応答ポリシーによって結果は変わります。クライアントでタイムアウトを設定できる場合は、たとえば3000ミリ秒から8000ミリ秒に一時的に変更して比較できます。これは待ち時間を延ばすだけで、速度が上がるわけではありません。軽いテストに成功しても、動画、UDP、長時間接続が正常とは限りません。

リモートのTCPポートに接続できても、TCPハンドシェイクが到達したことしか分かりません。認証、TLS、プロキシプロトコルのハンドシェイクが成功した証拠にはなりません。UDPベースの通信を使うノードもあり、その場合はTCPポートのテスト自体が適切ではありません。pingの成否でノードの良し悪しを判断しないでください。サーバーがICMPに応答しなくても、プロキシサービスは使える場合があります。

  • 特定のノードだけ失敗する：サブスクリプションを更新し、サービス提供元によってノードが変更されていないか、メンテナンスのお知らせがないか確認します。
  • 同じネットワークではすべて失敗し、テザリングでは正常：現在のネットワークの外部接続制限、DNS、リモート接続経路を重点的に調べます。
  • 2種類のネットワークで失敗し、ログに未対応プロトコルと表示される：設定の要件とコアの対応状況を確認し、クライアント公式の互換バージョンに更新してください。プロトコル名を安易に書き換えないでください。
  • ログに認証エラーまたはTLSエラーがある：アカウント、ノードの設定値、システム時刻を確認し、あらゆるハンドシェイク失敗をネットワークタイムアウトとして扱わないようにします。

8. 問い合わせ用の情報をまとめ、通常の設定に戻す

解決しない場合は、以下の情報をまとめて問い合わせると、「ノードがすべてタイムアウトする」とだけ伝えるよりも、的確な回答を得やすくなります。ログは障害発生の前後約30～60秒に絞り、サブスクリプションのトークン、パスワード、UUIDなどの認証情報を削除してください。

  • クライアント名、クライアントのバージョン、コアのバージョン、OSのバージョン。
  • 障害の発生日時とタイムゾーン、Wi-Fi・有線LAN・スマートフォンのテザリングのどれを使っていたか。
  • 失敗したのがサブスクリプションの更新、ノードテスト、特定アプリからのアクセスのどれか。
  • 実際に使っているローカルプロキシポート、待ち受けプロセスが正しいか、明示的なプロキシリクエストの結果。
  • システムプロキシとTUNのオン・オフ状態、ルールモードかグローバルモードか、適用されたポリシーグループ。
  • ノード、ネットワーク、テスト先を変えたときの結果。変更する項目は毎回1つだけにする。

テスト後は通常のルールモード、元のDNS設定、必要なプロキシスイッチに戻し、一時的なデバッグログを無効にしてください。最終判断は再現可能な証拠に基づいて行います。ポートが待ち受けているか、リクエストがコアに入っているか、ドメイン名を解決できるか、リモートのハンドシェイクが完了するかを順に確認しましょう。この手順で調べれば、「Clashに接続できない」という問題を、対処可能な段階まで絞り込めます。初期設定に慣れていない場合は、まずクイックスタートガイドで基本設定を確認してください。クライアントのよくある問題はヘルプセンターも参照できます。