Clash トラブルシューティングマニュアル

ネット接続不可:プロキシ有効化後に全断

定義:プロキシを有効化すると、いかなるサイトにもアクセスできなくなり、プロキシを無効化すると直ちにネットワークが復旧する。この種の故障は、トラフィックが確かにClashへ入ってはいるものの、正しく送出されていないことを示しています。以下の順序で診断を進めてください。

1.1 まず「全断」と「一部不通」を区別する

3種類のサイトをそれぞれ1回開いてみます:中国本土のサイト1つ、海外のサイト1つ、IP直接指定のアドレス1つ(ルーター管理画面 192.168.x.1 など)。この3種類全てが不通の場合のみ本章の範囲に該当します。海外サイトのみ不通の場合はDOC-02でノードを確認し、一部サイトのみ不通または遷移が異常な場合はDOC-05でDNSとルールを確認してください。このステップは10秒程度で、後の判断ミスを防げます。

1.2 プロキシモードと出力先の選択を確認する

現在のモードを確認してください。ルールモード(Rule)では、設定ファイルにフォールバックルール MATCH がない場合、マッチしなかったトラフィックが破棄される可能性があります。グローバルモード(Global)では、選択中の出力先が失効ノードだと全トラフィックが失敗します。ダイレクトモード(Direct)でシステムプロキシを有効にすると、トラフィックが一旦ローカルを経由してから直接接続するため、通常は断線しませんが、設定が異常な場合はループが発生することがあります。対処法:まずグローバルモードに切り替え、遅延が正常なノードを手動で選択して復旧するか確認してください。復旧すればルールまたはポリシーグループが原因なので、ルールモードに戻して段階的に確認します。復旧しない場合は次のステップへ。

1.3 ローカルのリスニングポートを確認する

Clashはデフォルトでローカルの7890番ポート(混合ポート)でリスンします。ポートが起動していない場合、システムプロキシは空のアドレスを指すことになり、全断状態として現れます。コマンドでリスニング状態を確認してください:

# Windows(PowerShell または CMD)
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

出力がない場合、カーネルのリスンに失敗していることを示します:設定ファイル内の mixed-port または port フィールドを確認し、クライアントログにbind失敗の記録がないか確認してください(よくある原因は他プログラムによるポート占有で、DOC-07のポート競合の項へ)。出力があるがPIDがClashプロセスでない場合、ポートが占有されていることを示すので、設定でポートを変更するか、占有プロセスを終了させてください。

1.4 curl でブラウザを迂回してリンクを検証する

ブラウザ自体のキャッシュ、拡張機能、DoH設定が判断を妨げる可能性があります。コマンドラインから直接ローカルプロキシ経由でコンテンツなしの検知用アドレスにリクエストしてください:

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

HTTP/2 204 または HTTP/1.1 204 が返れば、「ローカル → Clash → ノード → ターゲット」の一連のリンクが通っていることを示し、問題はブラウザまたはシステムプロキシ層にあるのでDOC-06へ。タイムアウトまたは接続リセットが返る場合はノード側が不通であることを示すのでDOC-02へ。

1.5 実行ログを確認する

ログレベルを info または debug に調整し、アクセスを1回再現して出力を観察してください。典型的な3種類の記録:

• dial tcp ... i/o timeout:ノードサーバーへの接続がタイムアウトしており、ノードに到達不能。DOC-02へ。
• EOF または connection reset:接続確立後に中断されており、多くはノード側のプロトコルパラメータ不一致か通信への干渉。ノードを変更するかサブスクリプション提供元に連絡してください。
• no such rule / proxy not found:設定ファイル内のルールが存在しないポリシーグループ名を参照しており、設定エラーに該当します。サブスクリプションを再更新するか、手動編集したフィールドを修正してください。

ノードタイムアウト:遅延テストの全体または一部が失敗

定義:クライアントのノード一覧で遅延テストを実行した結果、タイムアウト、-1、または空白が表示される。まず明確にしておくべき点:遅延テストが測定するのは「そのノードを経由してあるテストURLにアクセスするまでの完全な所要時間」であり、テスト失敗が必ずしもノード失効を意味するわけではなく、テストアドレス自体が到達不能な場合もあります。

2.1 全て失敗する場合によくある4つの原因

