Clashクライアントのシステムトラブルシューティングガイド

01 / CONNECTION

Clashを有効にするとまったくインターネットに接続できない

「カーネルが動作していない」のか「トラフィックが入った後の処理に失敗している」のかを切り分ける

クライアントを開くとすべてのウェブページにアクセスできない場合、最初に行うべきことはノードの変更ではなく、リクエストがMihomoカーネルに入っているか確認することです。クライアントのログ画面を開き、通常のウェブページを一度更新してください。ログに新しい接続がまったく現れない場合、障害はシステムプロキシ、TUNによる取り込み、ブラウザーのプロキシ設定、または端末のローカルポートにある可能性が高いです。ログにリクエストが継続して記録され、タイムアウト、接続拒否、DNSエラーになる場合は、トラフィックがすでにカーネルへ届いているため、ノード、ルール、DNSを確認します。

次にシステムプロキシを一時的に無効にするか、クライアントを終了して、端末が直接接続に戻るか確認します。無効にしてもアクセスできない場合は、Wi-Fi、LANケーブル、ルーター、認証ポータル、またはシステムのネットワークスタックが原因の可能性が高くなります。無効にするとすぐ復旧する場合は、クライアントによるトラフィックの取り込みに関係しています。すぐにアンインストールせず、まず現在の待ち受けポートを確認してください。一般的な mixed-port はHTTPとSOCKSの両方を受け付けます。システムプロキシに設定するポートは、設定ファイルとクライアントの設定に一致している必要があります。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

WindowsではPowerShellまたはコマンドプロンプトで netstat -ano | findstr :7890 を実行し、macOSとLinuxでは lsof -nP -iTCP:7890 -sTCP:LISTEN を実行します。Mihomoに対応するプロセスが待ち受け状態になっていれば、ローカルプロキシの入口が確立しています。待ち受けがない場合はクライアントのカーネル起動エラーを確認してください。ポートが他のプログラムに使用されている場合は、競合プロセスを終了するか、クライアントの混合ポートとシステムプロキシのポートを同じように変更します。競合プロセスの詳しい特定方法はポート使用中のトラブルシューティングで確認できます。

直結・グローバル・ルールモードで障害の層を特定する

カーネルが正常に動作していることを確認したら、まず直結モードに切り替えてテストします。直結モードが使える場合、ローカルプロキシの入口とDNSはおおむね機能しており、障害はノードまたはルールにある可能性が高いです。直結モードも使えない場合は、DNS、TUNのルーティング、システムプロキシを重点的に確認します。次にグローバルモードへ切り替え、明らかに利用可能なプロキシノードを選択します。グローバルモードではアクセスできるのにルールモードではできない場合、リクエストが誤ったルールで利用不能なポリシーグループへ送られているか、最終的に不適切な DIRECT または REJECT ポリシーに一致しています。

ルールモードでは、ログから対象ドメインに対応する一致結果を確認します。たとえばコードホスティングサイトへアクセスすると、ログに一致したルールの種類と最終的なポリシーグループが表示されます。ポリシーグループ名だけで判断せず、グループを展開して実際にどのノードが選択されているか確認してください。ポリシーグループが、すでに無効な手動選択項目のままになっている場合や、ヘルスチェック先に到達できず選択肢がない場合もあります。変更後は新しいリクエストを発生させてください。既存の接続は新しい設定の結果を自動的には反映しません。

TUN、LAN、ファイアウォールの境界を確認

TUNモードは仮想ネットワークアダプターを使って、より多くのアプリのトラフィックを取り込みます。システムプロキシより範囲が広い一方、権限、ルーティングテーブル、セキュリティソフトの影響を受けやすくなります。TUNを有効にして接続できなくなった場合は、まずTUNだけを無効にし、システムプロキシのみでテストしてください。無効化後に復旧するなら、通常はノードが主な原因ではありません。Windowsでは仮想ネットワークアダプターの作成に必要な権限があるか確認します。macOSではネットワーク拡張機能またはシステムサービスが許可されているか確認します。LinuxではTUNデバイス、ルーティングルール、プロセス権限を確認してください。修復後にTUNを再び有効にし、システムプロキシと複数のサードパーティVPNでデフォルトルートを同時に取り込まないようにします。

allow-lan は他のLAN端末がこの端末のプロキシへ接続できるかどうかだけを決める項目であり、この端末自身がプロキシ経由でインターネットへ接続できるかには影響しません。LANへサービスを提供する場合は、待ち受けアドレス、ファイアウォールの受信規則、ルーターのクライアント分離設定も確認してください。トラブルシューティング中は変数を減らすため、allow-lan: false のままにすることをおすすめします。最後にシステムの日付とタイムゾーンを確認します。時刻のずれが大きいとTLS証明書の検証に失敗し、多くのサイトで同時にハンドシェイクが失敗することがあります。以上を終えたら、ルールモード、TUN、LAN共有を一つずつ戻し、各段階で再テストしてください。

02 / TIMEOUT

ノードのタイムアウト、ハンドシェイク失敗、速度テスト不能

速度テストの失敗は、すべての通信が失敗したことを意味しない

