まず失敗したリクエストを特定する

FlClashのログには、Clash Meta（mihomo）コアとクライアント自身のログが記録されます。warningが表示されても、プロキシ全体が使えないとは限りません。バックグラウンドアプリ、ノードのヘルスチェック、サブスクリプションの更新、ブラウザーのリクエストが同時にログへ出ることもあります。切り分けは、失敗したログと実際の操作を対応させるところから始めましょう。

  1. 現在の設定名、出力モード、ポリシーグループで選択中のノード、システムプロキシとTUNの有効・無効を記録します。
  2. FlClashのログ画面を開き、ほかのダウンロードを一時停止して、問題を安定して再現できるURLに1つだけアクセスします。
  3. 操作した時刻を記録し、その前後約10秒のログを保存します。対象ドメイン、ポート、適用ルール、ポリシーグループ、最終的な出力先を確認してください。
  4. 一度に変更する条件は1つだけにし、同じURLで再試行します。たとえば、DNSやTUNスタックはそのままにして、先にノードだけを切り替えます。

以下のログは各項目を説明するための例であり、実測結果ではありません。コアのバージョンによって項目の順序や表現は異なる場合があります。例にある 192.0.2.10 は文書用のアドレスで、接続可能なノードとして使用できません。127.0.0.1:7890 もローカルポートの例にすぎないため、実際に設定で待ち受けているポートに置き換えてください。

ログレベル：まずリクエストを確認し、次に深刻度を見る

mihomoでよく使われる log-level の値は、debug、info、warning、error、silent です。ログレベルが決めるのは出力範囲であり、障害の原因ではありません。warningがヘルスチェックの失敗を示すこともあれば、infoから対象リクエストの出力先が誤っていると分かることもあります。

レベル主な用途対処方法
debug接続や名前解決などの詳細を確認一時的に有効化し、再現後に戻す
infoルールと出力経路を確認日常的なトラブル対処の基本
warning接続や名前解決などの異常を表示失敗したリクエストと一致するか確認
error設定または実行中のエラー具体的なエラーの前後を確認
silentコアのログ出力を抑制調査中はinfoまたはdebugに変更

より詳しい情報が必要な場合は、クライアントのログレベル設定から一時的に変更できます。設定を編集する場合は、最終的に適用される設定の log-level: debug を確認してください。サブスクリプションのキャッシュファイルだけを編集しても、クライアントによる設定の再生成や更新で変更が上書きされることがあります。調査後は info に戻し、リクエスト情報が記録され続けないようにしましょう。

dial tcpのタイムアウト：接続先を確認する

dial tcp 192.0.2.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

dial tcp はTCP接続の確立を意味します。後ろにあるtimeoutだけでなく、その前に表示されるアドレスがプロキシノード、直接接続する宛先、ローカルのプロキシサービスのどれなのかが重要です。プロキシ経由ならノードサーバーのアドレス、DIRECTなら対象サイトのアドレスがエラーに出ることがあります。この1行だけで「サイトがブロックされた」「サブスクリプションが無効になった」とは判断できません。

i/o timeoutとconnection refusedの違い

  • i/o timeout：接続や関連するネットワーク処理が制限時間内に完了しなかった状態です。ノードに到達できない、パケットロス、ルーティング異常、ファイアウォールによる無応答の破棄などが原因になり得ます。
  • connection refused：接続が拒否されたことを示します。ポートでサービスが待ち受けていない、サーバーのポート設定が異なる、または接続先の機器が明示的に拒否している場合によく発生します。
  • network is unreachable：現在のシステムに宛先ネットワークへの有効な経路がありません。IPv6アドレスでのみ発生する場合は、端末のIPv6接続を個別に確認してください。

2つの比較で原因の範囲を絞る

ネットワークは変えずに別のノードを手動で選び、新しいリクエストを実行します。特定のノードだけでタイムアウトが続く場合は、そのノードのサーバーアドレス、ポート、稼働状況を優先して確認します。次にノードは変えず、Wi-Fiからスマートフォンのテザリングに切り替えて試します。元のネットワークだけで失敗するなら、ローカルのインターネット接続やプロバイダーまでの経路を調べる価値があります。これらの比較で原因の範囲は絞れますが、特定の機器の故障を証明できるわけではありません。

ノードの遅延テストに成功しても、すべてのサイトにアクセスできるとは限りません。テスト対象は通常、指定された確認用アドレスと1つの接続経路に限られ、実際の通信を代替するものではありません。ポリシーグループを切り替えても、既存の長時間接続は以前の出力先を使い続けることがあります。ページを再読み込みするか接続を作り直してから判断してください。