1. サブスクリプションが期限切れ、または通信量を使い切っている。サブスクリプション提供元のユーザーパネルにログインしてアカウント状態を確認してください。これが全滅タイムアウトの最も頻度の高い原因なので、まずこれを確認し、先にソフトウェアを疑わないでください。
2. ローカルのネットワーク自体が不通。プロキシを無効にし、任意の中国本土のサイトに直接アクセスして基本的なネットワークが正常か確認してください。基本ネットワークが切れていれば、どのノードもタイムアウトします。
3. テストURLがローカルネットワークにブロックされている。一部のクライアントのデフォルトテストアドレスは特定のネットワーク環境で到達不能な場合があり、「ノードは実際使えるがテストは全て赤」という状態になります。テストアドレスを https://www.gstatic.com/generate_204 または http://cp.cloudflare.com/generate_204 に変更して再テストしてください。
4. システム時刻のずれが大きい。一部の暗号化プロトコルは時刻に敏感で、ローカル時刻と標準時刻の差が一定範囲を超えるとハンドシェイクに失敗することがあります。システム時刻の自動同期を有効にして再テストしてください。

2.2 一部タイムアウト:正常な現象と対応の境界

サブスクリプションには通常数十のノードが含まれ、個別ノードが特定時間帯にタイムアウトするのは常態です。原因はノードサーバーのメンテナンス、回線の変動、地域のネットワーク規制の変化などです。対応方針:

• 同一地域の複数ノードが全てタイムアウトし、他地域は正常な場合──その地域の回線障害なので、他地域を利用し、提供元の修復を待ってください。
• ランダムに散発的にタイムアウトする場合──対応不要です。ポリシーグループで url-test タイプを使い自動的に利用可能なノードを選択させれば十分です。
• 特定の数ノードが長期的に固定でタイムアウトする場合──サブスクリプション提供元にフィードバックする、または設定内でそのノードを除外してください。

2.3 ポリシーグループを自動的に失効ノードから避ける

ノードを手動選択するポリシーグループは、ノードが失効しても自動切り替えされません。よく使うポリシーグループを自動測定タイプに変更すると、「突然切れる」という感覚を大幅に減らせます。例:

proxy-groups:
  - name: "自動選択"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 60
    proxies:
      - "ノードA"
      - "ノードB"
      - "ノードC"

フィールド説明:interval は再テストの間隔秒数で、120未満は推奨しません。頻繁すぎる測定は余分なリクエストを発生させます。tolerance は許容誤差ミリ秒数で、新ノードの遅延が現在のノードよりこの値以上低くなければ切り替わらず、遅延が近い2ノード間で切り替えが頻発することを防ぎます。

2.4 遅延数値の正しい読み方

遅延テストは完全なHTTPリクエストを実行するため、数値はノードの物理的な距離、プロトコルのオーバーヘッド、テストアドレスの位置という3つの要因の影響を受けます。経験値の参考:アジア近距離ノードは数十~百数十ミリ秒、欧米ノードは200~400ミリ秒が正常な範囲です。遅延が低いのはハンドシェイクが速いことのみを意味し、帯域が大きいことは意味しません。ダウンロード速度の問題はDOC-04で対処してください。

サブスクリプション失敗:インポートエラーと更新失敗

定義:サブスクリプションリンクを貼り付けてインポートするとエラーが出る、または既存のサブスクリプションで更新をクリックすると失敗する。サブスクリプションは本質的にHTTPで取得するリモート設定ファイルであり、診断の考え方は「あるURLが開けない」場合の診断と同様です:まずリンク自体を確認し、次にネットワークパスを確認し、最後にコンテンツ形式を確認します。

3.1 リンク自体が有効か確認する

1. リンクの完全性を確認する。サブスクリプションリンクは通常非常に長く、トークンパラメータを含むため、チャットツールからコピーすると途切れたり、改行やスペースが混入しやすくなります。提供元のユーザーパネルから再コピーし、何度も転送しないことを推奨します。
2. リンクの形式を確認する。Clash系クライアントにはClash形式(YAML)のサブスクリプションが必要です。提供元によってはクライアントごとに異なるリンクを提供している場合があり、形式を間違えると「解析失敗」エラーになります。多くの機場(サブスクリプション提供元)はリンク末尾にパラメータを付加して形式を指定できますので、提供元の説明に従ってください。
3. ブラウザで直接リンクを開く。proxies:、port: などのフィールドで始まるYAMLテキストが表示される場合、リンクとコンテンツは両方正常で問題はクライアント側にあります。404やエラーページが返る場合、リンクが失効しているので提供元に再発行を依頼してください。

