Clashのトラブル対処
接続と設定の診断

症状から確認箇所を絞り、根拠をもとに設定を修正します。まず問題が起きている層を特定し、変更が有効か確認しましょう。

クライアントをインストール済みで、接続や設定に問題が起きた場合に調べるためのガイドです。初めて使う場合は、まずClashの設定ガイドに沿ってサブスクリプションの追加、ルールモードの設定、接続確認を行ってください。ここではインストール手順ではなく、失敗時の原因別の対処を説明します。画面上の名称はクライアントの表示に従い、設定キーは実際に動作しているカーネルに合わせてください。

変更する変数は一度に1つにし、変更前の値を記録してください。起動できる設定を1つ保存し、一時的な診断項目をサブスクリプションの設定に直接書き込まないでください。ログを共有する際は、サブスクリプションURL、アカウント情報、ノードの認証情報を隠します。エラーの種類、対象ドメイン、適用ルール、発生時刻が残っていれば、通常は原因の特定を続けられます。

インターネットに接続できない：通信が途切れている層を確認する

まず通常のネットワーク環境に戻し、問題の範囲を確認する

まずクライアントのシステムプロキシとTUNをオフにし、ほかのVPNやプロキシアプリも終了します。普段、直接接続できるサイトを開き、Wi-Fi、有線LAN、モバイル通信が正常か確認してください。オフにしても接続できない場合は、ルーター、ネットワーク認証、システムに残ったプロキシ設定を優先して調べます。ノードを次々に切り替える必要はありません。公衆ネットワークでは、先に認証ページを開く必要がある場合があります。プロキシを先に起動すると認証リクエストが迂回し、すべてのサイトに接続できなくなることがあります。

基本のネットワーク接続が正常なら、クライアントを再起動し、設定が選択されていること、カーネルが起動していること、プロキシグループに利用可能なメンバーがあることを確認します。画面の「接続済み」はローカルサービスの起動を示すだけの場合があり、リモートプロキシに接続できるとは限りません。まずルールモードで同じサイトにアクセスし、接続一覧にリクエストが表示されるか確認してください。記録がない場合は通信の入口を、記録はあるのに接続できない場合はポリシー、ノード、名前解決の結果を調べます。

明示的なプロキシリクエストで入口と出口を切り分ける

設定画面で実際のmixed-portを確認してから、以下のテストを実行します。例ではローカルポート7890を使用しています。設定が異なる場合は、コマンド内のポートを実際の値に変更してください。Windowsでは、旧バージョンのPowerShellにある同名コマンドとの動作差を避けるため、curl.exeを使います。テスト対象は現在開けないサイトに変更しても構いません。リクエストは1～2回で十分で、並列負荷テストは不要です。

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

Connection refusedと表示される場合、通常は対象ポートで待ち受けていないか、ポート番号が間違っています。ローカルプロキシへの接続後にタイムアウトする場合は、出口ノード、ルール、リモートネットワークに問題がある可能性があります。HTTPステータスコードが返った場合は、ネットワーク経路の一部が動作していますが、そのステータスが対象サイトと中継サービスのどちらから返されたか確認してください。証明書エラーは別途対処し、証明書検証を無効にして原因を覆い隠さないでください。

モード、プロキシグループ、ルールの順序を確認する

ルールモードでは、設定に記載された順にルールが適用され、最初に一致したポリシーが使われます。対象サイトが先にREJECTに一致している場合、ノードを変更しても拒否は解除されません。プロキシグループでDIRECTが選択されている場合も、プロキシのスイッチをオンにしただけでは、その接続がリモート経由になるとは限りません。全体のスイッチだけを見るより、接続の詳細で適用ルールと実際の経路を確認しましょう。カスタムルールに記載するポリシー名は、既存のプロキシグループ名と完全に一致させてください。

比較のため、一時的にグローバルモードへ切り替え、検証済みのノードを明示的に選択できます。グローバルモードでは接続できるのにルールモードでは失敗する場合、ルールの適用、プロキシグループのネスト、直接接続時の名前解決を優先して確認します。どちらのモードでも失敗する場合は、ローカルの入口とノード自体を調べます。比較が終わったらルールモードに戻してください。グローバル転送は、LAN、社内システム、通信量の扱いに影響することがあります。

確認結果優先して調べる項目次の手順
プロキシをオフにしても失敗する基本ネットワーク、認証、残存設定ゲートウェイとシステムプロキシを確認
明示的なプロキシ接続は成功するが、ブラウザーでは失敗するブラウザー設定、拡張機能、アプリの通信経路システムプロキシと個別設定のプロキシを確認
グローバルモードでは使えるが、ルールモードでは失敗するルールの順序、プロキシグループ、DNS接続詳細で適用ルールを確認
特定のサイトだけ接続できない対象サービス、出口制限、個別ルール対象サイトと出口を変えて比較

修復後、再現可能な手順で確認する

ページがたまたま再読み込みできたことを、修復完了の根拠にしないでください。既存の接続を閉じるかテスト用アプリを再起動し、直接接続するサイト、プロキシが必要なサイト、LAN内のアドレスを順に確認します。接続一覧が想定どおりかも確認してください。ブラウザーが古い接続を再利用することがあり、ポリシー切り替え後は新旧のリクエストで経路が異なる場合があります。結果が安定したら設定を保存し、使用できたポート、モード、選択中のプロキシグループを記録してください。

ノードがタイムアウトする：プローブ失敗と通信失敗を分けて考える

まず、どのテストでタイムアウトしたか確認する

