症状の特定 / 設定の確認 / 復旧の検証

Clash トラブル対処ガイド

このページでは、接続に問題が起きたときの確認手順をまとめています。初回インストールやサブスクリプションの追加、ルールモードの選択については、まずClash 設定ガイドに沿って初期設定を完了してください。設定済みなのに期待どおりに動作しない場合は、以下から該当する症状を選んで確認します。初期設定とトラブル診断を分けて、通常の操作と復旧手順が混在しないようにしています。

確認を始める前に、クライアント名、実際に使用しているコア、OS、接続ネットワーク、現在のモード、エラーが発生した時刻を記録してください。復元できるローカル設定を保存し、一度に変更する項目は一つに絞って、同じ条件でテストします。拡張フィールドについては、mihomoを使用するクライアントを主な例として説明します。画面上のスイッチ名はクライアントによって異なるため、名前だけで互換性を判断せず、実際に適用されている設定を確認してください。

接続できない：問題の発生箇所を切り分ける

まず通常のインターネット接続を確認

クライアントのシステムプロキシとTUNをオフにし、クライアントを終了してから、普段直接アクセスできるサイトをブラウザーで開きます。公衆Wi-Fiではログイン画面での認証が必要な場合があります。LANケーブルがつながっていることや、Wi-Fiアイコンが表示されていることだけでは、インターネットに接続できているとは限りません。この時点で接続できない場合は、ルーターや認証状態、ほかの端末の接続状況を確認してください。基本のネットワークが復旧する前にノードを次々と切り替えると、同じ根本原因が残ったまま各テストに影響します。

クライアントを終了しても直接接続できない場合は、システムにローカルプロキシの設定が残っていないか、ほかのVPNがまだルーティングを制御していないか確認します。正常に終了しても、他のプログラムが変更した設定まで元に戻るとは限りません。元の値を記録してから、使っていない手動プロキシを解除してください。組織が管理する端末では、管理者のポリシーに従います。ネットワークアダプターをすべてリセットするのは避けてください。業務用ネットワークの固定アドレスや専用ルートまで削除されることがあります。

ローカルの待ち受けとプロキシの出口を確認

クライアントを再起動し、設定は一つだけ読み込んで、まずTUNをオフにします。コアが正常に起動しているか、mixed-portの実際の値はいくつかを確認してください。以下のコマンドは、ローカルの7890番ポートで待ち受けている想定です。画面に別のポートが表示されている場合は、その値に合わせて変更します。Windowsでは、ターミナルによって別のツールとして解釈されるのを避けるため、curl.exeを使用できます。テスト用URLは同じ条件で比較するためのもので、すべてのサイトへの接続性を示すものではありません。

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

プロキシを明示してすぐに接続拒否になる場合は、リモートノードではなく、まずローカルの待ち受けを確認します。よくある原因は、コアが起動していない、ポート番号が違う、別のクライアントがポートを使用していることです。ローカルポートには接続できるものの、その後リモートからの応答がタイムアウトする場合は、リクエストが次の段階まで進んでいます。接続ログで宛先、出站ポリシー、ハンドシェイクのエラーを確認してください。発生箇所が異なるため、対処方法も別です。

モードとルールを一つずつ切り分ける

ローカルの待ち受けが使えることを確認したら、ルールモードでテストリクエストが実際にどのルールに一致したかを調べます。短時間の比較にはグローバルモードを使い、利用可能と確認済みの出站を選んで、テストURLは変えずに試してください。グローバルモードでは成功し、ルールモードでは失敗する場合は、サブスクリプションを変更するのではなく、ルールの順序、プロキシグループの選択、DIRECTの出口を確認します。グローバルモードでも不調なノードは直せません。テスト後は元のモードに戻してください。

プロキシグループに名前が表示されていても、有効なメンバーが選択されているとは限りません。グループが実在するノードやプロバイダーを参照しているか、サブスクリプションの更新で名前が変わり、参照先が無効になっていないか確認します。ルールは上から順に評価されます。前方の広いDIRECTルールが宛先を先に捕捉していないか、最後のフォールバックが実在するポリシーを指しているかも確認してください。ルール全体を一度に置き換えず、接続ログで一致したルールを確認してから、必要最小限の範囲を変更します。

復旧後は、ブラウザー、新しく開いたターミナル、最初に失敗したアプリをそれぞれテストします。ブラウザーだけ成功し、ほかのアプリで失敗する場合は、プロキシへの接続方法も確認してください。ドメイン名を使うリクエストだけ失敗する場合は、DNSの項目へ進みます。安定して再現できない場合は、スリープから復帰した直後か、ネットワークを切り替えた直後か、別のネットワークツールが動作していないかを記録してください。「有効にしたのに使えない」と繰り返すより、こうした条件のほうが原因の特定に役立ちます。

ノードのタイムアウト：通信とハンドシェイクを確認

