mihomo・システム確認ガイド

Clash トラブル対処ガイド

症状から接続元、ルールの適用、接続先を切り分けます。変更は一度に一つだけ行い、同じリクエストで結果を確認してください。

初めてインストールして設定を読み込む場合は、クイックスタートガイドに沿って基本操作を行ってください。このページでは、設定済みなのに接続に問題がある場合の確認方法をまとめています。まず問題の範囲を特定し、該当する項目を確認しましょう。Clash配布ステーションはクライアントの使い方に関する情報をまとめたサイトであり、各クライアントの公式開発元ではありません。メニュー名は画面によって多少異なる場合があるため、実際の設定と実行ログを確認してください。

作業を始める前に設定をエクスポートし、現在のモード、選択中のポリシーグループ、システムプロキシ、TUNの状態を記録してください。失敗したリクエスト前後のログを保存し、発生時刻、対象ドメイン、使用中のネットワークも控えます。クライアントの再インストール、DNSの変更、ノードの切り替えを同時に行わないでください。複数の設定を一度に変えると、接続が復旧しても原因を特定できません。

インターネットに接続できない：ローカルネットワークとプロキシ経路を切り分ける

どの段階で接続できなくなるか確認する

まずシステムプロキシとTUNモードをオフにし、普段から直接接続できるサイトにアクセスしてください。それでも接続できない場合は、Wi-Fiのログイン認証が必要か、有線ケーブルが接続されているか、OSに有効なデフォルトゲートウェイが設定されているかを確認します。この段階では、まだClashの処理が原因とは限りません。公衆Wi-Fiの認証は通常、直接接続の状態で行います。認証後にクライアントを再度有効にして、同じ方法で確認してください。

直接接続は正常で、プロキシを有効にすると失敗する場合は、カーネルの状態を確認してください。タスクトレイにアイコンがあるかだけでは判断できません。クライアントのログ画面を開き、設定が読み込まれているか、待ち受けポートが開いているか、設定の解析失敗、アドレスの競合、起動直後の終了が繰り返されていないかを確認します。画面を表示するプロセスとmihomoカーネルは別です。ウィンドウが開いていても、ローカルプロキシが動作しているとは限りません。

設定画面で実際に使用している混合ポートを確認します。以下ではローカルポート 7890 を例にします。テスト前に、現在使用中のポート番号に置き換えてください。このコマンドはプロキシを明示的に指定するため、ブラウザーがシステム設定を読み取るかどうかの影響を受けません。Windowsでは、PowerShellの一部の環境で curl が別のコマンドとして解釈されるのを避けるため、curl.exe を使用してください。

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

ローカルアドレスに接続できないというエラーが出る場合は、待ち受けポート、カーネルの状態、端末のセキュリティソフトによる遮断を確認してください。ローカルプロキシへの接続後にタイムアウトする場合は、ポリシーグループとリモート接続を調べます。HTTPレスポンスヘッダーを受信できた場合、ステータスコードが成功でなくても、リクエストはサーバーの応答段階まで進んでいます。ローカルプロキシが起動していないと一括りにしないでください。

ログでルールとポリシーグループを確認する

モードを「ルール」に切り替え、プロキシ画面を開いて、該当するポリシーグループで利用可能な出口が選択されているか確認します。設定によっては通信先ごとに複数のグループが使われます。デフォルトのグループだけを変更しても、他の通信先には反映されません。対象に一度アクセスし、接続画面またはログでドメイン、ルールの種類、ポリシーグループ、最終的に選ばれたポリシーを確認してください。他のサイトへの接続成功を、対象リクエストの証拠にしないでください。

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

この例は、設定内に Proxy という名前のプロキシまたはポリシーグループがすでに存在することを前提としています。単独で読み込める完全な設定ではありません。ルールは上から順に評価され、最初に一致した時点で判定が終了します。対象が前の拒否ルールまたは直接接続ルールに一致すると、末尾の MATCH は適用されません。変更するときは対象に関係するルールだけを調整し、元の順序を残しておけば元に戻せます。

比較のために一時的に「全体」モードへ切り替える方法もありますが、全体用のポリシーグループでも出口を選択してください。全体モードでは正常でルールモードでは失敗する場合、ルール、通信に使われるポリシーグループ、または関連するDNS処理に原因を絞れます。どちらのモードも失敗する場合は、両方で共通するローカル待ち受けや出口を優先して確認します。比較後はルールモードに戻し、一時的な診断設定を恒久的な対処として使わないでください。

競合を解消して復旧を確認する

トラブルシューティング中は、ネットワークを制御するツールを一つだけ有効にしてください。他のVPN、ブラウザーのプロキシ拡張機能、古いプロキシクライアント、パケットキャプチャツールが接続経路を同時に変更する場合があります。まず一つずつ終了して再確認し、ネットワークアダプターの削除やネットワーク全体のリセットは避けてください。クライアントを終了しても直接接続できない場合は、システムにローカルポートを指すプロキシ設定が残っていないか確認します。サービスが停止しているのに接続先だけ残っていると、端末全体がオフラインのように見えることがあります。

復旧後は、直接接続する対象を一つ、プロキシ経由の対象を一つ選び、それぞれが想定どおりのポリシーに一致するか確認します。ページが表示されることだけでなく、ログに記録された接続元とルールの適用先も確認材料になります。ブラウザーだけが失敗し、コマンドでのテストが正常な場合はシステムプロキシの項目へ進んでください。ドメインの名前解決に問題が集中している場合は、すべての手順をやり直さずにDNSの項目を確認します。