ノード一覧でのタイムアウトは、通常、クライアントが実行したプローブリクエストの結果です。すべての通信に失敗するという意味ではありません。プローブ先に接続できない、接続先で制限されている、想定と異なる応答が返るといった理由で、利用可能なノードが異常に見えることがあります。まずそのノードを選んで実際のサイトにアクセスし、ログも確認してください。ウェブサイトを開けるのにプローブだけ失敗する場合は、ノードを削除したりサブスクリプションが無効だと判断したりせず、テスト先とタイムアウト設定を確認します。

実際のアクセスも失敗する場合は、同じプロキシグループ内のほかのノードと比較します。すべて失敗する場合は、基本ネットワーク、アカウントの状態、共通設定、ローカルでの通信遮断が原因の可能性があります。1つのノードだけ失敗する場合は、ノードの接続先、プロトコル設定、その回線に問題がある可能性が高くなります。リスト全体を一度にテストすると、多数の同時接続によって制限されることがあるため避けてください。接続先が異なるノードを2つ選び、順番にテストすれば、原因を絞り込むには十分です。

ログから接続、ハンドシェイク、名前解決を見分ける

dial tcpに続いてタイムアウトが記録されている場合は、TCP接続の確立に時間がかかっていることを示します。connection refusedは接続が明示的に拒否された状態で、ポートが開いていない、またはサービスが起動していない可能性があります。ハンドシェイクの失敗は、プロトコルまたはTLSの処理段階に進んでいることを示します。エラーの接続先がノードサーバーなのかウェブサイトなのかを確認してください。原因に応じた確認箇所が異なるため、末尾の「timeout」だけを見て判断しないでください。

ノードの接続先にドメイン名を使っている場合は、まずその名前を解決できるか確認してください。名前解決に失敗すると、それを利用するすべての接続が途中で止まります。誤ったアドレスに解決された場合は、ハンドシェイク失敗として現れることがあります。TLS系のプロトコルでは、システム時刻、サーバー名、サブスクリプションで指定されたパラメーターも確認してください。servernameを安易に削除したり、フィンガープリントやトランスポートのパスを変更したりしないでください。通常、これらの項目はサーバー側と一致させる必要があり、推測で変更すると確認事項が増えてしまいます。

現在のネットワークで使えるプロトコルか確認する

ネットワークによってはUDPが制限されています。TCP系のノードは使えるのにUDPを必要とするプロトコルが失敗し続ける場合は、別のネットワークでも試し、ローカルネットワークの制限かサーバー側の問題かを切り分けます。Hysteria2やTUICなどの動作を、通常のTCPポートテストだけで判断することはできません。逆に、TCP接続を確立できても、プロキシプロトコルの認証や転送が成功したとは限りません。

職場、学校、公衆Wi-Fiには、明確なアクセス方針が定められている場合があります。トラブルの確認時はネットワーク管理者のルールに従い、制限を回避しないでください。利用が認められている自宅ネットワークやモバイル通信で同じノードを試します。特定のネットワークだけで失敗する場合は、発生時刻、プロトコル、エラーが起きた段階を記録すると、サービス提供元が調査しやすくなります。テスト目的でローカルプロキシの待ち受けをLAN全体に公開しないでください。

プロキシグループで実際に選択されているノードを確認する

手動選択グループ、自動選択グループ、フォールバックグループでは動作が異なります。画面で上位グループを選んでいても、実際の出口は下位の自動選択グループにある場合があります。上位に表示された名前が最終的なノードとは限りません。接続経路を展開し、どのメンバーがリクエストを処理したか確認してください。自動選択の結果にはプローブのキャッシュが影響する場合があります。テストを更新した後、実際のリクエストでも確認し、色やラベルだけで判断しないでください。

サービスの稼働状況と通信量の上限を確認してください。アカウントの期限切れ、ノードの移行、同時接続数の制限によって、設定形式が正しいノードでも動作しないことがあります。まずサブスクリプションを更新し、サービス提供元が公開している状態を確認します。公開の場にノードURI全体を貼り付けないでください。ノードのパスワード、UUID、サブスクリプションURLはアクセス権限を与える情報です。アカウントの認証情報と同様に扱ってください。

修復手順と元に戻す際の注意点

まず、有効なサブスクリプションに更新し、検証済みノードを選択して、サービス提供元の元のパラメーターに戻します。その後、別のネットワークでも再確認してください。証明書エラーをskip-cert-verifyの常時設定で解決しようとしないでください。先に時刻とサーバー名を確認し、証明書の問題はサービス提供元に問い合わせます。タイムアウトを一時的に延ばす方法は応答の遅さを調べる場合に限り有効で、認証失敗、ドメイン名の誤り、閉じたポートは修復できません。

自動プローブだけに問題がある場合は、アクセスが許可された安定したテスト先に変更して再試行できます。確認時は「プローブの成否」と「実際の通信の成否」を別々に記録してください。遅延、通信量の倍率、接続地域の選び方については、Clashのノード選びガイドも参照してください。遅延が小さくても帯域が十分とは限らず、ノードが使えてもすべてのサイトがその出口を受け入れるとは限りません。

サブスクリプションの取得に失敗する：リクエスト失敗と設定解析失敗を切り分ける

取り込んだURLとエラーが起きた段階を確認する

サブスクリプションの更新は2段階です。まずURLから応答を取得し、次にクライアントまたはカーネルが内容を解析します。接続タイムアウト、証明書エラー、異常なHTTPステータスはリクエスト段階の問題です。取得後にYAMLエラー、未対応の項目、プロキシグループの参照エラーが出る場合は解析段階の問題です。まずエラー全文を読み、どの段階で失敗したか確認してください。更新ボタンを繰り返し押しても、URLの期限切れや形式の非互換は解決しません。

