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

インターネットに接続できない：まず基本回線とプロキシ経路を切り分ける

クライアントのシステムプロキシとTUNをいったん無効にして、普段なら直接アクセスできるサイトを開いてみてください。ウィンドウを閉じただけでは、システム設定が解除されないことがあります。終了後もバックグラウンドで動作するクライアントもあります。通信の取り込みを止めても接続できない場合は、Wi-Fiのログイン認証、ルーター、LANケーブル、回線事業者との接続を先に確認しましょう。この段階でノードを何度も切り替えても、基本回線の問題は解決しません。公衆Wi-Fiでは、先にWeb認証が必要な場合があります。認証ページは通常、プロキシを無効にして開きます。

問題の範囲を確認してから調べる場所を決める

直接接続するサイト、プロキシが必要なサイト、別のアプリをそれぞれ試し、どれが成功するか記録します。すべて失敗する場合は、停止したローカルポートをシステムプロキシが参照していないか確認してください。プロキシが必要な接続だけ失敗するなら、ポリシーグループと出口を確認します。特定のサイトだけ失敗する場合は、そのドメインに適用されるルール、接続先サービスの状態、アクセス制限を調べましょう。1つのサイトだけでインターネット全体の状態を判断しないでください。ブラウザーのキャッシュに残った古いページも、接続成功の証拠にはなりません。

次に、カーネルが起動していることを確認します。クライアントのメイン画面が開いていても、バックグラウンドのカーネルがポートを待ち受けているとは限りません。動作状態と起動ログを確認し、ポートの競合、設定の解析エラー、権限不足などがないか調べてください。設定の読み込み前にログが止まっているなら、まず起動失敗を解消します。接続記録がある場合は、そのリクエストがDIRECT、特定のポリシーグループ、REJECTのどれに振り分けられたかを追います。接続記録がないなら、リモート側のプロトコル設定をいじるのではなく、通信の取り込み方法に戻って確認してください。

明示的なプロキシ指定で原因を絞り込む

クライアントの設定で混合ポートを確認し、コマンドでプロキシを明示してテストします。以下ではローカルポート7890を例にしています。実際のポートが異なる場合は数字を置き換えてください。例と同じポートにするために、設定全体を変更する必要はありません。Windowsでは、同名の別コマンドとして解釈されるのを避けるため、curl.exeを使用できます。テスト先は接続確認用であり、どのネットワークでも必ず接続できるとは限りません。

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

1つ目のコマンドはプロキシを明示していませんが、ターミナルのプロキシ環境変数の影響を受ける可能性があります。実行前に環境変数を確認してください。2つ目でローカル接続が拒否される場合は、待ち受けアドレス、ポート、カーネルの状態が一致していません。ローカル接続が確立してからリモート側でタイムアウトする場合は、ノードや通信経路を調べます。明示的なプロキシ指定では成功し、ブラウザーでは失敗するなら、出口はおおむね利用可能です。ブラウザーの拡張機能、システムプロキシ、安全なDNSを確認してください。HTTPステータスコードが返っても、接続先サービスのすべての機能が正常とは限りません。

元に戻せる手順で接続を復旧する

ルールモードに戻し、以前使えた出口を選択します。ほかのプロキシクライアントや、通信を二重に取り込むツールを終了してから再接続してください。一時的にTUNを無効にしてシステムプロキシだけを使うと、ルーティングとアプリのプロキシ設定を切り分けやすくなります。ただし、システムプロキシを参照しないアプリには同じテストになりません。切り替えのたびに古いWeb接続を閉じるか、テスト対象のアプリを再起動してください。確立済みの接続は、ポリシーを変えてもすぐには切り替わらないことがあります。

クライアントを終了した後にすべてのサイトへ接続できなくなる場合は、システムのネットワーク設定を開き、残っている手動プロキシのアドレスを解除して、ネットワーク設定の自動取得に戻します。ネットワークを一括リセットすると、業務用ネットワークに必要な仮想アダプターや固定アドレスまで削除される可能性があるため、安易に実行しないでください。復旧後は、まず直接接続を確認し、次にクライアントを起動して機能を1つずつ有効にします。最後に問題を起こした設定を記録しておけば、毎回再インストールするのではなく、原因を絞って修正できます。

ノードがタイムアウトする：テスト失敗と出口への接続不能を切り分ける

まず接続先に実際にアクセスし、その後でクライアントの遅延テストを確認してください。テストのタイムアウトは、所定の時間内に探査が完了しなかったことを示すだけです。テスト先、名前解決、探査方法、現在の通信経路が原因の場合もあり、それだけでノードが恒久的に使えないとは判断できません。Webページを開けるのに探査だけ失敗する場合は、アクセス可能なテスト先に変更するか、クライアントの既定のテスト設定に戻してください。これを理由にサブスクリプション全体を削除する必要はありません。測定の限界については、遅延テストと実際の通信速度の違いもご覧ください。