速度テストの失敗と実際の通信障害を区別

クライアントの遅延テストは、通常、指定されたURLへの経路を測定します。その結果がすべての通信の状態を示すわけではありません。テスト先が制限されている、リダイレクトされる、一時的に利用できない場合、ノードがタイムアウトしても一般のWebサイトには接続できることがあります。反対に、テスト成功が示すのは軽量なリクエストが完了したことだけで、動画の再生、アップロード、長時間接続の安定性までは保証しません。ノードが使えないと判断する前に、実際に問題が起きたアプリで再テストしてください。

まず同じネットワークで複数のノードを比較し、次に同じノードを別の信頼できるネットワークで試します。一つのノードだけ失敗する場合は、そのノードのサーバー状態や設定を優先して確認します。現在のネットワークで全ノードが失敗し、別のネットワークでは成功する場合は、接続ネットワークの制限やルーティングの問題が考えられます。比較中はクライアントのモードと設定を変えず、差がネットワークによるものか設定によるものか分かるようにします。

接続の段階ごとにログを確認

クライアントのログ画面を開き、一時的にログレベルを上げてからリクエストを一度だけ実行し、関連する行をすぐに記録します。解析エラーはサーバーアドレスを取得する前に発生します。接続タイムアウトは通常、通信の確立中に起きます。ハンドシェイクエラーはプロトコルのネゴシエーションまで進んだ状態です。リモート側の切断、認証失敗、証明書エラーも、単にネットワークが遅いとは限りません。最初に発生したエラーを確認してください。その後に続くエラーは、最初の失敗による連鎖反応の可能性があります。

症状優先して確認次の手順
サーバードメインを解決できないノードのドメインとブートストラップDNSDNSログとサーバーアドレスの入力を確認
接続がタイムアウトする、または拒否されるサーバーポート、ルーティング、サービスの状態ノードを固定して接続ネットワークを切り替えて比較
認証またはハンドシェイクに失敗するプロトコルの項目、時刻、証明書、コアの対応状況サブスクリプションの提供元と互換性のある設定を確認
速度テスト時だけタイムアウトするテスト先と測定方法実際のアプリのリクエストで確認

TLSを使う接続では、まずシステムの日付、タイムゾーン、自動時刻設定が正しいか確認します。次にサーバー名やトランスポートの種類、パスなどの項目がサーバー側の設定と一致しているか確認してください。サーバーアドレスと証明書の検証に使う名前は、同じ文字列とは限りません。推測で互いに置き換えないでください。証明書エラーが出ても、検証を無効にする方法を万能な修正策として使わないでください。設定ミスを見えなくし、接続先の認証も弱めてしまいます。

プロトコルの対応状況とテスト条件を確認

トランスポートによってはUDPを使います。現在のネットワークでは通常のWeb通信ができても、UDPが制限されている場合があります。その場合はローカルポートだけを変更するのではなく、サービス提供元が用意している別のトランスポートを比較します。これだけでUDPを使うアプリがすべて利用できないと判断しないでください。ノードプロトコルの基盤となるトランスポートと、プロキシ経由でアプリが使うトランスポートは別の層です。対応状況とルールを個別に確認してください。

古いコアでは、サブスクリプションに含まれる新しいプロトコル項目を認識できないことがあります。ログに未対応の種類が明記されている場合は、クライアントが実際に使用しているコアを確認してから、対応クライアントまたは互換性のあるサブスクリプション形式を選んでください。ダウンロードページでClash Plusを優先して確認するか、OSに合ったメンテナンス中のクライアントを選べます。コアの関係や設定項目の違いはClashオリジナル版・Meta・mihomoのコア比較を参照してください。設定ファイルの拡張子だけで互換性を判断しないでください。

短時間に大量の並列テストを繰り返すと、ローカルネットワークやリモートサービスに負荷がかかり、かえってタイムアウトが増えることがあります。自動テストを一時停止し、ノードを一つに固定して、既存の接続が終了してから少数のリクエストを送信してください。サービス提供元に問い合わせる場合は、機密情報を伏せたエラーの段階、接続ネットワークの種類、再現時刻を伝え、認証情報は公開しないでください。修復後は軽量リクエストと継続的な接続の両方を確認し、テスト用の接続先だけが復旧した状態ではないことを確かめます。

サブスクリプションを更新できない：取得と解析を切り分ける

設定が実際に取得できているか確認

サブスクリプションの更新失敗は、大きく二つの段階に分かれます。URLからコンテンツを取得できない場合と、取得した内容を現在のクライアントで読み込めない場合です。更新時の表示やログを確認し、DNSの名前解決、接続タイムアウト、アクセス拒否、設定の解析エラーのどれに当たるか特定します。サブスクリプション一覧に古いノードが残っていても、更新に成功したとは限りません。以前の設定がキャッシュとして保持され、画面上では使える状態のままでも、リモートからの更新が成功しているとは限りません。