貼り付けた内容に、先頭や末尾の空白、改行、日本語以外の句読点などが混入していないか確認してください。アカウントの管理ページ、決済ページ、ノード管理ページではなく、サービス提供元が発行したサブスクリプションURLを追加します。URLのクエリパラメーターには認証情報が含まれる場合があり、末尾が欠けると別のリクエストになります。サブスクリプションURL全体を含むコマンドを共用端末で実行したり、スクリーンショットや公開ログに貼り付けたりしないでください。

HTTPの結果から次の確認箇所を判断する

ステータスコードは確認の手がかりです。具体的な意味はサービス提供元の実装によって異なります。認証失敗やアクセス拒否は、認証情報、アカウントの状態、リクエストの制限が関係している可能性があります。リソースが見つからない場合はURLが変更された可能性があり、リクエスト過多の場合は更新を中断してください。成功ステータスが返っても、内容がログインページ、メンテナンスページ、エラー説明で、設定ファイルではないことがあります。ブラウザーでURLを開けても、クライアントが同じ内容を取得できるとは限りません。

結果よくある原因対処方法
リクエストがタイムアウトするネットワーク経路、DNS、サービスへの到達性直接接続とプロキシ経由の更新を比較
401 / 403認証情報、アカウント、リクエスト制限管理画面の状態とインポート方法を確認
404URLの移行またはパスの誤り最新のサブスクリプションURLを再コピー
429更新頻度が高すぎる再試行をやめ、サービスの案内に従って待つ
応答は成功したが解析に失敗する内容形式、エラーページ、構文コンテンツの種類と設定構造を確認

更新経路が起動時の依存関係にならないようにする

サブスクリプションURLによっては、プロキシ経由でないとアクセスできない場合があります。現在のプロキシノードが使えず、新しいノードを取得するリクエストまでそのノードに依存すると、更新できない状態から抜け出せなくなります。クライアントにプロキシ経由で更新する設定があるか確認してください。ネットワークで許可されている場合は直接接続での更新を試すか、保存してある利用可能な設定で先に接続します。アクセスできないURLを何度も別の形式に変換しても、本当の経路の問題は解決しません。

サービスによっては、User-Agentに応じて異なる形式を返します。まずサービスの管理画面でClashまたはmihomo向けのインポート方法を選び、指定されたクライアント要件に従ってください。リクエストヘッダーを適当に偽装すると、別のクライアント向けの内容が返る場合があります。非公開のサブスクリプションを見知らぬオンライン変換サービスに渡すと、認証情報の漏えいリスクが広がります。変換が必要な場合は、ツールの提供元とデータの扱いを先に確認してください。

YAMLとカーネルの互換性に関するエラーを調べる

YAMLのインデントにはスペースを使い、タブを混在させないでください。エラー行番号が示すのは、解析を続けられなくなった位置で、原因は前の行の引用符、コロン、リストのインデントにある場合があります。エラー行の前後を確認してから、最上位の構造を調べます。以下は正しいルール記述の例で、単独で接続できる完全な設定ではありません。ポリシー名は、既存の設定にあるグループ名と一致させてください。

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

YAMLの構文に問題がないのに、プロトコルや項目が未対応と表示される場合は、実際に動作しているカーネルを確認してください。クライアント名、画面上のバージョン、カーネルの機能はそれぞれ異なります。古いカーネルではmihomoの拡張構文を使えない場合があります。エラーが出た項目を単に削除して設定を読み込ませないでください。その項目はプロトコルに必要なパラメーターかもしれません。互換性の範囲はmihomoとオリジナルカーネルの違いも参照してください。

ローカルの変更を保護し、更新後の動作を確認する

リモートサブスクリプションを更新すると、直接編集した内容が上書きされる場合があります。クライアントがオーバーライド、マージ、ローカルルールに対応している場合は、ダウンロード済みのキャッシュではなく、該当する設定層にカスタム項目を置いてください。更新後はノード一覧、プロキシグループのメンバー、ルールが想定どおりか確認し、ノードを1つ選んで実際に接続します。サブスクリプションファイルを読み込めても、それは解析に成功したことを示すだけで、リモートの全ノードが利用可能とは限りません。

新しい設定で起動に失敗し、以前の設定が使える場合は、まず古いコピーに戻し、新しい設定のエラー記録を残してから対処してください。すべての設定やキャッシュを一度に消すと比較できなくなるため避けましょう。詳しい対処方法はサブスクリプション更新失敗の確認リストを参照してください。修復後は不要な自動更新を減らし、クライアントを再起動しても同じ有効な設定を読み込めることを確認します。

速度が遅い：ノード、回線、端末の3層に分けて調べる

条件をそろえて比較し、異なる指標を混同しない

ウェブページの表示、動画のバッファリング、ファイルのダウンロードは、原因が同じとは限りません。対象、時間帯、操作を具体的に記録します。最初のページ表示まで長く待つのか、ダウンロード開始後の転送速度が低いままなのかを区別してください。テスト中はほかのダウンロード、クラウド同期、システム更新を一時停止し、端末の場所とネットワークをそろえます。時間帯やサイトが異なる結果をそのまま比較しても、変化がノードと対象サービスのどちらによるものか判断できません。

遅延テストで分かるのは、主にプローブの往復時間と処理時間であり、帯域ではありません。遅延の小さいノードでも混雑することがあり、帯域の大きいノードでも、地域間の通信時間によってウェブサイトの表示が遅くなる場合があります。経路が異なるノードを2つ選び、テストが許可された同じサイトにアクセスして、最初の応答と継続的な転送速度をそれぞれ確認します。大容量のテストを繰り返すと、サービス提供元のルールに従って通信量が消費されるため避けてください。