クライアントのノード速度テストは通常、固定されたテスト先へアクセスし、制限時間内にDNS、TCP、TLS、HTTPのリクエストを完了させます。テスト先が現在のネットワークで制限されている、応答形式が変わった、またはノードがそのアドレスへアクセスできない場合、画面にはタイムアウトと表示されますが、他のサイトは利用できることがあります。まず実際の通信で確認してください。グローバルモードで対象ノードを選択し、異なる2つのサイトを開きながらログを確認します。ウェブページは表示できるのに速度テストだけ失敗する場合は、すぐにノードが無効だと判断せず、ヘルスチェック先や間隔を調整します。

実際のリクエストもタイムアウトする場合は、まず同じ設定に含まれる複数のノードを比較します。特定のノードだけが失敗する場合、リモート入口への到達不能、プロトコルパラメーターの不一致、証明書名の不一致、ノードの失効がよくある原因です。すべてのノードが同時に失敗する場合は、ローカルネットワークの制限、サブスクリプション項目の解析異常、システム時刻の誤り、通信事業者の経路問題が考えられます。自宅回線からモバイルホットスポットへ切り替えるなど、別のネットワークでもテストしてください。ネットワークを変えると復旧するなら、設定とクライアントはおおむね正常で、元のネットワークのDNS、IPv6、UDP、出口制限を重点的に調べます。

ログの段階からエラー箇所を判断する

「timeout」は最終結果にすぎません。重要なのは、どの段階でタイムアウトしたかです。リモートIPへの接続時点でタイムアウトするなら、TCP経路に到達できないか、入口ポートが遮断されている可能性があります。TLSハンドシェイクエラーなら、サーバー名表示、証明書のドメイン、システム時刻を確認します。authentication failed なら、認証情報がサービス側と一致していません。ノード接続は確立できるのに対象サイトがタイムアウトする場合は、リモートDNS、対象サイトの制限、ポリシーチェーンも確認します。ログを共有する際はエラー種別と対象ドメインを残し、サブスクリプションURLや認証情報は公開しないでください。

プロトコル設定では、アドレス、ポート、認証情報、トランスポート層のパラメーターを一組として一致させる必要があります。YAMLを手動編集すると、インデントの誤りで項目が別の階層に入り、クライアントには読み込めても期待どおりに接続できないことがあります。サブスクリプションの元データと照合し、異なるノードのTLS、ネットワーク種別、プラグインパラメーターを経験だけで混在させないでください。ノード名は表示用の文字列であり、名前が同じに見えてもパラメーターが同じとは限りません。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

url-test はテスト結果に基づいて候補を自動選択します。interval は再チェックまでの秒数で、短すぎると余分な接続が発生し、長すぎると状態変化の検出が遅れます。tolerance は遅延が近いノード間で頻繁に切り替わるのを抑えるために使います。トラブルシューティング中は手動の select に変更し、ノードを一つずつ検証すると、自動グループ選択の影響を排除できます。すべてのノードが同じように一時的な失敗を示す場合は、テスト先を現在のネットワークから直接名前解決できるかも確認してください。

TCP、UDP、IPv4、IPv6を個別に検証する

ウェブ閲覧は主にTCPを使いますが、音声、ゲーム、一部のDNS、HTTP/3ではUDPが使われます。ノードでウェブページを開けても、UDP転送が正常とは限りません。ウェブは正常なのに通話、ゲーム、QUICで問題が出る場合は、アプリのQUICを一時的に無効にするか、該当する通信をUDP対応が明確なノードへ送るルールにします。逆に、ノード設定がUDPを必要とするのに現在のネットワークがUDPを厳しく制限している場合、完全なオフラインではなく接続品質の不安定さとして現れることもあります。

IPv6もよくある分岐です。ドメインがAレコードとAAAAレコードを同時に返すと、システムまたはカーネルがIPv6を優先することがあります。ローカルにIPv6アドレスがあっても出口ルートが不完全だと、接続が失敗するまで待ってからIPv4へフォールバックするため、ノードが非常に遅く見えます。Mihomoの設定で ipv6: false を一時的に指定して比較してください。無効化で明らかに改善しても、IPv6を恒久的に無効にすべきとは限りません。ルーターのプレフィックス配布、デフォルトルート、DNS応答を引き続き確認し、IPv6経路が完全になったら元に戻します。

最後に端末の時刻、ファイアウォール、その他のネットワークフィルタリングソフトを確認します。セキュリティソフトがブラウザーの通信は許可しても、Mihomoカーネルの外部接続を阻止することがあります。企業や学校のネットワークで一般的なポートだけが開放されている場合もあります。許可されたネットワーク環境で比較テストを行ってください。2台の端末と2種類のネットワークでノードが失敗し、同じ設定の他のノードは正常なら、問題をそのノード自体に絞り込めます。この場合はクライアントを何度も再インストールせず、サブスクリプションを更新するか提供元へ問い合わせます。

03 / PROFILE

サブスクリプションの読み込み・更新に失敗する、または設定が空になる

取得したのが設定内容かウェブページかをまず確認する