3.2 取得段階で失敗した場合の対処

リンクは有効だがクライアント更新がタイムアウトになる場合、サブスクリプションサーバー自体が干渉を受けたネットワークパス上にある可能性があります。2つの対処方向:

• 既存の利用可能なノードで中継して取得する。Clash Verge Revなどのクライアントでは、サブスクリプション設定に「プロキシ経由で更新」のスイッチがあります。前提として現時点で少なくとも1つの使える旧設定があることが必要です。
• コマンドラインで問題を再現する。curlでクライアントのリクエストを模擬し、具体的にどのステップで失敗しているか観察してください:

# 直接接続で取得(リンクは自分のものに置き換えてください。例のtokenは仮の値です)
curl -I "https://example.com/api/v1/client/subscribe?token=xxxx"

# ローカルプロキシ経由で取得
curl -x http://127.0.0.1:7890 -I "https://example.com/api/v1/client/subscribe?token=xxxx"

直接接続が失敗し、プロキシ経由で成功する場合、サブスクリプションサーバーへの直接接続が到達不能であることを示すので「プロキシ経由で更新」を有効にすれば解決します。両方失敗する場合、サーバー側の異常なので、待つか提供元に連絡してください。

3.3 User-Agent 制限

一部のサブスクリプションサーバーはリクエストのUser-Agentによって異なる形式を返す、または未知のUAを拒否します。ブラウザでは開けるがクライアントでは解析に失敗する場合、クライアントのサブスクリプション設定でUAを手動で clash または clash.meta に変更して再試行してください。この項目は、クライアントを変更した後にサブスクリプションが突然失効するシーンで特に多く見られます。

3.4 更新失敗だが旧設定は使用可能

クライアントは前回成功した取得の設定をキャッシュしており、サブスクリプション更新の失敗が継続的な旧ノードの利用に影響を与えることはありません。そのため更新失敗があってもすぐに接続問題として対処する必要はありませんが、注意点があります:旧設定内のノードアドレスは提供元のローテーションにより次第に失効する可能性があり、利用可能なノードが徐々に減少する形で現れます。できるだけ早く本章3.1~3.3に従って更新機能を回復させてください。

速度が遅い:接続は正常だが帯域が想定に達しない

定義:ページは開ける、動画は再生できるが、速度がローカルの通信環境の水準や以前の体感より明らかに低い。速度問題は変数が最も多いため、レイヤーごとに分離する必要があります:ローカルネットワーク → ノード → プロトコル → ルール → 対象サイト。

4.1 基準を確立する:まず直接接続を測定し、次にプロキシを測定する

プロキシを無効にし、中国本土の速度測定サーバーで1回測定し、その数値をローカル通信環境の基準として記録してください。プロキシを有効にし、ノードを1つ選択して、同じ対象または該当ノードの地域の測定ポイントに対して再度測定してください。プロキシの速度が基準の半分以上であれば、通常は正常な損失範囲内です。差が大きい場合はさらに下へ進んで診断してください。

4.2 ノード側の要因

• ノードの負荷。人気の時間帯(夜間)は公共ノードの利用者が集中し、帯域が分割されます。あまり使われない地域のノードに切り替えたり、時間差で比較すると、明らかな差が確認できます。
• 回線の種類。同一サブスクリプション内の異なるノードが利用する国際回線の品質差は非常に大きいです。よく使う3~5個のノードを個別に実測し、それぞれの安定した速度を記録し、良好な結果のものを固定して使い、遅延の数値だけでノードを選ばないでください。
• 倍率マーク。一部の提供元は高品質回線に対して通信量倍率を設定しており、ノード名にその表示があることが多いので、選択時に注意してください。

4.3 クライアントとプロトコル側の要因

