Clash のトラブルシューティング：症状の切り分けから接続復旧まで

1. Clash は接続済みなのにインターネットに接続できない

クライアントが起動していないのか、プロキシが適用されていないのか、設定が使えないのかを切り分ける

「インターネットに接続できない」はブラウザーに現れる結果にすぎず、障害は3つの異なる場所で発生する可能性があります。第1層はクライアントのコアが正常に動作せず、ローカルプロキシポートが待ち受けていない状態です。第2層はコアが正常でも、ブラウザーやアプリがリクエストを Clash に渡していない状態です。第3層は通信が Clash に届いているものの、ノード、ルール、DNS の失敗によって目的のサイトに到達できない状態です。まずクライアントのステータス画面またはログ画面を確認します。ログに新しい記録がまったくない場合、通常はアプリの通信がクライアントに入っていません。システムプロキシ、ブラウザーのプロキシ拡張、TUN モードを確認してください。Web ページを開いた際にログへリクエストが続けて記録され、末尾に timeout、connection refused、DNS error などが出る場合は、ノードと名前解決の経路を確認します。

ローカルポートが待ち受け状態か確認するには、クライアントの設定で混合ポートを探します。一般的な設定名は mixed-port です。ポート番号は特定の値である必要はありません。重要なのは、クライアントに表示されるポートと、システムプロキシ、ブラウザー拡張、ターミナルの環境変数が一致していることです。Windows ではターミナルから netstat を実行でき、macOS と Linux では lsof を使用できます。コマンドに出力があれば、何らかのプロセスがポートを使用しています。ただし、そのプロセスが現在のクライアントか確認してください。旧クライアントの残存プロセスがポートを占有していると、新しいクライアントが起動できない場合があります。

netstat -ano | findstr LISTENING
lsof -nP -iTCP -sTCP:LISTEN

ローカル接続とプロキシ接続を比較する

まずシステムプロキシと TUN を無効にし、通常ならローカルネットワークから直接開けるサイトへアクセスして、基礎ネットワークが使えることを確認します。次にシステムプロキシだけを有効にして同じサイトへアクセスし、Clash のログを確認します。この比較により、Wi-Fi の認証未完了、LAN ケーブルの切断、ゲートウェイの異常、通信事業者側の障害を切り分けられます。プロキシを無効にしてもアクセスできない場合、Clash の設定を調整しても解決しません。先にシステムのネットワーク接続を直してください。プロキシ無効時は正常で、有効にするとすべて失敗する場合は、ローカルポート、ルール、ノード、DNS に問題が絞られます。

ブラウザーのキャッシュや拡張機能の影響を避けるため、ローカルプロキシを明示したコマンドでテストする方法もあります。ポート番号はクライアントの設定画面に表示された混合ポートへ置き換えてください。コマンドは応答を返すのにブラウザーだけ失敗する場合、コアとノードはおそらく正常です。ブラウザーのプロキシ拡張、HTTPS 検査ソフト、システムプロキシを上書きする設定を確認してください。コマンドもタイムアウトする場合は、その時刻のログを確認し、どのポリシーグループとノードが選ばれたかを確認します。

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

ルールモードとポリシーグループの選択を確認する

ルールモードは、ドメイン、IP、ルールセットに基づいて、直接接続、プロキシ、拒否を決定します。サブスクリプション更新後、ポリシーグループがデフォルトに戻ったり、すでに無効なノードを参照したりすることがあります。プロキシまたはポリシーグループの画面を開き、現在のグループが最終的にどのノードへ接続しているかを階層ごとに確認してください。最上位のグループ名だけを見てはいけません。ルールの誤判定か確認するには、一時的にグローバルモードへ切り替え、利用できることを確認済みのノードでテストします。グローバルモードでは復旧し、ルールモードでは失敗する場合、クライアントとノードは正常で、重点的に確認すべきなのはルールセット、ポリシーグループの参照、ルールの順序です。グローバルモードでも失敗する場合は、ノードと DNS を確認します。

ルールの問題を隠すために、グローバルモードを常用しないでください。ルールは上から順に照合されるため、前方の広すぎるルールが、後続のより具体的なドメインルールを先に捕捉することがあります。すべてのプライベートアドレスを直接接続する設定は通常妥当ですが、誤った IP 範囲や広すぎるドメインサフィックスがあると、目的の通信がプロキシを迂回します。接続履歴で適用されたルールを確認するほうが、モードを何度も切り替えるより効果的です。カスタムルールを変更した後は設定を再読み込みし、YAML の構文エラーによって古い設定へ戻っていないことを確認してください。

ループバックプロキシとファイアウォールによる遮断を確認する

一部のセキュリティソフトはローカルループバック接続を遮断します。クライアントは動作中と表示されるのに、127.0.0.1 宛てのプロキシリクエストがすべて失敗する場合があります。ファイアウォールのルールを削除するのではなく、関連するネットワークフィルタリング機能を一時停止して比較テストを行ってください。企業の端末では、管理ポリシーによってシステムプロキシが固定されていることもあります。この場合、設定スイッチを変更しても数秒後に元へ戻ります。システムプロキシ画面でローカルアドレスとポートが維持されているか確認し、2つのプロキシツールが同時にシステム設定を書き換えていないことも確認してください。

スリープ復帰、Wi-Fi の切り替え、VPN 切断の後に問題が起きた場合は、まずクライアントを終了し、プロセスが完全に終了したことを確認してから再起動します。ネットワークインターフェースが変わると、古い接続や DNS キャッシュが、すでに無効になったインターフェースに残ることがあります。クライアントを再起動するほうが、システムプロキシのスイッチを何度も操作するより、待ち受けポートと接続プールを確実に再構築できます。それでも復旧しない場合は、システムのネットワークインターフェースまたは OS を再起動し、問題が再現するか判断できるよう再起動前のログを保存してください。

2. ノードのタイムアウト、ハンドシェイク失敗、接続拒否

単一ノードの障害か、グループ全体の障害かを判断する