DNS解決失敗：ノードのドメインとサイトのドメインを区別する

lookup example.com: no such host
dns resolve failed: context deadline exceeded

no such host は通常、名前が存在しない、または利用可能なアドレスを取得できなかったことを示します。context deadline exceeded は処理が制限時間を超えたという意味です。後者はDNSに限ったエラーではないため、前後のDNS関連項目と合わせて確認してください。まず、失敗したドメインがノードサーバーのものか、アクセス先のものかを特定します。影響する範囲はそれぞれ異なります。

ノードサーバーのドメインで名前解決に失敗

プロキシ接続を確立するには、先にノードのアドレスを名前解決する必要があります。その名前解決に使うDNS上流が、解決対象のノード経由でなければならない設定だと、依存関係が循環することがあります。有効な設定の proxy-server-nameserver など、ノードのドメイン解決に関する項目と、DNS上流へ到達するための経路を確認してください。まだ確立していないプロキシ経由に、すべての名前解決をむやみに送らないようにしましょう。

アクセス先サイトのドメインで名前解決に失敗

dns セクションの nameserver、nameserver-policy と、使用している場合は fallback を確認します。respect-rules が有効なら、DNSリクエストに適用されるルール経路も確認してください。DoHアドレスはHTTPSで通信します。設定が https:// だからといって、現在のネットワークから必ず到達できるとは限りません。

  • 特定のドメインだけ失敗する：スペル、ドメイン別の名前解決設定、DNS上流からの応答を確認します。
  • すべての宛先ドメインで失敗するがノードには接続できる：宛先ドメインの名前解決経路とDNS上流を優先して確認します。
  • TUNを有効にした場合だけ失敗する：DNSハイジャック、システムのリゾルバー、ほかのネットワークソフトとの処理の競合を確認します。

ハンドシェイク失敗：証明書・プロトコル・切断を見分ける

tls: failed to verify certificate: x509: certificate has expired or is not yet valid
tls: first record does not look like a TLS handshake
EOF

TCP接続が成功しているのは、トランスポート層の接続先に到達できたことを示すだけです。その後のノードプロトコル、TLS、認証、宛先サイトへの接続で失敗することがあります。ログのTLSエラーは、プロキシ通信だけでなくDNS上流やほかのHTTPSリクエストから出ている場合もあります。まず、どの接続のエラーなのかを特定してください。

  • 証明書の期限切れ・有効期間前：まずシステムの日付、時刻、タイムゾーンを確認し、その後サーバー証明書の有効期間を調べます。端末の時刻がずれていても検証に失敗します。
  • 証明書名の不一致：ノードの servername、実際のサーバー証明書、サブスクリプションのパラメーターが一致しているか確認してください。指定されたドメインを安易にサーバーのIPアドレスへ置き換えないでください。
  • 最初のレコードがTLS形式ではない：TLSではないサービスに接続しているか、中間機器から別の内容が返されている可能性があります。ポートとTLS設定を確認してください。この表示だけでパスワードの誤りとは判断できません。
  • EOFまたはconnection reset by peer：相手側が接続を閉じた、または接続がリセットされたことを示します。これだけでは切断理由は分からないため、ハンドシェイク前後のログとサーバーの状態を確認してください。

サブスクリプション更新後に同種のノードがすべて失敗する場合は、まずクライアントに含まれるコアがそのプロトコルとパラメーターに対応しているか確認し、サブスクリプション提供元の設定要件も確認してください。skip-cert-verify: true を万能な修正方法として使わないでください。証明書検証を無効にすると本人確認の強度が下がり、ポート、認証、トランスポート方式の不一致も解決しません。

ルール不一致：まずモードを確認し、最終的な出力先を見る

「ルールに一致しない」は、ユーザーが現象を説明する表現としてよく使われますが、固定されたコアエラーではありません。Ruleモードでは通常、ルールが上から順に評価され、最初に一致したルールのポリシーが使われます。GLOBALモードとDIRECTモードでは通常のルールリストによる振り分けは行われません。まず現在のモードを確認し、接続ログの一致タイプとポリシーの経路を確認してください。

proxy-groups:
  - name: Web
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Web
  - MATCH,DIRECT