ノードのタイムアウト：ポート、ハンドシェイク、接続先のリクエストを切り分ける

エラーが発生した段階を確認する

「タイムアウト」は、待ち時間が制限を超えた結果を示すもので、原因が一つとは限りません。クライアントがノードのサーバーに接続できない、プロトコルのハンドシェイクが完了しない、出口から接続先に接続できないなど、複数の状況で似たエラーが表示されます。エラーの前後を含むログを保存し、特にサーバーアドレス、接続方式、ダイヤル、TLS、レスポンス読み込みのどの段階で発生したかを確認してください。最後の一言だけを切り取ると、重要な手がかりを失います。

まず影響範囲を確認します。同じノードでどの接続先も失敗するのか、特定のサイトだけなのか、同じサブスクリプション内の他のノードは正常か、スマートフォンのテザリングに切り替えると復旧するかを調べてください。比較の際は、一度に変える条件をできるだけ一つにします。特定のWi-Fiで全ノードが失敗するなら、各ノードのプロトコルを同時に変更するのではなく、そのネットワークのアクセス制限、認証状態、出口ポリシーを優先して確認します。

現在のクライアントが古い設定の同名ノードではなく、最新のサブスクリプションを使用しているか確認します。設定画面で対象の設定を選び、ポリシーグループに戻って選択状態を確認してください。自動選択やフォールバックを使うグループでは、テスト中に最終的な出口が変わる場合があります。ノード一覧の単発テスト結果ではなく、ログに記録された実際の出口を基準に判断してください。

サーバーアドレスとTCP接続を確認する

Windowsでは Test-NetConnection を使って、サーバーのTCPポートに接続できるか確認できます。以下の予約済みサンプルアドレスはコマンドの形式を示すだけです。実際のテストでは設定ファイルのサーバーとポートを指定してください。サンプルの結果からサーバーの状態を判断することはできません。このテストでは、プロキシのパスワード、プロトコル設定、UDPの利用可否は検証できず、TCP接続を一度確立できるかだけが分かります。

Test-NetConnection -ComputerName 192.0.2.10 -Port 443

TCP接続に失敗する場合は、サーバーのメンテナンス状況、サブスクリプションが最新か、ローカルファイアウォールがプロセスを遮断していないか、現在のネットワークが該当ポートを制限していないか確認します。TCPで接続できてもプロキシが使えるとは限りません。パスワード、トランスポート経路、TLSのサーバー名、プロトコル設定が誤っていればハンドシェイクに失敗します。サブスクリプションで管理されているノードは、推測で認証項目を変更せず、まずサブスクリプションを更新してください。

ログに証明書の検証失敗が記録されている場合は、まずシステムの日付、タイムゾーン、時刻を同期し、ノードのドメインと証明書設定を確認します。証明書検証を無効にする方法を一般的な解決策として使わないでください。サーバー側の設定ミスや接続への干渉を見逃すおそれがあります。Webサイトに表示される証明書警告には、システムの信頼チェーンが関係する場合もあります。確認手順についてはHTTPS証明書エラーの原因分析を参照してください。

サーバーアドレスがドメイン名で指定されている場合、起動時のDNSにも依存します。サーバーのドメイン自体を解決できないと、リモート接続はまだ始まっていません。接続先のWebサイトを変えても、この段階の確認にはなりません。エラー内で解決に失敗したのがノードのドメインか、アクセス先のドメインかを確認してください。前者では直接接続可能な初期名前解決の経路を、後者ではDNSとルール振り分けを確認します。両者を同じ設定の問題として扱わないでください。

テスト結果と実際の通信を分けて考える

ノード一覧のテストでは、通常、指定されたテスト先に小さなリクエストを送ります。テスト先がブロックされている、応答方式が異なる、現在のネットワークに適していない場合は誤判定することがあります。逆に、テストに成功しても動画、ゲーム、すべてのWebサイトが正常とは限りません。まず一般的なHTTPSリクエストを試し、実際の接続先でも確認して、特定のサービスだけで失敗するかを調べてください。一度の結果だけで全ノードを削除しないでください。

ゲームや通話ではUDPが必要な場合もあります。Webサイトは開けるのにリアルタイム通信が失敗する場合は、ノードとサーバーが必要な通信方式に対応しているか、クライアントの接続方式が対象アプリをカバーしているかを確認します。TCPポートのテストはUDPのテストの代わりにはならず、ブラウザーの速度測定でもUDP経路の正常性は分かりません。サーバー側の対応が不明なら、設定を何度も切り替えるのではなく、サブスクリプションの提供元に問い合わせてください。

再接続を繰り返すと、同じログが大量に記録され、最初のエラーを見つけにくくなります。自動テストを一時停止し、出口を一つ選んで接続の全過程を記録してから、正常と分かっている別の出口と比較してください。別の出口が正常なら、古いノードで失敗した段階とテスト時刻を記録し、サービス提供元に調査を依頼します。すべての出口で同じ症状が出る場合は、ローカルネットワーク、DNS、クライアントの接続元など、共通する要因を確認します。

最終的な復旧の判断基準は、実際のリクエストが安定して完了することであり、テストボタンが成功表示になることではありません。確認後は元の自動選択設定に戻し、一時的な全体モードを使い続けていないか確認してください。同じ問題が繰り返し起きる場合は、発生時のネットワーク、ノードの種類、エラー段階を記録しておくと、ネットワーク環境の変化、サブスクリプションの更新遅れ、特定の出口の長期的な不調を見分けやすくなります。

サブスクリプションの更新に失敗する：取得経路と設定の解析を確認する