ノードの負荷とネットワーク経路を確認する

1つのノードだけ遅く、ほかのノードと直接接続は正常な場合は、そのノードの回線や負荷を優先して調べます。夜だけ遅く、別の時間帯には回復する場合、共有出口や通信事業者の経路が混雑している可能性があります。同じ地域の別の回線に切り替えるほうが、隣接する地域に変えるだけより原因の特定に役立ちます。地域ラベルだけでは物理回線、出口IP、対象サービスの経路が同じとは限りません。実際の接続結果を基準に判断してください。

すべてのノードが遅い場合は、プロキシをオフにした通常のネットワーク接続を基準として比較します。直接ダウンロードも遅い場合は、Wi-Fiの電波、周波数帯、ルーターの負荷、回線を確認し、可能なら有線LANでも比較してください。特定のサイトだけ遅い場合は、コンテンツ配信経路、速度制限、出口の識別ポリシーが関係している可能性があります。別のサイトも試すと端末全体の問題を除外しやすくなりますが、元のサイトが必ず利用できることを示すものではありません。

DNSの待ち時間と転送速度の問題を切り分ける

最初の表示は遅いのに、2回目は明らかに速い場合、DNS、TLSハンドシェイク、キャッシュが関係している可能性があります。ログで名前解決に時間がかかっていないか、ドメインへの再試行が繰り返されていないかを確認してください。ダウンロード開始後も継続して遅い場合は、回線の転送速度、パケットロス、サーバー側の制限を優先して調べます。速度の問題が起きたからといってDNSをすべて変更しないでください。リゾルバーを変えるとコンテンツ配信先のIPも変わり、比較条件がそろわなくなることがあります。

追加ツールをインストールせず、明示的なプロキシリクエストで所要時間を記録できます。以下のコマンドは合計時間と最初の1バイトを受信するまでの時間を出力します。数値は実際のリクエストから得られます。HTTPプロキシ経由の場合、ドメインの名前解決はプロキシカーネルまたはリモート側で行われることがあるため、結果を独立したDNSテストとして扱わないでください。同じリクエストを異なるノードで実行した場合の比較に使います。

curl --proxy http://127.0.0.1:7890 --max-time 30 -o /dev/null -sS \
  -w '最初の1バイト: %{time_starttransfer}s\n合計時間: %{time_total}s\n' \
  https://example.com

Windowsではcurl.exeを使い、出力先の/dev/nullをNULに置き換えて、コマンドを1行で記述します。小さなページをテスト対象にし、主に応答までの時間を確認してください。大容量ファイルの帯域を測る用途ではありません。最初の応答が正常なのに特定のダウンロードだけ遅い場合は、対象の速度制限、ダウンロードツールの同時接続数、プロキシルールで同じ出口が選ばれているかを調べます。

端末側の通信制御とリソース使用量を確認する

システムプロキシとTUNを比較する際は、プロトコル、DNS、プロキシグループを同時に変更しないでください。TUNモードだけが遅い場合は、ほかのVPN、仮想ネットワークアダプター、セキュリティソフトが同時に動作していないか、ログで同じ接続を二重に処理していないか確認します。タスクマネージャーでCPU使用率が高い、またはディスクへの書き込みが続く場合も、ネットワークの体感速度に影響することがあります。短時間の調査が終わったら通常のログレベルに戻し、大量のログを長時間書き込み続けないようにしてください。

大量の接続、小さなファイルの並列転送、バックグラウンド同期は、カーネルと端末の負荷を高めます。まず関係のないアプリを終了し、同じ作業をもう一度実行してください。ルーターや低消費電力の端末では、暗号化処理や接続数が処理能力の制約になる場合があります。デスクトップPC向けの高い同時接続数をそのまま適用しないでください。速度を上げるためにセキュリティ保護を恒久的に無効にするのも避けましょう。プロセス、ルール、発生時間を比較して、競合の原因を特定します。

MTUとトラフィックの振り分け範囲を調べる

小さなリクエストは正常なのに、大きなページや長時間の接続が止まりやすく、特にTUNや特定のネットワークで発生する場合は、MTU、経路上のパケットロス、UDPの処理に問題がある可能性があります。まず別のネットワークとプロトコルで再確認し、安定した違いが見られてから、対応するMTU設定を少しずつ調整して元の値も記録してください。あらゆる端末に共通する最適値はありません。根拠なく値を下げるとオーバーヘッドが増えるだけで、問題が解決しないこともあります。

最後に、遅いリクエストに適用されたルールを確認します。ダウンロードによっては直接接続され、メディアのリクエストが別のプロキシグループに割り当てられている場合があります。すべての速度を、手動で選択中のノードのせいだと決めつけないでください。一時設定を元に戻し、同じ対象で再テストして、近い時間帯にももう一度確認します。段階的な確認方法はClashの速度低下を段階別に診断する方法を参照し、一時的な変動を恒常的な障害と誤認しないようにしましょう。

DNSの問題：名前解決経路とFake-IPの対応付けを確認する

システムの名前解決とカーネルの名前解決を区別する

ブラウザー、セキュリティソフト、OS、プロキシカーネルのいずれも名前解決に関与する場合があります。端末でドメインを解決できても、アプリが同じ結果を使うとは限りません。アプリで暗号化DNSを有効にしている場合は、システムのリゾルバーを経由しないこともあります。まず失敗したドメイン、エラー内容、現在の通信制御モードを記録してください。ログに該当する名前解決リクエストがない場合は、カーネルのDNS設定をすべて変更する前に、アプリがどの経路で名前解決しているか確認します。