• カーネルのバージョン。mihomoカーネルは新プロトコルと並行処理性能の最適化が継続的に更新されており、長期間クライアントを更新していない場合、性能を損なう可能性があります。インストーラーページ で最新版を入手してください。Clash PlusとClash Verge Revはいずれもmihomoカーネルを内蔵しています。
• UDPサポート。ビデオ通話、ゲーム、一部のストリーミングはUDPに依存しています。ノードや設定がUDPを許可していない場合、これらのアプリは劣化したり、カクついたりします。設定内の該当プロキシの udp: true フィールド、および提供元がUDP転送に対応しているかを確認してください。
• ブラウザのQUIC。ブラウザは一部のサイトに対してHTTP/3(UDP 443)を使用しますが、UDP転送品質が悪いノードではむしろ遅くなります。ルールでQUICをブロックしてTCPへのフォールバックを強制するのはよく使われる手段です:

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT

4.4 ルール側の要因:トラフィックの流れが正しいことを確認する

速度が遅くなる隠れた原因の1つは「本来直接接続すべきトラフィックがプロキシを経由している」ことです。中国本土のサイトが海外ノードを経由して戻ってくると、速度は必然的に大幅に低下します。クライアントの接続パネルで現在のアクティブな接続を確認し、中国本土のドメインが DIRECT にマッチし、海外のドメインがプロキシのポリシーグループにマッチしていることを確認してください。分流ルールの設定が不適切な場合は、サイト内の記事 ルール分流の実践 を参照して修正してください。

4.5 ローカル環境の要因

Wi-Fi信号の弱さ、ルーターの性能ボトルネック、他デバイスによる帯域占有は、いずれも「ノードが遅い」と誤判定されがちです。有線接続かルーター近くに移動して再測定し、ローカルの干渉を排除してください。ソフトルーター/ルーター上でカーネルを動かしているユーザーは、デバイスのCPU使用率にも注意が必要です。暗号化トラフィックのスループットはデバイスの処理能力に制限され、低スペックデバイスでは100Mbps程度が上限になるのは正常な現象です。

DNS異常:解決エラー、リーク、一部サイトが開けない

定義:全体的にネットワークは利用可能だが、一部のサイトが開けない、エラーページに遷移する、または検知ツールでDNSリークが表示される。DNSはClashの故障の中で最も直感的でない種類の1つで、症状は「特定のサイト」に現れる一方、根本原因は解決レイヤーにあります。

5.1 DNSの問題かどうかを判断する

開けないサイトに対して以下を実行してください:IPを直接指定して接続すると通る場合(そのサイトが対応していれば)、またはクライアントログでそのドメインが解決されたIPが明らかに異常(予約アドレスに解決されている、対象事業者のアドレス帯に明らかに属さないなど)であれば、解決の問題と判定できます。もう1つの典型的な信号:プロキシを有効にした状態で、あるサイトが「お住まいの地域では利用できません」と表示するのに、ノードの地域は明らかに正しい場合──多くはDNSリクエストが直接接続を経由してしまい、実際の位置が露呈している状態です。

5.2 fake-ip と redir-host を理解する

Clashの enhanced-mode には2種類の値があります。fake-ip モードではカーネルがドメインリクエストに対して即座に198.18.0.0/16帯の仮アドレスを返し、実際の解決は出力時まで遅延されます。利点は応答が速く、汚染に対して天然の耐性を持つことで、欠点は実際のIPに依存する一部のプログラム(LAN上の発見機能、一部のゲームプラットフォーム)が異常になることです。redir-host モードは実際の解決結果を返し、互換性が良いものの上流DNSの品質への依存度が高くなります。一般にデスクトップとモバイルはfake-ipを推奨し、フィルタリングリストと併用してLANドメインを除外してください。

5.3 そのまま使える dns セクションの設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

構造の説明:nameserver は日常の解決を担当し、中国国内のDoHを設定することで中国本土のドメイン解決を速く正確にします。fallback は汚染された疑いのあるドメインの再解決を担当し、海外のDoHを設定します。fallback-filter はGeoIPで判定し、解決結果がCNアドレス帯に属さない場合にfallbackの結果を採用します。各フィールドの詳しい原理とハイジャックのシナリオについては、サイト内の記事 Clash DNS設定の詳解 を参照してください。

5.4 DNSリークの確認と対処

