ノードがタイムアウトする・接続できないときの確認手順

1. 速度テストのタイムアウトと実際の接続失敗を区別する

FlClashの遅延テストは通常、ノードを経由して指定のテスト先にリクエストを送るもので、ノードサーバーへの単純なpingではありません。「タイムアウト」は、制限時間内にテストが完了しなかったことを示します。原因はノードの接続先、名前解決、プロトコルのハンドシェイクのほか、テストサイトにアクセスできないだけの場合もあります。まず状況を記録し、確認する箇所を絞りましょう。

2. ローカルネットワーク：通信の取り込みを無効にして直接接続できるか確認する

まずFlClashのシステムプロキシとTUNを無効にし、普段から直接接続できるサイトにアクセスします。OSに手動プロキシの設定が残っている場合は、そちらも確認して元に戻してください。クライアントを終了しただけでは、ローカルポートを指すプロキシ設定が残ることがあります。その場合、ブラウザーは待ち受けを停止したポートに接続し続けるため、ネットワーク全体が切断されたように見えます。

ネットワークの接続先とシステム時刻を確認する

1. ネットワーク認証を完了する。ホテル、学校、公共のWi-Fiでは、ブラウザーで認証が必要な場合があります。「ネットワークへのログインが必要です」というOSの通知がないか確認してください。
2. システムプロキシを確認する。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシとセットアップスクリプトを確認します。macOSでは「システム設定」→「ネットワーク」→使用中のネットワーク→「詳細」→「プロキシ」を開きます。
3. 時刻を合わせる。Windows 11では「設定」→「時刻と言語」→「日付と時刻」から確認できます。日付、タイムゾーン、時計のずれは、TLS証明書の検証や一部のプロキシプロトコルの認証に影響する場合があります。
4. 接続するネットワークを切り替える。ノードはそのままにして、パソコンを元のWi-Fiからスマートフォンのテザリングに切り替えます。テザリングで接続できる場合は、元のネットワークのDNS、ファイアウォール、または外部接続の制限を優先して確認してください。

一般的なWebサイトに直接接続できても、ノードのポートまで通信できるとは限りません。一方、pingに応答がなくても、サーバーやネットワーク事業者がICMPを遮断している可能性があるため、サーバーが停止しているとは断定できません。続いて、サブスクリプションに記載されたサーバーアドレスと実際のポートを確認します。

3. サブスクリプションの有効性：取得成功、設定の反映、アカウントの利用可否を区別する

FlClashの「設定」ページで使用中のサブスクリプションを探し、手動で更新して、現在選択されている設定と一致することを確認します。ボタン名はバージョンによって多少異なるため、実際の画面に従ってください。更新後は「プロキシ」ページでノード一覧と選択中のポリシーグループを確認し、古い設定や別のグループのノードをテストしていないか確かめます。

3つの段階で確認する

• サブスクリプションへのリクエスト：HTTP 401または403が返る場合は、URLの認証情報やサーバー側のアクセス制限を確認します。404の場合は、URLの有効期限切れやパスの変更を確認してください。HTTP 200はリクエスト成功を示すだけで、レスポンスが設定ではなくログインページの場合もあります。
• 設定の読み込み：ログにYAMLの構文エラー、未対応のプロキシタイプ、設定の読み込み失敗がないか確認します。他のクライアント向けの共有リンクは、そのままmihomoの完全な設定として読み込めるとは限りません。
• サービスアカウント：サブスクリプション提供元のページで、有効期限、残りの通信量、利用端末数、メンテナンスのお知らせを確認します。アカウントが無効でも、ローカルにノード一覧が残っていることがあります。

設定でリモートプロキシプロバイダーを使用している場合は、該当プロバイダーの更新状況も確認してください。メイン設定のダウンロードに成功しても、すべてのリモートリソースが更新されたとは限りません。再インポートが必要な場合はサブスクリプションのインポート手順を、サブスクリプションの提供元についてはサブスクリプションの提供元と利用範囲をご覧ください。

4. システムプロキシとTUN：通信がFlClashに届いているか確認する

