Clash トラブルシューティング大全

共通の診断の考え方とツール

Clashのデータ経路は4つの段階に分けられます:アプリがリクエストを送信 → システムプロキシまたはTUNがトラフィックをクライアントに渡す → クライアントがルールに従って送信先を振り分ける → ノードがトラフィックを目的地まで届ける。どの段階が切れても「ネットに繋がらない」という現象として現れますが、原因と対処法は全く異なります。診断の核心となる動作はただ一つ:問題がどの段階で発生しているかを特定し、その段階だけを修正することです。

診断の順序:近い段階から遠い段階へ

以下の順序で固定して確認し、直感で手順を飛ばさないようにしてください:まずクライアントのプロセスが動作し設定が読み込まれているか(画面上でノード一覧が見えるか)を確認し、次にトラフィックが実際にクライアントに入っているか(コネクションパネルに新しい接続記録があるか)を確認し、さらにルールマッチングが期待通りか(接続記録内の送信先が想定した策略グループか)を確認し、最後にノード自体を疑います。逆の順序——最初からノードやサブスクリプションを切り替える——は最もよくある時間の無駄で、本機側の経路が通っていない状態ではどのノードに切り替えても結果は同じだからです。

ログは第一の証拠

すべてのClash系クライアントはログパネルを提供しており、ログの詳細度は設定ファイルのlog-levelフィールドで制御されます。診断中は一時的にdebugに切り替えることを推奨し、問題解決後はinfoに戻してください。そうしないとログ量が非常に多くなります。

1つのコマンドでプロキシ経路を検証する

ブラウザに依存せず、curlを使ってローカルの混合ポート経由で1回リクエストを送るのが、「クライアントからノードまで」の段階が通っているかを判断する最も速い方法です。204または200が返れば経路は正常、タイムアウトで固まる場合はノードが繋がっていないことを示し、接続拒否はローカルポートがリスンしていないことを示します。

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

混合ポートが既定の7890でない場合は、コマンド内のポート番号を設定ファイルのmixed-portの実際の値に置き換えてください。このコマンドはシステムプロキシの設定を経由しないため、その結果によって「システムプロキシの設定不備」と「ノード不通」という2種類の問題をきれいに切り分けられます:コマンドは通るがブラウザは通らない場合はシステムプロキシの章を、コマンドも通らない場合はノードタイムアウトの章を確認してください。

変数を絞り込む:一度に1つの条件だけを変更する

原因が定まらない問題に遭遇した場合は、順番に3つの対照実験を行います:別のノードに切り替える(単一ノード障害を除外)、グローバルモードに切り替える(ルールの問題を除外)、他のプロキシ/アクセラレータ/セキュリティ系ソフトを一時的に終了する(複数プログラムによるトラフィックの奪い合いを除外)。毎回1つの条件だけを変えて結果を記録すれば、3回の実験の後には問題の範囲が通常は明確な1つの章に絞られます。

起動後にまったくインターネットに接続できない

症状の定義:クライアントを起動すると、すべてのウェブサイト(現地国内のサイトも含む)が開けなくなる、あるいはクライアントを終了するとネットワークが正常に戻る。このタイプの問題は、ほとんどが本機側の経路にあり、ノードの問題ではありません。

ステップ1:物理的なネットワーク自体が正常か確認する

まずクライアントを完全に終了し(プロセスの終了であり、トレイへの最小化ではない点に注意)、その状態で中国本土のウェブサイトを開いてみます。この時点でも開けない場合、問題はClashとは無関係であり、まず本機のネットワークを解決してください。終了後は開けて起動後は開けない場合は、引き続き以下の手順で確認します。留意すべき例外が1つあります:クライアントを終了した後もすべてのウェブサイトが開けない場合——これは通常システムプロキシの残留設定が原因で、クライアントが異常終了した際にシステムプロキシの設定を戻す前に終了してしまったことによるものです。対処法はシステムプロキシの章の「プロキシ残留」の節を参照してください。