サービス提供元の管理ページからサブスクリプションURLをコピーし直し、空白、改行、チャットアプリが追加した句読点が含まれていないか確認します。URLのクエリパラメーターが認証に使われている場合があり、任意に削るとリクエストが失敗します。システムのクリップボードを使う際は、ほかのアプリが内容を読み取る可能性にも注意してください。確認のために、不明な変換サイトへURLを送信しないでください。URLを公開してしまった場合は、サービス提供元の管理機能からサブスクリプションの認証情報を更新してください。

アクセス拒否は必ずしもクライアントの問題とは限らず、サブスクリプションの期限切れ、通信量の条件、アクセス頻度、サーバー側のポリシーが原因の場合もあります。URLを開いてログイン画面、エラー説明、Web認証画面が表示されるのはWebページの取得には成功していますが、設定の取得に成功したわけではありません。確認するのは応答の種類とエラー内容だけで十分です。応答全体を共有する必要はありません。一時的なアクセス制限が疑われる場合は、更新ボタンを何度も押さず、サービス提供元の案内に従って待つか、アカウントの状態を確認してください。

設定の種類と更新方法を確認

完全な設定ファイル、ノード一覧、ルールセットはそれぞれ別のものです。完全な設定ファイルにはポート、プロキシグループ、ルールを含められます。プロキシプロバイダーには通常ノード情報を、ルールプロバイダーには指定された動作タイプのルールを渡します。ノード一覧を完全な設定ファイルとして読み込むと、ルールやプロキシグループが不足することがあります。完全な設定ファイルをルールセットのURLに指定すると、構造エラーになります。まずサービス提供元がどの種類の入口を用意しているか確認し、クライアントで対応する機能を選んでください。

サブスクリプションの取得にもネットワーク接続が必要です。更新リクエストをプロキシ経由にする設定で、唯一使えるノードが今回の更新に依存していると、起動時に依存関係が循環することがあります。クライアントが対応している場合は、一時的にDIRECTで更新するか、動作確認済みの別の出站に切り替えてください。ただし、サブスクリプションURLがその方法でアクセスできることが前提です。依存関係を解消するために、認証情報を含むURLを第三者に渡して取得させないでください。

解析エラーとローカル上書き設定

YAMLエラーが発生した場合は、まずエラー付近のインデント、コロン、リスト記号を確認します。インデントにはスペースを使い、タブは避けてください。特殊文字を含む文字列は、構文に沿って正しく引用符で囲みます。行番号は解析を続行できなくなった位置を示すことがあるため、その直前の行も確認してください。読み込みを通すためにエラー項目を安易に削除しないでください。認証、トランスポート、ポリシーの関係を担う項目かもしれず、解析エラーが実行時エラーに変わるだけです。

mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

この例はリストの階層とルールの書き方を確認するためのもので、プロキシ出站は含まず、完全なサブスクリプションの代わりにはなりません。元の設定に別の名前のプロキシグループがある場合、ルールではスペースや大文字・小文字を含めて完全に同じ名前を使う必要があります。解析できてもポリシーが存在しないと表示される場合は、ルール、プロキシグループ、ノード、プロバイダーの順に参照先を確認してください。リモート更新で以前の名前が削除されていないかも確認します。

修正前に現在の設定をバックアップし、別のコピーに新しいサブスクリプションを読み込みます。ノード、プロキシグループ、ルールがそろっていることを確認してから切り替え、古いキャッシュや設定を同時に削除しないでください。自動更新だけ失敗し、手動更新では成功する場合は、スケジュール実行がスリープ、バックグラウンド制限、起動時のネットワーク未接続の影響を受けていないか確認します。基本的な用語はよくある質問を参照してください。操作の順序は設定ガイドを確認し、この章ではトラブル時の分岐と復旧の根拠を扱います。

速度が遅い：名前解決とデータ転送を切り分ける

まず、どの段階で遅いかを確認

ページが長時間表示されない、転送開始後も速度が出ない、再生中に定期的に停止する、といった症状は、それぞれ名前解決、接続確立、スループット、接続の安定性に関係する可能性があります。クリックから最初の応答までの時間と、転送開始後も速度が落ち続けるかを記録してください。遅延の表示だけで判断しないでください。軽量なテストでは転送データが少なく、結果が短時間で返っても大容量ファイルのダウンロードが速いとは限りません。反対に、往復時間が長くても継続的な転送速度が必ず低下するわけではありません。

同じ宛先を選び、近い時間帯に同じ端末でテストします。まず、ほかのダウンロード、クラウド同期、システム更新を停止してください。Wi-Fiの電波が弱い、端末がアクセスポイント間を移動している、ルーターの負荷が高いといった状況では、直接接続もプロキシ経由も遅くなります。有線接続やアクセスポイントの近くを比較対象にできますが、一度の比較で端末、ネットワーク、接続先サイト、ノードを同時に変えないでください。変数が多いと、速度が改善しても再現可能な結論を得にくくなります。

