トラブル対処 読了時間：約10分

FlClashのノード接続がタイムアウトする・接続できないときの対処法｜サブスクリプション、時刻同期、DNSを順番に確認

ノード接続のタイムアウトは、サブスクリプションと設定の更新、システム時刻、ポートとファイアウォール、DNS、通信モードの順に確認します。症状ごとの原因と対処法を解説します。

1. ノードテストのタイムアウトと実際の通信障害を切り分ける

FlClashのノードテストに失敗しても、すべてのウェブページにアクセスできないとは限りません。テストでは指定された確認用URLにアクセスするため、そのURLがブロックされている、異常な応答が返る、応答が制限時間を超えるといった場合にもタイムアウトになります。一方、テストに成功しても、その時点での接続確認ができただけです。すべてのドメインやUDP通信、アプリの接続が正常とは限りません。

切り分けを始める前に、FlClashのバージョン、OSのバージョン、使用中の設定名、通信モード、失敗した時刻を記録しておきます。その後、同じURLと同じ方法で再テストし、一度に変更する設定は1つに絞ります。バージョンによってメニューの位置が異なる場合があるため、以下では設定項目名と確認可能なシステム操作を基準に説明します。例示するポート番号は、クライアントの既定値を示すものではありません。

症状まず確認する項目判断の目安
サブスクリプションの更新エラー、リストが空サブスクリプションURL、応答内容、設定の解析この時点では、利用可能なノード設定がまだ読み込まれていません
特定のノードだけ接続できないノードの提供状況、プロトコルのパラメーター同じネットワークで、ほかのノードから同じURLにアクセスできる
すべてのノードで失敗するローカルネットワーク、時刻、コアの起動状態複数の異なるノードで失敗する
テストは成功するが、ブラウザーで開けないシステムプロキシ、ルール、DNSテスト通信とブラウザーの通信は、異なる経路を通る場合があります
ブラウザーでは使えるが、特定のアプリでは使えないアプリのプロキシ対応、UDP、TUNシステムプロキシでは、通常すべてのアプリの通信を経由させることはできません

ほかのプロキシクライアントやVPNを一時的に停止し、複数のプログラムが同時にシステムプロキシやルーティングを書き換えるのを防ぎます。社内ネットワークへの接続が必要な場合は、管理対象のセキュリティソフトを独断で停止せず、許可されている接続方法を管理者に確認してください。

2. サブスクリプションの更新と使用中の設定を確認する

更新に成功したら、実際に使用中の設定も確認する

  1. FlClashの設定一覧を開き、使用するサブスクリプションを選んで更新します。更新結果と最終更新時刻を記録してください。
  2. 現在選択されている設定が、更新したものと同じか確認します。リストに新しい設定が表示されていても、コアがその設定に切り替わったとは限りません。
  3. プロキシ画面に、想定したプロキシグループとノードが表示されているか確認します。グループが空の場合は、DNSを直接変更せず、まず設定の読み込みエラーを確認してください。
  4. 現在のルールが参照しているプロキシグループでノードを手動選択し、同じURLをテストします。自動選択グループはテスト中に接続先が切り替わることがあり、結果を比較できなくなる場合があります。

サブスクリプションのダウンロード失敗とノードの接続失敗は、別の処理経路で起きます。前者はクライアントが設定を取得する処理、後者はmihomoコアが設定に従ってサーバーへ接続する処理です。以前の設定が引き続き動作する場合もあるため、「サブスクリプションの更新に失敗したのにウェブページは開ける」という状況は矛盾しません。

応答されたエラーに応じて対処し、同じURLを何度もインポートしない

  • HTTP 401または403：サブスクリプションの有効期限、リンクの再発行状況、サーバー側のアクセス制限を確認します。これらのステータスコードはゲートウェイから返される場合もあるため、応答元も確認してください。
  • HTTP 200だが設定を解析できない：ログイン画面、認証画面、または互換性のない内容が返されている可能性があります。ステータスコードが成功でも、有効な設定が返されたとは限りません。
  • ドメインを解決できない、または接続がタイムアウトする：現在のネットワークからサブスクリプションのドメインにアクセスできるか確認します。サブスクリプションの更新にプロキシが使われるかどうかは、クライアントのバージョンや関連設定によって異なります。ブラウザーでの結果だけから判断することはできません。
  • 更新後に一部のノードが消えた：プランの状態やサービス提供側の変更を確認し、設定内で参照しているプロキシグループも確認します。利用できなくなった項目を選び続けないようにしてください。

3. ネットワークとシステム時刻を確認する

FlClashのシステムプロキシとTUNをオフにし、通常の直接接続でウェブページを開けるか確認します。ネットワークにポータル認証が必要な場合は、先にWi-Fiへログインしてください。パソコンをスマートフォンのテザリングに切り替え、設定とテストURLは変えずに確認します。同じノードが特定のネットワークでだけ失敗する場合は、クライアントの再インストールより先に、そのネットワークの出口制限、ルーティング、UDP対応を疑ってください。

