Clashのトラブルシューティング完全ガイド

インターネットに接続できない：ローカルの入口からリモートの出口まで

まず、問題が起きている範囲を確認する

クライアントの画面が開き、プロキシが有効になっていても、通信が成功したとは限りません。発生時刻、ネットワークの種類、現在の設定、失敗したアプリを記録し、通常は直接接続できるサイトと、実際に開けないサイトの両方へアクセスします。プロキシを無効にして同じテストを行い、どちらのサイトも開けない場合は、Wi-Fi接続、ゲートウェイ、ネットワーク認証を先に確認してください。プロキシを有効にした場合だけ失敗するなら、ローカルの待ち受け、ルール、リモートの出口を調べます。

ほかのプロキシクライアント、ブラウザーのプロキシ拡張機能、ネットワーク設定を変更する可能性のあるツールを一時的に終了し、複数のプログラムがシステム設定を上書きするのを防ぎます。設定をすぐに削除したり、システムプロキシとTUNを同時に有効にしたりしないでください。まず現在のログを保存し、通信を引き継ぐ方法を一つだけ使って問題を再現します。会社や学校の管理端末では管理ポリシーに従い、競合の切り分けを目的にセキュリティ機能を削除しないでください。

プロキシを明示してシステム設定を切り分ける

クライアントの設定画面で混合ポートを確認し、コアが起動していることを確かめます。以下のコマンドに記載したポート番号は例です。実際に待ち受けている値に置き換えてください。プロキシを明示すると、ブラウザーがシステムプロキシ設定に従っているかどうかを一時的に切り分けられます。Windowsでは、ターミナル内の同名コマンドのエイリアスを避けるためにcurl.exeを使います。それ以外のプラットフォームでは通常、curlをそのまま使えます。

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 25 \
  -I https://example.com/

ローカルポートへの接続がすぐに拒否される場合、リクエストはまだプロキシコアに届いていません。まずコアの状態とポートを確認します。リモートからの応答待ちでタイムアウトする場合は、ログに記録された接続先、適用されたルール、出口を調べます。HTTPレスポンスが返ってきてもステータスが成功でなければ、通信経路の一部は確立しています。サーバーによる拒否、ログイン要求、コンテンツへのアクセス制限を、単純にローカルプロキシの障害と判断しないでください。上記のコマンドはレスポンスヘッダーだけを確認します。このリクエスト方式に対応していないサイトでは、通常のGETリクエストでもう一度試してください。

ルールの適用先と出口の状態を切り分ける

接続画面またはログ画面を開き、失敗したリクエストを一度再現します。対象のドメインに適用されたルール、入ったプロキシグループ、そのグループで選択されている出口を確認してください。ルールモードでは、対象が直接接続に回る場合も、拒否ルールに該当する場合もあります。全般モードへの一時的な切り替えは比較のためだけに使います。全般モードでは接続でき、ルールモードでは失敗する場合は、ルールの順序とプロキシグループの選択を確認します。両方で失敗する場合は出口への接続を調べ、ルール一覧を何度も変更する必要はありません。

一つのWebページが、ログイン用ドメイン、静的リソース、APIのドメインを使っている場合があります。トップページは表示されるのにログインボタンが読み込み中のままなら、トップページにルールを追加するのではなく、失敗した子リクエストを調べます。ブラウザーの開発者ツールにあるネットワークパネルで失敗したドメインを探し、クライアントの接続ログと照合してください。スクリーンショットを共有する前に、完全なURLに含まれるクエリパラメーター、アカウント情報、サブスクリプション情報を隠します。エラー名と適用されたルールが分かれば十分です。

最後に同じ接続先を使って復旧を確認します。プロキシを明示したリクエスト、ブラウザー、プロキシが必要なほかのアプリがそれぞれ成功するか確認してください。ルールモードに戻し、一時的なデバッグログを無効にして、テスト状態を常用設定として残さないようにします。ブラウザーだけが失敗し、コマンドは成功する場合はシステムプロキシの章へ、ログに名前解決エラーがある場合はDNSの章へ進んでください。手順を絞って確認するには、接続済みなのにWebページが開けないときのチェックリストもご覧ください。

ノードのタイムアウト：名前解決、ハンドシェイク、通信を分けて確認

エラーが発生した段階を見極める

画面に表示されるタイムアウトは、接続確認用URLに対するものか、実際の通信リクエストに対するものかで意味が異なります。接続確認に失敗しても、出口が完全に使えないとは限りません。確認先がアクセスを制限していたり、確認リクエストにルールが適用されたりする場合があります。まず出口を一つ選び、同じ接続先に対して少数回のリクエストを繰り返してから、該当時刻のログを確認します。サーバーのドメイン名解決、サーバーへの接続タイムアウト、プロトコルのハンドシェイク、接続先サイトの応答遅延を区別してください。