実際の出站先と接続の再利用を確認

接続画面で宛先のドメイン、一致したルール、実際の出站を確認します。「自動選択」という名前のプロキシグループでも、現在の接続が想定したメンバーを使っているとは限りません。テスト先と実際の通信先で経路が異なることもあります。ポリシーを切り替えた後も、既存の長時間接続は以前の出站を使い続ける場合があります。ブラウザーの接続プールやアプリのセッションも、すぐに再確立されるとは限りません。テストセッションを閉じるか自然に終了するのを待ってから、新しい条件で比較してください。既存の接続で切り替えの反映を判断しないでください。

自動選択とフェイルオーバーは、目的が異なります。自動選択は通常、テスト結果をもとにメンバーを選び、フェイルオーバーは接続可能性を重視します。どちらも、宛先ごとに最適なスループットを保証するわけではありません。テスト間隔が短すぎると、頻繁な測定が発生することもあります。再生中に途切れる場合は、まず安定した出站を一つに固定して様子を見てから、自動選択に戻すか検討してください。切り替えを繰り返すと、接続を維持する必要がある通信に余分な変数が加わります。

宛先による違いとプロトコルの制限を確認

特定のサイトだけ遅い場合は、同じノードでほかのサイトにも問題があるか比較し、宛先がCDNを経由しているか確認します。出口が異なると、別のキャッシュ拠点が割り当てられることがあります。また、個別の配信元が速度を制限している可能性もあります。この場合、プロキシ側で名前解決されている、または古いアドレスの接続が再利用されていると、システムのDNSを変えても効果がないことがあります。まず、どちら側でドメインが解決されているか、すべてのリクエストが遅いのか特定の大容量リソースだけ遅いのかを確認してください。

アプリによってはUDPベースの通信を使い、経路が不安定だと失敗後に別の方式へ切り替えることがあります。クライアント、ノード、接続ネットワークのどれもが通信に影響します。必要であれば、アプリの正式な設定を使って限定的に比較してください。特定のプロトコルを無効にする設定を、端末全体の標準設定に広げないでください。通信が復旧したら、元の設定と変更点を記録し、長期的な互換性への影響を確認します。

TUN環境で小さなリクエストは成功するのに、大きな応答が止まる場合は、経路MTUやフラグメントの問題を確認します。まずWi-Fiのパケットロスやリモート側の速度制限を除外し、クライアントが対応しているパラメーターを一つずつテストしてください。MTUを根拠なく極端に小さくすると、カプセル化や処理の負荷が増え、ルーティングの問題を見えにくくすることがあります。既定値を記録し、変更のたびに接続を作り直してください。再現性のある改善がなければ、出所が分からない値を残さず元に戻します。

端末のリソースとテスト範囲を確認

通信中のCPU、メモリ、ディスク使用量を確認します。コアのCPU使用率が高い状態が続き、ほかのネットワークアプリもリソースを使っている場合は、並列接続を減らし、不要なデバッグログを停止してから比較します。ルール数が多いという理由だけで速度低下を説明することはできません。使用中のコア、ルールの動作、端末のリソースを合わせて判断してください。セキュリティソフトのネットワーク検査が負荷を増やす場合もありますが、速度測定のために端末の保護を長時間無効にするのは避けてください。

原因が分かったら、効果のあった変更だけを残します。特定ノードの容量やリモートサイトが原因であれば、ローカル設定だけで解決できるとは限りません。サービス提供元が用意する利用可能な出站に切り替えるか、リモート側の復旧を待ってください。スリープ復帰後にだけ遅くなる場合は、性能関連の設定を重ねるのではなく、ネットワークインターフェースやルートの復旧を優先して確認します。仮想ネットワークアダプターが通信を引き継ぐ仕組みはTUNモードの設定ガイドを参照してください。

DNSの問題：名前解決の経路を追う

どこで名前解決されているか確認

DNSの問題はドメイン名でサイトを開けない症状として現れますが、すべてのエラーが同じリゾルバーに起因するとは限りません。ブラウザーが独自の暗号化DNSを使う場合や、システムにキャッシュがある場合、クライアントのコアがプロキシ側の名前解決を行う場合があります。まず、失敗したアプリがどの経路を使っているか確認し、該当するログを調べてください。システムの名前解決コマンドが成功しても、そのコマンドの経路が使えることを示すだけです。ブラウザーやプロキシ側で同じアドレスが取得できるとは限りません。