サブスクリプションの読み込みに失敗したときは、ブラウザーでリンクを何度も開かないでください。クライアントが必要とするのは、解析可能なYAML、互換性のあるサブスクリプションテキスト、またはサブスクリプションサービスが返す設定内容です。URLがログインページ、エラーページ、認証画面、HTMLのリダイレクトページを返す場合、HTTPステータスが成功でもクライアントは設定として解析できません。クライアントの更新ログでステータスコード、レスポンスタイプ、解析エラーを確認すると、「内容を取得できていない」のか「取得した内容の形式が非対応」なのかをすばやく切り分けられます。

ダウンロード層でよくある問題は、リンクのコピー漏れ、チャットアプリによるクエリパラメーターの切り詰め、サブスクリプションの期限切れ、端末時刻の誤り、サブスクリプションのドメインを解決できないDNS、ネットワークからそのURLへ接続できないことです。リンクを公開せず、サービスのページからクライアントへもう一度コピーしてください。余分に見える疑問符、等号、パラメーターを手動で削除しないでください。認証に使われている可能性があります。ブラウザーで開くとログインを求められる場合は、サービスのページから専用のクライアント用サブスクリプションURLを取得し、ブラウザーのアドレスバーに表示された管理ページのURLをコピーしないでください。

形式エラー、非対応項目、上書き失敗を切り分ける

ダウンロードは成功したのにYAML解析エラーが表示される場合は、まずエラー行を確認します。YAMLは空白で階層を表すため、Tab、コロン後の空白不足、閉じられていない引用符、リストのインデント不一致によって設定全体が無効になることがあります。コロン、シャープ記号、特殊文字を含むノード名は引用符で囲むのが安全です。エラーがカスタム上書き内容を指している場合は、上書きを一時的に無効にして元のサブスクリプションを直接読み込みます。元の内容が動作するなら、問題はサブスクリプション元ではなくローカルの上書きにあります。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

設定は解析できるのにクライアントにノードが表示されない場合、サブスクリプションがルールだけを含んでいないか、非互換な形式変換を経ていないか、変換ツールがノード項目を破棄していないかを確認します。クライアントごとに拡張項目の対応状況は異なります。Clash Plus、Clash Verge Rev、FlClashなどのMihomo対応GUIクライアントは一般的なMihomo設定を処理できますが、一部の旧クライアントは新しいプロトコル項目を認識できません。YAML、共有リンク、その他の設定形式を扱う場合はサブスクリプション形式の変換方法を参照し、変換後にプロキシ一覧、ポリシーグループの参照、ルールの対象が残っているかを重点的に確認してください。

更新時は、動作する設定を一つ残す

確実なトラブルシューティングでは、唯一の設定を直接上書きせず、旧設定と新設定を共存させます。現在動作している設定に名前を付けて保存し、新しいProfileを作成して更新後のサブスクリプションを読み込みます。リモート側が空の内容を返したり、新しいルールが非対応だったりしても、すぐ旧設定へ戻せます。Profile、サブスクリプションURL、ローカルの config.yaml の関係は複数設定の切り替えと管理方法で確認できます。

サブスクリプションの更新は成功と表示されたのにノードが変わらない場合、クライアントが別のProfileを使っているか、更新後にカーネルを再読み込みしていない可能性があります。現在有効な設定の名前、更新時刻、ファイルパスを確認してから、「適用」または「再読み込み」を実行します。設定にリモートルールセットやプロキシプロバイダーが含まれる場合は、それらの子リソースも更新に成功したか確認してください。メイン設定のダウンロードに成功しても、参照先のリモートファイルまで到達できるとは限りません。リモートファイルの取得に失敗すると、ログに具体的なURL種別、ステータスコード、解析エラーが表示されることが多いです。

ネットワークが制限されている場合、サブスクリプション内容を出所不明のオンライン解析ツールへ貼り付けることはおすすめしません。変換が必要なら、信頼できるオープンソースツールまたはローカル環境を優先し、変換結果でポリシーグループが存在しないノードを参照していないか、ルールの末尾に MATCH が残っているか、DNS項目が現在のカーネルに適合しているか確認してください。修正後は、まずルールモードで直結サイトとプロキシサイトを一つずつ開き、その後に設定更新をテストします。クライアントに「成功」と表示されるだけで設定全体が正常だと判断しないでください。

04 / PERFORMANCE

接続は成功するが速度が遅く、ウェブページが重い

スループット、初回応答時間、接続の安定性を分けて見る

「速度が遅い」には、大容量ファイルのダウンロード速度が低い、ウェブページを開くまで長く待つ、接続速度が安定しないという3つの異なる問題があります。スループットは主にノードの帯域、回線の混雑、プロトコルのオーバーヘッドに左右されます。初回応答の遅さはDNS、IPv6からのフォールバック、接続確立が原因であることが多く、変動は無線信号、自動ポリシーグループの頻繁な切り替え、パケットロス、モバイルネットワークの状態変化から生じます。まずどの種類かを明確にしてから、適切な方法でテストしてください。一度の速度テスト結果だけでは、これらの要因を区別するのは困難です。