接続拒否は、接続先から拒否されたか、途中の機器が接続を拒否したことを示す場合が多くあります。接続タイムアウトが示すのは、待ち時間内に期待した応答がなかったことだけで、サーバーが停止したとは限りません。認証失敗や証明書の名前不一致は別の種類の手がかりです。タイムアウト時間を延ばして隠そうとしないでください。赤いタイムアウト表示だけのスクリーンショットより、エラーの原文を記録するほうが原因の特定に役立ちます。

システム時刻とサーバーの接続先を確認する

システムの自動時刻設定を有効にし、日付、タイムゾーン、実際の時刻が正しいことを確認します。証明書を使う接続では有効期間が検証されるため、システム時刻が間違っていると、正常に使える設定でもハンドシェイクに失敗し続けることがあります。次に、サブスクリプションの更新後もサーバーのアドレス、ポート、通信パラメーターがローカル設定で上書きされていないか確認します。ノードの設定をコピーする際にパス、サービス名、トランスポート設定が抜けると、下位の接続は確立してもプロキシプロトコルのハンドシェイクが完了しないことがあります。

サーバーのポートを個別にテストする場合は、PowerShellで次のコマンドを使えます。例のドメインは構文の説明用です。設定に記載されたサーバーアドレスに置き換えてください。テストに成功しても、TCPポートに接続できたことしか分かりません。認証、TLS、上位のプロキシプロトコルが正常とは限りません。また、失敗してもUDPだけを使うサービスの状態は判断できません。テストのためにノード設定全体を公開しないでください。

Test-NetConnection -ComputerName example.com -Port 443

証明書の検証を無効にする方法は、通常の対処としておすすめできません。証明書エラーが発生した場合は、サーバー名、システムの信頼チェーン、システム時刻、ネットワークに管理下の検査機器が存在するかを確認します。特定のSNIや通信経路が必要な設定では、推測で変更せず、サービス提供元に設定値を確認してください。期限切れのサブスクリプションに古い接続先が残っている場合は、更新で解決することがあります。更新前にローカルの上書き設定をバックアップしてください。

ネットワークを比較してローカルの制限を見分ける

同じ端末、同じ設定、同じ接続先を使い、現在のWi-Fiからスマートフォンのテザリングに切り替えて比較します。テザリングでは接続でき、元のネットワークでは接続できない場合、問題の範囲を元のネットワーク経路、認証状態、アクセス制御に絞れます。同じネットワークに接続した別の端末でも比較してください。クライアントと出口を同時に変更すると検証する条件が増え、復旧しても原因が分からなくなります。

ネットワークによっては、特定の接続方式しか許可されず、特にUDPが制限されることがあります。TCPを使うWebページは正常でも、UDPに依存するアプリが失敗する場合は、出口のプロトコル、コア、リモートサービスが対象の通信に対応しているか確認します。TUNはアプリのパケットを引き継げますが、UDP非対応の出口を自動的に対応させるものではありません。IPv6を使う場合は、実際に接続しているアドレスファミリーも比較し、一つの到達不能な経路をすべての入口の障害と誤認しないようにします。

一つの接続先だけが失敗し、同じ条件でほかの接続先は使える場合は、発生時刻、エラーの種類、ネットワークの比較結果を記録してサービス提供元に伝えてください。直結は正常なのにすべての接続先が失敗する場合は、クライアントのコア、DNS、ローカルファイアウォールを確認します。短い間隔で繰り返し接続確認を行わず、適切な頻度に戻してください。並行して何度も検査するとログが読みづらくなるだけでなく、リモート側の制限が発動し、症状が複雑になることがあります。

サブスクリプションの更新失敗：リンク、応答内容、設定のマージを確認

ダウンロード失敗と解析失敗を区別する

サブスクリプションの更新には、URLへのリクエスト、コンテンツの取得、設定の解析、設定の適用という複数の段階があります。ダウンロードのタイムアウトは通常、前半の段階で起こります。解析エラーの場合はコンテンツを取得できていても、クライアントが対応していない形式で返されている可能性があります。ネットワークリクエスト、HTTPステータス、YAML構文、コアによる設定検証のどこで失敗したかを記録し、すべてをリンク切れと決めつけないでください。更新前に現在使える設定をエクスポートし、最後の有効なコピーが上書きされないようにします。