1. プロキシ経由でDNSリーク検知サイトにアクセスし、表示された解決サーバーの帰属を確認してください。全てノードの所在地域のサーバーであれば正常、ローカルの通信事業者のサーバーが出現した場合はリークです。
2. リークの発生源を確認する。よくある発生源は3つ:ブラウザ内蔵のDoH(設定内で独立にDNS over HTTPSを設定しており、Clashを回避している)、システムプロキシモード下でUDP 53リクエストがプロキシを経由していない、IPv6解決の迂回。
3. 個別に対処する:ブラウザ内蔵のセキュアDNSを無効にする、TUNモードを有効にしてDNSリクエストも一緒に接収させる(DOC-06参照)、設定で ipv6: false を設定するかIPv6ルールを補完する。

5.5 GeoIPデータベースの古さによる誤判定

ルール内の GEOIP,CN,DIRECT はローカルのGeoIPデータベースに依存します。データベースが長期間更新されていない場合、新しく使われ始めたアドレス帯が誤判定され、一部の中国本土サイトが誤ってプロキシを経由したり、一部の海外サイトが誤って直接接続になる現象として現れます。多くのクライアントは設定内にGeoIP/GeoSiteデータベースの更新入口を提供しているので、1回更新を実行してカーネルを再起動してください。更新に失敗する場合、まず現在のプロキシが利用可能であることを確認してから「プロキシ経由で更新」の方法で再試行してください。

システムプロキシ無効:クライアントは動作しているがトラフィックが直接接続になっている

定義:クライアントは正常動作、ノードの遅延も正常だが、ブラウザやアプリのトラフィックがプロキシを経由していない。核心となる認識:「システムプロキシ」はOSレイヤーの単なる推奨設定にすぎず、アプリはそれに従うこともできれば無視することもできます。これが本章の診断フレームワークを決定します。

6.1 システムプロキシ設定が書き込まれていることを確認する

まずクライアントの「システムプロキシ」スイッチが有効になっていることを確認し、次にOSレイヤーで照合してください。Windowsは「設定 → ネットワークとインターネット → プロキシ」で手動プロキシが 127.0.0.1:7890 を指しているか確認します。macOSは「システム設定 → ネットワーク → 詳細 → プロキシ」でHTTP/HTTPSプロキシの項目を確認します。クライアントは有効にしたのにシステムに書き込まれていない場合、よくある原因は権限不足、または他のプロキシソフトに設定を奪われていることです。クライアントを再起動するか、競合するソフトを終了して再試行してください。

6.2 天然にシステムプロキシを経由しないトラフィックの種類

6.3 コマンドラインツールのプロキシ設定

# macOS / Linux(現在のターミナルセッションで有効)
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:HTTP_PROXY="http://127.0.0.1:7890"

# git 個別設定(グローバル)
git config --global http.proxy http://127.0.0.1:7890

検証方法:curl -I https://www.gstatic.com/generate_204 を実行し、クライアントの接続パネルにcurlからの接続記録が表示されれば有効になっています。

6.4 TUNモードでシステムプロキシを置き換える

TUNモードは仮想ネットワークカードを作成し、システムのルーティングレイヤーで全トラフィックを接収します。どのアプリの協力にも依存せず、「システムプロキシに従わない」問題を解決する根本的な方法です。有効化のポイント:デスクトップでは管理者/システム拡張の権限が必要、初回有効化時にサービスコンポーネントのインストールが必要(クライアントがガイドします)、有効化後はシステムプロキシのスイッチを無効にして二重プロキシを避けることを推奨します。原理とプラットフォーム別の手順については、サイト内の記事 TUNモードの原理と有効化手順 を参照してください。

6.5 ブラウザ拡張機能とPACの競合

ブラウザにSwitchyOmegaなどのプロキシ拡張機能をインストールしている場合、拡張機能側の設定がシステムプロキシより優先されます。システムプロキシは明らかに正しく設定されているのに、ブラウザが依然として拡張機能の旧ルールに従うという現象として現れます。対処:拡張機能を「システムプロキシ」モードに切り替える、または拡張機能を無効化してください。同様に、システムに残留するPAC自動設定スクリプトのアドレスも手動設定を上書きすることがあるため、診断時は「設定を自動的に検出する」と「セットアップスクリプトを使用する」を両方無効にしてください。