システムプロキシは、OSのプロキシ設定に従うアプリに主に影響します。一方、TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。確認の始点はそれぞれ異なります。複数のクライアント、ブラウザーのプロキシ拡張機能、TUNを同時に有効にするより、まず片方だけで最小限のテストを行うほうが原因を特定しやすくなります。

デスクトップ：まずローカルプロキシポートを確認する

TUNを無効にし、FlClashのコアを起動したまま、クライアントに表示される実際の待ち受けアドレス、混合ポート、システムプロキシの設定を確認します。以下ではローカルの混合ポート 7890 を例にしています。別のポートを使う設定では、実際の値に置き換えてください。チュートリアルだけを頼りにポート番号を決めないでください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Windows PowerShellでは、コマンドの先頭を curl.exe にすると、古い環境で curl が別のコマンドとして解釈されるのを防げます。実行中はFlClashの接続ログも確認してください。HTTPレスポンスが返れば、そのプロキシリクエストは接続先に到達しています。ローカルポートへの接続が拒否された場合は、待ち受けポート、コアの稼働状態、ポートの競合を確認します。

• コマンドでは接続できるが、ブラウザーではできない：システムプロキシ、ブラウザー拡張機能、ブラウザー独自のプロキシ設定、別の自動プロキシスクリプトが使われていないか確認します。
• 接続はクライアントに届くが、出口が違う：「プロキシ」ページでモードとポリシーグループの選択を確認します。ルールモードでは接続先がDIRECTに振り分けられる場合があります。速度テストに成功しても、実際のWebアクセスにそのノードが使われるとは限りません。
• 接続ログにリクエストがまったくない：まずアプリがプロキシを経由せずに接続していないか確認してください。この段階では、リモートノードの設定を何度も変更しないでください。

TUN経由の場合：権限、ルーティング、VPNの競合を確認する

他のVPNや同種のTUNクライアントを停止し、システムの案内に従って必要な権限を許可してから、FlClashのTUNだけを有効にします。仮想インターフェースの作成失敗、権限不足、ルートの書き込み失敗がログに記録されていないか確認してください。デスクトップ環境では、システムやバージョンによって管理者権限、またはクライアントが提供するサービスが必要な場合があります。

AndroidではVPN接続リクエストを許可したか確認し、アプリのアクセス制御で対象アプリが除外されていないかも確認してください。別の「常時接続VPN」や「VPN未接続時に接続をブロックする」設定が有効な場合も確認が必要です。ファイアウォールを長時間無効にしてテストするのは避けてください。ブロックログを確認し、信頼できるクライアントに必要な範囲だけルールを設定します。

5. DNS設定：ノードのドメインと接続先のドメインを分けて確認する

プロキシ接続では通常、2種類の名前解決が関係します。1つはノードサーバーのドメインを接続先IPに変換する処理、もう1つはアクセス先サイトのドメインを解決する処理です。ノードの接続先を解決できない場合、通信はプロキシサーバーに届きません。接続先サイトのドメインを解決できない場合は、ノードの速度テストが正常でも一部のページが開けないことがあります。ログに記録されたホスト名を確認して原因を判断してください。

まずOSの名前解決結果と比較する

nslookup example.com

コマンド内のドメインを、実際に問題が起きているWebサイトのドメイン、または設定内のノードサーバーのドメインに置き換えます。タイムアウト、レコードなし、想定外のアドレスでは、それぞれ確認すべき箇所が異なります。nslookupの結果は、その時の問い合わせ経路を反映するもので、mihomoの最終結果と同じとは限りません。TUNのDNSハイジャックが有効な場合、問い合わせがクライアントに取り込まれることもあります。