基準値を取るときは、他のダウンロード、クラウド同期、システム更新を停止し、同じ端末、同じネットワーク、同じテスト先を使って、直結とプロキシの結果をそれぞれ記録します。直結自体が遅いなら、まずローカルネットワークを改善します。直結は安定しているのにすべてのノードが遅い場合は、ローカルからノード入口までの経路、クライアントの取り込み方式、サブスクリプションの回線を確認します。特定のノードだけが遅い場合は、同じポリシーグループ内の別ノードへ切り替えます。テスト中はモードを変えないでください。ルールによって異なる出口へ送られると、結果を横並びで比較できません。

大容量トラフィックが誤ったポリシーへ送られていないか確認する

ルールモードでは、ウェブページ本体、画像、動画、ダウンロードURLが異なるドメインから配信されることがあります。トップページがプロキシ経由で開いても、すべてのリソースが同じノードを通るとは限りません。ログでリソースのドメインが直結、拒否、別のポリシーグループに一致していると、ページの一部だけ読み込みが遅くなります。開発者ツールのネットワーク一覧で待ち時間が最も長いドメインを見つけ、Mihomoのログでルール一致を確認してください。修正時はまず完全一致のドメインルールやドメインサフィックスルールを調整し、最初から範囲の広すぎるルールを追加しないでください。

ルールは上から下へ順に評価されます。前に広範囲のルールを置くと、後ろの精密なルールが隠れてしまいます。たとえば DOMAIN-SUFFIX がすでにリクエストに一致している場合、後続の完全なドメイン向けルールは実行されません。変更後は設定を再読み込みし、新しい接続を確立してください。ページを更新するだけでは、ブラウザーが古い接続を再利用し、新しいルールが反映されていないように見えることがあります。必要に応じて対象のタブを閉じ、古い接続が終了してから再試行します。

DNS、接続の再利用、転送方式を確認する

ウェブページが長時間「接続中」のままになる場合、DNSクエリの遅さやIPv6の試行失敗がよくある原因です。まず本ガイドのDNS章にある方法でドメイン解決を比較し、IPv6を一時的に無効にしてフォールバックの問題を確認します。同じドメインを何度も解決しているログがある場合は、他のソフトがDNSキャッシュを削除していないか、ブラウザーが独自のセキュアDNSを有効にしていないか確認します。ブラウザーとMihomoが異なる解決経路を使うと、名前解決結果とルール判定が一致しないことがあります。

一部のネットワークではUDPの品質が不安定ですが、ブラウザーはHTTP/3を優先して使うことがあります。特定サイトの初回読み込みだけが遅く、更新すると復旧する場合が典型です。ブラウザーのQUICを一時的に無効にするか、対象通信をTCPへフォールバックさせて比較します。フォールバック後に安定するなら、ローカルネットワーク、ノードのUDP対応、リモート経路のどこに問題があるかをさらに切り分けてください。単一のスイッチに頼り続けないことが重要です。TUNモードも仮想ネットワークアダプターの処理を一層追加するため、性能の低い端末では高スループットの場面に影響することがあります。条件をそろえてシステムプロキシモードと比較してください。

端末のリソースとポリシー切り替えによる影響を減らす

クライアント画面の動作の重さとプロキシのスループットは別の問題ですが、システムリソースが不足すると両方に影響します。CPU、メモリ、ディスク使用率を確認し、Mihomoカーネルのインスタンスが複数同時に動いていないか確認してください。ルール数が多い、ルールプロバイダーの更新頻度が高い、ヘルスチェック間隔が短すぎると、バックグラウンド処理が増えます。自動速度テストの間隔を適切に設定し、トラブルシューティング中は一時的に手動ポリシーグループへ変更すると、テスト中のノード自動切り替えを防げます。

無線ネットワークでは、信号強度、周波数帯、干渉も同時に確認します。ルーターから離れると、プロキシ接続はパケットロスの影響を受けやすくなり、ウェブページで再送が繰り返されることがあります。LANケーブルまたはアクセスポイントの近くでテストすれば、無線の問題をすばやく切り分けられます。モバイルホットスポットでは、省電力、信号の切り替え、通信事業者のネットワーク状態も影響します。同じノードが有線では正常で無線では遅いなら、ノード設定を変更し続けても解決しません。

最後は段階的に元へ戻します。まず手動ノード、システムプロキシ、ルールモード、デフォルトDNSで安定した基準状態を作り、その後、自動速度テスト、TUN、カスタムDNS、ルール上書きを一つずつ復元します。各段階でウェブ閲覧、ファイルダウンロード、長時間接続を少なくとも一度テストしてください。これにより、ある場面の改善と引き換えに別の場面で障害が起きていないか確認できます。

05 / DNS

DNSの名前解決失敗、汚染、Fake-IPの異常

システムDNSとMihomo DNSのどちらで発生したエラーかを確認する