時刻のずれはTLSや一部プロトコルの認証に影響する

システムの日付、表示されるタイムゾーン、実際の時刻をそれぞれ確認します。タイムゾーンの表示が異なるだけで認証に失敗するとは限りませんが、システム時計が実際の時刻からずれていると、証明書が有効期間前または期限切れと判定されることがあります。時刻の検証を行う一部のプロトコルでも接続が拒否されます。

  • Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにしてから「今すぐ同期」を実行します。
  • Android：通常は「設定」→「システム」→「日付と時刻」で自動設定をオンにします。メーカーによっては「その他の設定」にある場合があります。
  • macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定がオンになっていることを確認します。

同期後に接続し直し、証明書エラーが解消したか確認します。時刻が正しいのにTLSエラーが続く場合は、サーバーのドメイン名、証明書、設定内のTLSパラメーターを確認してください。証明書の検証を無効にする方法を常用しないでください。接続先の認証が弱まり、サーバーに到達できない問題の解決にもなりません。

4. 混合ポート、コアの起動状態、ファイアウォールを確認する

システムプロキシは、プロキシに対応したアプリをローカルの待ち受けポートへ接続させる機能です。mihomoが起動していない、または別のプログラムが待ち受けポートを使用している場合、ブラウザーでプロキシが設定済みと表示されていても、FlClash経由の接続は確立できません。まずクライアントのログに address already in use、bind、設定の読み込み失敗に関する情報がないか確認してください。

実際の混合ポートを使って明示的なプロキシ接続をテストする

FlClashの設定で「混合ポート」を確認し、ポート番号を控えます。以下では例として 7890 を使用します。クライアントに表示されているポートも7890の場合に限り、そのまま実行してください。テストURLは、現在アクセスする必要があり、アクセスが許可されているHTTPSサイトに置き換えられます。

# Windows PowerShell：7890の待ち受けプロセスを確認
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Windows：ローカルHTTPプロキシを明示してリクエストを送信
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

# macOS / Linux：待ち受けを確認して同じリクエストを実行
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 https://example.com/

ここでの8秒は接続確立までのタイムアウト上限、20秒はリクエスト全体の制限時間であり、ノードの品質基準ではありません。curl -I はHEADリクエストを送信するため、サイトによっては403や405が返される場合があります。HTTP応答があればサーバーの応答段階まで接続が進んでいますが、TLSが完了したか、クライアントの接続記録にどう表示されているかも確認してください。

  • すぐに接続拒否が返る：ローカルポートが正しいか、コアが実行中かを重点的に確認します。リモートノードを変更するだけでは解決しないことがほとんどです。
  • 別のプロセスがポートを使用している：プロセスIDから該当するプログラムを確認し、競合しているプログラムを通常の手順で終了するか、FlClashのポートを変更してアプリのプロキシ設定も合わせて更新します。正体の分からないシステムプロセスを強制終了しないでください。
  • ローカルプロキシへの接続後にタイムアウトする：リモート接続、ルール、DNSを引き続き確認し、同じ時刻のログを調べてください。

ファイアウォールではプログラムとネットワークの範囲を指定して許可する

ファイアウォールやエンドポイントセキュリティソフトが、コアの外向き通信を制限している場合があります。ブロックの記録を確認し、実際の実行ファイルを対象に許可してください。アップデート後にファイルの場所が変わった場合は、ルールが引き続き有効かも確認します。ローカルプロキシのテストで通常「LANからの接続を許可」を有効にする必要はなく、パブリックネットワーク向けの受信ポートを開放する必要もありません。ファイアウォール全体を無効にしたままにしないでください。

5. ログからDNSの名前解決失敗とリモート接続のタイムアウトを切り分ける

名前解決で区別すべき対象は少なくとも2つあります。プロキシサーバーのドメインと、最終的にアクセスするウェブサイトのドメインです。サーバーのドメインを解決できない場合は、プロキシサーバーへの接続前に失敗します。ウェブサイトのドメインをどの経路で解決するかは、ルール、接続先プロトコル、DNS設定によって異なります。DNSエラーが出たら、まずどのドメインでエラーが起きたのか確認し、変更する箇所を判断してください。

システムの名前解決テストで確認できるのは、システムDNSの経路だけ

# サンプルサイトのシステムDNSの結果を確認
nslookup example.com