ノードテストがタイムアウトしても、クライアント全体が壊れているとは限りません。まず同じポリシーグループから、地域と入口の異なるノードを少なくとも2つ選び、同じテスト先で繰り返し確認します。特定のノードだけ失敗し、他のノードは接続できる場合、原因はそのノードの停止、入口アドレスの変更、ポートへの到達不能、サブスクリプション情報の期限切れなどが考えられます。利用可能なノードへ切り替え、サービス提供元のサブスクリプション更新を待ちます。同じサブスクリプションのノードがすべて失敗し、別の設定は正常なら、そのサブスクリプションまたは回線に問題があります。すべての設定とノードが同時にタイムアウトする場合に限り、ローカルネットワーク、ファイアウォール、システム時刻、プロトコルの互換性を確認します。

クライアントに内蔵された遅延テストは通常、指定 URL へ HTTP リクエストを1回送信します。単純な ICMP ping ではなく、「テストリクエストが完了するまで」の時間を測定しています。テスト先が現在のネットワークから到達できない、リダイレクトされる、特殊なハンドシェイクを要求する場合、利用可能なノードでもタイムアウトと表示されます。そのため、実際のWebページへのアクセスと接続ログも同時に確認し、赤い遅延表示だけで判断しないでください。ノードで目的のサイトを開けるのにテストだけ失敗する場合は、安定していてレスポンスサイズの小さいテスト先へ変更するか、実際のアクセス結果を主な判断材料にします。

よくあるエラーの方向性を読み取る

システム時刻、IPv6、プロトコル項目を確認する

TLS 系のノードは正確なシステム時刻を必要とします。時刻のずれが大きいと、証明書がまだ有効でない、または期限切れと判定されることがあります。システムの自動時刻合わせを有効にし、タイムゾーンが正しいことを確認してください。仮想マシン、デュアルブート環境、長時間スリープする端末では特に時刻ずれが起きやすくなります。ログが証明書名やハンドシェイクパラメーターを示している場合は、サブスクリプションで生成されたサーバー名、トランスポート方式、ポートが完全か確認します。ノードを手動編集した場合、項目名、インデント、ブール値の型の誤りによって、コアが想定と異なるパラメーターを読み込むことがあります。

IPv6 もよくある分岐の一つです。ノード入口のドメインが IPv4 と IPv6 の両方を返しても、現在のネットワークの IPv6 接続が不完全だと、クライアントが IPv6 を優先して試行し続け、タイムアウトすることがあります。まずシステムで対象ドメインの IPv4 と IPv6 の名前解決結果を確認し、短時間だけクライアントの IPv6 設定を無効にして比較します。無効化後すぐに復旧するなら、ローカル IPv6 ルートを修正する、DNS の応答方針を調整する、または設定で利用可能なアドレスファミリーを明示します。すべてのノードを無効と判断する必要はありません。

ネットワークの種類と出口側の制限を確認する

会社、学校、ホテル、公衆 Wi-Fi では、一般的でないポートが制限されたり、先にWeb認証を完了する必要があったりします。まず Clash を無効にし、任意の HTTP ページを開いて認証ページを表示し、ログインしてからノードを再テストします。モバイルホットスポットは有効な比較ネットワークになります。同じ端末、クライアント、設定がホットスポットでは正常で固定回線では失敗するなら、クライアント設定はおおむね正しく、元のネットワークの DNS、ルーティング、アクセス制御に問題があります。逆に、異なるネットワークでも同じノードだけが失敗するなら、ノード側の問題である可能性が高くなります。

到達不能の問題を隠すために、タイムアウト時間を延ばし続けないでください。タイムアウト値は高遅延回線への許容度を上げるためのもので、誤ったアドレス、閉じたポート、欠落したルートは直せません。長期的に観察する場合は、固定ノードで安定したサイトへ連続アクセスし、接続段階と転送段階のどちらで失敗するかを記録します。接続段階ですぐ拒否されるならサーバーポートの状態、長時間待ってタイムアウトするならパケットロス、ルートブラックホール、入口のフィルタリングが疑われます。接続成功後に頻繁に切断される場合は、MTU、ネットワーク切り替え、回線品質を確認してください。

サブスクリプション更新後の互換性問題

サブスクリプション更新後にすべてのノードがエラーになり、更新前は使えていた場合は、まず直近の利用可能な設定へ戻すか、バックアップから復元します。サブスクリプションの内容に、現在のコアが対応していないプロトコル項目が追加された可能性や、ポリシーグループ名が変更され、ルールが存在しないグループを参照している可能性があります。設定読み込みログで、unknown field、unsupported、proxy group not found などのメッセージを探してください。クライアントの互換性が原因だと確認できたら、ダウンロードページから保守が続いているクライアントを選びます。デスクトップとモバイルではまず Clash Plus を確認し、元のサブスクリプションを再読み込みしてください。破損したキャッシュ設定に上書きを繰り返さないでください。

3. サブスクリプションの読み込み失敗、更新失敗、設定が空になる場合

URL が完全か確認し、サブスクリプションとWebページを区別する

サブスクリプションの読み込みに失敗したら、まずコピーしたものが完全なサブスクリプション URL であり、サービスの管理画面トップ、利用ガイド、ブラウザーのアドレスバーで途中まで切れたリダイレクト URL ではないことを確認します。サブスクリプション URL には通常、パスとクエリパラメーターが含まれます。メッセージアプリの改行、QR コード認識、ブラウザー翻訳、テキスト整形ツールによって末尾の文字が削除されることがあります。URL をプレーンテキストエディターに貼り付け、先頭のプロトコル、ドメイン、パス、クエリ部分が完全か、前後に空白がないか確認してください。アカウント識別用のアクセスパラメーターが含まれる可能性があるため、サブスクリプションの原文をスクリーンショット、ログ共有、公開フォーラムに掲載しないでください。

ブラウザーでサブスクリプション URL を開くと、YAML テキスト、エンコードされた内容、ファイルダウンロードが返ることがあります。ログインページ、認証画面、プラン説明、HTML のエラーページが表示される場合、クライアントは設定として解析できません。ブラウザーでダウンロードできても、クライアントが更新できるとは限りません。ブラウザーが既存のプロキシ、ログイン Cookie、異なる DNS を使っている可能性があるためです。逆に、ブラウザーで開けないからといって URL が無効とは限りません。サービスによっては特定のリクエストヘッダーを要求します。最も確実なのは、クライアントの更新ログで HTTP ステータスと解析エラーを確認することです。

HTTP ステータスからリクエスト段階を切り分ける

初回読み込み時のネットワーク依存を処理する