任意のサイトのIPアドレスへ直接アクセスする方法だけで判断しないでください。HTTPSでは通常、証明書の検証や接続先サービスの選択にドメイン名が必要です。IPアドレスへ直接アクセスすると、DNSが正常でも拒否されることがあります。クライアントのログ、システムの名前解決結果、同じドメインへのリクエストを組み合わせて確認してください。ログにローカルの待ち受け失敗やリモートの認証エラーがすでに記録されている場合、DNSキャッシュを消しても通常は改善しません。

Fake-IPと実IPモードを理解する

Fake-IPモードではアプリに仮想アドレスを返し、コアが対応するマッピングからドメイン名を特定してルーティングします。そのため、システムの問い合わせ結果が仮想アドレスでも、誤った名前解決とは限りません。重要なのは、その後の接続も同じコアを通ることです。問い合わせはクライアントを経由する一方で、接続がクライアントを迂回すると、アプリが仮想アドレスへ直接接続しようとする場合があります。仮想アドレスをすぐにパブリックIPへ置き換えるのではなく、まず通信の引き継ぎが完全か確認してください。

一部のLANサービス、デバイス検出、特殊なアプリでは仮想アドレスが適さない場合があります。実際に問題があるドメインだけをフィルターに設定し、すべてのドメインを追加してモード本来の動作を変えないようにしてください。フィルターの構文や拡張モードはコアによって異なる場合があります。互換性を確認してから設定してください。仕組みと適用範囲はFake-IPとredir-hostの比較を参照してください。

上流DNSとブートストラップ依存を確認

以下はmihomo互換の設定を想定したDNSの例で、完全なプロキシ設定ではありません。パブリックリゾルバーを例に、ブートストラップ、暗号化DNS、指定ドメインのポリシーの関係を示しています。リゾルバーは現在のネットワークから到達可能か、実際の要件に合うかを確認して選んでください。この例では待ち受けアドレスを指定しておらず、OSのDNS設定を自動変更することもありません。クライアントが通信を引き継いだ場合にのみ、アプリのリクエストがこの設定を通ります。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "example.com":
      - https://dns.google/dns-query

ドメイン形式の暗号化リゾルバーを使う場合、コアは最初にそのリゾルバー自体のアドレスを取得する必要があります。これがブートストラップ依存の一部です。ブートストラップの名前解決ができなければ、その後の暗号化DNSも開始できません。ノードサーバーがドメイン名の場合も、信頼できる名前解決経路が必要です。ノードのアドレスを取得する唯一の方法が、まだ確立していないプロキシ接続に依存しないようにしてください。依存関係が循環している場合は、ノードのドメイン解決とプロキシ側の名前解決がクライアント内で別々に設定されているか確認します。

nameserver-policyは指定ドメインに使う上流DNSを選択する設定で、接続のルール分岐とは別のものです。出站ポリシーの代わりにもなりません。fallbackとそのフィルター条件の動作はコアのドキュメントに従って理解してください。メインのリゾルバーが失敗したときだけ起動する予備リストと単純にみなすことはできません。リゾルバーを増やすと問い合わせ先が広がることがあり、精度やプライバシーが自動的に向上するわけではありません。まず必要最小限の上流DNSで安定する状態を作り、明確な用途のある例外だけを追加してください。

順にキャッシュを消去して動作確認

設定を変更したら、まずコアを再読み込みし、テスト中のアプリで古いセッションを終了してから、必要に応じてシステムのDNSキャッシュを消去します。古い仮想アドレスを使う接続が残ったままコアのマッピングだけを消去すると、アドレスとドメイン名の対応が一時的に失われることがあります。社内ドメインには社内リゾルバーが必要です。パブリックDNSに置き換えても解決しないだけでなく、利用できていた業務サービスに接続できなくなることがあります。

検証では、パブリックドメイン、LAN内の名前、最初に失敗したアプリをそれぞれ確認します。プライバシー確認サイトに特定のDNS事業者が表示されても、それは確認できた一経路の手掛かりにすぎません。すべての問い合わせ先を単独で証明するものではないため、ブラウザーの設定、システムのインターフェース、コアのログと合わせて確認してください。詳しい手順はDNSリークの確認と漏えい対策を参照し、一つのテスト結果だけで経路全体を判断しないでください。

プロキシが機能しない：通信の引き継ぎ範囲を確認

システムプロキシとTUNを区別する

システムプロキシは、システム設定に従うアプリへプロキシの入口を提供するもので、すべてのプログラムの通信を自動的に引き継ぐわけではありません。一部のターミナルツール、ゲーム、バックグラウンドサービスは独自のネットワーク設定を使い、システムプロキシを無視することがあります。TUNは仮想ネットワークアダプターとルートを使って通信を受け取りますが、インターフェース、権限、除外ルールの影響を受けます。スイッチがオンになっていても、クライアントが設定を適用しようとしていることを示すだけで、対象の通信がコアを通っているとは限りません。