取得の失敗と読み込みの失敗を切り分ける

サブスクリプションの更新には、内容の取得と設定の解析という二つの段階があります。リクエストのタイムアウト、接続拒否、異常なHTTPステータスは取得段階の問題です。内容を受信した後にYAMLエラー、フィールドの型の誤り、参照先のポリシーがないと表示される場合は、解析段階の問題です。まず設定画面で更新エラーを確認し、同じ時刻のログを探してください。更新ボタンを何度押しても、通常はリクエスト経路は変わらず、構文エラーも解決しません。

サブスクリプションのURLが完全か、コピー時に末尾のパラメーターが欠けたり、空白や改行が混入したりしていないか確認します。URLにはアカウントへのアクセス情報が含まれることが多いため、公開フォーラム、オンライン変換サイト、スクリーンショットに載せないでください。問い合わせの際は、ドメイン、ステータスコード、エラーの種類だけを残し、パスに含まれる個人情報を隠します。URLを公開してしまった場合は、投稿を削除するだけでなく、サービス側で新しいURLを発行してください。

サービス提供元のホームページが開けても、サブスクリプションのAPIに接続できるとは限りません。ホームページとサブスクリプションで異なるドメイン、アクセス制御、配信経路が使われている場合があります。一方がWebページを返し、もう一方が有効な認証情報を必要とすることもあります。未認証、アクセス拒否、リクエスト過多などの応答がある場合は、サービス提供元の案内に従ってアカウントの状態と更新頻度を確認してください。制限を回避するために何度もリトライしないでください。

サブスクリプション更新時のネットワーク依存を確認する

サブスクリプションのドメインへのアクセスにプロキシが必要なのに、現在の設定に利用可能なノードがないと、「更新にはプロキシが必要だが、プロキシの取得には更新が必要」という循環が起きます。正常と確認済みの別の設定に切り替えるか、APIに直接接続できるネットワークで更新してください。サブスクリプションの取得にプロキシを使うかどうかはクライアントによって異なります。設定画面の関連項目を確認し、システムプロキシがカーネルのリクエストにも必ず適用されると考えないでください。

更新後はノードとポリシーグループが表示されたことを確認し、現在使用している設定が更新したものかも確認します。複数の設定を保存できるクライアントでは、ダウンロードに成功しても自動で切り替わらない場合があります。ログに古いサーバーが表示される場合は、設定の選択状態、リモートプロキシ一覧の更新状況、古いアドレスが上書きルールに残っていないかを確認します。選択の問題をキャッシュの未消去と誤認しないようにしましょう。

取得した内容がログインページ、アクセス確認ページ、一般的なエラーの説明ページなら、YAMLの拡張子で保存してもそのまま読み込めません。解析エラーが示す箇所は、サブスクリプションのルールの誤りではなく、ページ内の記号である可能性もあります。信頼できるローカルのテキストエディターでファイルの先頭と構造を確認してください。アカウント情報を含む設定全体を、公開の構文チェックサービスにアップロードしないでください。

YAMLと参照エラーを特定する

YAMLのインデントには半角スペースを使い、同じ階層のキーを揃えてください。よくある原因には、コロンの後にスペースがない、コピー時に全角記号が混入した、リストを通常の文字列として記述したことなどがあります。エラー行は解析器が競合を検出した場所を示しますが、原因が前の行にある場合もあります。該当箇所の前後数行と階層を確認し、エラーを消すためにポリシーグループ全体を削除しないでください。

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

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

これは設定構造の説明用サンプルです。ポリシーグループには一時的に DIRECT だけを含めており、名前の参照を示すもので、リモートプロキシとしては機能しません。ルール内の Proxy はグループ名と完全に一致させる必要があります。リモートプロキシ一覧とルール一覧にも、それぞれ対応する定義が必要です。スペルや大文字・小文字の違い、上書きによる名前の変更があると、ダウンロードに成功しても設定を読み込めないことがあります。

クライアントに設定の検証機能がある場合は、まず検証してから有効にしてください。コマンドラインを使う場合は、設定ファイルがあるディレクトリで以下のコマンドを実行します。設定で相対パスを使用している場合は、実際の作業ディレクトリで実行してください。検証に成功したことは、そのカーネルで設定を読み込めることを示すだけで、すべてのリモートノードに接続できることやルールが用途に合っていることまでは保証しません。

mihomo -t -f config.yaml

サブスクリプション自体は正常でも有効化後に失敗する場合は、ローカルの上書き設定、マージスクリプト、拡張設定を一時的に無効にし、元のサブスクリプションを読み込んで比較してください。元の内容で動作するなら、問題は二次的な変更層にある可能性が高いです。変更を一つずつ戻して、原因となった項目を特定します。唯一のバックアップを直接上書きしないでください。複数端末で同期する場合は、各クライアントが同じ上書き形式に対応しているかも確認してください。詳しくは複数端末での設定同期方法を参照してください。

長期的な運用では、サービス提供元のリモート設定とローカルのカスタムルールを分けて保存してください。更新に失敗した場合は、以前の正常な設定を残し、新しい設定が読み込めると確認してから切り替えます。サブスクリプションがサーバーエラーを返し続ける場合は、機密情報を伏せたステータスコード、発生時刻、クライアント名をサービス提供元に伝えてください。OSの再インストールやアプリデータ全体の削除は不要です。

速度が遅い：名前解決・接続・転送の段階ごとに切り分ける

まず遅さの具体的な症状を把握する

