Clashのトラブル対処ガイド

インターネットに接続できない：原因の段階を切り分ける

まず、端末自体がネットワークに接続できないのか、Clashを有効にした後に接続できなくなったのかを確認します。クライアントで「システムプロキシ」と「TUNモード」をオフにし、システム側のプロキシ設定も元に戻したうえで、普段直接アクセスできるサイトを開いてください。それでも失敗する場合は、Wi-Fi、ルーター、ネットワークのログイン画面を先に確認します。プロキシ設定では、ネットワーク自体の切断は直せません。公共Wi-Fiでは、認証ページでのログインを済ませてからクライアントを再度有効にしてください。認証による通信遮断をノードの障害と誤認するのを防げます。

直接接続と明示的なプロキシ接続を比較する

直接接続に戻したら、クライアントを起動して、まずTUNは有効にせず、コアが正常に動作していることを確認します。次の2つのコマンドで同じ接続先にアクセスします。1つ目はプロキシを明示的に迂回し、2つ目はローカルのプロキシポートに明示的に接続します。Windowsでは curl が別のコマンドとして扱われる環境があるため、curl.exe を使ってください。例ではポートに 7890 を指定しています。実行前にクライアントの設定で実際の待ち受けポートを確認し、置き換えてください。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

HTTPレスポンスが返れば、そのリクエストで少なくとも該当する接続処理は完了しています。レスポンスコードが成功を示していなくても、プロキシが切断しているとは限りません。2つ目のコマンドで Failed to connect to 127.0.0.1 とすぐに表示された場合は、まずコアとポートを確認します。ポートに接続できても、その後のハンドシェイクやリモート接続で失敗する場合は、プロキシグループ、ノード、DNSを確認してください。テストサイトで分かるのはその経路の状態だけなので、問題が起きていたサイトでも再テストしてください。

接続ログでリクエストがコアに届いているか確認する

「接続」または「ログ」を開き、フィルターを解除してから、問題を1回だけ再現します。該当するリクエストがまったくない場合、アプリがシステムプロキシを使っていない、既存の接続が再利用されている、またはTUNによる通信の取り込みが確立していない可能性があります。記録がある場合は、適用されたルール、プロキシグループ、実際の出口を確認してください。ホーム画面の稼働表示だけでは判断できません。画面のプロセスが起動していても、コアが設定の読み込みに成功しているとは限りません。設定の解析エラーがある場合は、まず該当行を修正してからノードの状態を確認します。

ログに DIRECT と表示され、対象サイトへのアクセスにプロキシが必要な場合、問題はノードの速度ではなくルールの選択にあります。一時的に「グローバル」へ切り替え、利用できることが分かっている出口を選んで、新しい接続で比較してください。グローバルモードで変わるのは、コアに届いた後の経路です。もともとクライアントを経由していないアプリが自動的にプロキシを使うようになるわけではありません。テスト後はルールモードに戻し、ほかのサイトまで同じ出口を通る状態を避けてください。

最小限の組み合わせで1項目ずつ戻す

明示的なプロキシ接続ではアクセスできるのに、ブラウザーではできない場合は、まずシステムプロキシだけを有効にし、ブラウザーを再起動して再テストします。特定のアプリだけがプロキシを使わない場合は、TUNを別途確認してください。複数のプロキシクライアント、通信最適化ツール、VPNを同時に起動するのは避けましょう。システムプロキシ、デフォルトルート、DNSを取り合う可能性があります。ほかのツールを終了するときは、ウィンドウを閉じるだけでなく、ネットワーク設定も解除されたことを確認してください。

最後に、最初に失敗した接続先で再テストし、どの設定を切り替えたときに変化したかを記録します。直接接続とプロキシ接続の両方が失敗する場合は、基本的なネットワークを確認してください。プロキシ接続だけが失敗する場合は、次の章に進みます。明示的なプロキシ接続では成功し、通常のアプリでは失敗する場合は、システムプロキシが機能しない場合を確認してください。設定の追加や有効化の手順を見直す場合は、サブスクリプションの追加手順に戻ってください。原因を切り分けずに再インストールを繰り返しても解決にはなりません。

ノードがタイムアウトする：接続経路を確認する

ノードの速度テストで「タイムアウト」と表示されても、制限時間内にテストリクエストが完了しなかったことを示すだけで、サービスの停止とは限りません。テスト結果は、接続先、名前解決、プロトコルのハンドシェイク、接続先からの応答にも左右されます。まずログを開き、同じ時刻のエラー全体を確認して、ノードサーバー、DNSの上流サーバー、テストサイトのどこへの接続で起きたかを切り分けてください。特にエラーに表示された接続先を確認します。コアからノードへの接続失敗と、ノードから接続先への通信失敗では、次に行う対処が異なります。