まずTUNをオフにした状態でシステムプロキシをテストします。新しいブラウザーセッションを開き、接続画面にアクセス先の記録が表示されるか確認してください。次にプロキシを明示するコマンドと比較します。コマンドでは成功し、ブラウザーでは失敗する場合は、ブラウザーのプロキシ拡張機能、アプリ独自のプロキシ、バイパスリストを確認します。コマンドでもローカルの入口に接続できない場合は、待ち受けの確認に戻り、アプリの設定を変更し続けないでください。

ポート、環境変数、OSの設定を確認

mixed-portはHTTPとSOCKSで共用する入口です。アプリ側では、対応するプロキシプロトコルを指定する必要があります。設定中のコントローラー用ポートはプロキシポートではありません。ブラウザーにコントローラー用ポートを指定しても、Webリクエストは転送されません。待ち受けアドレスがローカル専用の場合、スマートフォンなど別の端末から直接接続することもできません。LANへの公開は別途セキュリティを判断すべき設定です。認証やファイアウォールも考慮し、テストのためにすべてのインターフェースへ無条件で公開しないでください。

OS主な確認場所見落としやすい点
Windowsシステムのプロキシ設定、アプリごとの設定サービスによっては、ユーザーのブラウザーとは別のプロキシ設定を使用
macOS現在接続中のネットワークサービスのプロキシ設定Wi-Fiと有線の切り替え後は、現在の接続サービスを確認
Linuxデスクトップのプロキシ設定、プロセスの環境変数ターミナルやバックグラウンドプロセスがデスクトップのプロキシに従うとは限らない

ターミナルツールはプロキシの環境変数を参照することがよくあります。一方、すでに起動しているプロセスには新しい値が自動で反映されません。以下のコマンドは現在の環境を確認するもので、システム設定を変更するものではありません。大文字と小文字の変数、バイパスリストが併存していないか確認してください。ツールによって優先順位が異なる場合があります。古い変数を削除した後は、新しいターミナルを開いて再テストしてください。別のウィンドウで設定を変更しても、元のプロセスに反映されたとは限りません。

# macOS / Linux：現在のプロセスが引き継いだプロキシ環境変数を確認
env | grep -i proxy

# Windows PowerShell：プロキシ関連の環境変数を確認
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

TUNは独立した手順としてテスト

システムプロキシが安定してからTUNを有効にし、必要なサービスのインストールと権限の許可が完了しているか確認します。権限を付与するために、デスクトップアプリ全体を長期間にわたり過剰な権限で実行しないでください。まずクライアントが提供するサービス機能を使います。仮想ネットワークアダプターが表示されても、ルートが有効とは限りません。対象の接続がコアに入っているか、現在のデフォルトネットワークインターフェースが正しく認識されているか確認してください。

複数のVPN、仮想マシンのネットワーク、別のTUNツールを同時に使うと、ルートが重複することがあります。必要のない通信引き継ぎツールを停止し、クライアントを一つだけ有効にしてテストします。スリープからの復帰やネットワーク切り替え後は、古いインターフェースやルートが無効になっている場合があります。その場合はTUNを再度有効にして、クライアントにネットワークを再検出させてください。用途が分からないシステムルートを直接削除しないでください。業務用VPNや仮想マシンが使用している可能性があります。

LAN内の端末に接続できない場合は、すべての通信をDIRECTにするのではなく、プライベートアドレスへのルートやバイパスルールを確認します。プリンター、ネットワークストレージ、社内サービスでは、それぞれ異なる検出方法が必要な場合があります。リモート操作中の端末でルートを変更する場合は、接続を失わないよう、先に元に戻す方法を確保してください。設定の意味は仮想ネットワークアダプターによる通信の引き継ぎも参照してください。

最終確認では、ブラウザーだけでなく、最初に問題が起きたプログラムもテストします。そのプログラムがシステムプロキシ、アプリ独自のプロキシ、TUNのどれを使うか記録し、クライアント終了後もシステムが想定どおり接続できることを確認してください。システムプロキシに従わないアプリでは、正式に対応している接続方法を使います。スイッチが効かないことをクライアントのクラッシュと同一視しないでください。通信の引き継ぎ範囲が明確になって初めて、ルールの一致やDNSを信頼して判断できます。

クライアントがクラッシュする：復旧手段を確保

画面の終了とコアの停止を区別

ウィンドウが消える、トレイアイコンは残る、プロキシが突然停止する、といった症状はそれぞれ異なるプロセスが原因の可能性があります。クライアントによっては画面とコアが別々に動作するため、画面を再起動しても古いコアが終了しないことがあります。コアがクラッシュしても、画面には未起動と表示されるだけの場合があります。クライアントの状態画面とシステムのプロセス確認ツールで実際の状態を調べ、直近のログを保存してください。クライアントを何度も起動すると、残ったプロセスがポートを占有し、元のクラッシュの手掛かりが失われることがあります。