Webページを開くまで長く待つ、開き始めてから読み込みが遅い、大きなファイルの転送速度が安定しない、という症状はそれぞれ異なる段階の問題です。開始前と転送中のどちらが遅いかを記録し、同じ接続先で繰り返しテストします。初回だけ遅く次は速い場合は、DNS、接続の確立、アプリのキャッシュが関係している可能性があります。転送中ずっと遅い場合は、Wi-Fiの電波状態、出口の回線、サーバー側の速度制限を確認してください。

速度を測る際は、端末、ネットワーク、接続先、選択するポリシーグループを固定し、OSの更新、クラウドストレージの同期、大容量通信を一時停止してください。Wi-Fiでは電波状態を確認し、必要に応じて有線接続と比較します。スマートフォンのテザリングは自宅回線の問題を切り分ける補助になりますが、通信事業者の経路も同時に変わります。原因の範囲を絞る材料にはなりますが、それだけでノードやクライアントの不具合を証明することはできません。

ログに記録された最終ポリシーを確認し、遅いリクエストが想定した出口を通っているかを調べます。特定のサイトが別のポリシーグループに振り分けられている場合、デフォルトグループを変更しても速度は変わりません。複数のドメインからリソースを読み込むページでは、メインの文書と静的リソースの接続先が異なるか確認してください。ページ本文はすぐ表示されるのに画像がなかなか出ない場合、一部リソースのルールやリモート接続に問題がある可能性があります。

測定値だけでなく、処理にかかった時間を段階ごとに確認する

以下のコマンドは、リクエスト開始からの経過時間を表示し、同じ環境での比較に使えます。Windowsでは curl.exe、macOSとLinuxでは curl を使用します。プロキシのポートは実際の設定に置き換えてください。HTTPプロキシ経由でHTTPSに接続する場合、ドメインの名前解決がプロキシ側で行われることがあります。そのため、ローカルの名前解決時間は接続先のDNS処理全体の時間とは一致しません。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/

表示される値はリクエスト開始からの累積時間であり、それぞれが独立した所要時間ではありません。接続が速く最初のバイトを受信するまでが長い場合、プロキシのハンドシェイク、リモート接続、サーバーの処理が関係している可能性があります。総時間が増えても、単にレスポンスのデータ量が多い場合があります。macOSとLinuxでは出力先の NUL を /dev/null に変更してください。レスポンス内容やサーバーの動作はサイトごとに異なるため、異なるページの総時間だけで回線品質を比較しないでください。

ノードのテストでは、小さなリクエストが時間内に完了するかを確認します。ダウンロード帯域をそのまま示すものではありません。回線によっては単一接続と複数接続で異なる制御があり、ブラウザーのダウンロード、動画再生、速度測定ツールで結果が変わることもあります。アクセス権のある同じリソースを繰り返しテストし、別の出口とも比較してください。テスト結果をよく見せるために、カーネルのタイムアウト設定を頻繁に変更しないでください。

プロトコル、ルーティング、通信の取り込み方の違いを確認する

TUNモードだけ遅い場合は、まず別のVPNが同時に動いていないことを確認し、ログでルートの重複や通信のループが起きていないか調べます。システムプロキシで短時間比較すると、アプリからの接続元と出口回線を切り分けられます。システムプロキシは正常でTUNだけ異常でも、すぐにすべてのノードを変更しないでください。仮想ネットワークアダプター、DNSの取り込み、使用するネットワークアダプターを確認します。特に仮想マシンやコンテナーのネットワークがある端末では注意してください。

一部のアプリはUDPベースの通信方式を優先します。現在の出口がその通信に対応していないと、失敗を待ってからTCPへ切り替わり、開始時に時間がかかることがあります。管理できるテスト環境では、アプリの該当する通信設定を一時的に無効にして、改善するか確認できます。変更内容を記録し、テスト後に元へ戻してください。UDPを全体で遮断すると、通話やゲームなど他の通信にも影響するため避けてください。

MTUの不一致によって、小さなリクエストは正常でも、大きなデータの転送が止まることがあります。ただし、すべての遅延の原因がMTUとは限りません。特定のネットワークまたはTUN経路で再現し、他の接続方法では正常な場合に限り、さらに確認してください。クライアントとネットワーク環境の説明に従って範囲を絞って調整し、元の値を記録します。値を無作為に下げるとパケット数が増え、回線やサーバーの問題を見えにくくすることがあります。

長時間使った後に遅くなる場合は、接続画面で異常な再接続が大量に発生していないか、デバッグログが継続的にディスクへ書き込まれていないか、端末が省電力状態や過熱による性能低下に陥っていないか確認してください。まず異常なリクエストを発生させているアプリを終了し、クライアントのリソース使用量が下がるか確認します。詳細ログは短時間の調査に使い、常時有効にはしないでください。ログの書き込みや画面描画の負荷は、性能の低い端末にも影響します。

対処後は、同じ接続先、同じネットワーク、同じ接続方法で再テストし、もともと遅れていた段階が改善したかを比較してください。特定のサイトだけが遅く、他のサービスが正常なら、そのドメイン、適用されたポリシー、発生した時間帯を記録し、対象サービスまたは出口経路を調べます。一つのサイトの混雑をクライアント全体の性能問題と見なさず、単発のテスト結果から速度を保証することも避けてください。

DNSの問題：名前解決経路とFake-IPのマッピングを確認する

まずDNSリクエストの処理元を確認する