初回インストール時には利用できるノードがまだなく、現在のネットワークからサブスクリプションのドメインへ直接接続できないと、「設定をダウンロードするにはプロキシが必要だが、設定をダウンロードして初めてプロキシが使える」という循環が起こります。モバイルホットスポットなど、別のアクセス可能なネットワークで初回読み込みを行う方法があります。または、信頼できる端末で設定をダウンロードし、クライアントが対応するローカル読み込み機能で取り込みます。その後、元のネットワークへ戻って更新してください。ノード認証情報やポリシー情報が含まれる可能性があるため、サブスクリプション内容をオンライン変換サイトへ安易に渡さないでください。

古い設定がある場合は、まず利用できるノードを選び、システムプロキシを有効にしてからサブスクリプションを更新します。クライアントに「プロキシ経由で更新」や更新用プロキシの項目がある場合は、参照先のポリシーグループが最終的に利用可能なノードを選んでいるか確認してください。更新処理が直接接続を続ける場合は、ログでサブスクリプションのドメインに対応する接続記録を探し、DIRECT とプロキシのどちらが適用されたか確認します。ルールモードでは、サブスクリプションのドメインが誤って直接接続されることが、更新失敗のよくある原因です。正確なドメインルールを追加して設定を再読み込みしてください。

設定のダウンロードは成功したのにリストが空になる

更新成功と表示されたのにノードやポリシーグループが空なら、ネットワークリクエストは完了しても、返された内容がクライアントの想定する構造ではない可能性があります。まず設定管理画面でファイルサイズと更新時刻を確認します。極端に小さいファイルはエラーメッセージや空の応答であることが多いです。クライアントで元の設定を表示できる場合は、proxies、proxy-groups、rules などのトップレベル項目を確認してください。リモートプロバイダーだけを含む設定は、proxy-providers に依存している場合もあります。この場合、メインファイルの読み込み後にプロバイダーファイルもダウンロードする必要があり、後続リクエストの失敗によってノードリストが空になることがあります。

mixed-port: 7890
mode: rule
proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
rules:
  - MATCH,PROXY

上記の構造は項目の関係を説明するためのもので、例の URL はドキュメント用に予約されたアドレスです。実際の設定はサブスクリプションサービスが生成したものを使用してください。YAML のインデントにはスペースを使い、タブは使用できません。同じ階層の項目はインデントを統一します。コロン、シャープ記号、特殊文字を含む名前は引用符で囲むのが安全です。パーサーが行番号を示した場合は、まずエラー行の1行前を確認してください。実際に引用符やインデントが欠けている位置は、前の行にあることが多いためです。

キャッシュ、上書き、重複設定

クライアントには、リモートサブスクリプション、ローカルコピー、現在実行中の設定が同時に保存されていることがあります。サブスクリプションを更新しても新しい設定へ切り替えなければ、実行中の内容は変わりません。同じ名前の設定が複数ある場合も誤判断につながります。更新後は、現在の有効項目、更新時刻、設定の取得元が一致していることを確認し、設定を再読み込みします。設定管理画面に古い内容が残り続ける場合は、必要なカスタムルールを先にエクスポートし、失敗したサブスクリプション項目を削除してから再追加してください。壊れたキャッシュへ上書きを繰り返すのは避けます。

サブスクリプションを更新できても一定時間ごとに失敗する場合は、失敗時のネットワーク、システムプロキシの状態、応答ステータスを記録します。短時間に更新ボタンを何度も押すと、サーバー側で制限されることがあります。自動更新の間隔はサービス提供元の推奨値に合わせてください。読み込み入口と基本設定の流れはクイックスタートガイドで確認できます。ダウンロードページのよくある質問は、インストーラーやクライアント選びの問題にも役立ちます。

4. 接続は正常なのに速度が遅い、途切れる、ダウンロードが不安定

ノード、回線、ローカル設定を分けてテストする

速度低下はノードのせいだと考えがちですが、実際の経路にはローカル端末、ルーター、アクセス回線、ノード入口、ノード出口、目的サイトが含まれます。まずプロキシを無効にして基礎ネットワークをテストし、次にプロキシを有効にして1つのノードを固定し、同じサイト、同じファイル、近い時間帯で繰り返し測定します。テストサーバーの場所、並列方式、キャッシュ方針が異なるため、複数の速度測定サイトだけで結論を出さないでください。直接接続自体が混雑しているなら、Wi-Fi の電波、ルーターの負荷、通信事業者の回線を先に確認します。直接接続は安定しているのにプロキシだけ明らかに遅い場合は、ノードと設定の層を調べます。

ノードをテストするときはポリシーグループを固定し、url-test による途中の自動切り替えを避けます。まず同じ地域の2つのノードを比較し、次に異なる地域のノードを比較すると、単一ノードの負荷と地域間ルーティングの差を切り分けられます。遅延は操作への応答性を判断する指標であり、持続的な帯域幅を示すものではありません。遅延がやや高くてもパケットロスが少ないノードのほうが、遅延は低いが揺らぎの大きいノードより、Webページや動画の利用が安定することがあります。3層の確認手順はノード・回線・ローカル設定のチェックリストで詳しく確認できます。

混雑する時間帯と目的先の違いを観察する

夜間や特定のネットワーク環境だけ遅くなる場合、回線の混雑が関係していることが多いです。正常な時間帯と異常な時間帯を記録し、1回のテストだけで設定を恒久的に変更しないでください。すべての目的サイトが遅いなら、入口回線、ノード負荷、ローカルネットワークを優先して確認します。1つのサイトだけ遅い場合は、ノード出口からそのサイトまでのルート、サイト側の速度制限、コンテンツ配信地域の不一致が考えられます。Webページは正常でも大容量ファイルだけ遅い場合は、持続帯域、同時接続数の制限、トランスポート方式を確認し、トップページの表示速度だけで判断しないでください。

ポリシーグループの自動テストが頻繁すぎると、不安定になることがあります。url-test はテスト結果に応じてノードを選ぶため、ネットワークが揺れると出口が何度も変わります。確立済みの接続と新しい接続が異なる経路を使い、ログイン状態や長時間接続に影響することがあります。低遅延を重視するなら url-test、可用性を優先するなら fallback、接続を分散したい場合だけ load-balance を使用します。3つの動作方式とパラメーターの違いはポリシーグループ設定の詳細を参照してください。自動切り替え間隔を、実際のネットワーク変化周期より大幅に短くしないでください。