システムのツールで問い合わせると、基準となる結果を得られます。ただし、確認できる範囲を理解しておきましょう。nslookupは通常、システムに指定されたDNSサーバーへ問い合わせます。ブラウザーの暗号化DNSを完全に再現するものではなく、現在のHTTPプロキシを経由するとも限りません。応答したサーバーとアドレスを確認し、クライアントのログと比較してください。ドメインを解決できるのに接続できない場合は、経路、ルール、TLS、対象サービスを調べ、問題が起きている層を混同しないようにしましょう。

nslookup example.com

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

Fake-IPはドメインと接続を関連付けるために対応するアドレスを割り当て、カーネルがドメイン名に基づいてルールを適用できるようにします。有効時に割り当て範囲内のアドレスが表示されても、必ずしも異常ではありません。そのアドレスが実際のサーバーかどうかを、通常の直接接続で検証することもできません。アプリが割り当てアドレスを受け取った後も、同じカーネルが接続を制御する必要があります。名前解決だけ制御して、その後の接続を制御しないと、誤った経路にアドレスが送られる場合があります。

拡張モードを切り替えたり、カーネルを再起動したり、設定を変更したりすると、アプリが古い対応付けをキャッシュしていることがあります。関連するアプリを終了し、プラットフォームでサポートされている方法でキャッシュを消去してから、新しいリクエストを実行してください。WindowsではシステムDNSキャッシュを消去できますが、ブラウザーやアプリが独自のキャッシュを持つ場合もあるため、再起動するかアプリのネットワーク設定を確認します。モードを繰り返し切り替えながら古い接続を残すと、新旧の対応付けが混在するため避けてください。

ipconfig /flushdns

互換性の問題に応じてフィルターを設定する

LAN内のデバイス検出、一部のゲーム、実際のアドレスを必要とするアプリでは、例外設定が必要になる場合があります。問題が確認できたドメインに対してfake-ip-filterを設定し、すべてのドメインを対象外にしないでください。以下の例はFake-IPの範囲とLAN用ドメインのフィルターを示すもので、上流リゾルバーを含まないため、完全なDNS設定の代わりにはなりません。変更前に、現在のカーネルが対応するフィルター構文を確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

プライベートDNSや社内ドメインでは、組織が指定したリゾルバーが必要なことがあります。パブリックリゾルバーは社内DNSの代わりにならず、パブリックサービスへ変更すると業務システムに接続できなくなる場合があります。問題が社内ネットワークだけで起きるか記録し、ドメインのサフィックスとVPNで必要な名前解決方法を確認してください。LAN内のデバイス検出はmDNSやブロードキャストに依存することもあり、ドメインフィルターを追加するだけですべてのデバイス検出が復旧するとは限りません。

上流DNSとノードのドメイン名にある起動時の依存関係を確認する

暗号化DNSの上流サーバー自体がドメイン名で指定されている場合、その接続先を先に名前解決する必要があります。ノードサーバーのドメイン名も、プロキシを確立する前に有効なアドレスを取得しなければなりません。ノードの名前解決まで、まだ確立していないプロキシに依存していると、循環依存が発生することがあります。mihomoのdefault-nameserverやproxy-server-nameserverなどの設定は、それぞれ役割が異なります。まず現在のカーネルでの意味を確認し、必要な箇所だけ調整してください。

DNSリクエストをルールに応じて処理する設定を有効にしている場合は、リゾルバーへの接続が最終的にどの経路を通るかも確認します。相互に参照するポリシーをいくつも追加し、カーネルが自動的に依存関係を解決することを期待しないでください。同じ上流ドメインへの問い合わせがログに繰り返され、接続が完了しない場合は、まず起動時の名前解決経路を調べます。上流がタイムアウトする場合は、サーバー名が一般的かどうかだけでなく、現在のネットワークからアクセスできるか確認してください。

DNS漏えいと不正な名前解決結果を調べる

DNS漏えいとは、名前解決リクエストが意図した経路を通らないことです。「結果に現地の通信事業者名が含まれること」と同じ意味ではありません。ウェブ上のテスト結果は手がかりにすぎず、キャッシュ、ブラウザーの暗号化DNS、IPv6、テストサービス側の観測方法に左右されることがあります。システムのDNS設定、クライアントの問い合わせログ、アプリの設定を照らし合わせ、誰がどの経路でリクエストを送ったか確認してから、設計した経路と異なるか判断してください。

IPv6が有効な場合は、AAAAレコードとIPv6の経路も確認してください。IPv4のプロキシ入口だけを処理しても、IPv6のリクエストまで制御されるとは限りません。一方、IPv6を単に無効にすると、正常だった通信に影響する場合があります。同じドメインのアドレス種別と接続結果を比較し、使用しているプラットフォームに合わせて、すべての通信を制御するか、明示的に直接接続するか設定してください。用語の説明はFake-IPの用語解説を参照してください。

システムプロキシが機能しない：入口、ポート、TUNの経路を確認する

システムプロキシですべてのアプリが通信するわけではない

システムプロキシはOSがアプリに提供するプロキシ設定ですが、使用するかどうかはアプリの実装によります。設定を読み込むブラウザーがある一方で、コマンドラインツール、ゲーム、独自のネットワークスタックを持つアプリは使わない場合があります。ブラウザーでは使えるのに特定のアプリで使えない場合は、そのアプリに個別のプロキシ設定があるか確認してください。システムプロキシのスイッチだけを見て、カーネルの異常だと判断しないでください。より広い範囲の通信を制御する必要がある場合に、TUNを検討します。