ログにドメインの名前解決エラーがある場合、OS、ブラウザー、mihomo、ノードのサーバーのどこで発生したかを切り分けます。システムのDNS検索に成功しても、カーネルが使う上流DNSが正常とは限りません。ブラウザーで独自のセキュアDNSを有効にしていると、システムの名前解決経路を通らないこともあります。現在の通信の取り込み方とDNS設定を確認してから、該当する方法でテストしてください。一つの層での結果を別の層の正常性の証拠にしないでください。

まずエラーに表示されているドメインを確認します。ノードサーバーのドメインを解決できない場合、プロキシ経路を確立できません。Webサイトのドメインが解決できない場合は、経路の確立後に問題が起きている可能性があります。暗号化DNSを使用している場合、上流リゾルバーのホスト名も先に解決する必要があるかもしれません。これら三種類の名前を区別すると、初期名前解決、プロキシサーバーの名前解決、通常の接続先の名前解決のどこで依存関係が循環しているか判断できます。

Windowsでは Resolve-DnsName example.com、macOSとLinuxでは nslookup example.com を使ってシステムの名前解決経路を確認できます。特定のDNSサーバーを指定してテストする場合は、アドレスと待ち受けポートを確認してください。システム標準のツールは通常、標準DNSポートに問い合わせます。任意のローカル待ち受けポートのテストにそのまま使うことはできません。コマンドの成功は問い合わせに応答があったことを示すだけなので、クライアントのログに戻って実際のリクエストを確認してください。

Fake-IPの正常な動作を理解する

Fake-IPモードでは、予約済みアドレス範囲内のマッピング用アドレスが返されることがあります。これはカーネルがドメインと接続を関連付けるための仕組みであり、それだけでDNSの改ざんを意味するわけではありません。重要なのは、そのマッピング先への接続が引き続き同じカーネルに届くかどうかです。DNSをクライアントが処理していても、接続がクライアントを迂回すると、アプリはマッピングテーブル内でのみ意味を持つアドレスにアクセスしようとして失敗することがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

これはDNSの部分設定例です。既存の設定に統合して使用し、トップレベルの dns を重複して定義しないでください。二つの上流アドレスは置き換え可能な例にすぎないため、利用中のネットワークで到達できるものを選びます。ループバックアドレス上の非標準ポートで待ち受けても、システムのDNSが自動的に変更されるわけではありません。システムの問い合わせを取り込むかどうかは、クライアントの設定、TUN、プラットフォームにも左右されます。読み込めばすべてのアプリが切り替わると考えないでください。

LANプリンター、画面投影デバイス、実際のアドレスを必要とするアプリでは、特定の名前を fake-ip-filter で除外する必要がある場合があります。ただし、名前が実際にどのように解決され、どのローカルDNSを使っているかを確認してから、必要な範囲だけを追加してください。すべてのドメインを除外するとモード全体の動作が変わり、比較が難しくなります。仕組みとフィルターの範囲についてはFake-IPモードの詳しい解説を参照してください。

キャッシュと暗号化DNSの依存関係を確認する

DNSモードを変更しても、OSやブラウザーに古いアドレスがキャッシュされていたり、アプリが古い接続を再利用したりすることがあります。「設定を保存、カーネルを再読み込み、対象アプリを終了、必要なキャッシュを消去、再テスト」の順に進めてください。Windowsでは以下のコマンドでシステムのDNSキャッシュを消去できます。ブラウザー独自のキャッシュは消えず、サーバーが返した誤った結果も修正されません。

ipconfig /flushdns

クライアントの設定とキャッシュをすべて同時に削除しないでください。Fake-IPのマッピングと古い接続の不一致が疑われる場合は、データディレクトリ全体を削除するより、対象アプリを再起動してマッピングを作り直すほうが適切です。スリープから復帰した後に発生した場合は、ネットワークが切り替わっていないか、仮想インターフェースが復旧しているか、古い接続が元のネットワークに紐付いたままかを確認してから、カーネルの再起動が必要か判断します。

DoHやDoTを使用している場合は、上流アドレスに接続できるか、証明書が有効か、上流への接続が未確立のプロキシにルールで振り分けられていないか確認します。暗号化されているからといって、自動的に安定するわけではありません。現在のネットワークで接続を確立できなければ、問い合わせは失敗します。まず確実に到達できる通常の上流DNSと比較し、問題の段階を特定したうえで元の暗号化DNSに戻してください。安易に置き換えた設定を恒久的に使わないでください。

IPv6のみの環境やデュアルスタックネットワークで問題が起きる場合は、ログでIPv4とIPv6のどちらのアドレスが選択されたかを確認し、端末の実際のルーティング能力と照らし合わせます。システムにIPv6アドレスが割り当てられていても、すべての出口でIPv6接続できるとは限りません。IPv6関連の設定変更は、条件を絞ったテストで原因を調べるために使います。あらゆる名前解決の問題に対してIPv6を無効にする方法を固定手順にしないでください。

修正後は、以前失敗したドメインとLAN内の接続先にそれぞれアクセスし、インターネット向けのルール振り分けとローカルデバイスの検出が互いに影響していないか確認します。必要ならシステムDNS、カーネルの上流DNS、ブラウザー独自のDNSの設定を記録し、役割を分けて把握してください。特定のドメインだけで異常な応答がある場合は、権威DNSとルールを優先して確認し、端末全体のDNSリセットに範囲を広げないでください。

システムプロキシが機能しない：アプリの接続元とポートの種類を確認する

システムプロキシですべての通信を処理できるわけではない