DNS、IPv6、接続の再利用を確認する

Webページの初回表示が遅く、更新すると速くなる場合、DNS の問い合わせや初回接続の確立に時間がかかっていることがあります。ログでリクエストが DNS 段階にどれだけ滞留しているかを確認し、ローカル DNS と暗号化 DNS を個別にテストします。DNS サーバーは多ければよいわけではありません。不安定なサーバーへ並列問い合わせを行うと結果のばらつきが増え、誤った fallback フィルターによって毎回余分なタイムアウトを待つこともあります。まず安定したプライマリサーバーと明確なフォールバック方針を1組に絞り、効果を確認してください。

IPv6 の経路品質が低いと、ドメインが IPv6 アドレスを返した際に、リクエストが失敗を待ってから IPv4 へフォールバックし、新しいサイトを開くたびに数秒遅くなることがあります。短時間だけ IPv6 を無効にして比較すれば方向性を確認できますが、長期的には IPv6 の接続性を直すか、DNS とルーティング方針を一致させるべきです。DNS で IPv6 の応答だけを無効にして、他のアプリでは IPv6 を直接利用する状態にすると、新たな挙動の差が生じることがあります。変更のたびに接続ログで検証してください。

TUN、MTU、LAN 機器を確認する

TUN モードはデータを仮想インターフェースへカプセル化するため、MTU が適切でないと、小さなリクエストは正常でも大きなレスポンスやアップロードで再送が頻発します。一部のサイトだけ開く、読み込み中のまま止まる、文字は表示されるのに画像や動画だけ失敗する、といった症状が典型です。クライアントが対応する範囲で TUN インターフェースの MTU を少しずつ下げ、毎回同じ目的先でテストします。ブロードバンド、モバイルネットワーク、仮想マシン、VPN の多重接続では利用可能な MTU が異なるため、別の環境の固定値をそのまま使わないでください。

LAN 内でルーターがプロキシを実行している場合は、端末の通信が本当にそのルーターを経由しているか、旁路ルーターのゲートウェイと DNS アドレスが一致しているか確認します。端末が別の DNS を使うと、名前解決が想定したルールを迂回することがあります。二重ルーターや Mesh ローミングによって、端末が異なる出口へ切り替わる場合もあります。デスクトップクライアントで LAN 共有とローカル TUN を同時に有効にする場合は、ルーターのプロキシとの二重転送を避けてください。二重プロキシはハンドシェイクを増やし、送信元アドレスを変更し、問題のログを2台の機器に分散させます。

ローカルリソースとバックグラウンドタスク

クライアントの画面が重いからといって、必ずしもプロキシのスループット不足とは限りません。ファイル同期、写真のバックアップ、ゲームの更新、仮想マシンの実行中は、CPU、ディスク、ネットワークのリソースが競合します。タスクマネージャーやアクティビティモニターで、バックグラウンドプロセスがネットワークを占有していないか確認できます。セキュリティソフトの HTTPS スキャンはすべての接続を検査するため、遅延を大きく増やすことがあります。影響を判断するには一時的な比較テストを行い、組織の許可がない端末で管理ポリシーを変更しないでください。

最終的には、「基礎ネットワーク速度、固定ノードの結果、異常な時間帯、目的先の種類、TUN の有効・無効」の5項目を記録します。「とても遅い」だけでは、遅延、帯域幅、パケットロス、名前解決時間のどれか判断できません。再現可能な条件がそろったら、安定したノードを選ぶ、ポリシーグループを調整する、DNS または MTU を修正する、といった対応を選びます。ノードが長期間利用できないなら、複雑なパラメーターを積み重ねるより交換するほうが確実です。ローカル設定を何度も変更して追跡できなくなった場合は、バックアップ後に最小構成を新規作成し、機能を一つずつ戻してください。

5. DNS の名前解決失敗、汚染、漏えい、問い合わせループ

ドメインの問題か接続の問題かを確認する

DNS の障害は、ノードのタイムアウトと誤解されがちです。最も簡単な切り分けは、ドメインと IP を比較することです。ドメインでは失敗するのに既知の IP では接続できるなら、名前解決経路を優先して確認します。ドメインがアドレスへ解決できても接続がタイムアウトするなら、ノード、ルート、ファイアウォールを調べます。nslookup、dig、またはシステム標準の名前解決コマンドで応答を確認し、Clash のログで問い合わせがシステム DNS、Clash DNS、リモート DNS のどれによって処理されたか確認してください。

nslookup example.com
dig A example.com
dig AAAA example.com
ipconfig /flushdns
sudo dscacheutil -flushcache

コマンドラインとブラウザーで結果が異なることがあります。ブラウザーは独自のセキュア DNS、キャッシュ、拡張機能を使う場合がある一方、ターミナルは通常システムのリゾルバーを使用します。まずブラウザー独自の DNS を一時的に無効にして比較し、すべてのアプリが同じ経路を使っているか確認します。ブラウザーだけが異常なら、Clash のグローバル DNS を変更するのは第一選択ではありません。ブラウザー、ターミナル、クライアントの更新がすべて失敗するなら、システム DNS またはネットワーク出口の問題である可能性が高くなります。

redir-host と fake-ip の違いを理解する

redir-host は実際の名前解決アドレスを返すため挙動が分かりやすい一方、ルール判定が解決結果に依存し、ネットワークによって応答が異なることがあります。fake-ip はアプリに予約アドレスを返し、Clash がドメインとの対応関係を保存して後続接続を引き受けるため、より早い段階でドメイン単位の振り分けができます。fake-ip モードで予約アドレスが表示されるのは通常の挙動であり、実際のサーバーアドレスと解釈しないでください。本当の問題は、アプリが Clash を迂回して fake-ip へ直接アクセスすること、または対応記録が失われて接続を正しく復元できないことです。

一部の LAN 検出、プリンター、ゲーム、実 IP を必要とするアプリは fake-ip に適していません。フィルターリストで特定のドメインだけ実アドレスを返すようにできます。フィルターは問題が起きた具体的なドメインから始め、広すぎるサフィックスを一度に追加しないでください。大量のリクエストが fake-ip のドメイン対応機能を迂回するためです。変更後はクライアントの DNS キャッシュとアプリのキャッシュを消去し、元の状況を再現します。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