どの段階でタイムアウトするかを確認する

ログを開き、失敗したリクエストをもう一度実行して、同じ時刻の接続先、ポリシー、エラーを確認します。サーバーへの接続前に名前解決エラーが出る場合は、接続先ホスト名の解決に問題があります。サーバーのポート接続がタイムアウトする場合は、ローカルネットワーク、回線、リモート側の待ち受け、中継ファイアウォールなどが原因として考えられます。接続確立後にハンドシェイクが失敗するなら、プロトコル、トランスポート層、セキュリティ設定、サーバーの状態を確認してください。クライアントによってエラーの文言は異なるため、前後のログも読み、最後の英単語だけで判断しないでください。

現在のポリシーグループで、実際にどの出口が選択されているか確認します。自動選択グループはヘルスチェックに応じて切り替わることがあり、フォールバックグループも別のメンバーに切り替わっている可能性があります。画面に表示されたグループ名はサーバーアドレスではありません。個別の接続で出口までの経路を確認し、誤ってDIRECTや利用できないメンバーが選ばれていないか調べてください。ノードへの接続に別のプロキシが必要な場合は、前段の出口も確認します。チェーン接続では、どこか1か所で失敗するだけでも、最終的に接続先のタイムアウトとして表示されます。

ネットワークとサーバーのどちらに原因があるか交差テストする

同じ端末で、自宅のネットワークとスマートフォンのテザリングを切り替え、クライアント設定を変えずに同じ出口をテストします。特定のネットワークだけで失敗するなら、ネットワーク経路、ポート制限、名前解決の違いが考えられます。複数のネットワークで失敗する場合は、別の端末でも試してください。2台とも失敗し、同じサブスクリプションの他の出口は使えるなら、そのサーバーに問題がある可能性が高くなります。交差テストでは自動切り替えを無効にしてください。同じグループを選んだつもりでも、テストごとに出口が変わると正しく比較できません。

サブスクリプションの更新に成功しているか、アカウントの利用権が残っているか、サービス提供元が接続先を変更していないかも確認してください。サーバーのポート、暗号方式、通信経路を推測で変更しないでください。各設定はサーバー側と一致させる必要があり、経験だけで変更するとタイムアウトがハンドシェイクエラーに変わるだけの場合があります。端末の日付とタイムゾーンも正しく設定してください。時刻が大きくずれていると、証明書検証に失敗する可能性があります。証明書の問題が疑われる場合は、サーバー名と証明書設定を確認し、検証を恒久的に無効化しないでください。

一部のプロトコルの問題を、全面的な接続障害と混同しない

Webページは表示できるのに、音声通話やゲームがタイムアウトする場合は、UDPの対応状況、アプリの通信取り込み、接続先の制限が関係している可能性があります。まずノードのプロトコルとサーバーが必要な通信に対応しているか確認し、次にクライアントの接続記録を見てください。ブラウザーのQUIC、一般的なHTTPS、アプリ独自のプロトコルは、必ずしも同じ経路を通りません。Webページのテスト1回だけですべての用途を確認することはできません。アプリに互換性のある通信方式があれば、一時的な比較に利用できます。ただし、特定のプロトコルを無効にすることを、すべての端末に共通する最適化と考えないでください。

タイムアウト値の調整は応答の遅さを見分ける助けにはなりますが、遮断されたポートを使えるようにはできません。まず既定値のまま、問題が安定して再現することを確認してから、1回の探査時間を適度に延ばし、実際のリクエスト結果と比較してください。問い合わせ時は、発生時刻、ネットワークの種類、個人情報を伏せたエラー、交差テストの結果を添えます。サーバーの認証情報は送らないでください。特定の出口だけに問題がある場合は、まず利用可能なメンバーに切り替えて使い、サービス提供元に該当する接続先を調査してもらいましょう。

サブスクリプションを更新できない：取得、形式、設定の読み込みを個別に確認

まず、どの段階で失敗しているか確認します。URLから内容を取得できないのか、ダウンロードは成功したが解析できないのか、設定を読み込んだ後にカーネルが起動しないのかを切り分けてください。それぞれ対処方法が異なります。最後に使えた設定を残し、更新に失敗したときに動作環境まで上書きしないようにしましょう。クライアントにサブスクリプションが表示されていても、ローカルに情報が保存されていることしか分かりません。最新の内容を取得できたか確認するには、更新日時と結果を見る必要があります。

URLの完全性と取得経路を確認する

サービス提供元からClashまたはmihomo用のサブスクリプションURLをコピーし直します。チャットアプリで改行が入っていないか、前後に空白がないか、Webページからコピーした際に句読点が付いていないか確認してください。サブスクリプションURLにはアカウントへのアクセス情報が含まれることが多いため、パスワードと同様に管理します。完全なURLを公開の変換サービスに貼り付けたり、問題調査のためにスクリーンショットのタイトルへ記載したりしないでください。URLを公開してしまった場合は、サービス側で再発行してください。投稿を削除するだけでは、漏えいしたアクセス権を無効にできません。