システムプロキシは、その設定を読み取るアプリにプロキシアドレスを提供するもので、すべての通信を強制的に取り込む機能ではありません。ブラウザー、コマンドラインツール、ストアアプリ、ゲームは使用するネットワークライブラリが異なり、動作も変わります。Webサイトは開けるのに特定のアプリが直接接続する場合は、そのアプリがシステムプロキシに対応しているか、独自のプロキシ設定がないかを確認してから、TUNを使うか判断してください。正常に動作しているサブスクリプションを先に変更しないでください。

プロキシのアドレスが現在の端末のループバックアドレスを指しているか、ポートがクライアントの設定と一致しているか確認します。HTTPポート、SOCKSポート、混合ポートは自由に入れ替えられません。SOCKS専用ポートにHTTPプロキシのリクエストを送ると、接続が切断されたりプロトコルエラーになったりすることがあります。クライアントで混合ポートを有効にしていれば、一つの待ち受けで対応するプロキシプロトコルを利用できる場合がありますが、アプリ側でも正しい種類を選ぶ必要があります。

まずプロキシを明示的に指定するコマンドで確認し、その結果をプロキシを指定しないアプリのアクセスと比較してください。明示的なリクエストは成功するのにブラウザーが失敗する場合は、ブラウザー拡張機能、独自のプロキシ設定、システムプロキシの読み込み、除外リストを重点的に確認します。どちらも失敗する場合は、ローカルの待ち受けかノードへの接続を調べます。この比較により、「アプリからクライアントに届いていない」問題と「届いた後に転送できない」問題を区別できます。

プラットフォームごとに実際の設定を確認する

環境確認する場所と範囲
Windows「設定 → ネットワークとインターネット → プロキシ」を開き、ユーザー向けのプロキシ設定とWinHTTPが使用する設定を区別します。
macOS現在のネットワークサービスの「詳細 → プロキシ」を確認します。Wi-Fiと有線サービスで設定が異なる場合があります。
Linuxデスクトップのプロキシ設定、アプリの起動オプション、環境変数はそれぞれ別に適用されます。コマンドラインツールがデスクトップの設定を読み取るとは限りません。

Windowsでは netsh winhttp show proxy でWinHTTPのプロキシ状態を確認できますが、ブラウザーなどのユーザー向けプロキシ設定を完全に反映するものではありません。表示が直接接続でも、クライアントのシステムプロキシが無効とは限りません。また、一つのアプリを直すために設定全体をそのまま取り込まないでください。まずアプリが使うネットワークスタックを確認し、特にサービスとして動くプログラムは、そのアプリのドキュメントに従って設定してください。

macOSでWi-Fi、有線、その他のネットワークサービスを切り替えた後は、クライアントが現在有効なサービスの設定を更新しているか確認してください。自動プロキシ設定スクリプトを使っている場合は、手動のHTTP、HTTPS、SOCKS設定と重複していないかも確認します。業務用端末では管理ポリシーにより、画面で保存した設定が上書きされることがあります。この場合は端末の管理者に確認し、設定を何度も強制変更しないでください。

Linuxのコマンドラインアプリは http_proxy、https_proxy、no_proxy などの環境変数を参照することがありますが、対応状況はプログラムごとに異なります。新しい環境変数は通常、そのターミナルから起動したプロセスにのみ適用され、実行中のアプリには反映されません。一時的に確認する場合は、セッション全体やシステム設定を変更せず、コマンド一つにプロキシを指定すると元に戻しやすくなります。

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

socks5h は接続先ドメインの名前解決をプロキシ側で行う指定です。ローカルDNSの影響を切り分けるのに便利ですが、ポートが実際にSOCKSリクエストを受け付けることが前提です。ローカルで名前解決する設定に変えると、テストする経路も変わります。後で結果を比較できるよう、コマンドで使ったプロトコルと名前解決の場所を記録してください。「同じポートを使った」というだけでは、テスト条件が同じとは限りません。

除外設定とサンドボックスの制限を確認する

システムやアプリの除外リストを確認します。対象がLAN、特定のドメイン、自動設定スクリプト内の直接接続条件に一致すると、想定どおりプロキシを通りません。まず対象に関係する項目だけを正確に調整してください。除外設定をすべて消すと、ローカルサービスや社内リソースに影響する場合があります。ブラウザー拡張機能がプロキシの判断を引き継いでいることもあるため、調査中は一時的に無効にし、システム設定を単一の接続元にしてください。

一部のWindows UWPアプリでは、ローカルループバックへのアクセス制限により、プロキシの待ち受けが正常でもアプリからループバックアドレスに接続できないことがあります。UWPのループバック制限への対処方法を参考に、対象アプリに合わせて例外を設定するか、対応環境ではTUNを使用してください。すべてのアプリに一括で権限を与えたり、このプラットフォーム固有の問題を通常のデスクトップアプリに当てはめたりしないでください。

TUNを使う前に、競合するVPNを終了し、クライアントが必要とするサービスや権限が利用可能か確認してください。TUNは通信の取り込み方を変える機能であり、ノードの停止やサブスクリプションの誤りを修正するものではありません。テスト後は、システムプロキシも同時に有効にする必要があるか確認し、最終的な組み合わせを記録します。基本的な接続設定はシステムプロキシの設定手順を参照してください。ログに対象の接続が記録されるかどうかを、動作確認の根拠にします。

クライアントがクラッシュする：画面、カーネル、設定データを切り分ける

終了したプロセスを特定する

ウィンドウが閉じる、タスクトレイから消える、通信が切れるという現象は、同じプロセスが原因とは限りません。まずタスクマネージャーまたはアクティビティモニタで、画面のプロセスが残っているか、mihomoカーネルが繰り返し起動していないか、終了前にエラーが表示されたかを確認します。画面が応答しなくてもプロキシが使えるなら、描画やアプリデータを重点的に調べます。画面は正常なのにプロキシが停止する場合は、カーネルのログと設定の読み込みを優先して確認してください。

