トラブル診断 / mihomoとクライアントの設定

FlClashのトラブル対処
接続・サブスクリプション・DNS

症状に応じて確認箇所を絞り、設定は一度にひとつだけ変更します。ネットワーク、接続先、本体の通信制御を切り分け、ログを手がかりに原因を探します。

初回インストールやサブスクリプションの追加は入門ガイドをご覧ください。このページでは接続に問題が起きた際の確認方法を解説します。すべての手順を最初からやり直す必要はありません。ガイドの確認項目をクリアできない場合は、下の目次から該当する項目へ進んでください。接続が復旧したら、ガイドに戻ってルールモードとアプリの動作を確認しましょう。

ネットにつながらない：まず問題の箇所を切り分ける

「クライアントが起動中」と表示されても、ローカルサービスが動作している可能性を示すだけです。サブスクリプション、接続先、システム側の通信制御まで正常とは限りません。普段プロキシなしで接続できるサイトと、プロキシ経由でアクセスするサービスをひとつずつ選び、同じブラウザーでテストして具体的なエラーを記録しましょう。名前解決の失敗、接続拒否、証明書エラー、タイムアウトのどれでしょうか。特定のページが開かないだけで、ネットワーク全体が停止したと判断しないでください。サービスのメンテナンス、ログイン切れ、地域制限でもアクセスに失敗することがあります。

まず通信制御を解除して、通常のネット接続を確認する

FlClashを一時停止し、システムプロキシとTUNをオフにして、システムのプロキシ設定が実際に元へ戻ったか確認します。終了後もブラウザーがローカルポートを参照している場合は、残ったプロキシ設定を解除してください。設定が残っていると、プロキシを使わないテストになりません。信頼できるネットワークで一般的なサイトにアクセスし、必要ならスマートフォンのテザリングでも比較します。プロキシなしでも接続できない場合は、Wi-Fi認証、ルーター、LANケーブル、回線を先に確認してください。ホテルや学校などのネットワークでは、ログイン画面での認証が必要な場合もあります。

1台の端末だけで通常接続に失敗する場合は、システム時刻、ネットワークアダプター、セキュリティソフトの通知を確認します。同じネットワーク上のすべての端末で失敗するなら、上流側の問題が考えられます。この場合、サブスクリプションを何度も追加し直しても解決しないでしょう。通常のネット接続が復旧したらFlClashを起動し、同じテストサイトで再確認してください。テスト対象を変えると、その違いを修復の効果と誤認するおそれがあります。ブラウザーの既存の接続は以前の状態を一時的に引き継ぐことがあるため、新しいリクエストで確認しましょう。

現在の設定と接続先を確認する

設定画面を開き、追加した設定が現在の設定として選択されているか確認します。リストにファイルがあるだけでは、コアがその設定を使っているとは限りません。プロキシ画面では、ルールが参照するグループに利用可能な接続先があるか確認します。手動で選ぶ場合は、使えない項目を選んだままにしないでください。まずルールモードでテストし、比較のため一時的にグローバルモードへ切り替えます。グローバルでは使えるのにルールモードで失敗するなら、ルールのマッチ状況やグループを確認しましょう。どちらも失敗する場合は、接続先とローカルポートを調べます。

DIRECTモードでは、リクエストがプロキシの接続先を経由しません。より強力な接続モードという意味ではありません。モードの切り替えは原因の切り分けにのみ使い、テスト後は普段使うルールモードに戻してください。ログにグループが存在しない、設定の解析に失敗した、ポートをリッスンできないといった明確なエラーがあれば、まずその問題を解消します。設定の読み込みに失敗しても、画面に以前の設定情報が残ることがあります。設定名だけで判断せず、コアを再起動して最新の起動ログを確認し、実際に読み込まれた内容と想定が一致しているか確かめましょう。

プロキシを明示して、システム側の通信制御を切り分ける

デスクトップのターミナルで次のリクエストを実行します。例では、デフォルトの混合ポート 7890 を使用しています。変更済みの場合は、クライアントに表示されているポートを指定してください。Windowsでは、ターミナルによって同名の別名が使われるのを避けるため、curl を curl.exe と入力できます。このコマンドはローカルプロキシを直接指定するため、ブラウザーのシステムプロキシ設定には依存しません。ただし、検証できるのはこのリクエストだけで、すべてのアプリが通信制御されていることを示すものではありません。

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

ローカルポートに接続できない場合は、コアが動作しているか、ポート番号が一致しているか、別のプロセスがポートを使用していないか確認します。プロキシへの接続後にタイムアウトする場合は、接続先かDNSを調べてください。コマンドは応答するのにブラウザーで失敗する場合は、ブラウザーの拡張機能、独自のプロキシ設定、システムプロキシを確認します。応答が必ず成功ページである必要はありません。サービスからアクセスを拒否されても、通信経路の一部が確立したことは分かります。すべてのエラー状態をネット接続の失敗と決めつけず、応答内容を確認しましょう。

比較結果から次の確認先を選ぶ

症状まず確認する項目次に確認する項目
通常接続もできない基本ネットワーク、認証、残存プロキシまずシステムのネット接続を復旧する
プロキシを明示すれば使えるが、アプリでは失敗するアプリ側のプロキシ設定とシステム連携システムプロキシが効かない
ローカルポートには接続できるが、接続先でタイムアウトする接続先、時刻、上流ネットワークノードのタイムアウト
一部のドメインだけ失敗するDNS、ルール、対象サービスDNS・名前解決