サービス提供元のアカウントページからサブスクリプションURLをコピーし直します。クリップボードに改行や前後の空白、チャットアプリが付けた句読点が混入していないか確認してください。URLにはアクセス認証情報が含まれることが多いため、公開の変換サイト、オンラインYAMLチェッカー、公開サポートフォームには貼り付けないでください。ブラウザーでURLを開けても、クライアントが同じプロキシ、リクエストヘッダー、ネットワーク経路を使ったとは限らず、応答が対応形式であるとも限りません。

応答の実際の形式を確認する

クライアントにダウンロードエラーの詳細表示があれば、まずステータスコードと応答の種類を確認します。Webページ、ログイン画面、アクセス認証画面が返されると、コアがHTMLの先頭行をYAMLとして読み込み、構文エラーのようなメッセージを表示することがあります。ステータスが成功でも、内容が正しいとは限りません。サーバーが説明文を成功ステータスで返す場合もあります。ローカルでファイルの先頭部分だけを確認し、設定データ、ノード情報、Webページのどれかを見分けてください。認証情報を含むファイル全体を、相談のためにアップロードしないでください。

クライアントによって、対応するサブスクリプション形式は異なります。別のプロトコルやアプリ向けのデータは、ファイルの拡張子を変えただけではClashの設定として使えません。サービス提供元でClashまたはmihomo対応の形式を選び、再度インポートしてください。設定がプロキシプロバイダーやルールプロバイダーを参照している場合は、メイン設定のインポート後に外部リソースもダウンロードできるか確認します。メインファイルの取得に成功しても、依存するリソースが準備できているとは限りません。

YAMLと上書き設定のエラーを特定する

手動編集後に解析エラーが発生した場合は、インデントにスペースを使っているか、同じ階層のキーが揃っているか、リスト項目の前にハイフンがあるかを確認します。特殊文字を含む文字列には適切な引用符が必要ですが、すべての数値や真偽値を無条件に引用符で囲まないでください。以下は構文確認用の有効な部分構造で、接続に使える完全な設定ではありません。実際のプロキシグループと出口はサブスクリプションから提供されます。

mixed-port: 7897
mode: rule
log-level: info
allow-lan: false

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

クライアントは、サブスクリプションの元データ、全体上書き、スクリプト処理、画面上の設定を統合してからコアに渡すことがあります。元ファイルの構文が正しくても、最終設定で存在しないプロキシグループを参照していれば適用に失敗します。最近追加した上書き設定やスクリプトを一時的に無効にし、元のサブスクリプションを適用します。復旧した場合は一つずつ有効に戻し、競合する設定を特定してください。自動更新される元ファイルを直接編集して恒久対応しないでください。次回の更新で手動変更が上書きされる可能性があります。

自動更新に失敗した場合は、アプリがバックグラウンドで動作しているか、端末がスリープしていないか、更新間隔の単位が正しいかも確認します。クライアントによって、間隔の設定単位は分、時間、内部処理用の秒など異なります。他の場所で見た数値をそのまま使わないでください。無効なリンクへ極端に短い間隔で繰り返しリクエストしないでください。まず手動更新に成功したことを確認してから、自動更新のスケジュールを戻します。設定場所とエラー別の対処はサブスクリプション自動更新の間隔についてをご覧ください。

復旧の確認では、更新時刻だけでなく、対象の設定が選択されているか、コアに正しく適用されたか、参照先のプロキシグループが存在するかも確認します。サーバーから不正な内容が繰り返し返される場合は、個人情報を隠したステータスコード、エラー行番号、リクエスト時刻をサービス提供元に伝えてください。形式の確認方法はサブスクリプションの解析失敗を自分で確認する手順をご覧ください。サブスクリプションの基本はヘルプセンターで確認できます。

通信速度が遅い：接続開始の待ち時間と転送速度を分けて確認

どの段階で遅くなるのかを把握する

Webページが長時間真っ白になってから一度に表示される場合と、ダウンロード開始は速いのに途中から遅くなる場合は、原因が異なります。前者は名前解決、接続の再試行、ハンドシェイク、重要なリソースの読み込み待ちが考えられます。後者は出口の帯域、ネットワークのパケットロス、接続先の速度制限、ローカルWi-Fiの品質が関係する可能性があります。すべてのサイト、特定のサイト、特定のアプリのどれが遅いのかを先に確認し、同じ接続先、同じファイル、同じネットワークで比較してください。サーバーごとの違いをクライアントの性能差と誤認しないためです。