ステップ2:トラフィックがクライアントに入っているか確認する

クライアントのコネクション(Connections)パネルを開き、ウェブページを1回リロードして、新しい接続記録が出現するかを観察します。記録があればシステムプロキシの段階は通っており問題はそれ以降の段階にあります。記録が全くない場合、トラフィックがそもそもClashまで到達していないことを示します——システムプロキシへの書き込みが失敗しているか、そのアプリがシステムプロキシに従わない(典型例はコマンドラインプログラム)かのいずれかであり、どちらの場合もシステムプロキシの章で対処してください。

ステップ3:グローバルモードで比較確認する

送信モードを「ルール」から「グローバル」に切り替え、以前テストで使用できたノードを選んで、再度ウェブページをリロードします。グローバルモードでは接続できてルールモードでは接続できない場合、問題はルールにあることを示しています:多くはルールセットの欠落により大量のリクエストが誤った送信先に落ちているか、フォールバックルールMATCHが使用できない策略グループを指しているかです。設定ファイル末尾のフォールバックルールを確認し、それが指す策略グループ内に使用可能なノードがあるか確認してください:

rules:
  # ……ここより前は個別のルール……
  - GEOIP,CN,DIRECT      # 中国本土のIPは直接接続
  - MATCH,PROXY          # それ以外のトラフィックはPROXY策略グループへ(グループ内に利用可能なノードがあるか確認)

グローバルモードでも接続できない場合、ルールの問題は除外でき、問題はノードまたはローカルポートにあります。ノードタイムアウトの章を参照してください。

ステップ4:中国本土向けのトラフィックが誤ってプロキシ経由になっていないか確認する

もう一つの「半分だけ機能不全」の形態として、海外サイトは開けるのに中国本土のサイトはむしろ開けない、または極端に遅いという現象があります。これは中国本土向けのトラフィックもノードに送られてしまい、ノードから中国本土への戻り経路の品質が悪いことを示しています。ルール内にGEOIP,CN,DIRECTとよく使われる中国本土ドメインの直接接続ルールが含まれているか確認してください。サブスクリプションの設定にこの部分が欠けている場合は、rulesセクションの前寄りの位置に自分でDOMAIN-SUFFIXの直接接続項目を追加できます。ルールは上から下へマッチングし、ヒットした時点で停止するため、順序が重要です——直接接続ルールはフォールバックのMATCHより前に置いてください。

ノードが全てタイムアウトする、または遅延が異常

症状の定義:遅延テストですべてのノードがタイムアウト(timeout)と表示される、あるいはノードに遅延の数値は表示されるものの実際には接続を確立できない。まず遅延テストが何を測定しているかを理解した上で、問題の階層を判断します。

遅延テストの仕組みと限界