クライアントクラッシュ:起動失敗、突然終了、画面フリーズ

定義:クライアントが起動できない、起動直後に終了する、カーネルが繰り返し再起動する、または画面が長時間応答しない。この種の問題は9割が4つの原因に集約されます:設定の構文エラー、ポート競合、権限不足、インストールファイルの破損。発生頻度の高い順に診断してください。

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

YAMLはインデントとコロン後のスペースに非常に敏感で、設定を手動編集した後にカーネルが起動しなくなるのはよくあるクラッシュの原因です。特定方法:クライアントログ(Clash Verge Revのアプリログ、各クライアント設定内のログ入口)を確認してください。カーネルはエラーの中で行番号を示すことが多く、例えば yaml: line 42: mapping values are not allowed in this context のようになります。対処:行番号に従ってインデントを修正するか、一時的に変更前のサブスクリプション設定に戻して復旧するか確認してください。設定を変更する前にバックアップをコピーしておくのが最もコストの低い保険です。

7.2 ポート競合

7890(プロキシ)、9090(外部制御)などのポートが他プログラムに占有されている場合、カーネルは起動即失敗します。典型的な競合相手:完全に終了していない別のClashインスタンス、他のプロキシソフト、開発デバッグサービス。特定と対処:

# Windows:7890を占有しているプロセスのPIDを見つけ、PIDでプロセス名を確認
netstat -ano | findstr 7890
tasklist | findstr 

# macOS / Linux
lsof -i :7890

占有元を確認した後、そのプロセスを終了させるか、設定で別のポートに変更してください(同時にシステムプロキシの指定先も更新してください)。複数のClash系クライアントを同時に実行せず、使わなくなったものはアンインストールしてください。

7.3 権限とセキュリティソフト

• Windows:アンチウイルスソフトがカーネルプロセスをブロックしたり、カーネルファイルを削除したりすることがあり、「昨日まで使えたのに、今日は起動すると終了する」という現象になります。クライアントのインストールディレクトリをホワイトリストに追加してから再インストールしてください。誤検知の原因と対処の詳細については Windowsインストール全手順とよくある落とし穴 を参照してください。
• macOS:初回起動がブロックされた場合、「システム設定 → プライバシーとセキュリティ」で実行を許可してください。TUNモードのシステム拡張は個別に承認が必要です。
• TUN関連のクラッシュ:TUNの有効化には管理者権限が必要で、サービスコンポーネントのインストールが不完全だと有効化即クラッシュにつながります。管理者権限でサービスコンポーネントを再インストールするか、先にTUNを無効にしてシステムプロキシモードでクライアント本体が正常か確認してください。

7.4 インストール破損と残留物の競合

更新の失敗、ディスク異常はいずれもプログラムファイルを破損させる可能性があります。対処順序:まずアンインストールし、手動で残留ディレクトリを整理してください(注意:設定とサブスクリプションは通常ユーザーデータディレクトリに保存され、プログラムディレクトリとは分離されているため、プログラムディレクトリを整理しても設定は失われません。完全にリセットする場合はユーザーデータディレクトリも削除してください)、その後 インストーラーページ から再度ダウンロードしてインストールしてください。何度もクラッシュして明確なログの手がかりがない場合は、同じカーネルの別のクライアントに変更して相互検証してください──例えばClash Verge Revはクラッシュするがクラッシュ Plusは正常であれば、問題はクライアント本体にあり、設定やネットワークではないと判定できます。

モバイル端末専用問題:AndroidとiOSのプラットフォーム特有の問題

モバイルクライアント(Android版のClash Plus、Clash Meta for Android、FlClash;iOS版のClash Plus)は統一的にシステムのVPNインターフェースを介してトラフィックを接収するため、故障パターンがデスクトップとは明らかに異なり、独立した1章として扱います。

8.1 Android:VPNを確立できない