エラーが起きた段階から原因を絞り込む

dial tcp はTCP接続を確立するときの処理を示し、主な手がかりはその後に続く内容です。connection refused は、接続先のポートでサービスが起動していない、または接続を明示的に拒否された場合によく見られます。i/o timeout は、いずれかの処理がタイムアウトしたことを示します。接続先と前後のログも確認してください。no such host の場合は、まず名前解決を確認します。すべてのエラーをポートの競合と決めつけないでください。ローカルポートの競合は通常、起動ログに待ち受け失敗として明記されます。

同じネットワーク、同じテスト先で、別の出口を手動選択して比較します。1つだけ失敗する場合は、その設定の期限切れ、サーバーポートの変更、サービスの稼働状況を優先して確認してください。すべての出口で同時に失敗する場合は、同じサーバー名、サブスクリプションアカウント、上流ネットワークを共有していないか確認します。複数の出口が表示されていても、実際には同じ障害箇所に依存していることがあります。数が多いだけでは、独立した比較にはなりません。

名前解決、ポート、プロトコルのハンドシェイクを個別に確認する

ノードのホスト名をシステムで名前解決すると、名前自体を解決できているか確認できます。ただし、システムの問い合わせ結果がコアで使われる結果と同じとは限りません。ポートの疎通テストで分かるのは、特定のTCPポートに接続できるかどうかだけです。パスワード、プロトコル設定、その後のプロキシリクエストが有効かは確認できません。Windowsでは Test-NetConnection を使って実際のサーバーとポートを確認できます。ローカルの 7890 のテスト結果を、リモートノードが正常である根拠にしないでください。

TCP接続はできてもTLSやプロトコルのハンドシェイクに失敗する場合は、サーバー名、端末の時刻、サブスクリプションに含まれる元のパラメーターを確認してください。server、servername などのハンドシェイク関連項目を手動で変更した場合は、まず提供元の設定に戻します。証明書の検証やサーバー側の経路制御にドメイン名が使われることがあるため、安易にドメイン名をIPアドレスへ置き換えないでください。エラーを隠すために証明書検証をスキップする設定を有効にするのも避けましょう。セキュリティ上の前提が変わるうえ、原因が解決するとは限りません。

タイムアウトを延ばし続けず、ネットワークを変えて比較する

可能であれば、クライアント、設定、テスト先を変えずに、スマートフォンのテザリングと元のネットワークで比較します。テザリングでは正常で元のネットワークでは失敗する場合、ルーターの制限、ネットワークの出口、UDPの制限を確認する理由があります。Webサイトにはアクセスできても、UDPを使うアプリだけが失敗する場合は、選択したノードとプロトコルがその通信に対応しているか確認してください。通常のTCP速度テストに成功しても、UDPを使うサービスのテストにはならず、すべてのアプリが正常とは限りません。

速度テストの待ち時間を適度に延ばすと、応答が遅いのか、接続できないのかを切り分けられますが、認証情報の誤りや到達できない経路は直りません。テスト先自体にアクセスできない場合は、用途に合った安定した接続先に変更し、HTTPステータスを判定しているのか、別の方法で判定しているのかも確認してください。エラー全体の読み方は、実行ログのエラー内容と意味を参考にしてください。問い合わせ時は、「すべてタイムアウト」と表示された画面だけでなく、個人情報を隠したログ、失敗した段階、ネットワークを変えて比較した結果も添えると原因を特定しやすくなります。

サブスクリプションの更新失敗：ダウンロードと読み込みを切り分ける

サブスクリプションの更新失敗は、URLからダウンロードできない場合と、内容は取得できたものの読み込めない場合に分けて考えます。「プロファイル」画面で一度だけ更新し、HTTPステータス、解析エラー、発生時刻を確認してください。何度も更新ボタンを押しても新しい情報が増えるとは限らず、サーバー側のレート制限にかかることもあります。現在使用できる設定を保存しておき、新しいサブスクリプションを検証する前に古い設定を削除しないでください。URL全体を公開の問い合わせ欄に貼り付けるのも避けてください。

ダウンロードできない場合はURL、権限、接続経路を確認する

サービス提供元のページから、クライアント用のサブスクリプションURLをコピーし直します。先頭や末尾の空白、改行、日本語の句読点、コピー時に混入した説明文がないか確認してください。サブスクリプションURLはアカウント管理ページのURLとは限らず、ブラウザーのアドレスバーに表示されているURLとも限りません。アカウントを識別するパラメーターを含むURLは、再発行後に使えなくなることがあります。新しいURLを発行したら、クライアントに保存したURLを更新してください。設定名だけを変更しても、実際のダウンロード先は変わりません。