更新時のエラーを確認します。応答がない場合は、ネットワークと名前解決を調べてください。未認証やアクセス禁止が明示される場合は、URLの権限とアカウントの状態を優先して確認します。Webページが返ってきても解析に失敗する場合は、ログインページ、エラーメッセージ、アクセス確認ページをダウンロードしている可能性があります。ブラウザーでサービスのWebサイトを開けても、クライアントがサブスクリプションAPIを利用できるとは限りません。リクエスト経路、ログイン状態、ネットワーク出口が異なることがあります。サービス側の頻度制限を招かないよう、何度も連続して再試行しないでください。

クライアントによっては、サブスクリプション更新時の接続方法としてDIRECTかプロキシを選べます。使える設定がすでにあるなら、2つの取得経路を比較してください。初回追加で利用可能な出口がない場合は、現在のネットワークでアクセスできる正規の方法を使います。更新に現在使えないノードが必要だと、自力で解決できない循環に陥ります。その場合は、最後に使えた設定へ戻す、一時的に別の利用可能な出口を選ぶ、サービス提供元に接続先を確認する方法が、DNSを手当たり次第に変更するより確実です。

サブスクリプションの形式とカーネルの対応状況を確認

YAML形式の完全な設定、エンコードされたノード一覧、単一のURIリンクは、それぞれ異なる形式です。あるクライアントに読み込める内容でも、別のクライアントの完全な設定としてそのまま使えるとは限りません。追加画面で必要な形式を確認し、ノードの追加、設定ファイルの読み込み、サブスクリプションの更新を区別してください。別形式の場合は、まずサービス提供元から対応形式を入手します。変換が必要な場合は、サブスクリプション形式と変換方法の解説を参照し、ポリシーグループ、ルール、追加フィールドが失われる可能性を確認してください。

解析エラーには、行番号やフィールド名が含まれていることがよくあります。元のファイルに戻り、該当行と1行前を確認して、インデント、コロン、引用符、リスト記号を見直してください。YAMLのインデントにはスペースを使い、タブを混在させないでください。構文解析に成功しても、ポリシーの参照先が誤っている場合があります。ルールが存在しないグループを参照していたり、グループに存在しないノードが含まれていたりすると、読み込みに失敗したり、動作が不安定になったりします。空白や特殊記号を含む名前は省略せず、名前を変更した場合はすべての参照先も更新してください。

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

これは基本的な読み込みを確認するためだけの、直接接続用の設定です。リモートプロキシは含まれていません。クライアントがローカル設定の読み込みに対応している場合は、バックアップを取ったうえでテスト用の項目を別に作成し、元のサブスクリプションを上書きしないでください。最小構成では起動でき、元の設定では起動できない場合は、元ファイルのフィールド、参照先、外部リソースを確認します。どちらも失敗する場合は、ポート、ディレクトリのアクセス権、カーネルの実行環境を調べてください。

更新時の上書きと外部リソースの取得失敗に対処する

サブスクリプション本体の読み込みが成功しても、ルールセットやプロキシ一覧の取得に失敗する場合があります。外部リソースのURL、ファイルパス、エラーを個別に確認し、すべてのダウンロード失敗をサブスクリプションURLの問題と決めつけないでください。クライアントがオーバーライドや設定のマージに対応している場合は、次回の更新で上書きされないよう、ローカルの変更を専用の設定欄に保存します。マージ順が分からない場合は、最終的に適用された設定を確認してください。失敗が続く場合は、まずバックアップに戻し、カスタム設定を1つずつ追加します。クライアントとカーネルの機能が合わない場合は、クライアントのダウンロードから適したものを選んでください。一般的な用途にはまずClash Plusを検討し、ほかの選択肢はプラットフォームごとに確認できます。

速度が遅い：名前解決、ハンドシェイク、データ転送を切り分ける

まず、どの段階で遅くなるか説明できるようにします。リンクをクリックしてから長く待つのか、ページの読み込み開始後は速いのか、ファイルのダウンロードがずっと遅いのか、混雑する時間帯だけ重いのかを確認してください。最初の応答までの時間、スループット、操作時の遅延はそれぞれ別の指標です。クライアントの探査値が低くても、短いリクエストへの応答が速いというだけで、回線に十分な帯域があるとは限りません。複数の速度測定ツールやダウンロードを同時に実行すると、テスト自体が出口とローカルWi-Fiのリソースを消費するため、避けてください。

再現可能な比較テストを行う