これはルールの関係を示す例で、すぐに使える完全なサブスクリプションではありません。www.example.com へのアクセスは DOMAIN-SUFFIX に一致して Web ポリシーグループに進みますが、この例ではグループ内の選択肢がDIRECTだけなので、最終的には直接接続されます。つまり、「プロキシグループに一致した」ことは「リモートのプロキシノードを経由した」ことを意味しません。実際の調査ではルール名だけで判断せず、ポリシーグループで現在選択されている出力先まで確認してください。

  • ログの一致結果がMATCH：それより前のルールが対象ドメインに適用されていないか、外部ルールセットの読み込みに成功しているか、アプリの接続にドメイン情報が残っているかを確認します。
  • ドメインルールが適用されない：アプリがIPアドレスへ直接接続している可能性があります。スニッフィングですべてのプロトコルのドメインを復元できるわけではないため、確実な解決策とは限りません。
  • ルールの出力先がREJECT：意図的にブロックする設定か確認します。この場合はルールの目的に沿って対処し、最初にノードを切り替える必要はありません。
  • 変更後も以前の経路を使う：変更したProfileが実際に適用されているか確認し、新しい接続で再テストします。

ルールの参照関係を整理する場合は、当サイトの高度な設定のルール解説をご覧ください。サブスクリプションのルールを変更する前に、変更を保持する方法を確認し、更新時にローカルの変更が上書きされないようにしてください。

TUN・ポートの異常：端末側の接続口を特定する

listen tcp 127.0.0.1:7890: bind: address already in use
operation not permitted

address already in use は、待ち受けアドレスとポートが競合していることを示します。ほかのプロキシクライアントを終了し、以前のプロセスが残っていないか確認してから、FlClashの実際のポートを調べてください。待ち受けポートを変更した場合は、システムプロキシとプロキシアドレスを手入力しているアプリの設定も合わせて確認します。設定の数字だけを変えても不十分です。

仮想ネットワークインターフェースの作成やルーティングの変更時に operation not permitted が出る場合は、まず権限を確認してください。デスクトップOSでは、TUNの利用に管理者権限やクライアント付属サービスの許可が必要なことがあります。AndroidではVPN接続の許可が必要です。ほかのVPNやセキュリティソフトが通信を制御している可能性もあります。

  1. 現在の状態を記録し、ほかのVPNやプロキシクライアントを一時的に無効にします。
  2. TUNを無効にし、システムプロキシだけでブラウザーをテストして、ノードと基本的なプロキシ経路が正常か確認します。
  3. 次にTUNだけを有効にし、ネットワークインターフェース、権限、ルーティングのエラーが出るか確認します。
  4. TUNだけが失敗する場合は、端末側の通信経路を優先して確認します。すぐにすべてのサブスクリプションやDNS設定をリセットする必要はありません。

システムプロキシのテストに成功しても、そのテストに使ったアプリの経路が正常だと分かるだけです。すべてのUDP通信、ゲーム、バックグラウンドアプリが動作するとは限りません。TUNスタックはOSとコアの対応状況を踏まえて個別に比較してください。すべての端末に最適な設定が1つあるわけではありません。

トラブル情報を共有する：前後のログを残し、認証情報を隠す

有効な報告には、エラー画面の貼り付けだけでなく、問題を再現できる手順が必要です。OSとアーキテクチャ、FlClashのバージョン、コアのバージョン、現在のモード、TUNの状態、エラー発生時刻、「ノードを変更」「ネットワークを変更」した場合の比較結果を記載してください。バージョン情報はクライアントに表示される内容を使い、記事の日付をバージョンの根拠にしないでください。

  • 操作：例：「同じHTTPS URLを開き、新しい接続を作成すると約10秒後に失敗する」。秒数は実際に確認した結果を記載してください。
  • 範囲：失敗するのは1つのノードかすべてのノードか、1つのサイトか多くのサイトかを記載します。
  • ログ：ルール、出力先、最終エラーを含む関連ログを前後ごと保存し、最後の1行だけを切り取らないでください。
  • プライバシー：サブスクリプションURL、トークン、パスワード、UUID、機密ドメインを隠してください。サブスクリプション設定全体を公開しないでください。

最後に通信経路ごとに分類します。リクエストログがない場合は通信の入口、ノードのドメイン解決に失敗する場合は名前解決の起動経路、ノードへのTCP接続がタイムアウトする場合はノードとネットワーク、ハンドシェイク失敗の場合はプロトコルと証明書、出力先が想定と異なる場合はモード・ルール・ポリシーグループを確認してください。同じリクエストを段階ごとに確認すれば、複数の設定を同時に切り替えるより再現性のある結論にたどり着きやすくなります。