まず明示的なプロキシリクエストを実行してください。明示的なリクエストは成功するのにシステム設定を使うリクエストが失敗する場合は、ローカルのプロキシサービスと出口経路の一部は動作しており、システム設定またはアプリの通信経路に問題がある可能性が高くなります。明示的なリクエストも接続できない場合は、待ち受けポート、カーネルの起動、設定の読み込みを確認してください。特に異常終了後や複数のアプリが設定を奪い合った場合は、画面上のスイッチとOSの実際の設定が一時的に異なることがあります。

ポート番号と待ち受けアドレスを確認する

mixed-portはHTTPとSOCKSの両方の入口を提供します。portとsocks-portはそれぞれ別に設定します。外部コントローラーのポートはカーネル管理用であり、通常のリクエストを転送するプロキシポートではないため、取り違えないでください。設定を変更した後はカーネルが再読み込みされたことを確認します。古いプロセスが終了していないと元のポートを使い続け、画面の表示と実際の待ち受けが食い違うことがあります。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info

これはローカルで使う基本設定例です。既存の設定に統合してください。端末上だけで使う場合はループバックアドレスで待ち受け、LANに公開する必要はありません。allow-lanはほかの端末からのアクセスを許可する設定で、ローカルのシステムプロキシを修復するために必要なものではありません。ポートが使用中の場合は、OSのツールで該当するプロセスを調べ、ポートを変更するか競合するアプリを停止してください。正体の分からないシステムサービスをむやみに終了しないでください。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

プラットフォームの設定とコマンドライン環境を確認する

Windowsでは、ユーザーのプロキシ設定とWinHTTPのプロキシは別の入口です。一方の設定を読み込むプログラムは、もう一方の影響を受けないことがあります。macOSのプロキシ設定はネットワークサービスに紐づくため、Wi-Fiや有線LANに切り替えた後、新しいサービスを作成した後は、現在のサービスを確認してください。Linuxでは、デスクトップ環境のプロキシ設定と端末の環境変数が別々の場合があります。問題のアプリがどの設定を参照するか確認し、異なる設定を同じスイッチとして扱わないでください。

コマンドラインツールでは、明示的な引数または環境変数が必要なことがあります。以下の変数が影響するのは現在の端末と、そこから起動する子プロセスだけです。すべてのアプリの設定が変わるわけではありません。既に起動している端末やバックグラウンドサービスには古い値が残る場合があります。NO_PROXYの例外によって、対象がプロキシを迂回することもあります。ドメインの名前解決をリモート側で行うSOCKSアドレスにはsocks5hを使用できますが、対応状況はツールによって異なります。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

TUNの権限、ルート、除外設定を確認する

TUNは仮想ネットワークインターフェースを使って通信を制御するため、適切な権限とルート設定が必要です。クライアントはサービスモードやOSの認証を通じてこれらの処理を行う場合があります。画面のスイッチをオンにしただけで、ルートが正しく設定されたとは限りません。まずログで権限、ネットワークアダプター、ルートのエラーを確認し、実際のインターフェースも調べます。企業管理端末では仮想ネットワークアダプターが制限されることがあります。管理上の制限を無理に回避しないでください。

TUNを切り替える前にほかのVPNを終了し、システムプロキシの状態を保存してください。起動後は通常のアプリ、コマンドライン、LAN内の接続が正常か確認します。社内ネットワークが使えなくなった場合は、自動ルーティングと除外範囲を調べてください。プライベートアドレスの範囲全体を除外すればよいとは限りません。VPN経由でアクセスする必要があるリソースに影響する場合があります。現在のネットワーク構成に合わせて設定し、関係のないネットワーク範囲をそのままコピーしないでください。

異常終了後の復旧と動作確認

クライアントの終了後にネットワークへ接続できない場合、システムが停止済みのローカルポートを参照していることがよくあります。まずシステムのネットワーク設定で元のプロキシ状態に戻し、アプリが直接接続できることを確認してください。TUNの設定が残っている場合は、クライアントの正規の終了手順、ネットワークサービスの復旧、または端末の再起動で対処します。内容が分からないルートを手動で削除しないでください。自動起動を使う場合は起動順も確認します。ネットワークの準備ができる前にクライアントが起動すると、最初の接続に失敗することがあります。

常駐サービスが必要なLinux環境では、mihomoとsystemdのセットアップガイドを参照してください。修復後はクライアントを終了してから再起動し、待ち受けポート、プロキシ設定、ルートが正しく復元されるか確認します。最後にプロキシを停止した後もネットワークが正常であることを確認し、起動から停止まで一通り検証してください。

クライアントがクラッシュする：画面、カーネル、システムサービスを切り分ける

まず、どの部分が終了したか判断する

ウィンドウが消えてもカーネルが停止したとは限らず、トレイアイコンが残っていてもカーネルが正常とは限りません。クライアントのログとOSのプロセスを確認し、画面の異常終了、カーネルの停止、バックグラウンドサービスの起動失敗を切り分けます。画面の問題は操作や表示に影響し、カーネルの問題はプロキシの待ち受けに直接影響します。サービスの問題はTUNや特権機能だけに影響する場合があります。起動時、設定のインポート時、特定機能の有効化後のどこで発生したか記録してください。

通常の終了手順で残ったプロセスを終了し、もう一度起動してください。複数のインスタンスが設定ファイル、コントローラーのポート、プロキシポートを奪い合うと、後から起動したインスタンスがクラッシュしたように見えることがあります。バックグラウンドで動作中のクライアントがある場合、別のクライアントをインストールして同じ通信制御機能を同時に有効にしないでください。再テストの前に古いインスタンスが終了したことを確認し、プロセスの競合をソフトウェアの互換性の問題と取り違えないようにします。