DNSはドメイン名をアドレスへ変換します。システムプロキシを使う場合、一部のアプリはまずOSでドメインを解決し、その結果をプロキシへ渡します。TUNと強化DNSを使う場合は、クエリの多くがMihomoへ入ります。確認前にログで、リクエストにドメインが現れているか、DNSエラーがあるか、どの経路で処理されているかを確認してください。コマンドラインの nslookup や dig は通常、システム設定のリゾルバーをテストするため、Mihomo内部の結果と同じとは限りません。コマンドの結果とクライアントログを組み合わせて読み取る必要があります。

Windowsでは nslookup example.com を実行し、macOSとLinuxでは dig example.com A と dig example.com AAAA を実行します。システムの名前解決は失敗するのにMihomo経由のリクエストは正常なら、直結アプリだけが影響を受けている可能性があります。システムの名前解決は正常なのにMihomoのログでエラーが出る場合は、設定の nameserver、proxy-server-nameserver、出力経路を確認します。アドレスが返っても接続成功を保証するわけではないため、ルールが使う解決結果と実際の出口が一致しているかも確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1

これは項目同士の関係を理解するための基本例です。nameserver は通常の名前解決に使い、proxy-server-nameserver はプロキシサーバーのドメイン解決に使えます。ノードのアドレス自体が、まだ確立していないプロキシチェーンに依存するのを避けるためです。実際の設定では、ネットワーク環境から到達できるリゾルバーを選択してください。リゾルバーへ接続するためにプロキシが必要で、そのプロキシサーバーのドメイン解決を同じリゾルバーに依存すると、依存関係が循環します。その結果、すべてのノードが同時に接続できなくなります。

Fake-IPの用途と限界を理解する

Fake-IPモードでは、アプリに予約アドレス範囲内の一時アドレスを返し、Mihomoがマッピングを使って元のドメインを復元します。これにより、ドメイン情報を使った分流を維持でき、システムプロキシに従わないアプリもTUNで取り込めます。198.18.0.0/16 の範囲のアドレスが表示されても、通常は汚染ではなく、このモードの正常な動作です。本当の問題は、アプリが一時アドレスを長期間キャッシュする、Mihomoを経由せず直接接続する、または一部のLANサービスが実アドレスによる判定に依存する場合です。

プリンター、LAN内の検出、社内ネットワーク、特定アプリがFake-IPで異常になる場合は、まず別の強化モードへ切り替えて比較します。そのうえで必要なドメインだけをフィルタリングしてください。フィルター範囲はできるだけ正確にし、多数の公共ドメインを除外してドメイン分流の利点を失わないようにします。Fake-IP関連の設定を変更した後は、アプリとシステムのDNSキャッシュを削除し、関連する接続を再起動します。ルールを再読み込みするだけでは、古いマッピングが消えないことがあります。

キャッシュ、ブラウザーのセキュアDNS、漏れの経路を確認する

システム、ブラウザー、Mihomo、上流リゾルバーのいずれも結果をキャッシュする可能性があります。トラブルシューティングでは一か所だけでなく、層ごとにキャッシュを削除してください。Windowsでは ipconfig /flushdns を実行します。systemd-resolvedに対応するLinuxでは resolvectl flush-caches を実行します。macOSでは関連する名前解決サービスを再起動するか、ネットワークへ再接続して更新します。ブラウザーには独自のホストキャッシュと接続プールもあるため、すべてのブラウザープロセスを終了してから再起動すると、よりクリーンな結果を得やすくなります。

ブラウザーのセキュアDNSは指定した名前解決サービスへ暗号化クエリを直接送信するため、OSとMihomoが想定する経路を迂回することがあります。確認中は一時的にシステムのDNS設定を使い、ルールとFake-IPが正常だと確認してから、ブラウザー独自の名前解決を戻すか判断します。維持する場合は、その通信自体が正しく分流されていることを確認し、ブラウザーの解決結果がカーネルのルールプロバイダーが使うアドレスデータベースと異なる可能性も理解しておいてください。

問題がIPv6のドメインだけで発生する場合は、端末がアドレスを取得しているだけでなく、実際に利用可能なIPv6デフォルトルートを持っているか確認します。dns.ipv6: false またはグローバルの ipv6: false を一時的に設定すると切り分けに役立ちますが、影響範囲は異なります。前者は主にDNSの応答を制御し、後者はより広い範囲に影響します。最終設定は実際のネットワーク能力に合わせてください。修復後は、直結ドメイン、プロキシドメイン、LANホスト、A/AAAAレコードを同時に持つサイトをそれぞれ一度テストし、特定サイトだけの解決で終わらせないようにします。

06 / SYSTEM ROUTING

システムプロキシは有効だが、一部のアプリで機能しない

システムプロキシの影響を受けるのは、プロキシ設定を自分で読み取るアプリだけ

システムプロキシはグローバルなネットワークスイッチではありません。ブラウザーや多くのデスクトップアプリはシステムのHTTP/HTTPSプロキシを読み取りますが、ゲーム、コマンドラインプログラム、仮想マシン、一部のストアアプリ、独自のネットワークスタックを持つソフトは無視することがあります。そのため「ブラウザーは使えるが、特定のアプリは使えない」場合、通常はノード全体の障害ではなく、アプリのトラフィックがMihomoへ入っていません。アプリを操作しながらログを確認してください。接続記録がまったくなければ、アプリのプロキシ設定、環境変数、ループバック制限、TUNを確認します。記録はあるのに失敗するなら、ルール、DNS、ノードの層へ戻ります。