1. システムVPNの承認を確認する。初回起動時に「接続リクエスト」の承認画面がポップアップし、誤って拒否した場合はシステム設定のVPN管理画面でそのアプリのVPN設定を削除し、クライアントを再起動して承認を再度トリガーしてください。
2. VPNの排他性を確認する。Androidは同時に1つのアプリのみVPNチャネルを保持することを許可しており、他のVPN系アプリ(一部のセキュリティソフトの「ネットワーク保護」機能を含む)が動作中の場合、Clashは接続を確立できません。競合するアプリを無効にして再試行してください。
3. 一部のカスタムシステム(業務用プロファイル、キッズモード)はVPN権限を制限しており、該当する管理入口で許可が必要です。

8.2 Android:バックグラウンドで終了・通信切断

中国系メーカーのカスタムシステムの積極的な省電力ポリシーが、モバイル端末で通信が切断される最大の原因で、ロック画面から一定時間後にネットワークが中断し、通知バーのアイコンが消える現象として現れます。対処チェックリスト:

• システムのバッテリー設定でクライアントを「無制限」/「最適化しない」に設定する。
• マルチタスク画面でクライアントをロックする(下にスワイプしてカードをロック)ことで、一括クリーンアップによる誤終了を防止する。
• クライアントのフォアグラウンドサービス常駐通知を有効にし、見た目をきれいにするために無効化しないこと──常駐通知はシステムがプロセスの重要度を判定する根拠の1つです。
• 一部のシステムでは追加で「自動起動」と「バックグラウンドでの画面表示」権限の許可が必要です。

8.3 Android:アプリ別プロキシ

クライアント設定内の「アプリ別プロキシ」(Per-App Proxy)は、どのアプリがVPNを経由するかを指定できます。2つのモード:ホワイトリスト(リスト内のアプリのみプロキシを経由)とブラックリスト(リスト内のアプリはバイパス)。銀行系アプリがVPNに敏感な場合、バイパスリストに追加することでそのリスク管理エラーを解決できます。逆に、あるアプリが常に直接接続になっている場合は、それがバイパスリストに登録されていないか確認してください。アプリ別設定を変更した後は、VPNを再起動して反映させる必要があります。

8.4 iOS:Clash Plus 利用のポイント

iOS版はApp Store経由で Clash Plus をインストールし、システムのNetwork Extensionフレームワークをベースに動作します。プラットフォーム特有の注意点:

• 初回起動時はシステムのポップアップでVPN設定の追加を許可する必要があり、拒否した場合は「設定 → 一般 → VPNとデバイス管理」で対処してください。
• システムがNetwork Extensionに設定するメモリ上限は通常のアプリよりはるかに低く、ルールセットが大きすぎる、またはノードが多すぎる設定は拡張プロセスがシステムに回収されるトリガーとなり、VPNアイコンの点滅切断として現れます。サブスクリプションの規模を精選し、巨大なルールセットの読み込みを避けることで緩和できます。
• iOSのVPNも同様に全体で排他的なため、プロキシアプリを切り替える前に別のアプリの接続を切断してください。
• Wi-Fiとモバイルデータの切り替え時に一時的な通信切断が発生するのはシステムのネットワークスタック切り替えによる正常な現象で、数秒以内に自動復旧します。長時間復旧しない場合は、手動で接続を1回オフオンしてください。

8.5 モバイル端末のサブスクリプション更新失敗

スマートフォンでサブスクリプション更新がエラーになる場合の診断はDOC-03と同様ですが、モバイル端末特有の要因を2点補足します:モバイルデータ通信では一部の通信事業者が未知のドメインへの解決・接続ポリシーをより厳しくしている場合があり、Wi-Fiに切り替えて再試行することで区別できます。省電力モードはバックグラウンドのネットワークリクエストを制限し、フォアグラウンドでの手動更新には影響しませんが、「サブスクリプションの自動更新」タスクが長期間実行されず、ノードが静かに期限切れになっていることがあります──ノードが一括で失効しているのを発見したら、まず手動でサブスクリプションを1回更新してからテストしてください。

END OF FILE / C-007

上記8章を試しても解決しない問題については、以下の3つの情報を持って相談することを推奨します:クライアント名とプラットフォーム、再現手順、重要なログの断片(サブスクリプションリンクとトークンは隠してください)。散発的で頻度の高い一問一答は よくある質問 を参照してください。ゼロから設定する場合は 設定チュートリアル に戻ってください。クライアントの変更やアップグレードは インストーラーページ へ、全プラットフォームでClash Plusを第一推奨としています。