設定変更が原因か、以前の設定と比較する

サブスクリプションの更新や設定の編集後にクラッシュした場合は、まず起動できた直前のコピーに戻します。古い設定は正常で新しい設定だけ失敗する場合は、構文、ルールセットの読み込み、プロトコルの互換性、ファイルのパスを確認してください。クライアントによっては画面に設定エラーを表示し、カーネルの起動を拒否する場合があります。必ずしも再インストールが必要な問題ではありません。エラー行と前後の構造を残し、ノードの認証情報を隠してから確認してください。

コマンドラインでmihomoを運用している場合は、テストモードで設定を確認できます。以下のコマンドだけでは、実際の起動確認の代わりにはなりません。プログラム名とパスはインストール先に合わせてください。Windowsではmihomo.exeを呼び出す必要がある場合があります。GUIクライアントに内蔵の検証機能がある場合は、そちらを優先してください。別のカーネルが同じ設定ディレクトリを読み込み、競合するのを避けられます。

mihomo -t -f ./config.yaml

ルールだけの設定は読み込めるのに、特定のルールセットを追加すると失敗する場合は、ルールセットのパス、形式、ダウンロード結果を確認します。相対パスは通常、設定ディレクトリを基準に解釈されます。作業ディレクトリが常に同じとは限りません。追加内容を一度にすべて戻すのではなく、少しずつ追加して原因となる項目を特定してください。設定をすべて削除してから、サブスクリプションURLやローカルの上書き設定にバックアップがないと気付くことのないようにしましょう。

アーキテクチャ、OSの対応状況、権限を確認する

ダウンロード時はOSのプラットフォームとプロセッサーアーキテクチャを区別してください。Apple Silicon、Intel、ARMの端末では、異なるパッケージが必要な場合があります。起動エラーの原因は、アーキテクチャの不一致、システムコンポーネントの不足、非対応のOSバージョンかもしれません。ダウンロードセンターで、対象パッケージと動作要件を確認し、ファイル名が似ているだけで別のものに置き換えないでください。新しく導入する場合はまずClash Plusを検討し、その後、プラットフォームの要件に応じてほかのクライアントを選びます。

設定ディレクトリへの書き込み権限がない、ディスク容量が不足している、ログディレクトリの権限に問題がある場合も、起動に失敗することがあります。現在のユーザーがクライアント専用のデータディレクトリを読み書きできるか確認してください。システム全体のディレクトリをすべてのユーザーに書き込み可能にしないでください。Linuxではサービスの実行ユーザーとログインユーザーが異なる場合があります。端末から読める設定でもsystemdサービスから読めるとは限らないため、実際のサービス実行ユーザーに合わせて権限を確認します。

セキュリティソフトやリソースの問題は、根拠を確認して対処する

セキュリティソフトが仮想ネットワークアダプター、バックグラウンドサービス、プログラムの起動を妨げることがあります。隔離記録やシステム通知を確認し、ブロックされたファイルと操作を特定してください。セキュリティ保護全体を長期間無効にしないでください。企業管理端末の場合は、管理者にログを添えて確認を依頼します。TUNを有効にした後だけ終了する場合は、ネットワークアダプターと特権サービスを重点的に調べます。ウィンドウを開いた直後に失敗する場合は、グラフィック関連のコンポーネントとユーザーデータを優先して確認してください。

メモリやCPUの使用率が高いままの場合は、詳細すぎるログ、大きすぎるルールセット、接続ループがないか調べます。リソース使用量の増加は症状にすぎません。接続数、ログの内容、操作したタイミングと関連付けてください。まず通常のログレベルに戻し、通信を重複して制御するアプリを終了して改善するか確認します。メモリの少ない端末では、キャッシュを増やすより不要な設定を減らすほうが適切な場合があります。

範囲を絞ってリセットし、必要なデータだけ移行する

リセット前にバックアップを取り、破損が疑われるユーザー状態やキャッシュだけを移動して、クライアントに再作成させます。まず画面にリセット機能があるか確認し、削除される内容を読んでから実行してください。リモートサブスクリプション、ローカルルール、プロキシグループの選択、システムサービスの設定は、それぞれ異なるデータです。別のクライアントへ移行する際も、画面上の設定がYAMLだけですべて引き継がれるとは限りません。

Clash for WindowsとClashX Metaはサポートが終了したクライアントです。新しいOSとの互換性に問題が起きた場合は、現在も保守されている選択肢への移行を検討してください。移行前に設定とカスタム項目をエクスポートし、ダウンロードページのプラットフォーム別の案内に沿って選びます。まず基本的なプロキシ接続を確認してから、TUNや起動時の設定を戻してください。旧クライアントと新しいクライアントを同時に起動し、どちらも起動時にネットワークを制御する設定にしないでください。

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

VPNの許可と設定の読み込みから確認する

モバイル端末では通常、システムのVPNインターフェースを使って通信を制御します。初回接続時にはシステムの許可が必要です。サブスクリプションのインポートに成功しても、VPNの許可が完了したとは限りません。設定が選択され、プロキシグループに利用可能なメンバーがあることを確認してから接続を有効にし、システムにVPN状態が表示され、クライアントに接続記録が残るか確認します。許可が拒否された場合や端末管理による制限がある場合は、同じサブスクリプションを再度インポートするのではなく、まずシステム側の問題を解決してください。