例では一般的な項目構造を示しています。実際の DNS アドレスは、使用中のネットワークから到達できるものを選んでください。DNS サーバー自体へプロキシ経由でアクセスする必要がある場合、起動時にも利用できる基礎名前解決経路を確保します。暗号化 DNS へ接続するには、そのドメインを先に解決する必要があり、その解決がまだ確立していないプロキシに依存すると、循環依存が起きるためです。

DNS の循環と起動時の依存関係を処理する

ノードサーバーにドメイン名を使う場合、Clash はまずノード入口を解決してからプロキシを確立します。すべての nameserver がそのプロキシ経由でのアクセスを要求すると、起動時に利用できるリゾルバーがなくなります。ノードのドメイン用に直接接続可能な bootstrap 名前解決を用意するか、設定が対応していれば明示的な default-nameserver を使用してください。基礎リゾルバーの役割はプロキシの確立を支援することであり、すべてのアプリの問い合わせを担う必要はありません。設定後は起動ログを確認し、ノード入口の名前解決がプロキシ接続より前に行われ、同じタイムアウトを繰り返していないことを確認します。

TUN モードはシステム全体の DNS 通信も引き受けることがあります。システム DNS が Clash を指し、Clash の上流が誤ってシステムの待ち受けアドレスを指すと、問い合わせがローカルでループします。上流アドレスが現在のクライアント自身の DNS 待ち受けポートでないこと、別のプロキシソフトによって再び戻されていないことを確認してください。LAN ルーター、広告ブロッカー、クライアントが同時に DNS サービスを提供している場合は、アプリからシステム、システムから Clash、Clash から上流という問い合わせ順を書き出すと有効です。各段階に明確で重複しない宛先が必要です。

DNS 漏えいと振り分けの一貫性

DNS 漏えいとは通常、ドメインの名前解決が実際の接続とは異なるネットワーク経路を通ることを指します。必ずしも通信不能にはなりませんが、解決結果とプロキシ出口の地域が一致せず、コンテンツ配信の誤り、予期しないリダイレクト、速度の不安定さにつながることがあります。ルールモードでは、プロキシが必要なドメインに適切なリモート名前解決経路を使い、直接接続するドメインにはローカル DNS を使うようにできます。重要なのは DNS ルールと接続ルールを一致させることです。すべての問い合わせを単一のリモートサーバーへ強制すると、ローカルサービスや LAN ドメインが使えなくなることがあります。

漏えいを確認するとき、1つのWebページの結果だけに依存しないでください。Webページが示すのは特定のリクエストで使われた DNS サービスであり、ブラウザーのセキュア DNS、先読み、キャッシュが結果に影響します。より確実なのは、キャッシュを消去して新しいドメインを問い合わせ、Clash DNS のログ、システムのパケットキャプチャ、上流の問い合わせ記録を同時に確認する方法です。問い合わせが想定した経路を通っていることを確認してから、プライバシーや地域判定の問題を判断します。

キャッシュを消去して最小構成へ戻す

DNS を変更した後は、クライアント自身のキャッシュ、OS のキャッシュ、ブラウザーのキャッシュ、場合によってはルーターのキャッシュまで複数の階層を消去する必要があります。通常はまず Clash のコアを再起動し、次にシステムの DNS キャッシュを更新し、最後にブラウザーを完全終了して再起動します。ルーターの再起動は第一手段ではありません。グローバルアドレス、無線接続、DHCP 状態まで同時に変わり、変数が増えるためです。消去後は短時間だけ正常で、その後また失敗する場合は、自動上書き設定、DHCP で配布される DNS、ブラウザーのポリシーが古い設定を書き戻していないか確認します。

複雑な設定を切り分けにくい場合は、到達可能な基礎リゾルバー1つ、拡張モード1つだけで最小 DNS 設定を作り、追加スクリプトと上書きを無効にして通常のドメインだけをテストします。安定したら fallback、振り分け、フィルタールールを一つずつ追加します。追加ごとに挙動を記録してください。大規模な設定をコピーするより時間はかかりますが、問題を引き起こす項目を正確に特定でき、ネットワーク環境の違いをコアの欠陥と誤認しにくくなります。

6. システムプロキシは有効なのにブラウザーやターミナルで機能しない

システムプロキシの影響を受けるのは、システム設定に従うアプリだけ

システムプロキシは、OS 上のすべての通信を引き受ける機能ではありません。ブラウザーや一部のデスクトップアプリはシステムの HTTP、HTTPS、SOCKS 設定を読み込みますが、ターミナルのコマンド、ゲーム、仮想マシン、一部のクロスプラットフォームアプリは完全に無視することがあります。そのため「ブラウザーは使えるのにターミナルは使えない」場合、Clash の障害ではなく、アプリの種類によって異なるプロキシ入口を使っている可能性が高いです。より広範囲の通信を対象にするなら TUN モード、単一コマンドだけなら環境変数の明示設定が扱いやすく、解除も簡単です。

OS のプロキシ設定を開き、サーバーアドレスがローカルループバックアドレスで、ポートが Clash の現在の混合ポートと一致しているか確認します。クライアントで設定やポートを切り替えた後、古いシステム設定が同期されないことがあります。自動プロキシスクリプト、企業設定、他のプロキシソフトが手動設定を上書きしていないかも確認してください。Windows では異なるネットワーク設定画面が最終的に同じプロキシ項目へ書き込むことがあります。複数の場所で繰り返し変更すると混乱するため、クライアントの状態とシステム上の実際の値を基準にします。

ブラウザー拡張機能と独自 DNS

プロキシ拡張機能はシステムプロキシを上書きできます。拡張機能が直接接続、自動切り替え、古いポートを参照する状態だと、システムプロキシを有効にしても期待どおり動きません。ブラウザーのプライベートウィンドウを使い、プロキシ関連の拡張機能を一時停止してシステムプロキシだけをテストします。復旧したら、「Clash にシステムプロキシを書き込ませる」か「拡張機能から Clash のローカルポートを明示する」か、どちらか1つに統一してください。2つのルールが同時に判定する状態は避けます。

ブラウザー内蔵のセキュア DNS がシステムの名前解決経路を迂回し、Web のドメイン解決と Clash の設定が一致しなくなることがあります。通常、プロキシの TCP 接続確立そのものには影響しませんが、ルールの適用、地域判定、障害の切り分けに影響します。テスト中はシステムのデフォルト DNS を一時的に使い、ブラウザーとターミナルの挙動が一致することを確認してから、ブラウザー独自の名前解決を有効にするか判断します。ブラウザーとターミナルの2つの確認経路については、システムプロキシが機能しない場合の対処を参照してください。