401 または 403 が表示された場合は、利用資格、URLの有効性、サービス提供元の制限を確認します。404 ではパスを優先して確認してください。429 の場合は、繰り返しリクエストせず、提供元の案内に従って待ちます。サーバー側のエラーはYAMLを変更しても解決できません。ブラウザーでURLを開けても、ダウンロードの問題がないとは限りません。ブラウザーはログインセッションを使っていても、クライアントからのリクエストは別で、異なる内容が返る場合があります。

更新リクエストが現在のプロキシに依存しているかも確認します。クライアントによっては、直接接続またはプロキシ経由で更新する設定がありますが、名称や初期動作はそれぞれ異なります。以前の出口が使えなくなり、サブスクリプションの更新もその出口経由になっていると、更新に失敗したプロキシに依存する状態になります。利用できるネットワークから直接更新するか、動作を確認済みの出口を一時的に選択してください。サブスクリプションをダウンロードするために証明書検証を安易に無効にしたり、URLを見知らぬオンライン変換サービスに渡したりしないでください。

読み込みに失敗した場合は、実際の形式とエラー行を確認する

ダウンロードに成功しても、内容が現在のクライアントに適した形式とは限りません。返されるデータはYAML設定、プロトコルURLの一覧、ログインページ、エラーの説明などの場合があります。yaml: unmarshal errors や cannot unmarshal などのメッセージは、行番号と合わせて構造を確認してください。内容の先頭がHTMLタグなら、行ごとに書き換えるのではなく、サブスクリプションURLやアクセス権限を見直します。Base64形式のテキストも、拡張子を .yaml に変えるだけでは完全な設定ファイルになりません。

# 階層構造のみを示す例。ノード情報は含まず、完全なサブスクリプションの代わりにはなりません
mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAMLのインデントにはスペースを使い、Tabは混ぜないでください。リスト項目にはハイフンを付け、フィールドのコロンの後には通常スペースが必要です。エラー行は、パーサーが問題を検出した位置にすぎない場合もあります。実際の原因である引用符や階層の不足は、1行前にあるかもしれません。プロキシグループを参照する場合は、名称が定義と完全に一致している必要があります。サブスクリプションに現在のコアが対応していないプロトコルやフィールドが含まれる場合は、提供元に対応形式を問い合わせるか、互換性のあるクライアントを選んでください。未知のフィールドを削除しても、設定が元と同じ動作になるとは限りません。

更新後は有効化と設定の反映も確認する

「更新成功」と表示されたら、更新した設定が現在有効になっていることを確認し、プロキシ画面で必要なプロキシグループがあるか確認してください。クライアントによっては、「サブスクリプションのダウンロード」「プロバイダーの更新」「コアの再読み込み」が別の操作です。キャッシュが残っていると、一覧に変化がないように見える場合もあります。新しい設定の出口が実際の接続ログで使われたことを確認して、初めて更新完了です。画面に表示された最終更新時刻だけで判断しないでください。

サブスクリプションの生成ファイルに修正を直接書き込むと、次回の更新で上書きされる場合があります。ポート、DNS、ルールの変更を継続して使う場合は、クライアントが対応するオーバーライド、マージ、拡張設定の機能を使い、適用順も先に確認してください。形式の詳しい見分け方は、サブスクリプションの追加とYAML・Base64形式の解説をご覧ください。初回の追加手順ははじめにに沿って進めてください。クライアントを変更する場合は、ダウンロードページのClash Plusから、利用するプラットフォームへの対応を確認できます。ただし、有効なサブスクリプションや適切な権限の代わりにはなりません。

速度が遅い：ルールと接続経路を確認する

まず「遅い」の内容を具体的にします。ページの応答開始が遅いのか、ダウンロード速度が低いのか、動画が何度もバッファリングするのかで、DNS、接続時のハンドシェイク、出口の混雑、アプリ側の制限など原因が異なります。時間を近づけて、同じ接続先、同じファイル、同じ出口で比較してください。クラウドストレージの同期、システム更新、大容量通信も一時停止します。異なるサイトの結果を比較材料にしたり、一度の速度テストが速かったことから長時間の通信も安定すると判断したりしないでください。

出口を確認してから、接続速度と転送速度を比較する

「接続」画面で遅いリクエストを見つけ、適用されたルール、プロキシグループ、実際に使われたノードを確認します。サイトのトップページとダウンロードファイルでドメインが異なる場合、トップページがプロキシ経由でも、ファイルが同じ出口を通るとは限りません。ポリシーを切り替えても、既存の接続は以前の出口を使い続けることがあります。対象アプリを終了するか、該当する接続だけを切断してから新しいリクエストを送信してください。テストのたびにプロキシグループ全体を何度も切り替えると、条件が変わって比較できなくなります。