システムプロキシのアドレスは通常、ローカルのループバックアドレスと混合ポートを指します。例: 127.0.0.1:7890。クライアントが mixed-port を変更した場合、システム設定も同期させてください。一部のクライアントはシステムプロキシを自動設定しますが、異常終了後に古いポートが残ることがあります。画面に「システムプロキシ無効」と表示されても、OS内の古い値が消えたとは限りません。システムのネットワーク設定を開いて確認してください。プロキシ自動構成スクリプトと手動プロキシを、異なる入口へ同時に向けないようにします。

プラットフォームごとに実際の有効値を確認する

Windowsでは「設定」のプロキシページで手動プロキシを確認し、netsh winhttp show proxy でWinHTTPの設定も確認できます。ブラウザーが使うシステムプロキシとWinHTTPは完全には同じではありません。サービスによっては後者だけを読み取るため、アプリの種類に応じて判断してください。Microsoft Storeや一部のUWPアプリはループバック制限の影響も受けます。クライアントのループバックツールを使うか、Windows UWPアプリのループバック制限への対処方法に沿って設定します。変更後は対象アプリを完全に終了してから再起動してください。

macOSでは現在のネットワークサービスのプロキシ設定で、HTTP、HTTPS、SOCKSの各項目を確認します。Wi-Fi、LANケーブル、別のネットワークサービスへ切り替えると、それぞれ独立した設定を持つため、以前に設定したプロキシが引き続き有効とは限りません。scutil --proxy で現在のシステム結果を確認できます。Linuxデスクトップ環境のプロキシ設定は、デスクトップ設定に従うアプリにだけ有効です。コマンドラインツールは通常、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の環境変数を使い、大文字と小文字の変数を別々に読み取るプログラムもあります。

# 現在のターミナルセッションだけに設定する例
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# テスト完了後に削除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

コマンドラインの設定は、実際に待ち受けているプロトコルと一致させます。HTTPアドレスをSOCKSのパラメーターへ指定したり、その逆にしたりすると、接続拒否やプロトコル解析エラーが発生します。curl -I https://example.com で基本テストを行う場合は、明示的なプロキシパラメーターを付けた場合と付けない場合をそれぞれ実行し、環境変数の問題とローカルプロキシ入口の問題を切り分けます。テスト後は一時的な変数を削除し、後続のターミナル作業が意図せず古いプロキシを使わないようにします。

アプリがプロキシに対応していない場合にTUNを検討する

TUNはシステムプロキシを読み取らない通信を取り込むのに適していますが、仮想ネットワークアダプター、ルーティング、DNSの連携が必要です。有効にする前に、まずシステムプロキシの経路を安定させ、2つの問題を重ねないようにします。有効化後にLANだけが異常になる場合は、プライベートアドレスのルールが直結になっているか確認します。仮想マシンやコンテナが接続できない場合は、そのネットワークがホストのデフォルトルートを経由しているか、TUNが対象インターフェースを除外していないか確認します。企業VPNとTUNを同時に使うと、双方がデフォルトルートを変更する可能性があるため、どのネットワークがどの宛先を担当するか明確にしてください。

アプリの通信がすでにログに現れているのにルール結果が想定と異なる場合は、プロセスマッチングルールの対応状況を確認します。OSによってプロセス名、プロセスパス、サンドボックスアプリの識別能力は異なるため、プロセスルールだけに依存しないでください。ドメインとIPのルールは、複数のプラットフォームで再現しやすい傾向があります。アプリが固定IPや独自の暗号化DNSを使う場合、ログにドメイン分流へ使える情報が少ないことがあります。その場合は対象アドレス、ポート、プロセスルールを組み合わせて処理します。

最後に、ローカルファイアウォールがアプリによるループバックアドレスへのアクセスを許可しているか、プロキシが誤ったインターフェースで待ち受けていないか確認します。本機だけで使うならループバック待ち受けが安全です。LAN端末から接続する必要がある場合にだけLANアクセスを有効にし、受信規則を設定してください。修復後はブラウザー、コマンドライン、もともと失敗していたアプリを個別に検証します。3種類の入口がすべて正常なら、システムプロキシと取り込み経路が完成しています。

07 / RUNTIME

クライアントがクラッシュする、カーネルが起動しない、繰り返し終了する

グラフィカル画面が終了したのか、Mihomoカーネルが終了したのかをまず確認する

グラフィカルクライアントとMihomoカーネルは別の層です。画面が固まったり終了したりしても、カーネルプロセスが動作し続け、システムプロキシがそのカーネルを指し続けることがあります。逆に、画面が正常でもカーネルの起動に成功しているとは限りません。障害発生後はまずタスクマネージャーまたはアクティビティモニタを開き、画面プロセスとカーネルプロセスの状態を確認してから、ローカルポートが待ち受けているか確認します。画面が終了したのにポートが残っている場合は、再起動前に残留プロセスを終了してください。2つ目のインスタンスがポート競合で再び失敗するのを防げます。