端末、ネットワーク、出口、接続先を固定し、大きなファイルの同期、システム更新、その他の帯域を使う処理を止めてから、数回テストします。まず直接接続する対象を測定し、ローカルネットワークが混雑していないか確認します。次にプロキシが必要な通信を試し、結果を比較してください。出口を比べるときは、同じ接続先を近い時間帯にテストします。サーバーのキャッシュ、ファイルサイズ、地域ごとのコンテンツ配信の違いを、ノードの差と誤認しないためです。スマートフォンのテザリングでは、データプランの速度制限や電波状況も考慮してください。

ダウンロード速度は通常、1秒あたりのバイト数で表示されますが、回線の公称速度は1秒あたりのビット数で表されることが多く、そのまま比較できません。Wi-Fiのリンク速度も、アプリが継続して利用できる実効速度とは異なります。ルーターの性能、無線干渉、端末の省電力設定、出口の共有ユーザー数、接続先サーバーの速度制限などがボトルネックになる場合があります。まず有線と無線を比較するか、ルーターの近くでテストしてください。直接接続も遅いなら、ローカル環境から改善しましょう。プロキシのルールを変えても、Wi-Fiの容量は増えません。

遅いリクエストが実際にどの出口を通るか確認する

接続画面で読み込み中のドメインを探し、適用されたルールとポリシーを確認します。Webページは通常、複数のドメインを呼び出します。トップページは直接接続していても、静的ファイルはプロキシ経由になっていたり、ログインAPIが別の地域へ振り分けられていたりすると、一部の読み込みだけ遅くなる場合があります。メインドメインのルールが正しいからといって、すべてのリクエストが正しく処理されるとは限りません。接続記録をもとに必要なルールを追加し、より具体的なルールを広範囲に適用されるルールより前に配置してください。変更後は接続を張り直し、古い接続が以前の出口を使い続けないようにします。

ルールは上から順に照合されます。条件の広いルールを先に置くと、直接接続するはずの通信まで遠隔地へ送られ、往復時間が長くなることがあります。反対に、プロキシが必要なドメインを直接接続にすると、長時間待ってからエラーになる場合があります。エディター上の一部分だけでなく、最終的に適用される設定を確認してください。サブスクリプションとのマージやオーバーライドで順序が変わることがあります。照合方法を確認するには、カスタムルールと照合順序を読み、ルールを調整してください。同じ内容を大量に追加して試すのは避けましょう。

初回アクセスだけ遅く、次回以降は改善する場合は、DNS、接続時のハンドシェイク、リモート側の起動遅延を優先して確認します。開始時は速いのに転送速度が徐々に落ちる場合は、混雑、速度制限、端末の負荷が考えられます。タスクマネージャーでCPU、メモリ、ネットワークの使用状況を確認し、特定のプロセスがリソースを使い続けていないか調べてください。GUIクライアントでは、ログが多すぎると画面の動作に影響する場合もあります。原因を特定したら通常のログレベルに戻し、詳細なデバッグログを常時有効にしないでください。

MTU、プロトコル、同時接続数の変更は慎重に行う

TUNを有効にしたときだけ小さなページは開けるのに、大きなファイルや一部のサイトが止まる場合は、経路MTUやパケット分割を確認します。まずTUNを無効にし、明示的なプロキシだけを使う比較テストを行い、仮想NICによる通信の取り込みが関係するか確認してください。MTUは回線のテスト結果とクライアントのドキュメントに基づいて調整します。インターネット上の数値をすべての環境に当てはまる正解だと考えないでください。変更のたびに同じ通信をテストし、元の値も記録します。根拠なく値を下げるとパケット数が増え、速度が改善するとは限りません。

同様に、同時接続数を増やす、詳細設定をすべて有効にする、任意のパブリックDNSに変更するといった操作を、まとめて速度改善策にしないでください。同時接続数を増やすと接続の負荷が高まり、プロトコルによってはサーバー側の対応も必要です。まず目的の通信に適した距離と経路の出口を選び、不要な多段転送を減らします。自動選択は接続可能な状態を保つのに便利ですが、ヘルスチェックだけでは大容量通信のスループットを判断できないことがあります。連続ダウンロードでは比較テストの後に出口を固定し、頻繁な切り替えで判断がぶれないようにしてください。

DNSの問題：どこで名前解決し、結果をどこで使うか確認する

まず、ドメインの名前解決に失敗しているのか、接続先への通信が失敗しているのかを区別します。ログにホストが見つからない、名前解決がタイムアウトする、利用可能なアドレスがないと表示される場合は、DNSを優先して確認してください。IPアドレスを取得済みなのに接続がタイムアウトするなら、ルーティングや出口の問題かもしれません。URLのドメインをIPアドレスに置き換える方法は、確実なテストにはなりません。HTTPS証明書、サーバー名、仮想ホストのルーティングが元のドメインに依存している場合があります。名前解決ツールとクライアントのログを合わせて確認し、ブラウザーのエラーページだけで結論を出さないでください。

実際の名前解決経路を整理する