ターミナルに環境変数を設定する

多くのコマンドラインツールは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を読み取ります。環境変数は現在のターミナルセッション、またはそのセッションから起動したプロセスにだけ適用されます。新しいセッションでも維持するには、shell の設定ファイルへ書き込みます。トラブルシューティングではまず一時的に設定し、テスト後に削除してください。後日クライアントが起動していないときまで、すべてのコマンドが無効なポートを指すのを防げます。

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

curl -I https://example.com

unset HTTP_PROXY
unset HTTPS_PROXY
unset ALL_PROXY

socks5h の h は、ドメインの名前解決もプロキシ側へ任せることを示します。ローカル DNS とプロキシ経路の不一致を避けたい場合に適しています。ツールごとに対応する変数名とプロトコルは完全には同じではありません。小文字の変数だけを認識するものや、独自の設定ファイルを持つものもあります。curl は成功するのにパッケージマネージャーが失敗する場合は、Clash の設定を続けて変更するのではなく、そのツールのプロキシ仕様を確認してください。Windows PowerShell では現在のセッションの環境変数を使えます。ウィンドウを閉じれば自然に無効になるため、テストに適しています。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -I https://example.com
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

TUN モードへ切り替えるタイミング

プロキシ設定を持たないアプリ、システムプロキシを無視するアプリ、UDP 通信を引き受ける必要がある場合は、TUN モードが適しています。TUN は仮想ネットワークインターフェースを作成し、ルート経由で通信を受け取るため、システムプロキシより広い範囲をカバーできますが、VPN、仮想マシン、コンテナ、セキュリティソフトとの競合も起きやすくなります。有効にする前に他のネットワーク制御ツールを終了し、基本のシステムプロキシモードが使えることを確認してください。その後 TUN を有効にすれば、問題が仮想インターフェース、ルート、権限のどこにあるか、ノード自体と区別できます。

TUN を有効にした後は、仮想インターフェースが追加されているか、デフォルトルートが適切か、DNS が正しく引き受けられているか確認します。システムによっては、インターフェースの作成に管理者権限が必要です。権限が不足すると、画面上のスイッチはオンでも、コアのログにはデバイス作成失敗が記録されます。スリープ、ネットワーク切り替え、VPN 接続後は、ルートの優先順位が変わり、一部の通信が迂回したり、すべて切断されたりすることがあります。TUN を一度無効にしてから再度有効にするとルートを再構築できますが、頻発する場合は競合ソフトとインターフェースの優先順位を確認してください。

LAN 接続とリモート端末

スマートフォンや別のPCからこの端末の Clash を使うには、LAN 接続の許可を有効にし、リモート端末には Clash を実行している端末の LAN IP を入力します。127.0.0.1 ではありません。ループバックアドレスは常に現在の端末自身を指します。ホストのファイアウォールで、信頼できる LAN から対象ポートへの接続も許可してください。まずホストでポートの待ち受けアドレスを確認します。ループバックだけで待ち受けている場合、他の端末から接続できません。LAN インターフェースで待ち受けるようにした後、リモート端末からポートへの到達性をテストします。

LAN 共有は信頼できるネットワークに限定してください。公衆 Wi-Fi で共有が不要なら、この設定を無効にします。リモート端末はローカルポートへ接続できるのにインターネットへ出られない場合、ホストの Clash ログにその端末からのリクエストがあるか確認します。ログがなければリクエストは到達していません。IP、ポート、クライアント分離、ファイアウォールを確認してください。ログがあるのに失敗する場合は、ノード、ルール、DNS の分岐を調べます。「リモート端末からホスト」と「ホストからノード」の2区間を分けると、誤った端末で設定を繰り返し変更せずに済みます。

7. クライアントが起動しない、繰り返しクラッシュする、ポートが使用中

画面の終了とコアの終了を区別する

Clash クライアントは通常、グラフィカルインターフェースとプロキシコアの2つで構成されます。ウィンドウを閉じてもコアがバックグラウンドで動き続けることがあります。逆に、画面は正常に開いても、設定エラーやポート競合によってコアが繰り返し終了する場合があります。タスクバーやメニューバーのアイコン、プロセス一覧を使って区別してください。起動できない場合は、同種のクライアントと残存するコアプロセスを終了し、1つのクライアントだけを起動します。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu など、システムプロキシを書き換えるプログラムを同時に実行しないでください。ポート、システムプロキシ、TUN ルートが互いに上書きされます。

終了位置を判断する第一の手掛かりはログです。画面がまったく表示されない場合は、システムのイベントビューアー、クラッシュレポート、ターミナルからの起動出力を確認します。画面は表示されるのにプロキシ状態が何度も停止する場合は、コアのログを見ます。設定解析エラーには項目名や行番号が示されることが多く、ポート競合では address already in use、権限問題では permission denied が表示されます。動的ライブラリやコンポーネントが不足している場合は、アプリ起動時に読み込み失敗が報告されます。

ポートの使用状況を特定する

混合ポート、コントロールポート、DNS の待ち受けポートはいずれも競合する可能性があります。まずクライアント設定で関連ポートを記録し、システムコマンドで使用中のプロセスを確認します。Windows の PID はタスクマネージャーの詳細画面でプロセスに対応付けられます。macOS と Linux の lsof ではプロセス名も直接表示されます。ポートが使用中だからといって、すぐにシステムプロセスを終了しないでください。旧 Clash コア、別のプロキシツール、業務サービスのどれかを確認します。必要なプログラムが使用している場合は、Clash の設定で未使用のポートへ変更し、システムプロキシとターミナルの変数も同期して更新します。

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

ポートを変更しても競合が続く場合、設定ファイルが画面上の設定を上書きしているか、クライアントが複数の待ち受け設定を同時に読み込んでいる可能性があります。現在有効な設定で mixed-port、port、socks-port、external-controller、DNS listen を確認します。プロセスの特定とポート変更の手順は、ポート使用中で起動できない場合の対処を参照してください。

破損した設定と非互換項目を処理する