• ログに名前解決エラーがある：まずDNSの上流サーバーに接続できるか確認してください。暗号化DNSを使う場合は、そのサーバーのドメインを解決するための事前処理も必要です。関連する通信が正しくルーティングされているか確認します。
• 接続や名前解決が繰り返される：ノードの接続先を解決するためのDNSリクエストが、接続に失敗している同じプロキシへ再び送られていないか確認します。
• ブラウザーだけで問題が起きる：ブラウザーの「セキュアDNS」や独自の名前解決設定を確認します。一時的にOSのDNS設定へ戻して比較し、同じURLに再度アクセスしてください。
• Fake-IPアドレスが返される：Fake-IPモードの設定では、一般的な設定範囲に含まれる 198.18.0.0/16 のアドレスが表示されても、ただちに名前解決エラーとは限りません。アドレスの対応関係と通信の取り込み経路を続けて確認してください。

mihomoの設定で nameserver と proxy-server-nameserver は用途が異なり、後者はプロキシノードのドメイン解決に使われます。サブスクリプションやオーバーライド機能で設定が管理されている場合は、変更前にバックアップを取り、最終的に反映される内容を確認してください。DNS設定をむやみに丸ごと貼り付けると、名前解決モード、ルーティング、ルールの適用条件まで同時に変わるおそれがあります。

6. ノード自体を確認する：接続先への到達からプロトコルのハンドシェイクまで

ここまでのローカル側の確認が終わったら、リモートノードを調べます。ノードを1つに固定し、元のネットワークとスマートフォンのテザリングでそれぞれテストします。次にネットワークを固定し、接続先の異なるノードに切り替えて比較します。名前が異なるノードでも同じサーバーを共有している場合があるため、地域名だけでなくサーバーアドレスも確認してください。

エラーが起きた段階ごとにログを読む

TCP接続を使うノードの場合、Windows PowerShellで実際のサーバーポートに到達できるか確認できます。以下はコマンド形式の例です。ドメインには予約済みの例示用ドメインを使用しているため、実行結果を実際のノードの状態とみなさないでください。

Test-NetConnection -ComputerName node.example.com -Port 443

設定に記載された実際のアドレスとポートに置き換え、利用権限のあるサービスだけを確認してください。TcpTestSucceededがTrueでも、確認できるのはTCP接続の確立だけです。パスワード、TLS、WebSocketのパス、プロキシプロトコル全体が正しいとは限りません。Hysteria2やTUICなどUDP通信を使うノードは、TCPテストの結果では利用可否を判断できません。

TCPで到達できてもプロトコルのハンドシェイクに失敗する場合は、サービス提供元から設定を再取得し、サーバー名、認証情報、通信パラメーターを確認してください。証明書エラーが起きた場合は、時刻、証明書チェーン、サーバー名の設定を修正します。証明書検証の無効化を恒久的な対処にしないでください。

7. 復旧後の確認：結果を記録してから通常のモードに戻す

ノードが復旧したら、普段使うルールモードに戻し、必要なシステムプロキシまたはTUNを再び有効にします。直接接続するサイト、プロキシが必要なサイト、よく使うアプリを順に確認し、接続ログで適用された出力ポリシーを確認してください。グローバルモードでアクセスできても、その時点のプロキシ経路が使えたことしか分かりません。ルールモードでの振り分けは別途確認が必要です。

1. 環境を記録する：OS、FlClashのバージョン、コアのバージョン、障害が発生した日付と時刻を記録します。バージョン情報はクライアントの表示を基準にしてください。
2. 比較結果を記録する：元のWi-Fiとテザリングで差があるか、同じノードが他の端末で使えるか、別の接続先は正常かを記録します。
3. 通信経路を記録する：システムプロキシとTUNのどちらを使ったか、実際の待ち受けポート、出力モード、リクエストに適用されたポリシーグループを記録します。
4. エラーを保存する：今回の問題を再現した箇所に関係するログだけを切り出し、認証情報、サブスクリプションURL、不要なアクセス履歴を隠します。

すべてのノードが特定のネットワークでのみ失敗する場合は、そのネットワークの名前解決と外部接続の制限を優先して確認します。特定のノードが複数のネットワークや端末で失敗する場合は、接続先とログの情報をサービス提供元に伝えて調査を依頼してください。原因を段階ごとに絞ってから設定を変更すれば、変更と結果の因果関係を保てます。通信の取り込みやルールによる振り分けについてはプロトコル詳解をご覧ください。