ブラウザーの開発者ツールにあるネットワークタイムラインを使うと、接続待ち、最初の応答待ち、コンテンツのダウンロードを区別できます。統計用スクリプトやフォントの読み込みが止まっているだけでも、ページ全体の完了が遅れることがあります。クライアントのログでは出口やルールを確認できますが、ページが読み込むリソースの調査には代わりません。実際に時間がかかっているリクエストを特定し、直接接続かプロキシ経由かを調べるほうが、設定全体を何度も切り替えるより効果的です。

入口と接続先を固定して比較する

システムアップデート、クラウドストレージの同期、その他の帯域を使うタスクを一時停止し、ダウンロードを一つだけ実行して確認します。Wi-Fiが不安定な場合は、アクセスポイントの近くへ移動するか、有線接続で比較してください。複数の速度測定ツールを同時に実行せず、一度の測定結果だけで出口の順位を決めないでください。接続確認サイトの応答時間が示すのは、そのときの検査経路だけです。大容量ファイルの転送速度や、実際に使うサイトでの体感速度とは異なります。

プロキシを明示したリクエストの所要時間を確認するには、curlで処理段階ごとの時間を出力できます。以下のコマンドは通常のページ出力を残し、最後に所要時間を表示します。実際に試すときは、接続先を固定してください。HTTPプロキシ経由でHTTPSサイトへ接続すると、時間にはプロキシとのネゴシエーションが含まれる場合があります。特定の項目をリモートサーバー単独の所要時間とみなさないでください。同じ条件で複数回テストし、数値を絶対的な評価に使わず変化を確認します。

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 30 \
  --write-out '\nconnect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

直接接続でも遅い場合は、まずローカルネットワークと接続先サイトを確認します。特定の出口だけが遅い場合は、同じ設定内にある別の利用可能な出口と比較してください。すべての出口で特定のサイトだけ遅く、ほかのサイトは正常なら、接続先の負荷、地域間の経路、アプリ独自の制限が関係している可能性があります。この場合、クライアントの再インストールには根拠がありません。再確認できるよう、接続先、時刻、選択した出口を記録し、「速度が遅い」とだけ残さないようにします。

ルールによる遠回りと通信方式の違いを確認する

本来は直接接続できるリソースをルールがリモートへ送ると、接続距離が伸びることがあります。プロキシが必要なAPIを直接接続に回すと、長時間の再試行が発生する可能性があります。特にログイン状態を維持する必要があるサービスでは、トップページとAPIのドメインが異なる出口に分かれていないか確認します。明らかな誤りがあるドメインのルールだけを修正し、よく分からない大量のアドレスを全体のバイパスリストに追加しないでください。修正後は再接続します。既存の接続には以前の出口が使われ続ける場合があります。

ブラウザーはUDPを使うHTTP/3を優先し、接続できない場合にほかの方式へ切り替えることがあります。出口やネットワークがその経路に対応していない場合、切り替えを待つ間、初回の表示が断続的に遅くなる可能性があります。クライアント、出口のプロトコル、ネットワークの対応状況を確認してから、条件を記録したうえでブラウザーを比較してください。プロトコルを無効にするのは原因の切り分けに限り、説明なしにすべての端末共通の最適化として適用しないでください。

TUN環境で小さなページは開けるのに大きなリクエストが止まる場合に限り、経路MTUや関連するネットワーク機器の動作を調べます。ネット上で見つけたMTUの値をそのまま設定したり、DNS、プロトコルスタック、MTUを同時に変更したりしないでください。まず元の値を記録し、システムプロキシで比較します。TUNでのみ再現する場合は、ログとネットワーク環境を確認しながら一項目ずつ調整してください。プロキシ転送で元のネットワークのパケットロスがなくなるわけではなく、仮想ネットワークアダプターが回線の帯域を自動的に増やすこともありません。

復旧後は、実際に使う通信で確認します。同じWebページを開き、同じサービスにログインし、同じリソースをダウンロードしてください。一時的なテスト条件を解除して普段のルールに戻し、効果を確認でき、理由も説明できる設定だけを残します。特定の時間帯だけ発生する問題では、クライアント設定を繰り返し変えるより時間帯を記録するほうが役立ちます。特定のアプリだけに起きる場合は、そのアプリのキャッシュ、拡張機能、個別のプロキシ設定を確認します。

DNSの問題：システム、アプリ、コアの名前解決経路を整理する

まず、どこでドメイン名を解決しているか確認する

DNSの問題は、ドメインを開けない、初回アクセスに時間がかかる、アプリによって同じサイトの表示結果が異なる、といった症状で現れます。システムDNS、ブラウザーのセキュアDNS、アプリ内蔵の名前解決、mihomo DNSが同時に使われている場合があります。失敗したドメイン、エラーの種類、使用中の通信方式を記録してください。IPアドレスを直接指定してアクセスできても、それだけでは手がかりにとどまります。HTTPSのテストにはドメイン名も必要です。証明書、ホスト名、サーバーのバーチャルホストがドメイン名に依存する場合があります。