新しい設定を読み込んだ直後にクライアントがクラッシュしたり、コアが起動できなくなったりした場合は、まず古い設定へ戻します。画面を開けない場合は、アプリデータディレクトリの設定をバックアップしてから、最近追加されたファイルを別の場所へ移し、クライアントを初期状態で起動します。クライアントによってデータディレクトリは異なるため、パスを確認せずに一括削除しないでください。まずクライアントが提供するリセットやセーフスタートを使用します。手動で処理する場合もファイルは移動だけにしてコピーを残し、復旧を確認してから整理してください。

設定の非互換は、コアの項目変更、未対応のスクリプト構文、異常なリモートルール形式などでよく起きます。ログの最後に並ぶ連鎖エラーではなく、最初のエラーを確認してください。最初の項目解析失敗によって、その後のポリシーグループ、ルール、DNS がすべて構築できなくなるためです。最小構成でコアが動作するか確認し、プロキシ、ポリシーグループ、ルール、DNS を段階的に追加します。最小構成が安定するなら問題は元の設定にあります。最小構成でも終了するなら、プログラムファイル、権限、システムコンポーネントを確認します。

権限、アプリケーションディレクトリ、システムによる遮断

TUN サービスのインストール、仮想インターフェースの作成、システムプロキシへの書き込みには、より高い権限が必要になることがあります。通常のプロキシポートを使うだけなら、クライアントを常に管理者として実行する必要はありません。ただし、サービスの初回インストール時にはシステムの許可を求められることがあります。許可を拒否しても基本のシステムプロキシは使える場合がありますが、TUN は起動できません。ログから不足している権限を特定し、「常に管理者として実行」をすべての問題に対する解決策にしないでください。

アプリケーションディレクトリへ書き込めないと、設定の保存失敗、更新失敗、起動ループが発生することがあります。ポータブル版を保護されたディレクトリ、読み取り専用ディスク、同期フォルダーに置いた場合に特に起きやすい問題です。クライアントを通常のアプリケーションディレクトリへ置き、ユーザーデータディレクトリへの書き込み権限を確保してください。セキュリティソフトがコアファイルを隔離すると、画面は存在しない実行ファイルを起動し続けることがあります。システムのセキュリティ履歴を確認し、入手元を確認したうえで復元するか、ダウンロードページから保守中のクライアントを再インストールします。

更新後の異常とクリーン再インストール

更新後にクラッシュした場合は、まずシステムを再起動し、古いプロセスや動的ライブラリが使用中でないか確認します。次にサブスクリプション URL、カスタムルール、上書き設定をバックアップし、現在のインストール元を確認してから再インストールします。再インストールは、ユーザーデータをすべて削除することではありません。プログラムファイルが原因なら設定を残すことで復旧できる場合があります。設定やデータベースの破損が原因なら、古いデータをすべて残すと障害も一緒に戻ります。安全な方法は、先にバックアップし、新しいインストールを空のデータで起動して安定性を確認した後、項目ごとに取り込むことです。

Windows ではイベントビューアーのアプリケーションエラー、macOS ではシステムが生成したクラッシュレポートを確認できます。Linux ではターミナルから起動すると、不足しているライブラリや権限の情報を直接確認できることが多いです。ログを共有する際は、サブスクリプション URL、ノード認証情報、ローカルユーザー名、ディレクトリなどの機密情報を削除し、エラーの前後だけを残してください。クラッシュを安定して再現できるなら、「どの画面を開いたか、どの種類の設定を読み込んだか、TUN を有効にしていたか、直前に何をしたか」を記録します。終了後のスクリーンショット1枚だけより、診断に役立ちます。

ロールバック可能な安定状態を作る

復旧後すぐに古い設定をすべて有効にしないでください。まず1つの設定、1つのシステムプロキシ入口、デフォルト DNS でしばらく動作させ、その後 TUN、スクリプト、カスタム上書きを順番に有効にします。変更前には必ず利用可能な設定のコピーを残してください。クライアントは、現在のシステムに対応し、保守が続いているインストーラーを優先します。デスクトップとモバイルではまず Clash Plus を確認し、Linux では Clash Verge Rev または FlClash も選択できます。保守が終了したソフトは既存環境の維持に限って使用し、新しいシステムの互換性問題を解決する第一候補にはしないでください。

8. Android・iOS モバイル端末向けトラブルシューティング

VPN 権限とシステム状態を確認する

モバイル版 Clash クライアントは通常、システムの VPN インターフェースを通じて通信を引き受けます。そのため、アプリ内のボタンよりステータスバーの VPN アイコンのほうが、システムが認証を完了したかを判断する手掛かりになります。初回接続時にはシステムが VPN 接続を要求します。拒否すると、クライアントが接続中のままになったり、すぐ切断されたりします。システムの VPN 設定を開き、現在の構成が存在することを確認し、別の VPN、広告ブロッカー、企業向けセキュリティアプリが同じインターフェースを使用していないか確認してください。多くのモバイル OS では、同時に主要な VPN 接続を1つしか許可しないため、2つのアプリを単純に重ねて実行することはできません。

Android では「常時接続 VPN」や「VPN を使用しない接続をブロック」が有効になっていることもあります。別のアプリに紐付いていると Clash はインターフェースを確立できません。Clash に紐付いていてもクライアントのコアが起動していなければ、すべてのネットワークがシステムによって遮断されることがあります。まず強制項目を無効にして基本接続をテストし、クライアントが安定してから必要に応じて戻します。iOS では、古い VPN 構成を削除して再認証すると、システムに保存された構成と現在のアプリ状態の不一致が解消する場合があります。ただし、組織による管理構成でないことを事前に確認してください。

バックグラウンド制限、省電力、接続切断

モバイル OS はバックグラウンドアプリを制限します。画面ロックから数分後にプロキシが切断され、クライアントを開き直すと復旧する場合、電池最適化、バックグラウンド動作権限、メーカー独自の自動終了機能が原因であることが多いです。Android では、クライアントを電池最適化の対象外にし、バックグラウンド動作を許可し、システムの自動起動管理で必要な権限を維持します。メーカーによってメニュー名は異なりますが、同じネットワークで画面オン、画面ロック、省電力モードを個別にテストし、VPN アイコンとクライアントログがいつ消えるか観察する方法は共通です。