比較結果を記録してから、該当する項目へ進みましょう。復旧後は、通常接続できるサイト、プロキシ経由のサイト、最初に問題が起きたアプリをそれぞれ一度は確認してください。キャッシュだけでページが開いている状態ではないことも確かめます。原因を特定できない場合はFAQで基本事項を確認できます。ただし、画面上の状態を整えるために通信制御の設定をすべてオンにしないでください。必要最小限の設定のほうが、長期的に管理しやすくなります。

ノードのタイムアウト：接続先への到達不可とハンドシェイク失敗を切り分ける

タイムアウトは、処理のどこかが制限時間内に完了しなかったことを示すもので、原因を直接特定するものではありません。サブスクリプション内のサーバーアドレスが古い場合もあれば、名前解決、通信のハンドシェイク、接続先サービスの応答が止まっている場合もあります。現在の接続先、ネットワーク、テスト対象を記録し、同じ時刻のログを確認してください。クライアントの表示が「タイムアウト」だけなら、前後のエラー行を開き、名前解決、接続開始、安全な接続の確立のどの段階で止まったかを確認してから、接続先を変更するか判断します。

サブスクリプションの状態とシステム時刻を確認する

まず提供元の管理ページで、サービスが有効か、利用枠が残っているか、接続先に最近変更があったかを確認します。クライアントでサブスクリプションの更新に成功しても、内容に含まれるすべての接続先へアクセスできるとは限りません。現在のサブスクリプションを更新した後、設定が実際に反映されたか確認し、元のグループが古い項目を選んだままになっていないか調べます。比較に役立つルール、手動選択、上書き設定を失わないよう、設定を何度も削除して作り直すのは避けてください。

OSの日付と時刻を自動設定にし、タイムゾーンと実際の時刻を確認します。安全な接続では証明書の有効期間を検証するため、端末の時刻が大きくずれているとハンドシェイクエラーが起き、画面上では接続失敗と表示されることがあります。時刻を直したら接続をやり直してください。すぐにクライアントを再インストールする必要はありません。ログに証明書名や証明書チェーンの問題が表示される場合は、サブスクリプションの設定やネットワークによる認証の遮断を確認します。証明書検証を無効にして、実際のリスクを見えなくするのは避けてください。

個別の接続先、グループ全体、ネットワークの違いを比較する

同じネットワーク、同じテスト対象のまま、接続先をひとつだけ切り替えます。ひとつだけ失敗し、ほかが使える場合は、その接続先の状態を調べます。すべて失敗する場合は、ローカルネットワーク、サブスクリプション全体の状態、共通の名前解決が原因かもしれません。信頼できるスマートフォンのテザリングでも同じテストを行います。テザリングで使え、元のネットワークで失敗するなら、元のネットワークの制限、ルーター、上流側に原因がある可能性が高まります。ただし、一度の結果だけで具体的な遮断方法までは特定できません。

内蔵のテストボタンだけで、実際の通信が使えるか判断しないでください。テスト先、タイムアウトの設定、実際に利用するサービスは異なる場合があります。テストに成功しても、特定アプリのログインAPIやリアルタイム通信が正常とは限りません。ブラウザーやプロキシを明示したリクエストで、実際の接続先にもアクセスしてみましょう。特定のサイトだけ失敗する場合は、ルールでDIRECTに振り分けられていないか、接続先サービスが現在の出口を制限していないか確認します。「すべてのノードに接続できない」ケースとは分けて考えてください。

ログに記録された接続段階に応じて対処する

no such host や名前解決のタイムアウトが表示されたら、まず接続先ドメインの名前解決を確認します。connection refused は、接続先のアドレスか途中の機器がリクエストを拒否したことを示す場合が多いため、サーバーのポートとサービスの状態を確認してください。応答待ちのタイムアウトなら、経路が通らないか、相手から応答がない可能性があります。エラーメッセージは手がかりにすぎず、前後の状況も確認が必要です。対象サイトからのアクセス拒否を、プロキシサーバーからの接続拒否と混同しないでください。

ログにハンドシェイク失敗が記録されている場合は、プロトコル、トランスポート方式、サーバー名、サブスクリプションの追加パラメーターが正しいか確認します。変換サービスによっては特定のプロトコル項目が失われることがあり、手動編集でインデントや値の型を誤る場合もあります。まず提供元のmihomo対応の設定に戻してテストしてください。他のガイドを見てサーバー名、フィンガープリント、通信パラメーターを適当に変更しないでください。これらはサーバー側の設定と一致させる必要があります。どれを選んでも動作するわけではありません。

ローカル側の遮断を確認し、再現できる記録を残す

セキュリティソフトやファイアウォールが、アップデート後にクライアントやコアのプロセスをブロックしていないか確認します。まずブロック履歴を見て、必要な場合に限りプログラムのパスを指定したルールを作成してください。保護機能全体を無効のままにしないでください。会社の端末では統一されたポリシーにより、一般ユーザーが変更できない場合があります。ネットワーク管理のルールに従ってください。別のVPNが起動中なら先に切断し、デフォルトルートや仮想ネットワークアダプターの競合を避けます。テスト中に起動するプロキシコアはひとつだけにしてください。

「元のネットワークとテザリング」「接続先ひとつと複数」「テスト用URLと実際のサービス」の3点を比較すると、適切な管理者に問題を伝えやすくなります。手順に沿って確認する場合は、ノードのタイムアウト対処メモをご覧ください。基本ネットワークに問題がないのに、複数のネットワークですべての接続先が失敗するなら、タイムアウトを延ばして到達不能を取り繕うのではなく、サブスクリプション提供元にサービス状況を確認してください。