クライアントの遅延テストは、各ノードを経由してテスト用URL(一般的にはhttp://www.gstatic.com/generate_204)へ1回HTTPリクエストを送り、完了までの時間を記録するものです。これが検証しているのは「本機 → ノード → テストサイト」という一連の経路全体であるため、全ノードがタイムアウトする場合は通常ノードが全滅したわけではなく、本機からノードまでの段階が全体的に遮断されていることを示します。一部のノードだけがタイムアウトする場合は、そのノード自体の問題である可能性が高くなります。また、遅延の数値は1回の小さなリクエストの往復時間しか反映しておらず、実際のダウンロード速度とは別物であることに注意してください——この誤解については速度が遅い章で詳しく説明します。

全ノードタイムアウト:3つの原因を順に除外する

1つ目、サブスクリプションが失効している。ノードサーバーの情報(アドレス、ポート、パスワード)はサービス提供者側で入れ替わることがあり、ローカルの設定が古い情報のままだと全滅します。まず手動でサブスクリプションを1回更新し、再度遅延を測定してください。更新自体でエラーが出る場合はサブスクリプション失敗の章を参照してください。

2つ目、ローカルネットワークがノードのポートを遮断している。会社、学校、ホテルのネットワークでは80/443ポートしか許可していないことが多く、ノードが高位のポートを使用している場合はすべて繋がらなくなります。判断方法:スマートフォンのテザリングに切り替えて再度テストし、テザリングでは全て通るのに元のネットワークでは全てタイムアウトするなら、ネットワーク環境による制限だと確認できます。解決策は443ポートを使用するノードを優先的に選ぶことです。

3つ目、システム時刻のずれ。一部の暗号化プロトコルは時刻に敏感で、本機の時計と実際の時刻のずれが一定の範囲(通常約90秒)を超えるとハンドシェイクが全て失敗し、ノードが全滅した場合と全く同じ挙動を示します。システム時刻の自動同期が有効になっているか確認し、手動で校正してから再テストしてください。これは最も見落とされやすく、同時に最も直しやすい原因です。

遅延の数値はあるのに接続できない

遅延テストはHTTPの小さなパケットで行われますが、実際の通信はUDPや長時間接続を使う場合があり、経路が異なります。典型的な例:ウェブページは開けるのに音声/ビデオ通話が繋がらない——これはノードがUDP転送に対応していないケースです。これはノードの機能上の問題であり、UDP対応と明記されたノードに切り替えれば解決します。クライアント側では修正できません。

自動選択にフェイルオーバーを任せる

ノード障害時に手動で切り替えるよりも、url-testタイプの策略グループを使って、クライアントに現在最速のノードを自動選択させ、障害時には自動で切り替えさせる方が効率的です:

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies: [ノードA, ノードB, ノードC]
    url: http://www.gstatic.com/generate_204
    interval: 300        # 300秒ごとに再テスト
    tolerance: 50        # 新旧ノードの遅延差が50ms未満なら切り替えない(頻繁な切り替えを回避)

サブスクリプション更新の失敗

症状の定義:サブスクリプションの更新をクリックするとエラーが出る、あるいは長時間応答がない。サブスクリプションの更新は本質的にはクライアントがサブスクリプションURLへ1回HTTPリクエストを送り、返ってきた内容を設定ファイルとして解析する処理であるため、診断も「リクエスト失敗」と「解析失敗」の2種類に分けられます。

まずエラー内容を確認する:よくあるエラー対照表

リクエスト経路の問題:まずクライアントを介さずに検証する

コマンドラインで直接サブスクリプションURLにリクエストを送り、クライアント側の要因を排除します:

curl -v -o sub.yaml "https://サブスクリプションURL"

コマンドでは正常にダウンロードできるのにクライアントでの更新が失敗する場合、多くはクライアントの更新リクエストが使用不能なプロキシを経由していることが原因です。多くのクライアントは既定で「プロキシ経由でサブスクリプションを更新」する設定になっており、ノードが全て失効すると「サブスクリプションの更新には使用可能なノードが必要で、使用可能なノードを得るにはサブスクリプションの更新が必要」というデッドロックに陥ります。解決策は、クライアントのサブスクリプション設定で一時的に「直接接続で更新」に変更し、更新成功・ノード復旧後に元に戻すことです。初回のサブスクリプション導入時も同様です——この時点では本機にまだ使用可能なノードが1つもないため、直接接続によるリクエストを許可する必要があります。

コマンドでもダウンロードできない場合は、サブスクリプションサーバー自体が現在のネットワーク環境から到達できない状態であり、クライアントとは無関係です。ネットワーク環境を変えて(スマートフォンのテザリングなど)再試行するか、サービス提供者に連絡してサブスクリプションURLが変更されていないか確認してください。

解析の問題:返された内容が設定ファイルではない

YAML解析エラーが出た場合は、テキストエディタで前のステップで保存したsub.yamlを開いて内容を確認します。HTML(エラーページや認証ページ)であれば、サブスクリプションサーバーがこのリクエストをブラウザからのアクセスとして扱った、またはサブスクリプションが失効していることを示しています。Base64や他の形式でエンコードされたノードリストであり完全なYAMLでない場合は、そのサブスクリプション形式が別のコアを対象にしていることを示しており、サブスクリプション取得時に「Clash形式」を選択するか、サービス提供者が提供する形式変換用URLを使用する必要があります。

User-Agentがサーバー側で区別されて扱われる

一部のサブスクリプションサービスは、リクエストのUser-Agentに応じて異なる形式を返したり、見慣れないUAを拒否したりします。Clash Verge Rev、FlClashなどのクライアントではサブスクリプションリクエストのUAをカスタム設定できるため、403エラーや形式不一致が発生した場合は、UAをclashやサービス提供者が指定した値に設定してみてください。多くの場合すぐに解決します。

接続はできるが速度が遅い

症状の定義:ネットワークは利用可能だが、ウェブページの読み込みが遅い、動画の画質が上がらない、ダウンロード速度が期待値を大きく下回る。速度の問題は変数が最も多く、まず基準値を確立してから項目ごとに原因を突き詰める必要があります。

ステップ1:ローカル帯域幅の基準値を確立する

まずプロキシを無効にして直接接続で一度帯域幅を測定し、その数値を記録します。プロキシ経由の速度はこの上限を超えることはありません。直接接続自体が20Mbpsしかない場合、プロキシ経由で15Mbpsであればすでに正常な範囲の損失であり、それ以上手を加える必要はありません。この基準値を踏まえた上で、異なるノード間の実際の速度を比較してください。

ステップ2:「遅延=速度」という誤解を解く

遅延テストが反映するのは小さなパケットの往復時間であり、速度はノードの帯域幅と利用者数に依存します。60msのノードが200msのノードより大幅に遅いことは十分にありえます——前者は共用の混雑した回線かもしれず、後者は空いている大帯域の回線かもしれません。遅延だけを見てノードを選ぶのはインタラクティブ性が重視される場面(リモート端末操作など)に限って適しています。ダウンロードや動画視聴のような用途では実際のスループットを測定するべきで、その方法はそのノードを経由して実際に大きなファイルをダウンロードし、安定した速度を観察することです。

ステップ3:中国本土向けトラフィックがノードを経由していないか確認する

ルールが欠けている場合、中国本土向けのトラフィックが一度海外へ出てから戻ってくるため、速度が急激に低下し遅延も倍増します。コネクションパネルを開いて中国本土のウェブサイトにアクセスし、その接続の送信先がDIRECTになっているか確認してください。そうでない場合は、直接接続ルールを追加します:

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOIPルールはローカルのGeoIPデータベースに依存しており、クライアントは通常自動的にダウンロードします。ログにデータベースの欠落が表示された場合は、クライアントの設定でデータベース更新を手動で1回実行してください。

ステップ4:ピーク時間帯と回線の種類

夜間に一斉に遅くなり深夜に回復するのは、国際回線の混雑を示す典型的な特徴で、設定の問題ではなく回線の問題です。異なる着地リージョンのノードに切り替える(例えば近い香港/日本/シンガポールのノードは通常遠距離のノードより良好)か、サービス提供者が明記している優良回線を選んでください。すべてのノードが一日中遅い場合は、ダウンロード系のソフトがバックグラウンドで上り帯域を占有していないか、ルーターで速度制限やQoSポリシーが有効になっていないかを確認してください。

ステップ5:クライアントとコアレベルの要因

現在もメンテナンスされているクライアント(選定ガイドを参照)はコアが新しく、新しいプロトコルや多重化への対応が優れています。メンテナンスが終了した古いクライアントを長期間使い続けると、速度と互換性の両方で徐々に不利になっていきます。また、TUNモードとシステムプロキシモードはシステムによってスループットの表現が異なるため、速度が重要な場面では両方のモードを1回ずつテストし、良い方を採用してください。

DNS関連の問題

症状の定義:一部のサイトだけ開けず他は正常;ドメイン名が明らかに間違ったIPに解決される;TUNを有効にすると全てのドメイン解決が失敗する;あるアプリで表示されるIPが198.18.x.xから始まるアドレスになっている。これらの問題はすべてDNS設定に起因します。

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

ClashのDNSモジュールには2つの動作方式があります。fake-ipモードでは、クライアントは各ドメイン名に対してまず198.18.0.0/16帯の仮想IPを返し、アプリケーションに即座に接続を確立させ、実際の解決はトラフィックが送信される際に行われます——利点は解決の待ち時間がゼロで、ドメイン情報がルールマッチングのために完全に保持されることです。副作用として、一部のプログラムがこの仮想IPをキャッシュしたり報告したりして混乱を招くことがあります。redir-hostモードは素直に実際のIPを解決します。現在の主流の設定では既定でfake-ipが使われており、通常変更する必要はありません。198.18.x.xアドレスが見えること自体は故障ではありません。

そのまま使えるdnsセクションのテンプレート

dns:
  enable: true
  listen: 0.0.0.0:53          # TUNモードでは53番ポートでのリスンを推奨
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"                  # LAN内のホスト名にはfake-ipを使わない
    - "+.stun.*.*"             # STUN探索には実際のIPが必要
    - "time.*.com"             # 時刻同期系サービス
  nameserver:                  # 通常解決:中国本土のDoH、速く安定
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                    # フォールバック解決:海外DoH、汚染防止
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN             # 解決結果が中国本土のIPの場合はnameserverを信頼し、そうでなければfallbackを採用

各フィールドの役割分担:nameserverは日常的な解決を担当し、中国本土のDoHを選ぶことで中国本土のドメイン解決を速く正確に保ちます。fallbackは並行して行われる第2の解決経路で、fallback-filterがnameserverの結果を疑わしいと判断した場合(例えば海外ドメインなのに異常な結果が解決された場合)にfallbackの回答を採用し、これによって解決の汚染に対抗します。各項目の原理とさらなる書き方については、ブログ記事『Clash DNS設定の項目別解説』を参照してください。

典型的な故障と対処法

一部のサイトだけ開けず他は正常な場合:コネクションパネルでそのドメイン名を検索し、解決結果と送信先が想定通りかを確認します。ドメインが誤って直接接続になっており解決結果も異常な場合、そのドメインにプロキシ経由のルールを1行追加(DOMAIN-SUFFIX,example.com,PROXY)すれば通常は解決します。

TUNを有効にすると解決が全て失敗する場合:TUNモードはシステムのDNSリクエストもクライアントに取り込むため、この場合dnsセクションでenable: trueかつ53番ポートでリスンしている(上記テンプレートの通り)必要があります。そうでなければシステムから発せられた解決リクエストに応答するものがありません。クライアントのTUN設定内の「DNSハイジャック」オプションが有効になっているか確認し、設定ファイル方式の場合はlisten: 0.0.0.0:53が存在するか確認してください。

LAN内のデバイス(プリンター、NASなど)へのアクセスが異常な場合:LAN内のホスト名がfake-ipに取り込まれてしまっていることが原因です。対応するドメインパターンをfake-ip-filterに追加してください。テンプレート内の*.lanのようにします。

ゲームや通話系アプリの動作が異常な場合:この種のアプリはよくSTUNでパブリックIPを探索しますが、fake-ipがこの探索を妨害します。テンプレート内の+.stun.*.*のようなフィルタ項目はこのために用意されており、アプリが実際に使用する探索用ドメインに応じて追加すれば解決します。

システムプロキシが有効にならない

症状の定義:クライアントは正常に動作しており第1章のcurl検証コマンドも通るのに、ブラウザや一部アプリのトラフィックがClashを経由しない。あるいはクライアント終了後もシステムがプロキシ状態のままになっている。

システムプロキシが書き込まれているか確認する

クライアントの「システムプロキシ」トグルが行っているのは、127.0.0.1:7890をオペレーティングシステムのプロキシ設定に書き込むことです。トグルを有効にした後、実際にシステム側で一度確認してください:

トグルはONなのにシステム側に書き込まれていない場合:他のソフト(ブラウザのプロキシ拡張、アクセラレータ、別のプロキシクライアント)が設定を上書きしていないか確認してください。macOSではさらに、プロキシが書き込まれるのは「現在アクティブなネットワークサービス」である点に注意が必要です。複数のネットワークインターフェースが接続されている場合、別のインターフェースに書き込まれている可能性があります。

システムプロキシに従わないアプリ:環境変数とTUN

システムプロキシはあくまで一つの「提案」であり、アプリケーションはそれを無視することができます。コマンドラインツール(git、パッケージマネージャー、各種SDK)は多くの場合デフォルトでシステムプロキシを無視するため、環境変数を明示的に設定する必要があります:

export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890

このコマンドは現在のターミナルセッションにのみ有効で、一時的な使用に適しています。長期的に有効にしたい場合はshellの設定ファイルに書き込んでください。システムプロキシも認識せずプロキシ設定項目もないアプリケーションに対する根本的な解決策はTUNモードです:クライアントが仮想ネットワークカードを作成し、ネットワーク層で全てのトラフィックを引き受けるため、どのアプリケーションも回避できません。設定ファイルでの有効化方法:

tun:
  enable: true
  stack: system          # 互換性の問題が多い場合はgvisorに変更して比較テスト
  auto-route: true       # ルーティングを自動的に引き受ける
  auto-detect-interface: true

TUNには管理者/root権限が必要であり、DNSセクションは前章のテンプレートに従って正しく設定されている必要があることに注意してください。主要なクライアント(Clash Plus、Clash Verge Rev、FlClash)は設定画面にTUNトグルと必要な権限取得のガイドを提供しているため、設定ファイルを手動で編集するより画面上のトグルを優先して使ってください。

プロキシの残留:終了後もインターネットに接続できない

クライアントが強制終了された場合(クラッシュ、タスクマネージャーでのプロセス終了、システムの電源断など)、システムプロキシの設定を元に戻す前に終了してしまうため、再起動後にブラウザが既に存在しない127.0.0.1:7890への接続を試み続け、「何も開けない」という状態になります。修正方法:上表の位置に従ってシステムプロキシ設定に入り、手動でプロキシをオフにする、あるいはクライアントを一度再起動して正常に終了させ、設定を自動的に取り消させる方法があります。日常的にトレイメニューから正常に終了する習慣をつければ回避できます。

クライアントの起動失敗とクラッシュ

症状の定義:ダブルクリックしても反応がない、起動直後に強制終了する、コアが繰り返し再起動する、あるいはログが特定のエラーで止まっている。この種の問題はエラーメッセージの示す方向性が非常に明確なので、まずログ内の原文のエラーメッセージを見つけ出してください。

ポート使用中:bind: address already in use

起動ログにbind: address already in useが出た場合、設定でリスンしようとしているポート(よくあるのは7890/7891/9090)が既に他のプロセスに使用されていることを示しています——前回きれいに終了できなかった古いコアかもしれませんし、別のソフトかもしれません。3つのプラットフォームでの特定コマンド:

占有しているのが残留した古いコアであれば、それを終了させれば済みます。他の常駐ソフトであれば、こちら側のポートを変更する方が簡単です——設定ファイルで競合しないポートに変更します:

mixed-port: 7893           # HTTPとSOCKS5共用の混合ポート
external-controller: 127.0.0.1:9097   # 制御インターフェースのポートも合わせて競合を回避

ポートを変更した後は、システムプロキシと環境変数内のポート番号も忘れずに同期して更新してください。完全な手順については、ブログ記事『Clashでポート使用中のエラーが出た場合の対処法』を参照してください。

設定ファイルの構文エラー

ログにyaml: line N:のようなエラーが出た場合、設定ファイルのN行目付近に構文の問題があることを示しています。YAMLは形式に対して非常に敏感で、頻出する3つのエラーがあります:Tabインデントを使用している(スペースを使う必要がある)、コロンの後にスペースが抜けている(port:7890は誤り、port: 7890が正しい)、特殊文字を含む文字列に引用符が付いていない(ノード名に@や#などの文字が含まれる場合は引用符で囲む必要がある)。手動で設定を編集した場合は、エラーの行番号に従って1行ずつ確認してください。サブスクリプションから配信された設定でエラーが出た場合は、まずサブスクリプションを再更新してローカルの変更を上書きしてください。

権限不足

TUNを有効にする、あるいは低位のポート(DNSの53番など)をリスンするには権限の昇格が必要です:Windowsでは右クリックして管理者として実行するか、クライアントが提供するサービスモードを使用します。macOSではクライアントの案内に従って認可を完了させます。Linuxではコアファイルにケーパビリティを付与する(setcap cap_net_admin,cap_net_bind_service=+ep)か、systemdサービスとして実行します。ログにoperation not permittedが出る場合はこの種の問題です。

クリーン再インストール:最後の手段

繰り返しクラッシュしログにも明確な原因が示されない場合は、クリーン再インストールを行います:サブスクリプションURLをバックアップとして書き出す → クライアントをアンインストールする → 残留した設定ディレクトリを手動で削除する(各クライアントのデータディレクトリの位置は設定画面の「設定ディレクトリを開く」から確認できます) → ダウンロードページから現在メンテナンス中のバージョンを再インストールする → サブスクリプションを再導入する。古い設定ディレクトリを削除しないと、再インストールしても実質何も変わらず、問題がそのまま再発する点に注意してください。すでにメンテナンスが終了したクライアント(Clash for Windowsなど)を使っていて頻繁にクラッシュする場合は、メンテナンス中のクライアントに直接切り替えることを推奨します。移行の対照については選定ガイドを参照してください。

モバイル専用トラブル(Android / iOS)

モバイルOSはバックグラウンドプロセスやネットワークインターフェースに対する制御がデスクトップよりはるかに厳しく、「デスクトップでは一度も見たことがない」多くの問題はここに起因します。本章はプラットフォーム別に記載します。

Android:VPN認可とバックグラウンド生存

Android上のClashクライアント(第一候補はClash Plus、その他はダウンロードページのAndroid欄を参照)はシステムのVPNインターフェースを介してトラフィックを引き受けるため、初回起動時には「VPN接続を作成」というシステムのポップアップに同意する必要があります。誤って拒否すると、クライアントは空回りするだけになり、システム設定 → アプリ → 該当アプリ → 権限からは元に戻せないため、システムの「VPN」設定項目から接続の認可を再度実行する必要があります。ステータスバーに鍵のアイコンが表示されない場合は、VPNトンネルが確立されていないことを示します。

2番目に多い問題はバックグラウンドでプロセスが強制終了されることです:画面ロックからしばらくしてネットワークが切断され、アプリに戻るとコアが停止している場合、システムのバッテリー最適化機能がプロセスを整理してしまったことが原因です。3つの対処を行ってください:システムのバッテリー設定で該当アプリを「制限なし/バックグラウンド動作を許可」に設定する、最近使用したアプリの一覧で該当アプリをロックする、中国メーカー製のカスタムOS(MIUI、ColorOS、HarmonyOSなど)ではさらにそれぞれの「自動起動管理」で許可する。この3箇所すべてを設定すると、バックグラウンドでの生存率が大幅に改善します。

さらに、Androidクライアントは概ね「アプリ単位のプロキシ」に対応しています:指定したアプリだけプロキシを経由させる、あるいは指定したアプリを除外することができます。銀行系アプリがプロキシに敏感な場合は、除外リストに追加するだけで共存でき、端末全体でプロキシをオフにする必要はありません。

Android:設定とサブスクリプションの違いに関する注意点

モバイル端末でのサブスクリプション更新も「プロキシ経由更新」のデッドロック(サブスクリプション失敗の章を参照)の影響を受けます。通信量に敏感なユーザーは自動更新の間隔に注意してください。サブスクリプションファイル自体は小さいですが、頻繁なバックグラウンド遅延テストは継続的な小さなトラフィックを発生させます。複数デバイス間で設定を一致させる方法については、ブログ記事『Clashの複数デバイス設定同期方法の比較』を参照してください。

iOS:インストール経路とよくある問題

iOS側はApp Store経由でClash Plusをインストールします(公式サイトclashplus.io、ストアへのリンクはダウンロードページのiOS欄を参照)。インストール後の初回起動時も同様に、システムのポップアップでVPN構成の追加を許可する必要があり、対応する設定はシステム設定 → 一般 → VPNとデバイス管理に表示されます。よくある問題は2種類あります:一つはトグルをONにした直後に元に戻ってしまう現象——多くはサブスクリプションが未導入、あるいは設定に使用可能なノードがないことが原因で、まずアプリ内でノード一覧が空でないこと、遅延テストに結果が出ることを確認した上で接続を開始してください。もう一つはWi-Fiとモバイルデータの切り替え時に短時間通信が途切れる現象——これはシステムのネットワーク切り替え時にVPNトンネルが再構築される正常な過程であり、数秒以内に自動的に回復します。回復しない状態が続く場合は、アプリ内で手動で再接続してください。

iOSシステムは同時にアクティブにできるVPN構成を1つに制限しているため、複数のプロキシ系アプリをインストールしている場合は互いに取って代わる動作になるのが仕様です。よく使う1つだけを残しておいてください。また、iOSアプリがバックグラウンドでシステムに回収された後も、VPNトンネルはシステムのネットワーク拡張機能によって維持されるため、通常は接続に影響しません。頻繁に切断される場合は、アプリの再インストールを繰り返すよりも、まずサブスクリプションの有効性とノードの品質を確認してください。

モバイル端末共通のセルフチェックリスト

1. ステータスバーにVPNアイコンがあるか(Androidの鍵アイコン / iOSの「VPN」表示)——ない場合はトンネルが確立されていないため、認可の手順に戻ってください。
2. アプリ内の遅延テストで使用可能なノードがあるか——全てタイムアウトする場合はノードタイムアウトの章に従って対処し、モバイルデータとWi-Fiをそれぞれテストしてネットワーク環境による要因かを区別してください。
3. 直近のサブスクリプション更新が成功しているか——失敗している場合はサブスクリプション失敗の章に従って対処してください。
4. 問題が特定のアプリだけで発生しているか——そうであれば、アプリ単位のプロキシリストとそのアプリ自体のネットワークポリシーを確認してください。

解決しない場合の推奨アプローチ

本ページの手順を最後まで実行しても問題が特定できない場合、通常は3つの可能性が残ります。1つ目は、問題がサービス側にある場合です:サブスクリプションサービスのノード、回線、クォータの状態はサービス提供者しか確認できないため、診断中に収集した証拠(エラーメッセージの原文、どのノードが通りどのノードが通らないか、いつから発生したか)を持って問い合わせると、単に「使えない」と言うよりもコミュニケーションの効率が大幅に上がります。2つ目は、問題がクライアントの実装にある場合です:同じサブスクリプションを使って、メンテナンス中の別のクライアントで交差検証を行い、新しいクライアントで全て正常であれば、選定ガイドに従って移行を完了すれば十分で、無理に固執する必要はありません。3つ目は、問題が基本的な手順の見落としにある場合です:使い方ガイドに戻り、メインフローをもう一度実行してください。長時間調査した「奇妙な問題」の多くは、最終的にある基本的なスイッチがオンになっていなかったことが原因だと判明します。

最後に、クライアントとサブスクリプションの更新習慣を保つこと、メンテナンス中のクライアントを優先的に使用すること、よく使う送信先をurl-testによる自動選択に任せること——この3つを実践するだけで、本ページで扱った故障の7割以上を予防できます。ツールの価値は安定して予測可能であることにあり、一度設定すれば長期間静かに動作し続けることこそが、診断の最終的な目標です。