起動直後に終了する、設定を切り替えた後に終了する、TUNを有効にすると終了する、スリープ復帰後に異常が起きるなど、発生のきっかけを記録します。安定して再現できる最短の手順は、長時間の不定期な使用記録より役立ちます。再起動前に終了直前と直後のログを別ファイルへコピーしてください。何度も起動するとログが上書きされる場合があり、アプリデータを消去すると調査に必要な情報が失われます。

OSのイベントログ、空きディスク容量、セキュリティソフトの遮断履歴も確認します。ディスクが満杯、フォルダーに書き込み不可、カーネルファイルが隔離されていると、起動失敗のように見えることがあります。セキュリティ保護をすべて無効にせず、ブロックされたファイルと入手元を確認したうえで、セキュリティソフトとクライアントの説明に従って対処してください。業務用端末のポリシー制限は、管理者に確認を依頼します。

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

インストーラーはOSとCPUアーキテクチャに合ったものを選んでください。WindowsやmacOSの異なるアーキテクチャ、Linuxのパッケージ形式は、ファイル名が似ているだけで使い回せません。クライアントのダウンロードページから対応プラットフォームを選び、一般ユーザーはまずClash Plusを利用できます。Linuxではディストリビューションの依存関係、デスクトップ環境、パッケージマネージャーが表示する具体的なエラーも確認してください。システムライブラリをすぐに置き換えないでください。

アップデート後に問題が起きた場合は、古い画面が新しいカーネルに接続したり、複数のインスタンスがポートを取り合ったりしないよう、古いプロセスをすべて終了します。ポータブル版のフォルダー、システムへのインストール先、自動起動項目に別々のコピーが残っていることもあります。現在のプロセスの実際のパスを確認してから、どれを整理するか決めてください。名前が似ているフォルダーを直接削除すると、使用中の設定やバックアップを失うおそれがあります。

ログにアドレスの競合が表示されたら、ポートを変更する前に使用中のプロセスを調べます。Windowsでは以下のコマンドを実行し、ポート番号を実際の待ち受けポートに置き換えてください。出力されたプロセスIDはタスクマネージャーで確認します。ポートが使用中だからといって、未知のプロセスを強制終了しないでください。別のクライアントインスタンスや正常に動作しているローカルサービスの可能性があります。

netstat -ano | findstr :7890

競合しているのが別のプロキシツールだと確認できたら、通常の手順で終了してから現在のクライアントを起動します。ポートを変更する場合は、システムプロキシ、アプリ独自のプロキシ、関連スクリプトも合わせて更新してください。カーネルが起動しても、アプリが古いアドレスにリクエストを送ることがあります。コントロールAPIのポートと通信を中継するプロキシポートは用途が異なるため、数値が近くても入れ替えないでください。コントロールAPIを信頼できないネットワークに公開しないでください。

最小限の変更で設定の問題を特定する

特定の設定だけで終了する場合は、まずローカルの上書き設定とスクリプトを無効にし、元の内容を設定検証にかけます。カスタムルールが多すぎる、リモートルールセットを重複して読み込む、スクリプトでエラーが続くといった問題が起動やメモリに負荷をかけることがあります。拡張設定を一つずつ戻し、どの項目で問題が発生するか確認してください。別の大規模な設定に切り替えるだけでは有効な比較にならず、カーネル自体に欠陥がある証拠にもなりません。

アプリを初期状態でテストする必要がある場合は、サブスクリプション情報、上書きルール、ポリシーの選択をエクスポートし、元のデータフォルダーを別の場所へバックアップしてください。クライアントの説明に従って元のフォルダーを一時的に移動し、テストを実行します。用途が分からないフォルダーを再帰的に削除しないでください。初期状態で動作しても、元のデータに関係することが分かるだけです。何が原因か特定するために少しずつ戻し、元の設定を恒久的に捨てないでください。

TUNを有効にした場合だけ問題が起きるなら、アプリを丸ごと再インストールせず、サービスの権限、仮想インターフェース、他のVPNドライバーを確認してください。ログ画面を開いたときだけ画面が固まる場合は、ログ量を減らし、繰り返し発生しているリクエストを止めてから確認します。この二つは別のコンポーネントに関わる問題です。手順を詳しく記録すると、メンテナーが画面側とカーネル側のどちらのログが必要か判断しやすくなります。

最終テストでは、コールドスタート、設定の読み込み、リクエストを一度実行、正常終了を確認し、必要ならスリープ復帰も検証します。クライアント名、OSのアーキテクチャ、発生させた操作、機密情報を除いたエラーをまとめ、バージョン情報を推測で記載しないでください。実際のバージョンは「情報」画面で確認できます。別のクライアントへの変更が必要な場合は元のデータを残し、画面、通信の取り込み方法、設定の互換性の違いについてクライアント比較を参照してください。

モバイル端末の対処：VPN権限、バックグラウンド制限、ネットワーク切り替え

まずシステムのVPN接続状態を確認する

スマートフォンのクライアントは、通常、システムのVPNインターフェースを使ってアプリの通信を取り込みます。初回起動時にはシステムの許可が必要です。ステータスアイコンが表示されても、インターフェースが作成されたことを示すだけで、リモートノードへの接続成功を意味しません。クライアントのログを開いてから対象アプリでリクエストを実行し、接続がカーネルに届いて想定するポリシーに一致するか確認します。該当するログがない場合は、まず取り込み対象とアプリの除外設定を調べてください。