OS、ブラウザー、クライアント、リモートプロキシのそれぞれが名前解決に関わる可能性があります。ブラウザーで安全なDNSが有効だと、OSのリゾルバーを経由しない場合があります。アプリ内蔵の名前解決も、ターミナルのツールとは異なる結果になることがあります。TUNのDNSハイジャックが機能するかどうかは、ルーティングやリクエストの種類にも左右されます。まず現在のモード、クライアントのDNS設定、システムDNS、ブラウザー設定を記録し、問題のアプリが実際にどの経路を使っているか確認します。システムDNSを変更しても、アプリの問い合わせ先が変わるとは限りません。

システムのツールで安定したドメインを問い合わせ、同時にクライアントのログも確認してください。以下のコマンドで分かるのはシステムの名前解決結果であり、ブラウザーやプロキシの出口が取得するアドレスとは限りません。失敗するドメインと正常なドメインをそれぞれ問い合わせます。1つのドメインだけ失敗する場合は、権威DNSレコード、キャッシュ、分割DNSの設定が考えられます。すべて失敗する場合は、DNSサーバーに到達できるか確認してください。ターミナルの結果とクライアントログのアドレスが異なっていても、それだけで異常とは限りません。コンテンツ配信ネットワークから異なるアドレスが返ることがあります。

nslookup example.com

# LinuxまたはmacOSでdigがインストールされている場合に使用
dig example.com A
dig example.com AAAA

プロキシサーバー自体のドメインがどのように解決されるかも確認してください。プロキシの接続先を解決するリクエストが、まだ確立していないプロキシを経由しなければならないと、起動時に循環が発生します。mihomoのproxy-server-nameserverはプロキシノードのドメイン名解決に使われ、default-nameserverは暗号化DNSサービスのドメイン名解決に使われます。実際の動作はほかの設定項目にも左右されます。まず起動時に必要な名前解決経路を利用可能にしてから、接続先ドメインの振り分けを設定してください。すべての問い合わせを、到達できない出口へ無理に送らないようにしましょう。

fake-ipとキャッシュの適用範囲を理解する

fake-ipモードでは、アプリにマッピング用の仮想アドレスを返し、カーネルがその対応関係を使って接続を処理します。この種のアドレスが表示されても、名前解決が改ざんされたとは限りません。問題になるのは、アプリが仮想アドレスを受け取った後も、同じカーネルが接続を取り込めるかどうかです。アプリに古いキャッシュが残り、クライアントが終了している、またはマッピングが失われていると、接続できないことがあります。モードを切り替えたら古い接続を閉じ、影響を受けるアプリを再起動してください。必要に応じて該当するキャッシュだけを消し、すぐに大量の除外ルールを追加しないでください。

機器の検出、LAN内サービス、特定のアプリは実際のIPアドレスを必要とする場合があります。互換性の問題を確認してから、fake-ipの除外設定を使ってください。除外設定で変わるのは該当ドメインの名前解決方法であり、その後の通信が自動的に直接接続になるわけではありません。ルールとルーティングも確認する必要があります。LAN内のホスト名は、ルーター、検索ドメイン、マルチキャストによる検出に依存することがあり、パブリックDNSでは通常それらの情報を取得できません。リモートワークでは特に社内DNSの経路を維持し、すべての用途を1つのパブリックリゾルバーで置き換えないでください。

最小限のDNS設定で比較する

以下の設定例は項目同士の関係を示すものです。独立したテスト用設定に追加し、既存のサブスクリプションのDNS設定全体を上書きしないでください。この例は比較用に通常のDNSを使い、暗号化通信は含みません。現在のネットワークからリゾルバーに接続できない場合は、ネットワーク管理者またはサービス提供元に利用可能なアドレスを確認してください。このテストに成功しても、この名前解決経路が使えることを示すだけで、プライバシーやルーティング要件を満たしたとは限りません。

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

IPv4では正常でもデュアルスタック環境で断続的に失敗する場合は、IPv6の名前解決結果、デフォルトルート、プロキシの対応状況を個別に確認してください。特定のアプリでIPv6を無効にしただけで原因が解消したと判断しないでください。OS内の別のアプリが異なる経路を使っている場合があります。設定を戻すときは、ノードのドメイン名、一般の接続先、LAN内の接続先を分けて検証し、その後で暗号化DNSとルーティングルールを1つずつ戻します。TUNによる通信の取り込み全体については、TUNモードと仮想NICの設定をご覧ください。

システムプロキシが機能しない：アプリがプロキシ設定を参照しているか確認

まず、システムプロキシの役割を確認しましょう。システムプロキシは、アプリが読み取るプロキシ設定を提供するもので、すべての通信を強制的に取り込む仕組みではありません。ターミナルツール、ゲーム、サービスプロセス、独自に接続を確立するアプリは、設定を参照しない場合があります。有効にした後でブラウザーは使えても、特定のプログラムが直接接続することはあり、必ずしもクライアントの故障ではありません。まずプロキシを明示するツールでローカルの接続先を確認し、次に対象アプリがプロキシ設定に対応しているか調べます。より多くのアプリを取り込みたい場合は、システムプロキシの切り替えを繰り返すのではなく、TUNの利用を検討してください。