サブスクリプションの失敗：取得・解析・有効化を切り分ける

サブスクリプションの追加には、クライアントがリモートの内容を取得する、コアが設定を解析する、ユーザーが設定を選んで有効化する、という3つの段階があります。失敗した段階に応じて対処も異なります。「ダウンロードできない」場合はネットワークとURL、「解析エラー」は取得内容と形式、「追加後に接続先が表示されない」場合は設定構造と選択状態を確認します。エラーの全文を保存し、失敗アイコンだけで済ませないでください。問題の段階を正しく切り分ければ、同じ効果のない方法を繰り返さずに済みます。

URLから正しい内容を取得できているか

提供元からサブスクリプションURLを完全な形でコピーします。チャットアプリによっては改行が入ったり、末尾のパラメーターが欠けたり、説明文まで一緒にコピーされたりすることがあります。URLの前後にある空白は削除しますが、クエリパラメーターは勝手に削除しないでください。共有用のWebページURLをサブスクリプションURLとして使うと、ログイン画面がダウンロードされる場合があります。ブラウザーでページを開けても、クライアントがプロキシ設定を取得できたとは限りません。ログインの要否、特定のリクエストヘッダー、専用のサブスクリプションURLが必要か提供元に確認してください。

応答内容から原因を絞り込みます。認証失敗やアクセス禁止は、認証情報、アカウントの状態、アクセス制限が原因かもしれません。リソースが見つからない場合はURLが期限切れの可能性があります。リクエストが多すぎる場合は連続更新をやめ、提供元の復旧を待ちましょう。ネットワークのタイムアウトはこれらとは異なり、すべてをパスワードの誤りと考えてはいけません。サブスクリプションのドメインによっては、アクセスに既存のプロキシが必要です。有効な設定で一度更新する方法もありますが、サブスクリプションの取得を唯一の起動手段にしないでください。

ダウンロードした内容の形式を確認する

mihomoで使う設定ファイルは通常YAML形式ですが、プロキシのアドレスを含むテキストなら何でもそのまま設定として使えるわけではありません。提供元によっては、別のクライアント向け形式、エンコードされたリンク一覧、エラーを説明するWebページが返されることがあります。この場合はダウンロードに成功しても、解析に失敗します。Clashまたはmihomo対応と明記されたURLを優先してください。クライアントが複数の追加方法に対応している場合も、実際に使える形式は画面とコアの機能で確認してください。

エラーに行番号と列番号が表示される場合は、その周辺のインデント、コロン、リスト記号、値の型を確認します。YAMLのインデントには半角スペースを使い、タブを混ぜないでください。全角の句読点も構文上の記号の代わりにはなりません。以下はルール部分の構造例であり、サブスクリプション全体ではありません。設定内に Proxy グループがすでにあることを前提としています。この断片だけを設定として読み込ませても、接続先は作成されません。

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

設定を追加できたのに有効になっていない

設定リストに戻り、追加した項目を開けることを確認して、現在の設定として選択します。ローカルファイルを追加した場合、あとからサブスクリプションを更新しても、そのファイルが変更されるとは限りません。現在使っているものがURL設定、ファイルのコピー、上書き設定のある設定のどれかを確認してください。接続を開始したら最新のログを開き、解析エラーがないことを確かめます。リストに表示される更新時刻は操作の記録にすぎず、実行中のコアが新しい内容へ切り替わった証拠にはなりません。

設定を有効にできてもプロキシ画面が空なら、プロキシ項目やプロキシプロバイダーが存在するか、グループから参照されているか確認します。接続先をリモートのプロバイダーに分けている設定では、メインファイルのダウンロード後に子リソースの取得が必要な場合があります。子リソースのドメイン、権限、形式に問題があると、グループが空のままになることがあります。メインのサブスクリプションだけを更新せず、ログでプロバイダー名と更新エラーを確認してください。ログを共有する際は、名前とダウンロードURLも伏せましょう。

更新による上書きとルールの重複を防ぐ

長期間残したいローカル設定は、サブスクリプション更新で上書きされる本文を直接編集せず、クライアントの上書き機能を使うのが基本です。ただし上書き設定も、ルールの重複、存在しないグループの参照、既存項目と異なる値の型など、競合を引き起こすことがあります。調査時はいったんカスタム上書きを無効にして、元のサブスクリプションでテストします。正常に動作したらひとつずつ戻してください。サブスクリプション変換サービスと上書きファイルを同時に変更すると、どの層が原因か分からなくなります。

復旧後に手動更新し、設定が再読み込みできること、ルールや接続先の選択が想定どおり残っていることを確認します。自動更新だけ失敗する場合は、バックグラウンドでの実行条件とダウンロード時のネットワーク経路を調べてください。サブスクリプションには個人用ドメインや認証情報が含まれることがあるため、公開オンライン解析サービスにアップロードしないでください。初回の追加手順はサブスクリプションの追加と接続設定をご覧ください。振り分けが想定どおりでない場合は、rulesのマッチ順序の解説を参考にしてください。

速度低下・接続切れ：帯域、通信経路、サービス側の制限を切り分ける

「遅い」という症状を、ページの表示開始まで時間がかかる、ダウンロード速度が出ない、動画が頻繁に止まる、一定時間後に接続が切れる、といった具体的な現象に分けて考えます。原因となるボトルネックはそれぞれ異なる可能性があります。同じ端末、ネットワーク、接続先で繰り返しテストし、OSの更新、クラウドストレージの同期、その他の大容量通信は一時停止します。異なるサイトのダウンロード結果を直接比べたり、内蔵の接続テストだけでアプリの使用感を判断したりしないでください。