システムのツールで名前解決に成功しても、クライアントのDNS経路が正常とは限りません。プロキシを明示したHTTPリクエストでは通常、接続先のドメイン名をプロキシ側に解決させられます。SOCKSリクエストでローカル解決が行われるかどうかは、呼び出し方法によって異なります。ブラウザーが独自のセキュアDNSを使っている場合、システムの名前解決結果が迂回されることもあります。切り分けでは一つの経路だけをテストし、使用したツールを記録して、異なるDNSの結果を混同しないようにしてください。

主要なDNSパラメーターの役割を理解する

nameserverは通常の上流DNSを指定します。default-nameserverは、ドメイン名で指定された上流DNS自体を解決するために使われ、名前解決の初期経路がない状態を防ぎます。proxy-server-nameserverはプロキシサーバーのドメイン名解決に使われ、Webサイトの名前解決とは別の問題です。fallbackとそのフィルター条件は、候補となる応答の選択に関わります。すべてのリクエストがタイムアウトした後に順番に呼び出す予備リストではありません。

以下の設定例はfake-ipモードで確認するための最小構成で、TUNやルールの設定全体は含みません。上流DNSのアドレスはパラメーターの説明用です。ネットワークから到達できるアドレスを選んでください。待ち受けアドレスはローカルに限定し、LANへ不要なDNSサービスを公開しないようにします。クライアントの画面や上書きファイルでDNSを管理している場合は、同じ設定場所を使い、複数の設定が互いに上書きしないようにしてください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

fake-ipが返すのはコアが対応付けを管理する仮想アドレスであり、Webサイトの実際のサーバーアドレスではありません。テスト用ネットワークのアドレスが表示されても、それだけで名前解決が壊れているとは限りません。確認すべきなのは、その後の接続も対応付けを管理するコアを経由しているかどうかです。アプリが仮想アドレスを取得した後にTUNを迂回して直接接続した場合や、コアの再起動後もアプリが古いキャッシュを使っている場合は、名前解決は成功しているように見えても接続に失敗することがあります。

キャッシュと通信の引き継ぎ順を確認して復旧する

まず設定を適用してコアが起動したことを確認し、問題に関係するシステムやアプリのキャッシュを消去してから、リクエストをやり直します。Windowsでは次のコマンドでシステムのDNSキャッシュを消去できます。ただし、ブラウザー独自のキャッシュや接続プールをリセットするには、ブラウザーの再起動が必要な場合があります。ほかのシステムでは対応する方法を使い、Windowsのコマンドを共通手順として扱わないでください。キャッシュを何度も消去しても、上流DNSや通信経路の設定ミスは解決しません。

ipconfig /flushdns

TUNのDNSハイジャックは通常、指定したDNS通信を対象とします。アプリ内蔵の暗号化DNSまですべて一律に引き継ぐとは限りません。コアのDNS待ち受けが標準以外のポートにあっても、システムが自動的にそのポートへ問い合わせるわけではありません。対応するシステム設定やTUNの転送設定が別途必要です。ログにDNSリクエストが記録されない場合は、上流DNSを変える前にリクエストがコアに届いているかを確認してください。使われていない設定を変更しても効果はありません。

LAN内の端末名、社内ドメイン、マルチキャスト名は個別に検討する必要があります。一般向けのDNSサーバーは内部名を解決できないため、すべてのリクエストを公開DNSへ強制的に送ると、プリンターや社内サービスに接続できなくなることがあります。実際のドメインとネットワーク要件に合わせて名前解決ポリシーやfake-ipフィルターを設定し、既存の内部DNS経路を残してください。特定ドメインをフィルターしても、その名前をシステムが解決できるとは限りません。

復旧確認では、一般的なWebサイト、以前失敗したドメイン、必要な社内サービスをそれぞれテストし、プロキシサーバーのドメインも安定して解決できるか確認します。特定のDNS設定を無効にしたときだけ復旧する場合は、その設定がどの経路に作用しているか記録してから、残すかどうか判断してください。パラメーターの組み合わせとDNSハイジャックの詳しい説明はmihomo DNS設定ガイドをご覧ください。エラーログを一つ消すためだけにDNS設定全体を置き換えないでください。

システムプロキシが機能しない：ポート、アプリ、通信方式を確認

まずローカルの待ち受けを確認し、次にシステム側の入口を確認する