ルールモードでは遅く、グローバルモードでは正常な場合、対象ドメインに適切でない直接接続ルールが適用されていないか、関連するドメインが異なる出口に分散していないかを確認します。両方のモードで遅い場合は、ノードとローカルネットワークを確認してください。特定のサイトだけが遅い場合は、出口IPに対するサイト側の速度制限、CDNの割り当て、地域差も考えられます。すぐにクライアントを変更するのではなく、別の出口から同じリソースにアクセスして、サイトまでの経路とソフトウェア設定を切り分けてください。

GeoIPの更新：関連するルールだけを修正する

GEOIP は、接続先IPアドレスの地域に基づいてルールを適用するためのもので、通信品質を測定するものではありません。地理データベースのダウンロードや読み込みに失敗したというログが出た場合は、現在の設定で使われているデータの種類と、クライアントが実際に使用するデータディレクトリを確認します。コアによってデータベースのファイルや読み込み方法が異なる場合があるため、ネット上で見つけたファイルを安易にリネームして上書きしないでください。更新機能は通常「設定」「コア」または地理データ関連の画面にあります。項目名はクライアントによって異なります。

更新後はログを確認し、ダウンロードの完了と再読み込みの成功を確かめてください。ダウンロード開始の表示だけでは完了ではありません。更新先にアクセスできない場合は、まずダウンロード経路を修復してから、クライアントの更新機能で再試行します。根拠なく配布元URLを置き換えたり、読み込み可能な古いデータベースを削除して更新を強制したりしないでください。ルールプロバイダーを使っている場合は、該当するルールセットも別途更新する必要があります。GeoIPデータとリモートのルールセットは別のリソースです。

データベースの更新後、遅かったリクエストを新しく発行し、ルールが想定どおりに適用されるか確認します。IPアドレスの地域判定は、データの更新時期やCDNの境界によって異なることがあります。特定の接続先に問題が残る場合は、用途を確認したうえで対象範囲を絞ったドメインルールを追加し、広い範囲のルールより前に配置できます。以下の例は順序のみを示します。Proxy は既存の設定で定義されているプロキシグループである必要があります。存在しない場合は実際の名称に変更してください。そのままコピーしても出口が自動的に作成されるわけではありません。

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

Wi-Fi、UDP、通信経路も確認する

同じ端末でどの出口を使っても遅い場合は、有線接続にするかルーターに近づいて再テストし、スマートフォンのテザリングとも比較します。Wi-Fiの干渉、ルーターの負荷、上り回線の混雑も、プロキシが不安定になる原因です。TUNを有効にしたときだけ遅い場合は、まずTUNを無効にし、明示的なプロキシで同じ接続先を確認します。差が安定して再現する場合は、仮想ネットワークアダプター、ルートの競合、MTUを確認してください。固定のMTU値をそのまま適用せず、元の値を記録し、元に戻せるようにして1項目ずつ変更します。

アプリによってはQUICを優先して使うため、UDPが制限されていると何度も待たされることがあります。その一方で、通常のWebサイトへのTCP接続は正常に見える場合があります。アプリで設定できる場合は、該当機能を一時的に無効にして比較します。ただし、UDPをすべて無効にする方法を一般的な速度改善策として使わないでください。ネットワーク、出口、ルール、接続先、発生時間帯を記録し、再現できる結果を残します。プロキシグループの選択方法はプロキシグループの用語解説を参照してください。名前解決の段階でのみ大きく待たされる場合は、接続タイムアウトを延ばし続けるのではなく、次の章を確認します。

DNSの問題：名前解決の経路を確認する

DNSの問題は、no such host の表示、ドメインにアクセスできない、初回のアクセスに時間がかかる、TUNを有効にすると一部アプリが使えなくなる、といった形で現れます。まず、解決できないのがノードのホスト名、サイトのドメイン名、DNSの上流サーバーのどれかを確認してください。ノードのホスト名を解決できないと、複数のサイトに同時に接続できなくなることがあります。特定の接続先だけが失敗する場合は、そのドメインや上流サーバーに限った問題かもしれません。サイトが開かないからといって、システムDNS、コアのDNS、ブラウザーのセキュアDNSを一度に変更しないでください。どの設定が実際に使われているのか分からなくなります。

システム・ブラウザー・コアの名前解決を切り分ける