トラブルシューティング中は、VPNを使うサービスを一つだけ有効にしてください。企業VPN、ローカルVPNを使うフィルタリングツール、他のプロキシアプリがシステムのインターフェースを取り合うことがあります。後から起動したサービスによって、先に起動していたサービスが無効になる場合があります。仕事用プロファイルや管理ポリシーがある端末では、個人用と仕事用の領域を区別してください。一方の領域のアプリが、もう一方で作成したネットワーク経路を使えるとは限りません。

AndroidではClash Plusを選べます。用途に応じてClash Meta for Android、FlClash、Surfboardも利用できますが、対応する設定形式やメニューはそれぞれ異なります。iOSではiOSのダウンロードページでClash Plusを確認できます。公式サイトは clashplus.io です。デスクトップ版専用のサービスモードやシステムプロキシの手順を、そのままスマートフォンに適用しないでください。

Androidのバックグラウンド動作とアプリ別プロキシ

画面点灯中は正常でも、ロック後に接続が切れる場合は、バッテリー最適化、バックグラウンド動作の制限、メーカー独自の自動起動管理を確認します。必要に応じてクライアントのバックグラウンド実行を許可し、終了されなくなるか確認してください。省電力設定はアプリ情報、バッテリー管理、バックグラウンド起動などの画面に分かれていることがあり、名称も端末によって異なります。一つのクライアントを直すために、すべてのアプリを制限対象外にしないでください。

「常時接続VPN」やVPN未経由の接続をブロックする設定を有効にしていると、クライアントの停止後もシステムが通信を遮断することがあります。これは保護機能として想定される動作の一つです。調査時は元の設定を記録し、比較のために該当する制限を一時的に解除してください。問題の解決後、必要に応じて設定を戻します。アプリを終了しただけでシステムの状態を確認しないと、Wi-Fiそのものの不具合と誤認することがあります。

一部のアプリだけをプロキシ経由にする場合は、現在の設定が対象アプリのリストか除外アプリのリストかを確認してください。リストの種類を取り違えると、対象アプリが常に直接接続することがあります。新しくインストールしたアプリが自動で追加されるかどうかも、クライアントによって異なります。対象範囲を変更した後は、既存の接続が古い経路を使い続けないよう、対象アプリを終了してから再起動してください。ブラウザーとアプリ内ブラウザーは別プロセスの場合があるため、それぞれ確認します。

アプリが独自のDNS、専用プロトコル、固定アドレスへの直接接続を使うこともあります。一つのブラウザーが動作しても、すべてのアプリの通信が取り込まれているとは限りません。まずログで対象のリクエストを探し、接続元が記録されていないのか、ルールが誤っているのか、出口が対応していないのかを判断してください。Androidでの基本的な設定の読み込みと有効化はAndroidのクイックスタート手順を参照してください。問題が起きている状態で、同じ設定を何度も再インポートしないでください。

iOSとネットワーク切り替え後の復旧

iOSでは、システムのVPN設定が現在使用しているクライアントのものか確認し、自動接続する可能性のある他のVPNを終了してから接続します。システム設定とクライアントの表示が一致しない場合は、通常の手順で接続を停止してアプリを再起動し、再認証の際にアプリ名を確認してください。組織が管理する構成プロファイルをむやみに削除しないでください。組織所有の端末では、ネットワーク管理上の制約を事前に確認します。

Wi-Fiからモバイルデータ通信に切り替えると、古い接続が元の経路に紐付いたままになることがあります。まずシステムの切り替えが完了するまで待ってから、クライアントを再接続し、対象アプリを終了して再試行してください。モバイルデータ通信でのみ失敗する場合は、クライアントと対象アプリのモバイルデータ通信の権限、通信事業者の制限、現在のノードの通信方式を確認します。ネットワークの切り替えではDNS、アドレスファミリー、ルートも変わるため、ノードの停止だけが原因とは限りません。

ホテルや空港のWi-FiでWeb認証が必要な場合は、まずプロキシを停止して認証を完了し、その後接続を再開します。VPN経由の通信を必須にするシステム設定があると、認証画面が表示されないことがあります。その場合は該当する制限を一時的に変更し、設定を記録してください。認証後に一般的なWebページへアクセスして直接接続を確認し、それからプロキシをテストします。認証が完了する前にサブスクリプションやDNSを何度も変更すると、問題の段階を特定しにくくなります。

スマートフォンでは通信できても、テザリングで接続した端末が同じ経路を使えないことがあります。これは必ずしも故障ではありません。OSがテザリングの通信を端末内のVPNに通さない場合や、クライアントがその機能に対応していない場合があります。スマートフォンでの接続成功だけを根拠に、テザリング端末もプロキシ経由になると判断しないでください。LAN向けの明示的なプロキシが必要な場合は、クライアントの対応状況、待ち受け範囲、アクセス制御を確認し、信頼できるネットワークでのみ有効にしてください。

モバイル端末で対処した後は、画面点灯中の接続、ロック後の復帰、Wi-Fiとモバイルデータ通信の切り替えをそれぞれ確認し、対象アプリが想定したルールに引き続き一致するか調べます。特定の場面だけで失敗する場合は、その状況とシステムの制限を記録し、毎回クライアントを再インストールしないでください。一般的なボタンやログ項目はクライアント画面の概要を参照して確認できます。普段の利用に戻す前に一時的に解除したセキュリティ設定を復元し、使用可能な設定のバックアップを保存してください。

Clashをダウンロード