待ち受けアドレス、ポート、プロキシの種類を確認する

クライアントに設定されているポートを確認し、システムの手動プロキシ設定が同じアドレスを指定しているか確認します。ローカルアドレスとしてよく使われるのは127.0.0.1ですが、ポート番号は固定ではありません。HTTPプロキシ、SOCKS、混合ポートはそれぞれ機能が異なるため、任意に置き換えないでください。アプリがSOCKSを要求する場合は、SOCKSに対応したポートを入力します。HTTP CONNECTを使う場合は、対応する待ち受け先を選んでください。混合ポートで両方を使える場合もありますが、クライアント側でその待ち受けが有効になっている必要があります。

別のクライアント、ブラウザー拡張機能、組織の管理ポリシーがシステム設定を繰り返し書き換えていないか確認します。有効にした直後は使えても、しばらくするとプロキシアドレスが変わることがあります。まずほかの通信取り込みツールを終了し、設定が安定するか確かめてから、1つずつ再開してください。設定を奪い合うように複数のクライアントを自動起動しないでください。組織の管理下にある設定は、管理者の指示に従ってください。ポリシーを無断で上書きすると、業務ネットワークや認証サービスが使えなくなる可能性があります。

ターミナルと隔離環境は個別に設定する

ターミナルでは通常、ツールの引数や環境変数を使います。以下は、現在のUnix系ターミナルセッションに限りHTTPとHTTPSのプロキシを設定し、ローカルアドレスを除外する例です。Windows PowerShellでは対応する環境変数の構文を使ってください。環境変数名の大文字・小文字の扱いはツールによって異なるため、使用前にドキュメントを確認します。すでに起動中のプロセスは、後から変更した環境変数を自動では引き継ぎません。新しい環境からテスト対象のプログラムを再起動してください。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

# 現在のセッションに設定した一時値を解除
unset http_proxy https_proxy no_proxy

https_proxyの値がHTTPのURLでも、必ずしも誤りではありません。HTTPプロキシを通してHTTPSの接続先へトンネルを確立する用途で使われることがあります。環境変数名だけを見て、対応していないプロトコルの接頭辞に変更しないでください。コンテナ、仮想マシン、一部のサブシステムでは、127.0.0.1はその環境自身を指し、ホスト側のループバックアドレスとしてそのまま使えません。環境をまたいで接続する必要がある場合は、ホストのアドレス、待ち受け範囲、ファイアウォールを確認し、信頼できないネットワークにローカルプロキシを公開しないようアクセス元を制限してください。

必要な場合に限りTUNを有効にする

対象アプリがプロキシに対応していない場合は、クライアントのTUN機能を利用できます。ただし、必要な権限、仮想NIC、ルート、DNSの取り込みを先に確認してください。クライアントによってはシステムプロキシとTUNを併用できますが、両方を有効にすれば必ず安定するわけではありません。原因を調べるときは、通信を取り込む経路を一度に1つにして、リクエストの二重転送や別のVPNルートによる横取りを避けます。仮想NICが存在していても、ルーティングが正しいとは限りません。対象アプリの実際の接続記録で確認してください。

ブラウザーは正常でコマンドラインだけ失敗する場合は、プロキシを明示して確認します。すべてのアプリが接続記録に現れない場合は、待ち受けと通信の取り込みを確認してください。接続記録があるのに誤った出口を通る場合は、ルールを確認します。修正後は、プロキシが必要な接続、直接接続、LAN内の機器をテストし、プリンター、ファイル共有、業務ネットワークに影響がないことを確かめてください。クライアント終了後はシステムプロキシが正しく解除されるかも確認します。復旧まで確認しておけば、次回起動時に設定が残って接続できなくなるのを防げます。

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

まず、どのプロセスが終了したか確認してください。画面が開かない、ウィンドウが固まる、カーネルが停止する、バックグラウンドサービスが起動しない、という症状はそれぞれ別の問題です。ウィンドウを閉じてもプロキシが使えるなら、画面側のプロセスだけに問題がある可能性があります。画面は正常でもポートが待ち受けなくなった場合は、カーネルとサービスのログを確認してください。OSのエラーメッセージ、発生時刻、直前の操作（設定の更新、TUNの切り替え、スリープからの復帰、ネットワークの変更など）を記録し、「突然落ちた」だけで再現できない状態を避けましょう。

手がかりを残してから、最小構成で起動する