クライアントを終了した後も、システムのプロキシ設定が存在しないローカルの入口を指していると、すべてのWebページに接続できなくなることがあります。まずシステムプロキシの項目に従ってネットワークを復旧し、その後でプログラムの問題を確認してください。設定を保存する前に、データディレクトリ全体を削除しないでください。ローカル上書き設定、プロキシの選択、サブスクリプションの履歴が含まれていることがあります。バックアップは管理された場所に保存し、公開リポジトリに同期したり、そのまま問い合わせの添付ファイルとしてアップロードしたりしないでください。

アーキテクチャ、権限、起動エラーを確認

インストーラーはOSとCPUアーキテクチャに合ったものを選ぶ必要があります。ファイルのダウンロードが完了しても、現在のシステムで実行できるとは限りません。インストーラーが拒否される、実行形式が違う、起動後にクラッシュする、といった問題を分けて確認します。クライアントを選び直す場合は、まずクライアント一覧でClash Plusを確認し、システム要件を照合してください。Clash for WindowsとClashX Metaはメンテナンスが終了しているため、新しいシステムとの互換性問題を解決する選択肢として標準的に推奨できません。

ログにアドレスの競合が表示された場合は、別のコアが残っていないか、別のサービスが同じポートを使っていないか確認します。古いクライアントのものと明確に分かるプロセスを終了するか、ローカルの待ち受けポートを変更してアプリ側の設定も合わせてください。用途が分からないシステムプロセスは終了しないでください。権限不足の場合は、データディレクトリに書き込みできるか、別のアカウントがファイルを作成していないか、セキュリティソフトが必要なコンポーネントを隔離していないか確認します。原因を避けるために保護機能をすべて停止しないでください。

設定のコピーで問題を切り分ける

まずバックアップを作成し、クライアントが対応する新しい設定または独立したデータディレクトリを使って、最小限の設定で起動します。空の環境では安定し、元の設定でコアがすぐに終了する場合は、新たに追加したプロバイダー、ルールセット、スクリプト対応、項目の互換性を重点的に確認してください。構文解析に成功しても、外部リソースが取得できるとは限らず、現在のコアがすべての動作に対応するとも限りません。内容を一度にすべて貼り付けるより、段階的に戻すほうが原因を特定しやすくなります。

アップデート後に問題が起きた場合は、画面とコアのどちらが変わったのかをそれぞれ記録します。異なる入手元のコアファイルをインストール先へ直接上書きしないでください。クライアント独自の起動引数やインターフェースの取り決めがある場合があります。まず正式に用意されているコア管理・復旧方法を使ってください。以前の環境に戻すのは検証や一時的な回避策として扱い、互換性やセキュリティ更新に関する問題が判明している場合まで恒久的に無視しないでください。

画面だけが白く、コアの通信が続いている場合に限り、グラフィック描画や画面キャッシュを確認します。まず、プログラムに正式なハードウェアアクセラレーション設定があるか確認し、一度に一つの項目を比較してください。画面キャッシュを消去する前に、キャッシュとユーザーデータを区別します。インターネット上の曖昧なパス情報を頼りに、ディレクトリ全体を削除しないでください。起動できない場合は、開けない設定画面での操作を求めるのではなく、システムログやクライアントのログディレクトリから情報を取得します。

リソースを確認し、再現可能な報告を作成

メモリ使用量が増え続ける、サブスクリプション更新時に終了する、長時間動作後にクラッシュするといった場合は、発生条件を記録します。不要な自動更新や高頻度のテストを一時停止し、外部リソースの範囲を絞って再現するか確認してください。ディスク容量不足でデータベースの書き込みやログの作成に失敗することもあります。基本的な空き容量を確保しつつ、全体の空き容量だけでなく、クライアントのデータが保存されているパーティションやアカウントの容量制限も確認します。

修正後はバックアップした設定を再読み込みし、プロキシの選択、上書き設定、更新タスクが維持されているか確認してから、正常終了と再起動をテストします。特定の設定でのみ発生する場合は、問題を再現できる最小限の記述まで段階的に戻してください。最小構成でも終了する場合は、OSとの互換性、実行時の依存関係、プログラム自体の不具合を調べます。再インストールは復旧方法の一つですが、すべてのクラッシュを説明する診断結果ではありません。

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

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

Androidクライアントは通常、システムのVPNインターフェースを使って通信を受け取ります。初回接続時には明示的な許可が必要です。画面上のボタンがオンになっただけではトンネルが確立したとは限らないため、システムのVPN状態とクライアントの接続記録も確認します。仕事用プロファイル、企業の管理ポリシー、別のVPNアプリが関連機能を使用している場合があります。どのサービスが実際に有効か確認し、複数のツールが通信の引き継ぎを奪い合わないようにしてください。