システムの名前解決も失敗する場合は、ネットワークが正常か、システムDNSが使えるかを確認します。名前解決に成功してもFlClashのログに no such host や名前解決のタイムアウトが表示される場合は、クライアントコアが使用するDNS経路を別途確認してください。設定内の nameserver、proxy-server-nameserver、direct-nameserver はそれぞれ用途が異なります。システムの名前解決に成功したからといって、すべての経路が正常とは限りません。

  • ノードサーバーのドメインを解決できない：プロキシサーバーのドメインを解決するリゾルバーに到達できるか確認します。リゾルバーへのアクセス自体に、まだ接続できていないプロキシが必要な構成は避けてください。
  • DNS-over-HTTPSのリクエストがタイムアウトする：DNSサービスのドメインを解決するための初期問い合わせ、HTTPS接続、ルーティングが成立しているか確認します。すべてのリゾルバーを同じアドレスに変更すると、障害の影響範囲が広がる場合があります。
  • 198.18.0.0/15 の範囲内のアドレスが表示される：Fake-IPモードでは想定されたマッピング結果である可能性があります。アドレスの形式だけで名前解決エラーと判断しないでください。
  • 特定のウェブサイトだけで問題が起きる：そのドメインに適用されるルール、DNSの応答、接続先サービスの状態を確認します。1サイトだけの問題で設定全体を変更しないようにしてください。

DNSを変更したら、クライアントの再読み込みまたはコアの再起動機能を使って設定を反映し、既存の接続を閉じてから再テストします。Windowsの ipconfig /flushdns が消去するのはシステムDNSキャッシュだけです。mihomoのDNSキャッシュや既存の接続が消去されるわけではありません。一度に変更する項目は1つにし、元に戻せるよう元の設定を保存してください。

6. 通信モード、ルールの適用先、TUNの取り込み範囲を確認する

ルールモードで失敗する場合は、グローバルモードで原因を切り分ける

ルールモードでは上から順に照合され、最初に一致したルールの接続先が使われます。ブラウザーのリクエストが DIRECT に一致している場合、ノードテストに成功しても、そのリクエストが選択したノードを通るとは限りません。クライアントの接続記録で対象ドメイン、適用ルール、最終的な接続先を照合し、問題の通信が実際にどの経路を通ったか確認してください。

  1. ノードとテストURLは変えず、一時的にグローバルモードへ切り替え、グローバル用のプロキシグループで対象ノードが選択されていることを確認します。
  2. グローバルモードでは接続でき、ルールモードでは失敗する場合は、該当ルールの接続先が誤ったプロキシグループ、DIRECT、または REJECT になっていないか確認します。
  3. どちらのモードでも失敗する場合は、サーバー接続とDNSを引き続き確認してください。ルールの順序だけを変更しないでください。
  4. テスト後は元のモードに戻してください。グローバルモードは比較のためのテスト手段であり、すべての通信に適した設定ではありません。

システムプロキシとTUNでは解決する問題が異なる

明示的なプロキシ接続のテストは成功するのに特定のアプリでアクセスできない場合は、アプリがシステムプロキシを使うか確認してください。アプリによっては独自に接続したりUDPを使用したりするため、システムプロキシを有効にしても自動的にクライアント経由にはなりません。TUNは仮想ネットワークインターフェースを通じて、より多くの通信を取り込めますが、ルーティング、権限、除外ルールの影響を受けます。すべての通信が取り込まれるとは限りません。

TUNを有効にする前に、通常のプロキシ経由の接続が使えることを確認してください。デスクトップOSでは管理者権限やサービスのサポートが必要な場合があります。AndroidではVPN接続の権限が必要で、通常、別のVPNアプリと同時に実行できません。TUNを有効にして端末全体が通信できなくなった場合は、まずTUNをオフにしてネットワークを復旧し、仮想インターフェース、ルーティング、ほかのVPNとの競合を確認してください。TUN、DNS、ルールを同時に変更すると、原因を特定しにくくなります。

7. 結果を整理する：ノードを変更する場合とログを共有する場合

ここまで確認すれば、「FlClashが使えない」という漠然とした状況ではなく、問題のある層を特定できるはずです。特定のノードが複数のネットワークで失敗し、ほかのノードは使える場合は、サービス提供元にサーバーの状態や認証情報を確認してください。すべてのノードが同じネットワークでだけ失敗する場合は、まずローカルネットワークの制限を確認します。明示的なプロキシ接続は使えるのにシステムプロキシでは使えない場合は、ほかのプログラムがシステム設定を上書きしていないか確認してください。

問い合わせ前に次の6項目を記録する

  • FlClashのバージョン、OSのバージョン、ログに表示されるmihomoコアのバージョン。
  • 失敗した時刻とタイムゾーン。サービス側の記録との照合に役立ちます。
  • サブスクリプションの更新結果と、現在の設定が正常に読み込まれているか。
  • システムプロキシとTUNの有効状態、実際の混合ポート、現在の通信モード。
  • 同じURLを明示的なプロキシ接続、ルールモード、グローバルモードで試した結果。
  • 失敗の直前から直後までの短いログ。サブスクリプションのトークン、アカウント情報、公開に適さないアドレスは隠してください。

初期設定をもう一度確認する場合は、まずスタートガイドを参照してください。症状に応じて切り分けを続ける場合は、トラブルシューティングをご覧ください。クライアントを更新する前に、現在の設定と重要な項目を保存します。更新後に同じテストを繰り返せば、変化がバージョンまたは設定によるものか判断できます。

公式Clashをダウンロード プラットフォームとインストーラーを選択