システムの nslookup で分かるのは、そのコマンドが実際に問い合わせたDNSサーバーの結果だけです。ブラウザーやコアの結果と同じとは限りません。ブラウザーが独自の暗号化DNSを使っていたり、コアが nameserver-policy に従って特定のドメインを別の上流サーバーに問い合わせたりする場合があります。まず、システムに設定されたDNSを記録し、クライアントのDNS設定と最終的に適用された設定を確認してください。変更後は、オーバーライド機能がサブスクリプションの項目を上書きしていないかも確かめます。ファイルだけ変更しても、実行中の設定に反映されていない場合があります。

安定して再現するドメインを1つ選び、システムの名前解決、ブラウザーでのアクセス、コアのログをそれぞれ確認します。システムでは解決できるのにプロキシ接続に失敗する場合は、コアの上流サーバーと接続経路を調べます。ブラウザーではアクセスできても、ほかのアプリでは失敗する場合は、ブラウザーが独自に名前解決していないか確認してください。システム、ブラウザー、コアでは異なるキャッシュ結果が保存されることがあります。1か所を消去しても、すべてのキャッシュが自動的に消えるわけではありません。キャッシュを消去した後は、新しい接続を開始して確認してください。既存の接続をそのまま見続けないでください。

上流サーバーの接続性は、登録数より重要

暗号化DNSを使う場合、上流サーバーへの接続にもネットワークが必要です。上流サーバーをホスト名で指定すると、その名前を解決するための初期DNSが必要になることもあります。default-nameserver による初期の名前解決と、通常の名前解決に使う nameserver を区別してください。ルールに応じて上流サーバーへの接続経路を選ぶ機能を有効にしている場合は、循環依存がないか確認します。ノード名の解決にはプロキシが必要なのに、プロキシ接続の確立にはノード名の解決が必要、といった状態です。上流サーバーの数を増やすのではなく、コアのドキュメントに従って、ノードのホスト名を解決する独立した経路を設定してください。

以下は、通常のDNS通信を一時的に確認するための例です。すべてのネットワークに共通する推奨設定ではなく、TUNによる通信の取り込みも含みません。これらのフィールドに対応するmihomoの設定でのみ使用してください。マージする前に既存の設定を保存し、ローカルの待ち受けポートが使用中でないことを確認します。通常のUDP DNSはネットワークによって制限や干渉を受けることがあります。このテストの成否はあくまで1つの判断材料であり、暗号化DNSでの通信結果を示すものではありません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Fake-IP、LANの名前解決、DNSの横取りを個別に確認する

Fake-IPを有効にしている場合、合成アドレスが返されるのは正常な仕組みです。ただし、その後の接続も同じコアを通り、対応するマッピングが見つかる必要があります。アプリが合成アドレスを取得した後、TUNを迂回して直接接続すると失敗することがあります。合成アドレスを実際のサーバーアドレスとして別の端末に保存したり、そのIPアドレスに直接アクセスしてサイトの状態を判断したりしないでください。特定の端末の検出やLAN内サービスのために除外設定が必要な場合は、競合が確認できたドメインだけを追加します。すべてのドメインを除外すると、テストの意味がなくなります。

プリンター、NAS、社内ドメインは、ローカルのDNSサーバー、検索サフィックス、マルチキャストに依存することがあります。パブリックDNSはこれらの名前を解決できないため、パブリックDNSへの変更後に使えなくなっても不思議ではありません。ドメインごとのDNSルールがあるか、TUNのルートでLANへのアクセスが許可されているかを確認してください。通常のDNSの横取りでは、アプリ内蔵の暗号化DNSまで制御できるとは限りません。特定のアプリが想定した名前解決経路を使わない場合は、そのアプリの設定を確認し、DNSの横取り範囲をさらに広げないでください。

修正後は、問題が起きたときと同じドメイン、ネットワーク、アプリを使って再テストし、調査中に一時変更したログレベルやテスト設定を元に戻します。まず名前解決を安定させてから、ルーティングや速度の問題を調べると、キャッシュに偶然残っていた結果を修正と誤認しにくくなります。フィールドの階層や設定の優先関係は、config.yamlのport、dns、rulesを解説で確認できます。DNSが正常なのに接続ログがない場合は、名前解決の設定を変更し続けず、次の通信の取り込みに関する章を確認してください。

システムプロキシが機能しない：通信が取り込まれているか確認する

「システムプロキシが有効」と表示されていても、端末上のすべてのアプリがClashを経由するとは限りません。システムプロキシは通常、対応するアプリにHTTPなどのプロキシ設定を提供します。独自に接続を確立するアプリ、個別のプロキシ設定を使うアプリ、システム設定を参照しないプログラムは、直接接続することがあります。まず最初の章の明示的なプロキシ接続テストでローカルサービスが使えることを確認し、問題のアプリがどの方法で通信を取り込むのか確認します。明示的なプロキシ接続も失敗する場合は、システム設定の切り替えを繰り返すのではなく、コアとポートを先に修復してください。