Androidのダウンロードページでは、まずClash Plusを確認してください。互換性に応じてClash Meta for Android、FlClash、Surfboardを選ぶこともできます。クライアントによって対応する設定形式や機能の範囲は異なるため、完全なClash設定をどのクライアントでも使える共通ファイルと考えないでください。アプリを変更する前に必要な設定をエクスポートし、サブスクリプションの提供元がその形式に対応しているか確認します。

画面をロックすると切断し、画面を点灯すると復旧する場合は、バッテリー最適化やバックグラウンド動作の制限が関係していることがあります。対象アプリのバッテリー設定、バックグラウンドデータの許可、メーカー独自の自動起動設定を確認してください。常時動作が必要なクライアントだけを変更し、すべてのアプリを制限なしに設定しないでください。「常時接続VPN」や「VPNを経由しない接続をブロック」が有効な場合、トンネル終了時にネットワークが遮断されるのはシステム設定どおりの動作であり、Wi-Fiの故障とは限りません。

iOS：システムトンネルとオンデマンド接続を確認

iOSではダウンロードページにあるClash PlusのApp Storeリンクからインストールできます。公式サイトはclashplus.ioです。初回のVPN設定追加時は、システムの案内に従って許可してください。接続アイコンはシステム状態を確認する手掛かりにすぎません。実際のリクエストとクライアントの記録で通信経路も確認します。別のVPN設定がある場合は、異なるトンネルが使われていないか確認し、以前の設定状態を現在のクライアントの結果と取り違えないようにしてください。

アプリをバックグラウンドに移した後、設定画面が動作していないように見えても、システムトンネルが停止したとは限りません。対象アプリの通信可否、システムのVPN状態、クライアントを再度開いたときのログを合わせて判断します。オンデマンド接続ルールを使う場合は、現在のWi-Fiまたはモバイルネットワークが条件に含まれているか確認してください。ネットワーク名の変化やルールの一致状況によって接続動作が異なることがあります。運任せにシステム設定を何度も削除しないでください。

Wi-Fiとモバイルネットワークを個別に検証

まず安定したWi-Fiで接続を確認し、次にWi-Fiをオフにしてモバイルネットワークへ切り替えます。ノードとモードは変えずに比較してください。モバイルネットワークだけ失敗する場合は、クライアントのモバイルデータ通信の許可、通信事業者の制限、ノードのトランスポートが到達可能か確認します。特定のWi-Fiだけで失敗する場合は、まず認証画面やルーターの制限を調べます。公衆Wi-Fiでブラウザー認証が必要な場合は、現在のシステムの遮断設定を理解したうえで一時的にVPNを切断し、ログインを完了してください。

ネットワークを切り替えた後も、古い接続が以前のアドレスやルートを使い続けることがあります。一時的に通信できなくても、すぐにサブスクリプションを再追加する必要はありません。まず対象アプリの古いセッションを終了し、クライアントが再接続したか確認します。必要に応じて現在のトンネルを一度オフにして、再度オンにしてください。機内モードの切り替えを何度も行うと、ネットワーク、アドレス、セッションの状態が同時に変わります。限定的な復旧手段として使い、根本原因の特定に使わないでください。問題が切り替え直後だけか、その後も続くかを記録すると、原因を絞り込みやすくなります。

アプリ別ルールとLANアクセスを確認

Androidのアプリ別通信の対象リストは、特に見落としが起こりやすい項目です。アプリが除外されていると、クライアントのルールが正しくても、そのアプリのリクエストはクライアントに届きません。対象リストが「含める」方式か「除外する」方式かを確認し、新しくインストールしたアプリが対象になっているかも調べます。アプリがダウンロード時にシステムサービスを呼び出すこともあり、メインプロセスとは異なる動作に見える場合があります。接続ログと合わせて判断してください。ブラウザー一つで接続できても、ほかのアプリも同じ経路を通るとは限りません。

スマートフォンからLAN内のストレージ、画面共有機器、プリンターに接続できない場合は、ローカルネットワークの許可、アドレス範囲のバイパス、デバイス検出の経路を確認してください。検出プロトコルは通常のWebアクセスとは異なります。機器のアドレスを開けても、自動検出まで正常とは限りません。すべてのプライベートアドレスを恒久的にプロキシ経由にしたり、画面共有を復旧するためにルール全体を消去したりしないでください。まずトンネルを切断してLANの基本動作を確認し、必要なバイパス条件を一つずつ戻します。

最後に、画面点灯中の利用、画面ロック後の復帰、Wi-Fiとモバイルネットワークの切り替えの3パターンを再テストします。それぞれで最初に問題が起きたアプリを使い、端末の再起動後も許可と設定が復元されることを確認してください。特定のアプリだけで問題が起きる場合は、独自DNSを使うか、アプリ別通信の対象から除外されているか、バックグラウンド制限を受けているかを記録します。一般的な接続の説明はよくある質問、初回設定は初期設定ガイドを参照してください。トラブル対応中にすべての設定を何度も作り直す必要はありません。