起動ログには通常、原因が直接示されます。設定解析の失敗、ポート競合、ファイル権限不足、ルールファイルの破損、TUNの作成失敗、データベースの読み込み失敗などです。後続の連鎖エラーではなく、最初に現れた明確なエラーを記録してください。設定解析に失敗したら、まず動作する旧Profileへ戻します。ポート競合なら競合プロセスを探します。権限エラーなら設定ディレクトリとキャッシュディレクトリが書き込み可能か確認します。一つのファイル権限の問題を直すために、設定ディレクトリ全体を削除しないでください。

起動可能な最小設定を作る

設定とクライアントのどちらが原因か判断できない場合は、最小設定でカーネルを検証します。最小設定には待ち受けポート、モード、直結ポリシー1つ、最終ルールだけを残し、リモートルールセットとTUNは読み込みません。起動できれば、プログラム本体と基本権限は通常正常で、問題は元の設定項目または外部リソースにあります。それでも起動できない場合は、インストール、ランタイム、システム権限、ポートを引き続き確認します。

mixed-port: 7890
mode: rule
log-level: info

proxies: []

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

rules:
  - MATCH,DIRECT

この設定はローカル起動と直結入口の診断専用であり、プロキシノードは提供しません。検証後は日常用のサブスクリプションとして使わないでください。元の設定へ戻すときは、DNS、プロキシ、ポリシーグループ、ルールプロバイダー、TUNを順番に追加します。ある項目を追加した後にエラーが再発すれば、原因の範囲を絞り込めます。YAMLのエラー行は解析器が問題を検出した位置にすぎず、実際のインデントや引用符の誤りが数行前にあることもあります。前後の文脈を含めて確認してください。

キャッシュ、ルールファイル、設定ディレクトリを確認する

ルールデータベースやリモートリソースのダウンロードが中断すると、不完全なキャッシュが残り、カーネル起動時の読み込みに失敗することがあります。まずログで対象ファイルを特定し、そのキャッシュだけを削除してクライアントに再ダウンロードさせます。ディレクトリ全体を消去すると、Profile、上書き設定、画面設定まで同時に失われ、復旧コストが増えます。操作前にクライアントを終了し、設定ディレクトリをバックアップしてください。クライアントが設定のエクスポートに対応している場合は、そちらを優先します。

アップグレードやクライアント変更後にクラッシュする場合は、旧設定と新クライアントの非互換性も考慮します。Clash Plus、Clash Verge Rev、FlClashなどの異なるクライアント間で、アプリデータディレクトリ全体を直接コピーしないでください。より安全なのは、適切なクライアントを再インストールし、元のサブスクリプションまたは確認済みのYAMLを読み込む方法です。クライアントはダウンロードページでOSに合ったものを選び、別プラットフォームの設定ディレクトリ構造を共通形式として扱わないでください。

高負荷、スリープ復帰、異常終了に対処する

クライアントが長時間動作した後にクラッシュする場合は、ルール更新、ネットワーク切り替え、スリープからの復帰、大量の接続が同時に発生したタイミングと関係がないか確認します。ログレベルを長期間過度に詳細にするとディスク書き込みが増えるため、通常使用では info にし、短時間の診断時だけ詳細度を上げます。スリープ復帰後に仮想ネットワークアダプターやデフォルトルートが戻らない場合は、すぐシステムを再起動せず、まずTUNを無効にしてから再度有効にします。

クラッシュを安定して再現できる場合は、発生手順、OS、クライアント名、使用した取り込みモード、エラーログを記録します。問題を報告するときは最小再現設定を提供し、サブスクリプションURL、ノード認証情報、個人パス情報を削除してください。再現が安定しない場合は、まずカスタム上書き、リモートスクリプト、過度に短いヘルスチェックを無効にし、基本設定が安定するか観察します。項目を一つずつ戻して条件を特定するほうが、毎回すべてを再インストールするより再利用可能な解決策につながります。

08 / MOBILE

Android・iOSモバイル端末のトラブルシューティング

まずOSによるバックグラウンド通信の制限に対処する

モバイル端末のプロキシは通常、システムVPNインターフェースを通じてトラフィックを取り込みます。クライアントをバックグラウンドへ移すと切断される場合、まず省電力設定とバックグラウンド実行制限を確認し、ノードを疑うのは後にします。Androidではメーカーごとにバックグラウンド動作が追加制限されるため、クライアントのバックグラウンド実行を許可し、バッテリー最適化を解除し、ステータスバーにVPNマークが残っているか確認してください。ロック画面、タスクの消去、ネットワーク切り替え時にバックグラウンドサービスを終了するOSもあるため、保護対象アプリまたは自動起動リストにクライアントを追加します。

iOSはVPN設定を一元管理します。Wi-Fiとモバイルデータを切り替えた後に短時間再接続するのはネットワーク経路の変化によるものですが、長時間復旧しない場合はクライアントから再接続し、システムのVPN設定が現在のアプリを指しているか確認してください。複数のVPN、DNS、コンテンツフィルタリングアプリがインストールされていると、システムは一部のネットワーク拡張機能しか特定の順序で動かせないことがあります。トラブルシューティング中は他の取り込みツールを無効にし、クライアントを一つだけ残します。