システムプロキシのスイッチはシステム設定を書き換えるもので、すべてのプログラムが従うわけではありません。まずプロキシを明示したリクエストでコアのポートが使えるか確認し、次にシステムのプロキシホストがローカルのループバックアドレスになっているか、ポートがクライアントと一致しているかを調べます。混合ポートを変更した後も、システム設定、ブラウザー拡張機能、ターミナルの環境変数に古い値が残る場合があります。クライアントの設定画面に新しい数字が表示されているだけで判断せず、これらの入口をすべて確認してください。

ポートが競合すると、コアの起動に失敗する場合や、別のプロセスが使用予定のポートを占有している場合があります。WindowsのPowerShellでは待ち受けプロセスを確認できます。macOSやLinuxではlsofを使用できます。例にあるポート番号は実際の値に置き換えてください。プロセスを特定したら、まずどのアプリに属するか確認します。正体の分からないシステムプロセスを終了しないでください。競合するアプリを閉じるか空いているポートに変更し、設定を再適用します。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS / Linux
lsof -nP -iTCP:7897 -sTCP:LISTEN

ブラウザー、ターミナル、システムサービスを区別する

ブラウザーのプロキシ拡張機能がシステム設定を上書きすることがあり、アプリ独自のプロキシ設定を備えたものもあります。ターミナルのツールは通常、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYなどを参照しますが、対応状況はツールによって異なります。環境変数は通常、プロセスの起動時に引き継がれるため、変更後も起動中のターミナルやエディターに反映されない場合があります。ブラウザーが正常だからといって、バックグラウンドのサービスも同じプロキシを使っていると判断しないでください。

Windowsのユーザープロキシ設定と、一部のシステムサービスが使用するWinHTTPの設定は異なります。特定のサービスを調べる場合は、まずnetsh winhttp show proxyでその環境を確認できます。ただし、WinHTTP設定のインポートやリセットを、通常のブラウザー向けの定番修復手順にしないでください。macOSでは未接続のインターフェースを変更せず、現在使用中のネットワークサービスを確認します。Linuxデスクトップでは、プロキシが有効になるかどうかはデスクトップ環境とアプリの実装にも左右されます。

TUNモードでは権限とルートを個別に確認する

システムプロキシに従わないアプリにはTUNを検討できますが、有効にする前にクライアントのサービスコンポーネントや必要な権限が整っているか確認してください。TUNスイッチがオンでも、仮想ネットワークアダプターとルートが正常に作成されたとは限りません。デバイス作成の失敗、権限不足、ルートの競合がログにないか確認します。プロトコルスタックの選択肢は互換性に影響するため、クライアントが対応する項目を一つずつ試してください。プロトコルスタック、DNS、出口を同時に変更しないでください。

ほかのVPN、仮想マシンのネットワーク、コンテナネットワーク、セキュリティソフトはTUNのルートと競合することがあります。不要なネットワークツールを終了してから、システムプロキシとTUNの動作を比較してください。コアからリモートサーバーに接続できる必要があります。ルートを誤ると、その接続自体が再びプロキシへ送られ、ループが発生することがあります。クライアントの自動ルートやインターフェース検出機能を使う場合も、現在有効なネットワークインターフェースを認識しているか確認してください。

LANで共有するには、LAN接続を許可し、待ち受けアドレスとファイアウォールの範囲を正しく設定する必要があります。ほかの端末で127.0.0.1を指定すると、その端末自身を指すため、このPC上のプロキシには接続できません。共有するためにファイアウォール全体を無効にしたり、ローカルプロキシのポートをインターネットに公開したりしないでください。信頼できるLANからのみアクセスを許可し、共有ネットワークが変わった後も既存のアクセスルールが適切か確認します。

クライアントを終了した後にインターネットへ接続できない場合は、待ち受けが停止したローカルポートをシステムプロキシが引き続き指していないか確認します。残った設定を手動で無効にし、ほかのアプリがプロキシや自動設定スクリプトを書き込んでいないか調べてください。接続が復旧したら、クライアントを一つだけ再起動して動作を確認します。複数の自動起動項目が互いに設定を上書きしないようにするためです。システムプロキシとTUNの基本的な違いはヘルプセンターで、初回起動時の手順はクイックスタートガイドで確認できます。

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

まず、どの部分が終了したかを見極める

ウィンドウが閉じた、タスクトレイには残っている、コアが停止した、プロセス全体が終了した、という状態はそれぞれ異なります。まずタスクトレイのアイコンとシステムのプロセス一覧を確認し、ログへの書き込みが続いているか調べます。閉じるボタンを押した後にウィンドウがタスクトレイへ隠れるのは、多くの場合は設定どおりの動作で、クラッシュではありません。画面は使えるのにコアが繰り返し再起動する場合は、画面の問題と決めつけず、設定の適用エラー、リソースのパス、権限を優先して確認してください。