同じ条件で通常接続とプロキシ接続を比べる

まず通常接続できる信頼性の高い接続先をテストし、Wi-Fiの電波と基本ネットワークが安定しているか確認してから、プロキシが必要な接続先を試します。通常接続も遅い場合は、ルーターの負荷、無線の干渉、上流回線の帯域を調べます。有線接続にするか、アクセスポイントの近くで試す方法もあります。プロキシ接続だけが遅い場合は、同じグループの別の接続先と比較してください。短時間の混雑やキャッシュによる改善を見誤らないよう、一定時間観察します。接続先を切り替える際に、ネットワークも同時に変更しないでください。

テスト対象によって利用する地域やコンテンツ配信ネットワークが異なるため、結果に差が出ることがあります。大容量ファイルのダウンロードが速くても、オンライン会議やゲームの通信経路が安定しているとは限りません。アプリが頻繁に切断される場合は、画面ロック、ネットワーク切り替え、端末のスリープ、一定時間のアイドル状態の後に発生するか記録します。常に同じシステムイベントの直後に起こるなら、遠隔地の帯域よりも、バックグラウンド実行の制限、仮想ネットワークアダプター、接続の復旧処理を優先して調べましょう。

実際に適用されたルールと接続先を確認する

接続履歴やログで、対象ドメインに適用されたルール、グループ、最終的な接続先を確認します。ブラウザーのトップページと動画のリソースは、異なるドメインから配信されている場合があります。トップページが速く開き、再生が遅くても、同じ接続に問題があるとは限りません。ルールは上から順に評価されるため、先にある大まかなルールが適用されると、後続の細かなルールには到達しません。ルールを変更した後は、新しい接続で動作を確認してください。既存の接続は、ルールを更新しても新しい接続先へ自動で切り替わらないのが一般的です。

自動選択グループでは、速度測定先と実際のサービスが異なるため、最適でない接続先が選ばれることもあります。一時的に接続先を手動で固定し、問題が解消するか確認してから、測定方法の調整を検討してください。接続先サービス側で、出口の地域、同時接続数、アカウントの速度が制限されている場合もあります。この問題はローカルポートの追加や画面設定の変更では解決できません。特定のサービスだけが遅い場合は、設定全体に例外を大量に追加せず、そのサービスの異なるリソースやクライアントを比較してください。

プロトコル、パケット損失、ネットワーク切り替えについて

ダウンロードが継続的に遅い場合は、接続先の負荷、経路の混雑、パケット損失が原因かもしれません。最初のリクエストが遅い場合は、DNS、ハンドシェイク、接続の再利用も関係します。モバイル回線や公衆Wi-Fiの状態は時間帯によって変化します。プロトコル、接続の再利用、トランスポート設定をむやみにすべて有効にしないでください。設定値はサーバー側の対応状況に合わせる必要があります。UDPを使うサービスでは、接続先と通信制御の経路がUDPに対応しているかも確認します。HTTPプロキシが使えても、UDPを使うすべての通信が同じ経路を通るとは限りません。

Webページは開くのに一部アプリで問題が起きる場合は、ほかの条件を変えずにシステムプロキシとTUNの動作を比べます。TUNの場合だけ失敗するなら、接続先ではなくルート、DNS、仮想ネットワークアダプターを確認してください。MTUが適切でないと一部のリクエストが止まることがありますが、パケット分割や経路に明確な手がかりがある場合にだけテストします。元の値を記録し、一度にひとつだけ変更して、元に戻せるようにしてください。MTUをやみくもに小さくしても、一般的な速度改善にはなりません。

短時間だけログを詳しくし、負荷をかけ続けない

特定のリクエストを調べる場合は、一時的にログの詳細度を上げて問題を一度再現し、すぐ通常のレベルに戻します。大量のログ、すべての接続先への繰り返しの測定、複数クライアントの同時実行は端末への負荷を増やし、比較結果にも影響します。システムリソースを確認する場合は、問題の前後でどのプロセスが変化したかを見ます。メモリ使用量だけでメモリリークと判断しないでください。起動直後から遅い場合と、長時間使ううちに遅くなる場合は分けて記録しましょう。

主な症状まず比較する項目避けたい誤判断
初回アクセスに時間がかかる名前解決とハンドシェイク帯域不足とすぐに決めつける
特定のサービスだけ遅いルール、接続先、サービス側の制限すべてのソフトを再インストールする
画面ロック後に接続が切れるバックグラウンド実行と電源管理サブスクリプションだけを変更する
ネットワーク切り替え後に使えない古い接続、ルート、DNSキャッシュプロキシ設定を次々に追加する

改善を確認したらログを通常の設定に戻し、繰り返しのテストを終了して、普段使うサービスで動作を確かめます。混雑する時間帯だけ問題が起きる場合は、時刻とネットワークの状態を記録して提供元に伝えるほうが、「速度が遅い」というスクリーンショットだけを送るより役立ちます。安定して再現できない場合は、条件を集めることを優先してください。すぐ結論を出そうと設定を変更し続けると、元は使えていた経路まで損なうおそれがあります。

DNSの問題：名前解決の経路とドメインルールを確認する