システムに設定されたアドレスとポートを確認する

クライアントで混合ポートまたはHTTPポートを確認し、システムのネットワークプロキシ設定でホスト名とポートが一致しているか確認します。ローカル端末では通常 127.0.0.1 を使い、ノードのサーバーアドレスは使いません。external-controller は制御用インターフェースであり、ブラウザー用のプロキシポートではありません。9090 をプロキシポートに設定すると接続できません。HTTPとSOCKSのプロトコルも一致させてください。両方を受け付ける混合ポートを使っている場合は例外です。

Windowsでは、ユーザーのプロキシ設定と、一部のサービスが使うWinHTTPプロキシを区別してください。1つの画面にあるスイッチで、もう一方も変更されるとは限りません。macOSでは現在有効なネットワークサービスを確認します。Wi-Fiと別のネットワークアダプターで設定が異なることがあります。Linuxのデスクトップ環境のプロキシ設定も、すべてのプログラムで読み込まれるとは限りません。古いアドレスが残っている場合は、どのアプリが設定したのかを確認してから該当する画面で修正してください。インターネット上のリセットコマンドをそのまま実行し、業務用ネットワークに影響を与えないようにしてください。

ポートの競合とアプリ側の設定を分けて確認する

起動ログに address already in use や bind の失敗が表示される場合は、まずポートを使用しているプロセスを確認します。Windowsでは下のコマンドで待ち受け状況を調べ、タスクマネージャーでプロセスを特定してください。PIDが表示されても、使用中のサービスである可能性があるため、すぐに強制終了しないでください。ポートを変更する場合は、クライアント、システムプロキシ、手動で設定したアプリのポートをすべて合わせて変更し、最後に接続を再起動します。

netstat -ano | findstr :7890

ターミナルでは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY を参照することがあります。ブラウザーの拡張機能がシステムプロキシを上書きする場合もあります。まずアプリ側の設定をシステムに追従させるか、ローカルプロキシを明示的に指定して比較します。環境変数を変更しても、以前から起動していたターミナルやアプリには古い値が残っていることがあります。再起動して確認してください。プロキシの除外リストにあるドメインも接続結果に影響します。ワイルドカードやアドレス範囲も確認しましょう。

必要な場合にだけTUNを追加してテストする

明示的なプロキシ接続は正常で、対象アプリがシステムプロキシに対応していない場合に限り、TUNを個別にテストします。必要なサービスや権限が有効になり、仮想インターフェースとルートが作成されたことを確認してください。スイッチがオンでも、コアのログにエラーがある場合は通信の取り込みが完了していません。別のVPN、仮想マシンのネットワーク、コンテナーのネットワーク範囲がTUNのルールと競合する場合があります。元のルートと除外範囲を記録し、競合するツールを1つずつ停止して比較します。ルートテーブル全体を消去しないでください。

LANからの接続許可と、この端末のシステムプロキシは別の設定です。ローカル端末から使うだけなら、通常 allow-lan を有効にする必要はありません。他の端末からこの端末のプロキシを使う場合に限り、待ち受けアドレス、ファイアウォールの範囲、信頼できるネットワークの境界を確認してください。他の端末には、このPCのLAN内アドレスを入力します。各端末自身の 127.0.0.1 ではありません。ポートの基本的な使い方はポート設定ガイドを参照してください。起動時に有効にならない場合は、起動時の自動実行に関するFAQも確認し、コアが実際に起動しているか調べてください。

クライアントがクラッシュする：状況を記録してから復旧する

まず、画面が終了したのか、画面がフリーズしたのか、コアが停止したのかを切り分けます。ウィンドウが消えてもプロキシのコアが動いていることがあり、ウィンドウが表示されたままでもコアが終了していることがあります。プロセス一覧、待ち受けポート、直近のログを確認して、問題の範囲を判断してください。端末全体の通信に異常がある場合は、クライアントのデータを調べる前にシステムプロキシとTUNを元に戻し、基本的なネットワークを使える状態にします。「アンインストールして再インストール」を最初に行うと、再現条件やエラー記録まで失うおそれがあります。

問題が起きる前後の状況を必要最小限で保存する

起動方法、起動時・サブスクリプション更新時・特定の画面を開いたときのどの段階で問題が起きたか、その直前に設定を切り替えたかを記録します。ログファイルは前後の時刻が分かる状態でコピーしてください。最後の1行だけではなく、設定エラーより前のメッセージが重要なこともあります。ログにパス、サーバー名、接続先が含まれる場合は、共有前に個人情報を隠してください。システムイベントやクラッシュレポートにユーザーフォルダーが含まれる場合もあるため、生の資料をそのまま公開しないでください。