Wi-Fi、モバイルデータ、LANを個別にテストする

Wi-Fiだけ失敗してモバイルデータでは正常な場合、ルーターのDNS、IPv6ルート、認証ポータル、LAN制限がよくある原因です。まずプロキシを無効にしてWi-Fiのポータル認証を完了し、その後クライアントへ再接続します。モバイルデータだけ失敗する場合は、モバイルデータの権限、データセーバー、省電力設定、対象ネットワークからサブスクリプションのノードへ到達できるかを確認します。デュアルSIM端末では、現在のデータSIMが切り替わっていないかも確認してください。ネットワーク切り替え後は古い接続を再確立する必要があることがあります。

モバイル端末からプリンター、テレビ、その他のLAN端末へアクセスできない場合は、LAN権限とプライベートアドレスの分流を確認します。iOSではクライアントによるローカルネットワークへのアクセスを許可してください。Androidでは近くのデバイスやLAN関連の権限が必要になることがあります。ルールではプライベートアドレスを直結にし、ルーターの管理画面やローカルサービスをリモートプロキシへ送らないようにします。Fake-IP使用時にローカルドメインがルーターの名前解決へ依存する場合は、そのドメインを正確にフィルタリングするか、実IPで検証します。

アプリ分流、UDP、通知遅延に対処する

Androidクライアントには、アプリごとのプロキシ設定やバイパスリストが用意されていることがあります。特定のアプリがプロキシを使わない場合は、バイパスに追加されていないか確認します。そのアプリだけ接続できない場合は、まずアプリ分流を無効にし、すべてのアプリを同じポリシーに通して比較してください。システムアプリ、仕事用プロファイル、クローンアプリは異なるユーザー領域を使うことがあり、通常のアプリ一覧では対象にならない場合があります。アプリの対象範囲を変更した後は、VPN接続を停止して再確立します。

音声通話、ビデオ通話、ゲームはUDPへの依存度が高くなります。ウェブは正常なのにリアルタイム通信が失敗する場合は、ノードのUDP対応、モバイル回線の品質、ルール結果を確認します。モバイルネットワークはIPv4、IPv6、NATタイプがWi-Fiと大きく異なることがあり、同じノードでも結果が変わります。UDP対応が明確な別ノードへ一時的に切り替えるか、アプリをTCPへフォールバックさせて比較してください。ただし、すべてのタイムアウトをUDPのせいにしないでください。

通知の遅延は、アプリ自身のバックグラウンドポリシーが原因になることもあります。プロキシ接続が正常でも、対象アプリがバックグラウンドで起動できるとは限りません。まず通知権限、バックグラウンドデータ、省電力設定を確認し、Mihomoのログに対応する接続があるか確認します。ロック画面にするとログが完全に止まるなら、クライアントがバックグラウンドで生存しているかを重点的に調べます。ログはあるのに対象アプリへ通知が届かない場合は、アプリのプッシュサービスに対するルールとシステム通知設定を確認します。

読み込み、更新、ストレージ権限に関する注意

モバイル端末でブラウザやメッセージアプリからサブスクリプションを開くと、共有処理によってリンクが別のアプリに渡されることがあります。より確実なのは、クライアント内のサブスクリプション読み込み機能を使い、リンクが完全な状態か確認する方法です。Androidでローカルファイルを読み込む場合は、選択したファイルへのアクセスを許可してください。iOSで「ファイル」アプリから読み込む場合は、クラウド上のファイルが実際にダウンロードされるまで待ちます。設定を更新しても古いノードが表示されるときは、現在有効なProfileを確認し、手動で再読み込みしてください。

モバイル端末のストレージ容量が不足すると、ルールリソースの更新やログの書き込みに失敗することがあります。空き容量を確保する前に設定をバックアップし、クライアントデータを直接削除しないでください。アプリが頻繁にクラッシュする場合は、まず複雑なオーバーライドや大規模なリモートルールセットを無効にし、最小構成でVPNインターフェースを正常に確立できるか確認します。アプリを選び直す場合は、AndroidならAndroidクライアント一覧でClash Plus、Clash Meta for Android、FlClash、Surfboardを確認できます。iOSならiOSダウンロードエリアでClash Plusを確認できます。

モバイル端末での最後の対処は、接続を完全に再構築することです。クライアントを切断し、他のVPNやDNSツールを無効にしてから、機内モードを一度切り替えます。現在のネットワークへ再接続し、クライアントを起動して手動ノードを一つ選択してください。ブラウザー、対象アプリ、ロック画面からの復帰、ネットワーク切り替えを順にテストします。ブラウザーは常に正常なのに特定アプリだけが失敗するなら、問題はアプリ分流またはアプリ自身のネットワークポリシーに絞り込めます。すべてのアプリがネットワーク切り替えと同時に失敗するなら、VPNの再接続、バックグラウンド制限、そのネットワークからノードへ到達できるかを確認します。