名前解決の異常は、一部のサイトが開かない、初回アクセスに時間がかかる、ログにホストが見つからないと表示されるなどの症状として現れます。まず、サブスクリプションのダウンロード先、プロキシサーバーのドメイン、最終的な接続先サイトのドメインを区別してください。それぞれ異なる経路で名前解決される場合があります。対象サイトの名前解決が成功しても、サーバーのドメインも解決できるとは限りません。どのドメインでエラーが起きたかを特定し、該当するリクエストを確認します。すべてのDNSサーバーをまとめて置き換えるのは避けてください。

システムの名前解決とコアの名前解決を区別する

OS、ブラウザー、mihomoは、それぞれ異なるDNS設定を使う場合があります。システムのコマンドで問い合わせに成功しても、その経路が正常だと分かるだけです。ブラウザーでセキュアDNSが有効だと、システムの名前解決を経由しないこともあります。TUNのDNS通信制御では、コアがリクエストを処理する場合があります。調査時は、ブラウザーのセキュアDNS、システムDNS、コアのDNS、TUNの現在の状態を記録します。一時的に仕組みを把握しやすい経路にそろえて検証し、終わったら必要な設定に戻してください。

以下のコマンドは、システム既定の問い合わせとDNSサーバーを明示した問い合わせの違いを調べるためのものです。あらゆるネットワークで特定のパブリックDNSを恒常的に使うことを推奨するものではありません。2つ目のコマンドが失敗しても、現在のネットワークが通常のDNSリクエストを制限している可能性があります。Windows、macOS、多くのLinux環境では nslookup を利用できます。最小構成のシステムにこのツールがない場合は、標準の診断ツールを使ってください。出所不明のサイトから実行ファイルをダウンロードしてテストするのは避けましょう。

nslookup example.com
nslookup example.com 1.1.1.1

暗号化DNSと起動時の依存関係を確認する

暗号化DNSのアドレスにドメイン名が使われている場合、接続前に通常の名前解決が必要になることがあります。プロキシサーバーもドメイン名で指定されていて、その名前解決をまだ確立していないプロキシ経由に強制すると、依存関係が循環する可能性があります。起動直後はすべてタイムアウトするのに、キャッシュが残っていると時々使える場合は、この問題が考えられます。設定に適切な初期名前解決とプロキシサーバー向けの名前解決経路があるか確認し、まだ使えない接続先に上流の名前解決を依存させないようにしてください。

以下は、通常の名前解決とプロキシサーバーのドメイン解決の役割を示す、DNS設定の一部の例です。すべてのネットワークで使える設定一式ではありません。統合する前に、元のファイルに dns 項目がすでにないか確認してください。同じ階層に二重に貼り付けてはいけません。暗号化DNSを使う場合は、現在のネットワークから該当サービスへ接続できる必要があります。読み込み後にコアが未対応の項目を報告した場合は、元の設定に戻してから実際のコアの対応状況を確認してください。読み込みに失敗した状態でテストを続けないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

fake-ipの仕組みとアプリの互換性を理解する

fake-ipはアプリにマッピング用アドレスを返し、後続の接続でコアが元のドメインを特定できるようにします。このアドレスは接続先サイトの実際のグローバルIPではないため、名前解決が壊れたとは限りません。アプリがマッピング用アドレスを受け取った後にコアを通さず直接接続したり、そのアドレスを別の端末に渡したりすると、接続に失敗することがあります。まず対象の通信が同じ通信制御経路に最後まで入っているか確認してください。明確に互換性の問題があるドメインに限ってフィルタールールを検討し、すべてのドメインを例外にしないでください。

名前解決モード、ネットワーク、通信制御方式を切り替えた後も、システムやブラウザーに古いアドレスがキャッシュされている場合があります。対象アプリを終了して新しくリクエストし、必要であればOSの方法でDNSキャッシュを更新してください。Windowsでは必要性を確認した上で ipconfig /flushdns を実行できます。他のOSではDNSの仕組みに応じてコマンドが異なるため、同じコマンドをそのまま使わないでください。キャッシュの削除は上流のエラーを直す方法ではありません。毎回キャッシュを消さないと一時的にしかアクセスできない場合は、アドレスのマッピングと通信経路が一致しているか調べましょう。

名前解決の異常と地域別ルールの問題を区別する

GEOSITEは主にドメインの分類に基づき、GEOIPはIPアドレスのデータベースに基づいて判定します。どちらも同じ種類のDNS機能ではありません。ドメインを正常に解決できても、データベースの不足、分類名の誤り、前段のルールへのマッチによって、誤った接続先へ振り分けられることがあります。接続履歴で実際に適用されたルールを確認し、データベースの読み込みと更新に関するログも調べてください。ルール末尾のフォールバック先も存在している必要があります。前のルールに一致しないリクエストの接続先がなければ、その通信も失敗します。

修復後は、サーバーのドメイン、接続先のドメイン、最初に問題が起きたアプリをそれぞれテストし、再起動後の初回接続も確認します。データベースの更新と分類のトラブル対処については、GeoIP・GeoSiteの更新ガイドをご覧ください。特定のネットワークだけでDNSに失敗する場合は、そのネットワーク固有の制限を記録し、一時的なテスト設定をすべての端末に適用しないでください。

システムプロキシが効かない：アプリの通信がコアを通っているか確認する