毎回同じ設定の読み込み中に終了する場合は、まずクライアントのデータディレクトリをバックアップし、ソフトウェアが提供する設定の無効化または復元機能を使います。画面を開ける場合は、読み込み可能と確認済みの設定に切り替え、クラッシュが続くか比較してください。画面を開けない場合は、クライアントのドキュメントに従って設定の選択状態を変更し、内容の分からないファイルを推測で削除しないでください。カスタムルールプロバイダー、大きな設定ファイル、破損したキャッシュなどが関係する場合があります。一度に調べる対象は1種類にし、元に戻せるコピーを残してください。

インストーラー、コア、システム権限を分けて確認する

クライアントのダウンロードページで、端末のOSとプロセッサーアーキテクチャを確認し、各プラットフォーム向けのClash Plusのインストール手順を優先してください。Clash Verge RevやFlClashを選ぶ場合も、パッケージ形式がシステムに合っているか確認します。別のクライアントのプログラムディレクトリを上書きしたり、コアのファイルだけを置き換えて互換性に期待したりしないでください。画面とコアでは、制御インターフェースや設定の生成方法が異なる場合があり、混在させると問題を再現しにくくなります。

Windowsでは、セキュリティソフトの実際のブロック記録と、必要なバックグラウンドサービスが起動できるかを確認します。信頼できると確認できた項目が誤検知された場合に限って対処し、原因調査のために端末全体の保護を恒久的に無効にしないでください。macOSでは配布元とシステムの警告を確認してから、システム画面で必要な機能を許可します。すべてのクライアントが同じネットワーク拡張機能を使うわけではありません。関連するダイアログはmacOSの権限とキーチェーンの対処方法を参考にし、システム保護を回避するコマンドを一律に実行しないでください。

Linuxでは、まずターミナルから対象のプログラムを起動し、不足している依存関係、表示環境、権限のエラーを確認します。デスクトップアプリとサービスプロセスでは、環境変数、作業ディレクトリ、ユーザー権限が異なる場合があります。「ターミナルからは起動するが、メニューからは失敗する」場合は、起動環境を比較してください。システムサービスとして動作させる場合は、サービス管理ツールの出力を確認し、設定ファイルの場所と読み取り権限を調べます。通常の画面操作では一般ユーザーとして実行し、明確な機能上の必要がある場合に限り権限を付与してください。

データをすべて消去せず、段階的に復旧する

キャッシュの問題は、クライアントに備わっている削除機能で対処できますが、キャッシュ、サブスクリプション、設定、認証情報を区別してください。ユーザーデータを再作成する必要がある場合は、画面と関連するバックグラウンドプロセスを終了し、元のディレクトリをすぐ削除せず、バックアップとして別の場所に移動します。新しいデータで起動した後は、必要な設定を1つだけ追加し、古い設定をすべて戻さないでください。正常動作を確認してから、オーバーライド、ルールセット、起動オプションを1つずつ戻せば、問題の原因を特定できます。

復旧後は、ウィンドウが開くかだけでなく、問題を起こした操作を少なくとも1回再現してください。サブスクリプションを更新し、設定を再読み込みして、実際に接続を確立します。問題が続く場合は、クライアント名、システムのアーキテクチャ、再現手順、個人情報を隠したエラー内容を共有し、新しいデータで起動した場合も発生するか記載してください。確認できないバージョン情報を推測したり、一度だけの終了を特定のプロトコルのせいにしたりしないでください。画面の各機能に慣れていない場合は、クライアント画面の機能別ガイドで設定画面やログの場所を確認できます。

モバイル：権限・バックグラウンド・ネットワーク切り替え

モバイルでは、接続直後に失敗する、画面ロック後に切断する、Wi-Fiからモバイルデータに切り替えると失敗する、の3つに分けて確認します。主にそれぞれVPNの許可、バックグラウンド制限、ネットワーク切り替え後の再接続を調べます。まず1つのネットワークに固定してテストし、VPN接続を使うほかのアプリを終了してから、対象のクライアントを起動してください。一般的なモバイルOSでは、同時に利用できる主要なVPN接続は通常1つです。広告ブロック、企業ネットワーク接続、ほかのネットワークツールがプロキシと競合することがあります。ウィンドウが開いているかどうかだけでは判断できません。

Android：権限、アプリの対象範囲、バックグラウンドを確認する