iOS はバックグラウンドネットワーク拡張をより統一的に管理しますが、低電力モード、ネットワーク切り替え、システムリソースの回収によって再接続が発生することがあります。Wi-Fi からモバイルデータへ切り替えるたびに失敗する場合は、まずシステムのインターフェース切り替えを待ち、その後手動で一度切断して再接続します。短時間に接続ボタンを何度も押すと、未完了の状態が複数残ることがあります。アプリを終了し、システムの VPN 設定で接続を切ってから再度開くと、状態を整理しやすくなります。

Wi-Fi、モバイルデータ、プライベート DNS

Wi-Fi だけ失敗してモバイルデータでは正常なら、サブスクリプションとノードはおそらく利用可能です。Wi-Fi の認証、ルーターの DNS、IPv6、クライアント分離を確認してください。公衆 Wi-Fi では、まず VPN を切断してWeb認証を完了し、その後 Clash に接続します。モバイルデータだけ失敗する場合は、モバイルネットワークの IPv6、データセーバー、通信事業者のアクセスポイント、ノード入口への到達性が関係している可能性があります。各ネットワークで接続性のよいノードを選び、IPv6 関連設定を一時的に切り替えて比較してください。

Android のプライベート DNS はシステム全体の暗号化名前解決を有効にするため、クライアントによる DNS 引き受けと経路が異なることがあります。ドメインは開けないのに IP には到達できる場合、プライベート DNS を一時的に自動へ変更し、競合の有無を確認します。iOS の暗号化 DNS プロファイル、コンテンツフィルター、ブラウザー独自 DNS にも同様の影響があります。クライアント DNS、システムのプライベート DNS、ルーター DNS を同時に変更しないでください。まず1つの層だけを比較し、結果を記録してから次へ進みます。

アプリ別プロキシとバイパスリスト

Android クライアントには、アプリ別プロキシ機能が用意されていることがあります。特定のアプリだけ接続できず、ブラウザーは正常なら、そのアプリが除外されていないか、現在のモードが「選択したアプリのみをプロキシ」で、対象アプリのチェックが外れていないか確認します。アプリの更新、クローンアプリ、仕事用プロファイルにある同名アプリは、別の識別子を持つことがあります。アプリ別ルールを切り替えた後は、対象アプリを完全終了して開き直してください。既存の接続は新しい経路へ自動移行しません。

システムサービス、LAN 機器、決済関連アプリは、直接接続が必要になることがあります。明確な問題がある具体的なアプリだけをバイパスリストへ追加し、多数のシステムコンポーネントを一度に迂回させないでください。バイパス後も、アプリがブラウザーエンジンや共有サービス経由でリクエストを送る場合、実際の経路がアプリリストだけで決まるとは限りません。接続ログの対象ドメインとプロセス情報を確認し、ルール設定と組み合わせて判断するほうが、アプリ名だけで推測するより確実です。

サブスクリプション更新とストレージ権限

モバイル端末でサブスクリプション URL をコピーすると、改行が混入したり、ブラウザーが一部を省略したりしやすくなります。クライアントの貼り付け読み込み機能を使い、URL の前後も確認してください。QR コードの読み込みに失敗した場合は、テキスト方式へ切り替えると、カメラ認識の問題とネットワークリクエストの問題を分けられます。更新成功と表示されてもノードが変わらない場合は、現在選択中の設定が更新したサブスクリプションか確認し、手動で再読み込みします。古い設定が実行中なら、画面に表示されるサブスクリプション更新時刻は、コアが新しい設定へ切り替わったことを意味しません。

一部の Android バージョンでは、ファイルアクセスにシステムのファイル選択画面を使用します。ローカル読み込みでは、ディレクトリへの権限だけやクラウド上のプレースホルダーではなく、実際の YAML ファイルを選択してください。クラウドストレージのファイルがまだダウンロードされていないと、クライアントが空の内容を読み込むことがあります。まずファイルマネージャーでオフライン保存し、その後クライアントから読み込みます。ログのエクスポートやバックアップでも保存場所に注意してください。アプリデータを消去すると内部設定も削除されるため、リセット前にサブスクリプションとカスタムルールをバックアップします。

モバイル端末の発熱、バッテリー消費、通信量の異常

バッテリー消費が継続的に高い場合、頻繁な再接続、到達不能な DNS、短すぎるノードテスト間隔、大量のバックグラウンド通信が原因になっていることがあります。まずクライアントに接続失敗と再試行が繰り返し記録されていないか確認し、次にシステムの通信量統計で継続的に送受信しているアプリを調べます。自動テストの間隔が短すぎると、すべてのノードが何度も接続を確立します。ルールプロバイダーやサブスクリプション更新の失敗が再試行ループを作ることもあります。自動タスクを適切な間隔に戻し、不要な詳細ログを無効にすると、バックグラウンドの負荷を減らせます。

通信量が予想を大きく上回る場合は、サブスクリプションサービスの集計方法、ノード倍率、端末のバックグラウンドタスクを確認します。クライアントが転送した通信は、対象アプリと VPN アプリの両方のシステム統計に表示されることがあるため、単純に合算できません。動画の自動再生、クラウドフォト、システム更新は、プロキシ接続が安定するとバックグラウンド転送を再開することがあります。Clash 自体が通信を発生させたと誤解しないよう、一定の時間帯を固定し、バックグラウンド同期を停止して比較してください。

モバイル端末の復旧手順

次の順序で復旧することをおすすめします。まず VPN を切断し、他のネットワーク制御アプリを終了します。Wi-Fi またはモバイルデータで直接接続できることを確認し、Clash を再び開いて利用可能と確認済みの設定とノードを選びます。VPN を許可し、ステータスバーと接続ログを確認します。最後にプライベート DNS、アプリ別プロキシ、省電力設定を戻します。この最小構成でも接続できない場合は、Wi-Fi とモバイルデータを切り替えて相互テストすると、端末設定、現在のネットワーク、サブスクリプションやノードのどこに問題があるかを迅速に判断できます。

再インストールが必要な場合は、Android ダウンロード入口またはiOS ダウンロード入口からプラットフォームに合うクライアントを選びます。Clash Plus を優先候補にできます。再インストール前にサブスクリプション URL と必要なルールを保存し、インストール後はまず1つの設定を読み込んで基本アクセスを確認してから、古い設定を段階的に戻してください。モバイル端末の問題は、システム権限、バックグラウンド制限、ネットワーク切り替えが重なって起きることが多いため、デスクトップ版のパラメーターをすべて移すより、復旧手順を単純に保つほうが効果的です。