システムプロキシは、システム設定を参照するアプリにHTTPプロキシの接続先を提供するもので、すべての通信を強制的に転送する仕組みではありません。ターミナル、ゲーム、サービスプロセス、独自のネットワーク機能を持つアプリなどは、システムプロキシを使わない場合があります。TUNは仮想ネットワークインターフェイスとルーティングを通じて、より多くの通信を制御しますが、権限、ドライバー、ルートの状態に依存します。まずプロキシを明示したリクエストでローカルのコアが使えるか確認し、そのうえでアプリがシステムプロキシに従っているかを調べましょう。通信制御の範囲の違いを、クライアントの起動失敗と混同しないでください。

待ち受けアドレス、ポート、使用中のプロセスを確認する

FlClashで混合ポートを確認し、アプリに設定したポート番号と一字ずつ照合します。端末上のアプリでは通常 127.0.0.1 を使います。これは現在の端末自身を指し、LAN上の別のパソコンのアドレスではありません。デフォルトのポートでも、待ち受けに成功するとは限りません。別のクライアントやバックグラウンドプロセスが使用中の場合があります。以下のコマンドで待ち受け中のプロセスを確認できます。Windowsでは1つ目を、macOSまたは該当ツールをインストールしたLinuxでは2つ目を実行します。

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN

検索結果に表示されるプロセス番号が、想定したプログラムと一致するか確認してください。ポートが使用中だからといって、名前や用途を確かめず不明なプロセスを終了しないでください。システムサービスや別ユーザーのプロセスが正常な処理をしている場合があります。ほかのプロキシクライアントを終了してFlClashを再起動するか、ポートを変更してアプリの設定も更新してください。混合ポートはHTTPとSOCKS5の両方に対応しますが、すべてのアプリが自動でその接続先を認識するわけではありません。

アプリ独自のプロキシ設定と例外リストを確認する

ブラウザーのプロキシ拡張機能、開発ツール、ダウンローダー、コマンドラインの環境変数がシステム設定より優先されることがあります。該当する拡張機能を無効にするか、アプリの設定を「システムプロキシを使用」に戻してから、アプリを再起動してテストしてください。クライアントを終了しても、ターミナルに設定したプロキシ環境変数は自動で消えません。ターミナルのセッションによって値が異なる場合もあります。「一方のウィンドウでは使えるが、もう一方では使えない」ときは、コアの設定を変える前に環境の違いを比べましょう。

SOCKS5プロキシを使う場合は、ドメイン名をアプリ側で解決するか、プロキシ側で解決するかも確認します。curlを使える環境では、以下の形式でドメイン名の解決をプロキシ側に任せ、ローカルの名前解決経路と比較できます。HTTPプロキシのアドレス部分をSOCKSに変えるだけで、動作も完全に同じになると思わないでください。システムやアプリの例外リストによって、LAN内のドメインや特定のアドレスが直接接続される場合もあります。調査の前に例外を記録しましょう。

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

TUNを有効にしてもアプリの通信が制御されない

コアの起動ログを確認し、権限不足、仮想インターフェイスの作成失敗、ルート設定の失敗がないか調べます。管理者権限や補助サービスが必要なプラットフォームでは、スイッチの色だけで判断せず、クライアントの案内に従って権限を許可してください。アップデート後やプログラムの配置先を移動した後は、サービスが参照するパスを再確認する必要がある場合もあります。別のVPN、仮想マシンのネットワーク、企業のセキュリティソフトが同時にルートを変更することがあります。競合する機能を一時停止して比較してください。通信制御ツールを複数有効にすれば範囲が広がるとは限りません。

ブラウザーでシステムプロキシが使えてTUNで失敗するなら、TUNのルートとDNS制御を確認します。逆にTUNだけが使える場合は、アプリがシステムプロキシを無視している可能性があります。Windowsの一部のストアアプリでは、ループバックの分離によってローカルプロキシへ接続できない場合があります。対象アプリとシステムの案内に基づいてループバックのアクセス許可を確認し、すべてのアプリで一括解除しないでください。まず一般的なブラウザーでローカルの接続先を試し、問題の範囲を絞りましょう。

LANでの共有と終了後の復旧

スマートフォンからパソコンのプロキシに接続する場合、スマートフォンに設定するのはパソコンの現在のLANアドレスと混合ポートであり、スマートフォン自身のループバックアドレスではありません。パソコン側でLAN接続を許可し、信頼できるネットワークに限ってファイアウォールで必要なポートを開放します。ゲスト用Wi-Fiやアクセスポイントの端末間通信制限によって、端末同士が通信できない場合があります。両方の端末に同じWi-Fi名が表示されても、相互に通信できるとは限りません。ネットワークを切り替えた後は、パソコンのアドレスも確認し直してください。

詳しい共有手順は、混合ポートとLAN接続の解説をご覧ください。クライアントを終了する前に通信制御を停止します。異常終了後にネット接続できなくなった場合は、システムプロキシが停止済みのローカルポートを参照していないか確認し、その後に仮想ネットワークアダプターとルートを調べます。復旧したら、クライアントの起動中と終了後の両方でネット接続を確認してください。アプリを起動したままでなければネットに接続できない状態になっていないか確かめます。

クライアントのクラッシュ：画面、コア、設定の問題を切り分ける

起動できないケースには、ウィンドウがまったく表示されない、表示直後に終了する、画面は動作するのにコアが停止を繰り返す、という少なくとも3つのパターンがあります。関係する問題の層はそれぞれ異なります。インストーラーの入手元、CPUアーキテクチャ、OSの種類、直近の変更を記録してください。変更にはクライアントの更新、設定の追加、ディレクトリの移動、セキュリティポリシーの変更などが含まれます。バックアップ前にアプリデータを削除しないでください。クラッシュ後の設定やログは原因の特定に役立つ重要な情報です。