同じ端末にあるほかのVPN、仕事用プロファイル、セキュリティフィルター、一部の広告ブロックツールが通信制御を奪い合う場合があります。テスト中はネットワークを制御するアプリを1つに絞り、ほかの同種サービスを終了して確認してください。ブラウザー拡張機能によるフィルターはVPNと競合しない場合もあるため、実際の仕組みに応じて判断します。組織管理の端末では管理ポリシーに従い、管理プロファイルを削除して無理にプロキシを起動しないでください。

Androidのバックグラウンド動作と省電力制限

Androidで画面ロック後に接続が切れ、アプリに戻ると復旧する場合は、バックグラウンド制限が関係していることがあります。クライアントの通知が継続して表示されているか、システムがバックグラウンド動作を制限していないか確認してください。端末のバッテリー設定で、必要なバックグラウンド動作を許可します。メーカーごとに設定画面が異なるため、別メーカーの手順をそのまま使わないでください。変更後は画面をロックして待ち、解除後にアクセスしてログを確認します。画面を開いた状態のスイッチだけで判断しないでください。

「VPNを常時接続」と「VPNなしの接続をブロック」は、切断後の動作を変えます。VPNなしの接続をブロックしている場合、クライアントの停止後に端末全体がオフラインになるのは、システムポリシーどおりの動作かもしれません。調査時はまずこの設定を確認し、比較のため一時的にオフにするか判断します。調査が終わったら、必要な保護設定に戻してください。システムが通信を遮断している状態を、DNSやすべてのノードの故障と誤認しないようにしましょう。

Androidクライアントには、アプリごとのプロキシ設定や除外リストがある場合もあります。特定のアプリだけログに表示されない場合は、特に仕事用プロファイル内にある同名アプリが除外されていないか確認してください。除外設定が有効なアプリの通信は、プロキシグループの設定だけでは説明できません。Clash Plus、Clash Meta for Android、FlClash、Surfboardでは画面や設定の対応状況が異なります。移行時は機能を1つずつ確認し、設定をすべてそのままコピーしないでください。

iOSの接続とクライアントの選び方

iOSでClash Plusを使う場合は、まずシステムの案内に従ってVPN構成を追加し、有効なサブスクリプションを読み込んでポリシーを選択します。システムにVPNの状態が表示されても、通信経路が作られたことを示すだけです。実際のリクエストで出口を確認してください。設定を変更した後も古いリクエストが失敗する場合は、テスト用アプリを終了して再度開き、接続の再利用による影響を避けます。仕事用端末で制限がある場合は、個人用VPNを追加できるか先に確認してください。

クライアントの選び方とインストール方法はiOSダウンロードガイドを参照してください。Clash Plusの公式サイトはclashplus.ioです。アプリ内で問題が起きた場合は、インポートエラーと接続エラーを分けて記録し、同じ問題として扱わないでください。アカウント、サブスクリプションサービス、クライアントはそれぞれ別の要素です。アプリをインストールしても、利用可能なノードが自動的に提供されるわけではありません。

Wi-Fi、モバイル通信、テザリングを分けて確認する

Wi-Fiでは正常なのにモバイル通信で失敗する場合は、クライアントのモバイルデータ通信の許可、システムのデータ制限、サービス提供元による接続元ネットワークの制限を確認します。Wi-Fiだけで失敗する場合は、認証ページ、ルーターのDNS、ネットワークのプロトコル制限、管理ポリシーを調べてください。同じノードと対象を使い、2つのネットワークで結果をそれぞれ記録すると、原因を絞り込みやすくなります。ネットワークを切り替えると同時に設定まで変更しないでください。

Wi-Fiとモバイル通信を切り替えると、ローカルアドレス、IPv6の状態、NATマッピングが変わり、既存の接続を継続できない場合があります。切り替え後はシステムのネットワークが安定するまで待ち、新しいリクエストを開始してください。復旧しない場合は、クライアントの接続を一度オフにしてから再度有効にし、出口が再確立されたか確認します。切り替えの瞬間だけ失敗した場合と、切り替え後も失敗し続ける場合は異なる症状です。分けて記録してください。

スマートフォンでテザリングを有効にしても、接続先の端末が自動的にスマートフォンのVPNを通るとは限りません。通信を転送するかどうかはOSと実装によって異なるため、スマートフォンでウェブサイトが開けることだけでは、PCがプロキシ経由だと確認できません。接続先の端末でも出口を個別に確認してください。プロキシを共有する必要がある場合は、クライアントが対応するLAN側の入口とネットワーク分離設定を確認し、アクセス範囲を制限します。公衆Wi-Fiでプロキシポートを公開しないでください。

LANの確認と修復後の検証

画面共有、プリンター、LAN管理、ゲーム内のデバイス検出は、直接接続、ブロードキャスト、ローカル名前解決に依存する場合があります。プロキシを有効にした後で機能しなくなった場合は、LANの除外、ルート、Fake-IPの例外を確認してください。画面共有を復旧するために、すべての通信を直接接続に切り替えないでください。まず対象のアプリとアドレスを特定し、必要な例外だけを追加します。LAN内のデバイス検出とインターネット上のサイトへのアクセスは、別々に確認してください。

最後に4項目を確認します。アプリを前面に表示した状態でのアクセス、画面ロック後の復旧、Wi-Fiとモバイル通信の切り替え、クライアント停止後のネットワーク動作です。カスタムルールがサブスクリプション更新で上書きされないことを確認し、使える設定を1つ保存してください。よくある用語や質問はヘルプセンターを参照してください。初回インストールや移行の場合はクイックスタートガイドに戻り、基本の接続を確認してから、バックグラウンド動作、アプリごとの設定、LANの設定を戻します。