まずクライアントの画面から必要なログを書き出すか、プログラムデータのフォルダーで該当時間の記録を探します。共有前に、サブスクリプションURL、ノードの認証情報、閲覧履歴、ローカルユーザー名などを削除してください。設定フォルダー全体をそのままアップロードしないでください。アカウント情報やAPIの設定が含まれていることがあります。ログが長い場合は、起動からエラー発生までの部分を前後の情報も含めて抜き出します。最後の1行だけでは、設定の問題か実行環境の問題か判断できないことがあります。

バックアップを取ってから、最小限のローカル設定に切り替えます。自動更新、外部ルールのダウンロード、TUN、自動起動を一時的に無効にし、クライアントを起動してください。最小構成で動くなら、元の設定を1項目ずつ戻して、問題を起こす機能を特定します。最小構成でも動かない場合は、インストールファイル、システムコンポーネント、フォルダーのアクセス権、プロセスの競合を確認してください。設定の削除、再インストール、OSの更新を同時に行わないでください。復旧しても、本当に有効だった修正が分からなくなります。

権限、アーキテクチャ、ポートの競合を確認する

クライアントのダウンロードから、OSとプロセッサのアーキテクチャに合ったインストーラーを選んでください。一般的な用途にはまずClash Plusを検討し、別の画面や導入方法が必要なら、Clash Verge Rev、FlClashなどから対応するものを選びます。旧OSへの対応状況は、各クライアントの最新要件を確認してください。新しいインストーラーがすべて古い環境で動くとは限りません。Clash for WindowsとClashX Metaは開発が終了しています。移行時は利用可能な設定を残し、通信の取り込みとサービス設定を改めて確認してください。古いプログラムのフォルダー全体を新しいクライアントに上書きしないでください。

起動ログにアドレスの競合が表示された場合は、システムプロセスを手当たり次第に終了せず、まずポートを使用しているプロセスを確認します。Windowsでは以下のコマンドで例のポートに対応するプロセスIDを調べ、タスクマネージャーでプログラム名を確認できます。Linuxではssで待ち受け状態を確認してください。別のプロキシインスタンスが原因であれば、重複したプロセスを終了するか、設定でポートを変更し、システムプロキシとアプリの接続先も合わせて更新します。ログに表示されるポートがプロキシ用ではなく、コントロール用の場合もあります。項目を確認して個別に対処してください。

# Windows：例のポートを確認
netstat -ano | findstr :7890

# Linux：TCPの待ち受けを確認
ss -lntp

サービスのインストール、仮想NICの作成、通常の画面操作では、それぞれ必要な権限が異なる場合があります。ドキュメントで指定された操作に限って必要な権限を付与し、フォルダーの権限エラーを隠すためにすべてのプログラムを常に高い権限で実行しないでください。保護されたインストール先、書き込み禁止のデータフォルダー、ディスク容量不足によって、設定の保存に失敗することがあります。セキュリティソフトがコンポーネントを隔離した場合は、まず入手元と検出記録を確認し、端末の管理方針に沿って対処してください。試しに保護機能をすべて無効にするのは避けましょう。

スリープ復帰とリソースの継続的な増加に対処する

スリープからの復帰後やネットワーク切り替え後だけ問題が起きる場合は、まずネットワークに再接続し、次にカーネルを再起動して回復するか確認してください。復帰後にネットワークインターフェース番号、デフォルトルート、DNSサーバーが変わることがあります。古いTUNの状態がそのまま使えるとは限りません。クライアントに適切な復旧設定があることを確認してから、自動再接続を有効にするか判断します。自動で再起動を繰り返すと、問題発生時の状態が失われ、正常な接続まで切断される場合があります。原因調査の代わりにはなりません。

長時間の使用で次第に重くなる場合は、メモリ、CPU、ディスク書き込みが継続的に増えていないかを観察し、増加が始まった時刻と通信内容を記録してください。過剰なログ出力、大規模なルールセット、頻繁なヘルスチェックは比較して調べる価値がありますが、リソース使用量が高いだけで特定の不具合があるとは限りません。カスタム設定を1項目ずつ減らし、通常のログレベルに戻して、同じ時間だけ動かして比較します。更新や移行後は、安定して動作することを確認してから自動起動を再設定してください。Linuxのバックグラウンドサービスやログの確認方法は、mihomoとsystemdの導入ガイドを参照してください。

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

まず、OS上で現在のクライアントのVPN接続が確立されていることを確認してから、対象アプリをテストします。モバイル端末では通常、OSのVPNインターフェースを通して通信を取り込みます。ステータスバーのアイコンは接続状態を示すだけで、サブスクリプション、DNS、リモート出口が正常である証拠にはなりません。仕事用VPN、ファイアウォール、その他の通信フィルターアプリが端末にある場合、同じ通信取り込みの仕組みを奪い合うことがあります。まずどのアプリが通信を取り込むのかを明確にし、その後でルールやノードを確認してください。複数のツールが設定を交互に上書きする状態を避けましょう。

Android：VPNの許可とバックグラウンド制限を確認する