まずインストーラーと実行環境を確認する

インストーラーのページから、OSとCPUアーキテクチャに合ったクライアントを選びます。ファイル名にプラットフォーム名が含まれるかどうかだけで判断しないでください。macOSではApple SiliconとIntel、Androidでは端末のABIを区別し、Linuxではディストリビューションのパッケージ管理方式も考慮します。アーキテクチャが一致しないとインストールできない場合があり、互換レイヤーで動いても異常が起きることがあります。OSのアップグレード後に問題が始まった場合は、現在の環境との互換性をまず確認してください。

インストール先、設定ディレクトリ、一時ディレクトリに書き込み可能か、ディスクの空き容量が十分か確認します。読み取り専用の場所、ネットワーク共有、アクセス制限のあるフォルダーにプログラムを配置すると、リソースの書き込みに失敗することがあります。セキュリティソフトがコンポーネントを隔離した場合は、具体的な警告と入手元を確認してから、復元するか再インストールするか判断します。システムの保護機能全体を無効にしないでください。会社の端末で仮想ネットワークアダプターやバックグラウンドサービスが禁止されている場合は、管理ポリシーに従って対処する必要があります。

ウィンドウの終了とコアの終了を区別する

画面が表示されたまま接続だけが止まる場合は、コアのログに設定エラー、ポートの競合、起動権限のエラーがないか確認します。誤った設定を追加したことでコアが停止しても、アプリ全体が壊れたとは限りません。自動接続を停止し、以前正常に使えた設定を選んで再起動できます。ウィンドウ自体が消える場合は、OSのアプリクラッシュ記録とアプリのログを調べます。両方の記録時刻が一致するか確認し、以前のエラーを今回の原因と取り違えないようにしましょう。

Windowsではイベントビューアーのアプリケーションエラー、macOSではコンソールに表示される関連のクラッシュレポートを確認します。Linuxでデスクトップ環境やサービス管理ツールから起動した場合は、対応する起動出力とユーザーログを確認してください。ログの保存場所はインストール方法によって異なるため、クライアントに用意されたログ画面を基準にします。報告時はエラーの前後を抜き出せば十分で、ユーザーディレクトリ全体をまとめる必要はありません。ログにアクセス先のドメイン、パス、サブスクリプション情報が含まれることがあるため、共有前に伏せてください。

設定とデータディレクトリをコピーしてテストする

現在の設定、サブスクリプション情報、必要な設定をエクスポートまたはコピーしてから、最近追加した上書き設定、ルールプロバイダー、自動実行タスクを無効にします。元のサブスクリプションで起動でき、追加設定を重ねるとクラッシュする場合は、拡張設定をひとつずつ戻して、最小の再現条件を探します。すべてを一度に戻して推測を続けないでください。クライアントで独立したデータディレクトリを選べる場合は、元のディレクトリを残したままテストできます。利用可能な機能を確認し、不明な起動オプションを流用しないでください。

データを作り直す必要がある場合は、クライアントと残っているコアのプロセスを完全に終了してから、元のデータディレクトリを削除せずに名前を変更して保存します。再起動後の初期状態は、旧データとの関連を調べるためのものであり、プロキシ設定が自動で使えるようになるわけではありません。テスト後に旧ディレクトリ全体をそのまま戻すと、問題の原因となったファイルも再び含まれる可能性があります。設定、ルール、各種設定値を個別に移行し、その都度結果を記録してください。

バックグラウンドでの終了と再現性のあるクラッシュを区別する

長時間使った後にウィンドウが消える場合は、システムリソース不足、ユーザーセッションの終了、電源管理によるプロセス終了が考えられます。同じ時刻にほかのアプリも終了していないか、システムがスリープしていないか確認しましょう。メモリ使用量の増加は、稼働時間、接続数、ログの詳細度と合わせて分析します。一度の使用量の高さだけで継続的なメモリリークとは判断できません。特定のページを開いたときや設定を読み込んだときに毎回終了する場合は、最短の再現手順を記録してください。ランダムに再起動を繰り返すより、開発者が確認しやすくなります。

再インストール前にバックアップを読み取れることを確認し、以前の設定を記録します。新しいインストーラーを適用したら、最小構成で起動を確認してから元のデータを戻してください。一時的に別のクライアントを使う場合は、クライアント比較をご覧ください。複数のOSで使う場合はまずClash Plusを検討し、OSや現在の設定に応じてClash Verge RevまたはFlClashを選んでください。クライアントによって画面上の設定や上書き方法は異なるため、個人データディレクトリ全体をそのままコピーしないでください。

修復後は、コールドスタート、設定の更新、通常の終了をそれぞれテストしてください。旧データを戻したときだけ再発する場合は、何度も再インストールするのではなく、具体的な設定まで原因を絞ります。まれに起きるクラッシュは、時刻とそのときの操作を記録し、追加の情報を待ちます。再現条件が分からないうちは、特定のネットワーク設定を原因と決めつけないでください。

モバイルのトラブル：VPNの権限、バックグラウンド動作、ネットワーク切り替え

モバイル端末の問題は、サブスクリプションや接続先だけでなく、VPNの権限、電源管理、アプリごとの振り分け、Wi-Fiとモバイルデータの切り替えにも左右されます。この項目では主にAndroid版FlClashを扱います。iOS用クライアントの選び方はiOSのインストール方法をご覧ください。おすすめはClash Plusです。Androidの画面操作をiOSにそのまま当てはめないでください。また、ブラウザーでアクセスできても、すべてのアプリが同じプロキシ経路を通っているとは限りません。