クラッシュ直前に行った操作を記録します。サブスクリプションのインポート、アプリの更新、TUNへの切り替え、スリープからの復帰、システムへのログインなどです。アプリログの末尾と、同じ時刻のシステムエラー記録を保存します。設定ディレクトリ全体を提出する必要はありません。ログにはサーバーアドレス、アクセスしたドメイン、設定ファイルのパスが含まれる場合があるため、先に個人情報を隠してください。再現できる操作がある場合は、大量のスクリーンショットよりも明確な再現手順が役立ちます。

バックアップ後、最小構成で起動する

クライアントを終了し、関連プロセスが停止したことを確認してから、設定ディレクトリを別の場所へコピーします。バックアップにはサブスクリプション、上書きファイル、必要なユーザー設定を含めますが、公開クラウドストレージへアップロードしないでください。次に、クライアントが対応している独立した設定ディレクトリやリセット方法でテスト環境を起動します。データディレクトリの場所が分からない場合は、設定画面にある設定ディレクトリを開く項目を確認してください。ユーザーディレクトリ内の正体が分からないファイルを削除して修復を試みないでください。

最小構成で起動できたら、まず有効と確認できている設定をインポートし、上書き設定、スクリプト、画面設定を一項目ずつ戻します。いずれかを戻した後に問題が再発すれば、原因の範囲を絞り込めています。設定エラーはエラーが示す行と最終的な統合結果を確認して修正します。画面のデータベースやウィンドウ状態の問題なら、プロキシプロトコルを変更する必要はありません。インストーラーに専用コアが含まれる場合、入手元や互換性が不明なファイルへ手動で置き換えないでください。

mihomoの設定構文をローカルで確認する場合は、コアが提供するテスト用オプションを使えます。以下のコマンドは、現在のディレクトリに実行ファイルとテスト用設定があることを前提としています。このテストでは、設定をコアが受け付けるかを確認できますが、サーバーへの接続、ルールの妥当性、サブスクリプションのリソースが常にダウンロードできることまでは保証しません。コマンド出力に機密性の高いパスが含まれる場合もあるため、転送前に内容を確認してください。

# macOS / Linux
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

アーキテクチャ、実行環境、権限を確認する

再ダウンロードする前に、OSとプロセッサーのアーキテクチャを確認してください。特にIntelとApple Silicon、Android端末のインストーラーのアーキテクチャに注意が必要です。インストールに成功しても、依存コンポーネントがすべて揃っているとは限りません。グラフィック実行環境、システムコンポーネント、インストール先への権限も起動に影響します。アプリが示す具体的な不足コンポーネントやシステムエラーに対処し、提供元不明の修復ツールをまとめてインストールしないでください。

Windowsではイベントビューアーから障害モジュールを調べられます。macOSではシステムのクラッシュレポートとアプリの起動記録、Linuxではユーザーセッションのログやターミナルから起動した際の出力を確認します。ターミナルから起動するとグラフィック関連の依存エラーが分かることがありますが、問題を隠すためにデスクトップアプリ全体を管理者権限で常用しないでください。サービスコンポーネントに権限が必要な場合は、クライアントが提供するインストールと管理の手順を使います。

セキュリティソフトがコンポーネントを隔離した場合は、隔離履歴、インストール元、検出された理由を確認し、保護機能を一律に無効にしないでください。インストール先に書き込み権限がない場合や、同期ソフトがファイルを使用中の場合も、更新後のファイルが不完全になることがあります。アプリを完全に終了してから、ダウンロードセンターでOSに合ったインストーラーを選び、再インストールしてください。確認に必要な設定やログが消えないよう、データをバックアップしておきます。

Clash for WindowsとClashX Metaは開発が終了しています。新しいOSで互換性の問題が起きた場合は、現在の環境に対応したクライアントへの移行を検討してください。選択肢の第一候補はClash Plusです。LinuxではClash Verge RevやFlClashも確認できます。移行時は、まず設定をインポートして基本的な接続を確認し、その後にカスタム機能を一つずつ戻します。別のクライアントの設定ディレクトリ全体をそのままコピーしないでください。設定構文に互換性があっても、内部のデータ形式が同じとは限りません。

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

AndroidではVPNとアプリの適用範囲を確認する

Androidのクライアントは通常、システムのVPNインターフェースを使って通信を引き継ぎます。初回接続ではシステムの許可が必要です。許可を取り消した場合や端末のポリシーで制限された場合、アプリの画面が正常に見えても通信を引き継げないことがあります。システムのVPN状態とクライアントのログを確認し、ほかのVPN、仕事用プロファイルのネットワーク、同じ範囲を使用するアプリがないか調べてください。通知領域のアイコンだけで、出口やDNSが正常だと判断しないでください。