Androidでは初回接続時に、通常システムのVPN接続許可が表示されます。拒否した場合は、再度接続を開始して許可してください。画面上でノードが選択されていても、VPN接続が確立したとは限りません。システムで「常時接続VPN」や「VPNを使わない接続をブロック」が有効になっている場合は、現在のクライアントに設定されているか確認します。以前のクライアントを停止してもシステムの制限が残っていると、端末全体がネットに接続できなくなることがあります。仕事用プロファイルと個人用プロファイルは管理範囲が異なり、企業のポリシーで通信の取り込みが制限されている場合もあります。通常のアプリ設定で強制的に変更しないでください。

一部のアプリだけがプロキシを使わない場合は、アプリごとのプロキシ設定、迂回リスト、対象を含めるモードと除外するモードのどちらを使っているかを確認します。対象のアプリを誤って除外リストに入れた場合、ノードの障害とは異なる状態になります。まず接続ログにリクエストが記録されているか確認してください。アプリ独自のプロキシ設定や暗号化DNSも調べます。UDPに依存するアプリでは、Webページを開けても音声通話、ゲーム、リアルタイム通信が使えるとは限りません。対象となる機能を実際に使って確認してください。

画面ロック後に切断する場合は、クライアントに対するバッテリー最適化、バックグラウンド動作、自動起動の制限を確認します。必要なバックグラウンド接続を許可し、通知領域の状態とログを確認してください。端末メーカーによって設定項目の名称は異なるため、設定画面で該当項目を検索し、別の端末の手順を推測で当てはめないでください。バックグラウンド制限を解除しても切断する場合は、ネットワークの切り替えと同時に発生するか、プロセスが終了したのか、VPN接続は維持されているのに通信できないのかを記録します。それぞれ対処が異なります。

iOS：接続状態とサブスクリプションの有効性を確認する

iOSではダウンロードページからClash PlusのApp Storeページに進めます。公式サイトの入口はclashplus.ioです。初めて使う場合は、まずシステムのVPN構成を許可し、アプリに戻って現在の設定とプロキシの選択を確認してください。システムにVPNアイコンが表示されるのは接続状態を示すだけで、サブスクリプションが有効であることや、リモートサーバーに接続できることを保証しません。実際のリクエストとアプリのログで確認してください。システムのアイコンだけでノードが正常だと判断しないでください。

接続後にすべてのサイトへアクセスできない場合は、まずVPN接続を停止して元のネットワークを確認し、サブスクリプション、名前解決、出口の順に調べます。特定のWi-Fiでのみ失敗する場合は、ログイン用Webページでの認証が必要か、接続方式に制限があるか確認してください。端末が企業の管理下にある場合、VPNの設定が管理ポリシーによって制御されていることがあります。組織のルールに従って対処してください。用途の分からない管理設定を削除してテストしたり、業務ネットワークの問題をクライアントの権限不足だけで説明したりしないでください。

ネットワーク切り替え、テザリング、通信量は同じ条件で比較する

Wi-Fiからモバイルデータに切り替えると、以前の接続、DNSキャッシュ、NATの対応付けが使えなくなることがあります。まずシステムのネットワークが安定するのを待ってから、VPN接続を停止して再起動し、対象のアプリを開いて新しい接続を確立します。切り替えのたびに同じ問題が起きる場合は、それぞれのネットワーク単独で接続できるか、どちらの方向に切り替えたときに発生するかを記録してください。モバイルデータ自体に接続できないのか、クライアントが接続を再確立できていないのかを切り分けられます。最初から設定全体を削除する必要はありません。

スマートフォン本体でプロキシを使えても、テザリング先の端末が自動的に同じ接続を使うとは限りません。テザリングの転送と本体のVPN接続はシステム上の扱いが異なるため、接続先の端末で個別に確認してください。スマートフォンで開けたページだけを根拠に判断しないでください。モバイルデータの料金や通信量の扱いは携帯電話会社の契約によって決まります。プロキシを使っても契約条件は変わりません。通信量が増えた場合は、まずシステムのアプリ別通信量を確認し、バックグラウンド更新や大きなファイルのダウンロードを調べます。クライアントの接続記録の合計を、そのまま請求上の通信量とみなさないでください。

修正後は「現在のネットワークでアクセス」「画面ロック後の復帰」「ネットワーク切り替え後に新しい接続を確立」の3段階で再テストし、調査中に一時変更した設定を元に戻してください。それでも失敗する場合は、ネットワークの種類、VPN接続の状態、発生時刻、個人情報を隠したログを保存し、該当するタイムアウトまたはDNSの章に戻って原因を調べます。再現手順が明確になってから、クライアントを変更する必要があるか判断してください。再インストールでは、サブスクリプションの権限、バックグラウンド制限、実際の接続経路を確認する代わりにはなりません。