VPNの許可と、通信を制御するVPNがひとつだけか確認する

Androidでは通常、初めて接続を開始するとVPN接続の許可が求められます。誤ってキャンセルした場合は、クライアントに戻って接続を再開し、システムの案内に従って許可してください。システムのVPN状態とクライアントのコアログをあわせて確認します。ステータスバーにVPNアイコンが表示されても、接続先が使えるとは限りません。別のVPN、通信フィルター、企業向けネットワーク機能がある場合は、同じユーザー環境のVPN接続を使用していないか調べます。複数のアプリが接続を取り合う状態を避けてください。

システムのVPN設定で、「常時接続」と「VPNを経由しない接続をブロック」などの項目を確認します。これらの設定はクライアント停止後のネットワーク動作にも影響します。通信をブロックする設定が有効な場合、切断後に通常接続できないのは想定どおりであり、Wi-Fiの故障ではないかもしれません。調査前に現在の状態を記録し、必要性を確認したうえで一時的に変更します。テスト後は必要な保護設定に戻してください。組織管理の端末では設定を変更できない場合があります。管理ルールに従ってください。

画面ロック後だけ切れる場合はバックグラウンド設定を確認する

まず画面を点灯したまま一定時間接続を確認し、次に画面をロックして同じテストをします。ロック後だけ切断され、画面を復帰すると再接続する場合は、バッテリー最適化、バックグラウンド実行、自動起動の許可を優先して確認してください。設定名はメーカーによって異なります。他のスマートフォンの手順をそのまま使わず、システムのアプリ設定から該当項目を探しましょう。必要なバックグラウンド動作を許可して再テストします。端末内のすべてのアプリで省電力制限を解除する必要はありません。

「システムがクライアントのプロセスを終了した」ケースと、「プロセスは動作中だが接続先とのアイドル接続が切れた」ケースを区別します。前者では通知の消失、プロセスの再起動、VPN状態の変化が起きることが多く、後者は新しいリクエストを送ると復旧する場合があります。画面ロック中のWi-Fi休止やモバイルデータの制限でも、似た症状が起こります。通知、VPNアイコン、アプリからの実際のリクエストがどう変化したかを記録してください。ホーム画面のボタンだけでは、電源管理と接続復旧のどちらを確認すべきか判断できません。

Wi-Fiとモバイルデータの切り替え後に経路を再確認する

ネットワークを切り替えると端末のIPアドレス、デフォルトルート、DNSが変わり、既存の接続を引き継げないことがあります。OSのネットワークが安定するのを待ってから、クライアントで接続をやり直し、対象アプリも終了して再試行します。Wi-Fiでは使えてモバイルデータでは失敗する場合、クライアントによるモバイルデータの使用が禁止されていないか、サブスクリプションの接続先にモバイル回線からアクセスできるか確認してください。逆にWi-Fiだけで失敗するなら、Web認証が必要なホットスポット、端末間の通信制限、ネットワーク固有のアクセス制限を調べます。

アプリによってはIPv4、IPv6、UDPを併用するため、ブラウザーとは異なる動作をする場合があります。テストのためにシステムのIPv6を恒久的に無効にしないでください。失敗したリクエストのログ、通信制御の範囲、接続先の対応状況を確認してから、ひとつずつ比較します。AndroidのプライベートDNS設定も現在の名前解決経路に影響する場合があります。一時的に変更する際は元の値を記録してください。特定のアプリだけに問題がある場合は、アプリ独自のセキュアDNS、内蔵プロキシ、バックグラウンドデータの制限も確認します。

アプリごとの振り分けとLANプロキシの範囲

アプリごとのプロキシを設定している場合は、対象アプリを含めるリストか、除外するリストか確認します。仕事用プロファイル、複製アプリ、別ユーザーにインストールしたアプリは、別のアプリとして扱われることがあります。メインのユーザーでの選択が、そのアプリにも適用されるとは限りません。リストを変更したら、対象アプリを再起動するかVPN接続を作り直し、以前の経路を使う既存接続を更新します。システムのダウンロードサービスとブラウザーは、別々のプロセスから通信する場合があります。ブラウザーを対象に設定しただけで、すべてのダウンロードが制御されるとは限りません。

スマートフォンをパソコンの共有プロキシに接続する場合、Wi-Fi設定のHTTPプロキシは、その設定に従うアプリにだけ影響するのが一般的です。スマートフォン全体にVPNを設定したことにはなりません。パソコンのLANアドレスと実際のポートを入力し、両方の端末が相互に通信できる信頼済みネットワークに接続していることを確認します。そのネットワークを離れても手動プロキシ設定が残っていると、ブラウザーが存在しないパソコンのアドレスに接続しようとすることがあります。自宅のプロキシをすべてのホットスポットで使わず、ネットワークごとに設定を管理してください。

修復後は、画面点灯中、画面ロック中、Wi-Fiからモバイルデータへの切り替え、クライアント停止後のネットワーク動作を順に確認します。前面でブラウザーが使えるようになっただけなら、バックグラウンド同期や他のアプリも個別にテストしてください。初回の利用では入門ガイドに戻り、接続を確認できます。コアとクライアントの役割を確認する場合は、Clashオープンソースエコシステムの全体像をご覧ください。最終的に有効だった設定と元に戻す方法を記録しておけば、次回ネットワークが変わったときも同じ順序で原因を特定できます。