Clash Plus、Clash Meta for Android、FlClash、Surfboardでは、対応する設定形式や設定画面が異なります。インポート時には対応形式を選び、すべてのAndroidクライアントが同じ設定を受け付けると思い込まないでください。アプリごとのプロキシ設定を有効にした場合は、問題のアプリが想定した対象範囲に含まれているか確認します。対象を含めるリストと除外するリストのどちらを使うかは画面によって異なります。選択肢を逆に解釈すると、ブラウザーは使えるのに特定のアプリだけ常に直接接続されることがあります。

システムの「常時接続VPN」と「VPNを使用しない接続をブロック」は、別々の設定項目です。ブロックを有効にした状態でトンネルが切断され、通信が遮断されるのは、Wi-Fiの故障ではなくシステムがポリシーどおりに動作している場合があります。切り分けの前に元の設定を記録し、影響を把握したうえで比較してください。組織が管理する端末では管理ポリシーに従い、仕事用プロファイルのセキュリティ設定を変更しないでください。

バックグラウンドでの切断とインストール失敗を分けて対処する

画面ロック後に接続できなくなり、クライアントに戻るとすぐ復旧する場合は、バッテリー最適化、バックグラウンド動作の制限、メーカー独自の自動起動管理を優先して確認します。必要なバックグラウンド動作を許可したうえで、画面ロックから復帰までを一通りテストしてください。すべての省電力設定を無効にしても原因を特定できるとは限らず、バッテリー駆動時間に影響します。バックグラウンドプロセスが動作しているのに、Wi-Fiからモバイル通信へ切り替えた後で失敗する場合は、バックグラウンド権限をさらに増やすのではなく、ネットワークの再接続とDNSを確認します。

インストール時に互換性がないと表示された場合は、システム要件とプロセッサーのアーキテクチャを確認します。上書きインストールに失敗する場合は、署名やインストール元が異なる可能性もあります。アンインストール前に設定をエクスポートしてください。アプリのデータも削除される場合があります。インストールエラーを回避するために、安易なダウングレードや出所不明のインストーラーへの置き換えをしないでください。Android向けのクライアントとアーキテクチャはAndroidダウンロードで確認できます。初回インポートの手順はガイドに従ってください。

iOSではトンネル設定とリソース制限を確認する

iOSではiOSダウンロードからClash PlusのApp Storeページを開けます。クライアントの公式サイトはclashplus.ioです。接続できない場合は、システムのVPN設定が現在のクライアントに対応しているか確認し、トンネルを作成する許可がアプリにあることを確かめます。古い設定の残存、ほかのネットワークツール、端末管理ポリシーも接続に影響する場合があります。システムに表示される状態を確認して判断してください。

iOSのネットワーク拡張機能と前面のアプリ画面は別々に動作します。画面が開いていても、トンネルが継続して正常とは限りません。大きな設定、多数のルール用リソース、頻繁な更新は、拡張機能の負荷を高めることがあります。まず小さく、正常と確認できている設定でテストし、外部リソースを一つずつ戻してください。バックグラウンド制限の問題をサブスクリプションの破損と決めつけたり、ログを確認せずに何度もアプリを再インストールしたりしないでください。

Wi-Fi、モバイル通信、ポータル認証を分けて確認

公衆Wi-Fiでは、ブラウザーで認証を完了する必要がある場合があります。認証前にプロキシを有効にすると、ログイン画面が表示されないことがあります。まずネットワークの案内に従って認証を済ませてからクライアントを有効にしてください。Wi-Fiとモバイル通信では、IPv6、DNS、アクセス経路が異なる場合があります。ネットワークを切り替えた後は、テスト用リクエストを再接続してください。同じ設定が自宅で使えたからといって、会社のネットワークやテザリングで経路が制限されている可能性を除外することはできません。

スマートフォンのテザリングを使っても、スマートフォン自身のVPNが接続端末の通信まで引き継ぐとは限りません。動作はシステムの実装によって異なります。PCをスマートフォンのテザリングに接続した後も、PC側のシステムプロキシまたはTUN設定を個別に確認してください。モバイル端末が復旧したら、画面ロック、スリープからの復帰、ネットワーク切り替え、問題のアプリをそれぞれテストします。それでも失敗する場合は、OS、クライアント名、ネットワーク環境、個人情報を隠したログを整理し、このガイドの該当する章に戻って原因を絞り込みます。