Clash Plus、Clash Meta for Android、FlClashを起動するときは、OSの案内に従ってVPN接続を許可してください。許可を拒否しても画面上で設定を確認できる場合がありますが、アプリの通信は想定どおりトンネルに入りません。接続をタップしても許可画面が表示されない場合は、システムのVPN設定に古い構成が残っていないか、「常時接続VPN」や「VPNを経由しない接続をブロック」の設定が有効になっていないか確認してください。変更前の状態を記録し、管理対象の端末では組織のポリシーに従います。業務上必要な接続を無断で削除しないでください。

画面を表示している間は正常でも、ロック後しばらくすると使えなくなる場合は、バッテリー最適化、バックグラウンド動作、自動起動の制限を確認してください。設定画面の場所はメーカーによって異なるため、端末の設定を参照します。クライアントに必要なバックグラウンド動作を許可した後、画面をロックしてから復帰するテストを行い、接続が維持されるか確認してください。すべてのアプリの制限を一括解除する必要はありません。通信を取り込むクライアントだけを調整し、電池消費やバックグラウンドサービス終了の警告が出ていないかも確認しましょう。

一部のアプリだけプロキシを経由しない場合は、アプリごとの対象リストや除外リストが有効になっていないか確認してください。リストによる選択と全体の通信取り込みは意味が異なります。アプリの更新、仕事用プロファイル、アプリ複製機能によって、以前の選択が実際のプロセスに適用されなくなることもあります。まず通常のブラウザーを基準として、次に対象アプリをテストしてください。アプリ独自の安全なDNS、独立したネットワークスタック、アカウントの地域制限によって、ブラウザーとは異なる結果になる場合があります。1つのアプリの失敗だけでVPN全体が無効と判断しないでください。

iOS：接続設定と対象アプリの通信を確認する

iOSではiOSクライアントの案内から、推奨クライアントのClash Plusを確認し、公式サイトのclashplus.ioもご確認ください。初回接続時は、OSの案内に従ってVPN構成を許可してから、クライアントに表示される有効なサブスクリプションとポリシーを確認します。システムに複数のVPN構成が保存されている場合は、現在どれが有効か確認してください。古い構成を削除する前に用途を確認し、業務用接続や引き続き必要なネットワーク設定を誤って削除しないようにします。

ブラウザーでは使えるのに特定のアプリで失敗する場合は、まず接続記録に対象が表示されるか確認し、通信が取り込まれていないのか、ルールが誤っているのか、サーバー側で拒否されているのかを切り分けます。サービスによってはアカウントの地域、端末の位置、既存セッションに基づいて機能が決まるため、出口を切り替えても条件が自動で変わるとは限りません。古い接続の影響を除くために対象アプリを再起動する方法はありますが、アプリのデータをすべて消去するのは最初の手段にしないでください。決済、アカウント確認、業務認証に関わる場合は、まず安定したネットワークに戻し、サービス提供元の案内に従います。

Wi-Fiとモバイル通信を切り替えて再確認する

Wi-Fiからモバイル通信に切り替えると、ローカルアドレス、DNSリゾルバー、IPv6の状態、出口への経路が同時に変化する場合があります。切り替え直後に通信が止まる場合は、OSのネットワーク接続が安定するまで待ってから、クライアントを再接続してください。2種類のネットワークでの結果をそれぞれ記録します。Wi-Fiだけ失敗するなら、認証ページとルーターを確認してください。モバイル通信だけ失敗するなら、電波状況、データプラン、通信事業者の経路を確認します。運転中など、端末を操作するのに適さない状況で連続テストを行わないでください。

スマートフォンでクライアントを使って通信できても、テザリングで接続したPCの通信まで自動的にプロキシ経由になるとは限りません。テザリングの通信が取り込まれるかどうかは、OSの機能、ルーティング、クライアントの実装に左右されます。スマートフォンにVPNアイコンが表示されているだけで判断できません。ほかの端末とプロキシを共有する場合は、待ち受け範囲、認証、ファイアウォールも設定する必要があります。明確なLAN構成に沿って設定してください。一般的な用途では各端末に対応クライアントをインストールし、それぞれ個別に確認するのがおすすめです。スマートフォンのループバックアドレスをPCのプロキシ設定に入力しないでください。

トラブルの確認が終わったら、アプリを開いた状態での通信、画面ロック後の復帰、Wi-Fiとモバイル通信の切り替え、直接接続が必要なローカルサービスを順番にテストしてください。必要最小限のバックグラウンド権限を残し、一時的なデバッグ設定は元に戻します。問題が再現する場合は、端末のOS、クライアント名、ネットワークの種類、発生時刻、個人情報を伏せたログを整理し、該当する開発元またはサービス提供元に問い合わせてください。基本用語は用語集で確認できます。設定を作り直す場合は、入門ガイドに戻って手順を順に確認してください。不明なパラメーターを追加し続ける必要はありません。