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

診断前の準備:まず変数を固定してから手を動かす

プロキシ経路上の可変要素は非常に多いです:ローカルネットワーク、クライアント、コア、設定ファイル、サブスクリプション、ノードサーバー、対象ウェブサイト——どの層に問題があっても「ページが開かない」という同じ症状として現れます。診断の第一原則は一度に一つの変数だけを変更することです。そうしないと問題が消えても何が効いたのか分からず、再発時にまた最初からやり直すことになります。

手を動かす前に4つの基本情報を記録する

• クライアントとコア:使用しているクライアント(Clash Plus、Clash Verge Rev、FlClash など)、コアが Meta/mihomo か原版かを確認します。コアの違いによって一部の設定フィールドが認識されるかどうかが変わります。詳細はブログ記事3種類のコアの違い比較を参照してください。
• 動作モード:現在システムプロキシか TUN か、振り分けモードがルール(Rule)、グローバル(Global)、ダイレクト(Direct)のどれかを確認します。「時々うまくいく」問題の多くはモードの選択ミスが原因です。
• 設定の入手元:サブスクリプションリンクからの導入、ローカル YAML ファイル、あるいはサブスクリプション変換サービスを経由したものかを確認します。変換済みの設定は変換テンプレート由来の問題も追加で考慮する必要があります。
• 問題の範囲:すべてのウェブサイトが開かないのか、一部のウェブサイトだけ異常なのか;すべての端末で問題が起きているのか、1台だけなのか。範囲が明確であればあるほど、以降で読み飛ばせる章が増えます。

ログレベルを debug に切り替える

各クライアントにはログパネルが用意されており、デフォルトのレベルは通常 info で、接続確立とルールヒットのみを記録します。診断中は一時的に debug に切り替えることを推奨します:DNS 問い合わせの過程、ルールの逐次マッチング、ハンドシェイク失敗の原因などがすべて出力されます。ローカル設定ファイルの対応フィールド:

log-level: debug   # 診断終了後は info に戻すこと。debug ログは量が非常に多い

二分探索による原因特定

問題がどの層にあるか判断がつかない場合は、「コストの小さい順」で一つずつ切り替えて確認します:まずノードを変更(単一ノードの故障を除外)→ 次にグローバルモードに切り替え(振り分けルールの問題を除外)→ 動作確認済みの別の設定に変更(サブスクリプションの問題を除外)→ 最後にクライアントまたはネットワーク環境を変更(端末やローカルネットワークの問題を除外)。各層を切り替えるごとに1回テストし、問題がどの層で消えたか、そこに障害があります。

↑ 目次へ戻る

ネット接続不可:プロキシ起動後すべてのウェブサイトが開かない

症状の定義:クライアントは接続済みと表示されているが、ブラウザでどのウェブサイトにアクセスしても失敗する。ダイレクト接続なら開けるはずのサイトも含まれます。この種の問題の要点は、まず「トラフィックがそもそもプロキシに入っていない」のか「プロキシには入っているが出口が通っていない」のかを見分けることです。両者の対処法は全く異なります。

ステップ1:curl でローカルプロキシポートを直接テストする

ブラウザやシステムプロキシ設定を経由せず、ローカルポートに直接リクエストを送ることで、コア自体が動作しているかを即座に判断できます:

# 中国本土からアクセス可能なアドレスをテスト(コアとダイレクトルールの検証)
curl -I -x http://127.0.0.1:7890 https://www.baidu.com

# 204 検出用アドレスをテスト(プロキシ出口の検証)
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

結果は3パターンあります。両方通れば、コアは正常で問題はシステムプロキシ層にあるため、第7章へ進んでください。1つ目は通り2つ目がタイムアウトの場合、ダイレクトは正常でプロキシ出口が通っていないため、第3章でノードを診断してください。両方が拒否(connection refused)される場合、コアがこのポートをリスニングしていないことを意味し、以下に進んでください。

ステップ2:ポートがリスニングされていない3つの原因

• 設定の解析失敗により、コアがそもそも起動していない。ログに error レベルの YAML 解析エラーが出ます。よくあるのは手動編集時のインデントのずれ、または原版コアが Meta 専用フィールドを読み込んだ場合です。設定を修正するか、該当構文をサポートするコアに切り替えます。
• ポートが他のプログラムに占有されている。ログに bind: address already in use と出ます。Windows では netstat -ano | findstr 7890、Linux/macOS では lsof -i :7890 で占有プロセスを見つけ、終了させるか、設定内の mixed-port を変更して再起動します。
• ポートが IPv6 のみでリスニングされているか、ファイアウォールでブロックされている。設定内に通常とは異なる bind-address が書かれていないか確認してください。Windows で初回起動時にファイアウォール認可ポップアップを拒否した場合、「Windows セキュリティ → ファイアウォール → アプリにファイアウォール経由を許可」で手動許可が必要です。

ステップ3:「プロキシを切ってもネットが使えない」残留物の確認

クライアントが異常終了(クラッシュ、強制終了)した場合、システムプロキシを元に戻せず、システムが既に存在しない 127.0.0.1 のポートを指し続けることがあり、「Clash を起動しない方がネットが使える」という現象になります。対処法:クライアントを再起動し、一度正常に終了させて設定を復元させる;あるいは手動で解除する——Windows は「設定 → ネットワークとインターネット → プロキシ」で手動プロキシを無効化、macOS は「システム設定 → ネットワーク → 詳細 → プロキシ」で各項目のチェックを外します。TUN モードの異常終了では仮想ネットワークカードのルーティングが残る場合があり、システムを再起動すればクリアされます。

↑ 目次へ戻る

ノードタイムアウト:遅延テストが全滅または大半が赤表示

クライアント内の遅延テストは ping ではなく、そのノード経由で検出用 URL(通常は HTTP 204 を返すアドレス)に完全なリクエストを送り時間を計測するものです。したがって「タイムアウト」は、完全なプロキシ経路——端末 → ノードサーバー → 検出アドレス——のうち少なくとも1箇所が切れていることを意味します。

全ノードタイムアウト時の診断順序

1. まずローカルネットワークを確認:プロキシを切って中国本土のウェブサイトに直接アクセスします。ローカルが断線している場合、すべてのノードが必ずタイムアウトになります。これは最も見落としやすいステップです。
2. サブスクリプションの期限切れを確認:サービス提供元の契約期限切れやトラフィック使い切りの場合、サーバー側が認証を拒否します。すべてのノードが同時にタイムアウトになるのは典型的な特徴です。サービス提供元のユーザーパネルで状態を確認してください。クライアント内で無駄に時間を消費しないこと。
3. システム時刻を確認:一部の暗号化プロトコルは時刻のずれに敏感で、端末の時刻が標準時刻と大きくずれているとハンドシェイクが黙って失敗します。スマートフォンとPC両方で「自動時刻設定」を有効にしてください。
4. 検出アドレスを変えて再テスト:検出用 URL 自体がブロックされたり不安定な場合、良好なノードでもタイムアウト表示になります。クライアント設定でテストアドレスを別の 204 エンドポイントに変更して再テストしてください。
5. サブスクリプションを更新:サービス提供元がサーバーの IP やポートを変更した場合、旧設定内のノードは当然すべて無効になります。手動でサブスクリプションを更新して最新のノードリストを取得してください。更新に失敗する場合は第4章を参照してください。

一部ノードのタイムアウト:正常現象と異常の境界線

プロバイダのノードに個別故障があるのは通常のことで、少数のノードのタイムアウトは対処不要で、使えるノードに切り替えれば十分です。警戒すべきは同一プロトコルのノードが集団でタイムアウトになるケースです——例えば特定プロトコルのノードがすべて落ち、他のプロトコルは正常な場合、そのプロトコルの特徴が現在のネットワーク環境で狙われている可能性が高く、短期的に別プロトコルへ切り替え、サービス提供元にフィードバックしてください。もう一つのパターンは「有線ではタイムアウト、テザリングでは正常」またはその逆で、これはローカルネットワークが特定のポート/プロトコルをブロックしていることを示し、会社や学校のネットワーク環境でよく見られます。

テスト数値の読み方

もう一点注意:遅延が低いことは速度が速いことと同義ではありません。遅延は往復時間を反映するもので、帯域が十分かどうかは第5章の測速方法で確認してください。自動選択グループ(url-test)は周期的に自動で再テストして切り替えます。ノードが頻繁に切り替わる問題も第5章で合わせて扱います。

↑ 目次へ戻る

サブスクリプション失敗:導入エラーと更新失敗の対処法対照表

サブスクリプションの問題は2段階に分かれます:初回導入の失敗はフォーマットの問題であることが多く、これまで正常だったのに特定の更新から失敗し始めた場合はネットワークまたはサーバー側の問題であることが多いです。まずクライアントが表示するエラー内容を確認し、それに対応する対処法を当ててください。

エラー表示対照表

フォーマットの問題:まず入手したものが何かを見分ける

Clash クライアントは YAML 構造の設定しか認識しませんが、市場に流通しているサブスクリプションには Base64 ノードリストや各プロトコル専用フォーマットもあります。Base64 のサブスクリプションを直接 Clash クライアントに与えると「解析失敗」になります。見分け方は簡単です:ブラウザでサブスクリプションリンクを開き、返される内容が proxies:、proxy-groups: といったフィールドで始まっていれば Clash 形式;空白のない長い英数字の並びであれば Base64 です。フォーマットの違いと変換の原理については、ブログ記事Clash サブスクリプションフォーマット詳解で自前の変換サービスの構築方法も含めて詳しく解説しています。

「時々うまくいく」更新失敗

サブスクリプションのドメイン自体が一部のネットワーク環境で干渉を受けるのはよくあるケースで、そのため矛盾が生じます:サブスクリプションの更新にはプロキシが必要なのに、プロキシの設定自体がサブスクリプションから来ている、というものです。多くのクライアントには「プロキシ経由で更新」というスイッチがあり、現在の状況に応じて逆に試してみてください:プロキシが使える場合はオンにして更新、プロキシが既に無効な場合はオフにしてダイレクトで更新します。両方失敗する場合は、スマートフォンのテザリングでPCを一度更新させ、使える設定を取得してからプロキシを復元し、通常のネットワークに戻してください。また、一部のクライアントはサブスクリプションの自動更新間隔を設定できるので、12時間か24時間に1回程度に設定してください。頻繁すぎる自動更新はサーバー側のレート制限に触れてかえって失敗しやすくなります。

↑ 目次へ戻る

速度低下:接続はできるが帯域が期待に届かない

速度の問題を診断する前提として、まず基準値を確立してください:プロキシを切って裸速を1回測定し、プロキシをオンにしてもう1回測定します。この2つを比較しなければ意味がありません。裸速が 50 Mbps しかないなら、どのノードも 200 Mbps を出せるはずがありません。

ボトルネックがどの区間にあるかを特定する

1. 複数の異なる地域のノードで測速する。すべてのノードが遅く、しかも同程度に遅い場合、ボトルネックはローカル側(ルーターの性能、通信事業者の国際出口、Wi-Fi 信号)にある可能性が高いです。個別のノードだけが遅い場合は、そのノード自体の負荷または回線の問題で、ピーク時間帯(夜間)に特に目立ちます。
2. プロトコルのオーバーヘッドを比較する。同じサーバー上で、多層の伝送カプセル化を伴うプロトコル(WebSocket + TLS の組み合わせなど)の処理量が軽量なプロトコルより低いのは正常な物理的オーバーヘッドであり、故障ではありません。
3. 二重プロキシになっていないか確認する。ブラウザ拡張のプロキシ、システムに残っている他の VPN が Clash と重なっている場合、トラフィックが2回迂回し、速度は半減以上に落ちます。診断中は他のプロキシツールをすべて無効化してください。

振り分けの不正確さによる「見せかけの遅さ」

中国本土のウェブサイトが急に遅くなった場合、8割はノードの問題ではなく、そのトラフィックが誤ってプロキシに送られたことが原因です。典型的な原因は GeoIP/GeoSite データベースが古くなっており、新しく追加された国内ドメインや IP セグメントがデータベースに含まれておらず、ルールにマッチしないためデフォルトのプロキシ経路を通らされてしまうというものです。判断方法:プロキシをオンにした状態で国内サイトにアクセスし、クライアントの接続パネルでこの接続が DIRECT かプロキシグループのどちらにヒットしているか確認します。修正方法(Geo データベースの更新、ルールの有効性検証)についてはブログ記事GeoIP と GeoSite データベースの更新方法で段階的に解説しています。

自動選択グループのパラメータチューニング

url-test による自動選択を使う場合、2つのパラメータが体感に直接影響します:interval は再テストの周期を、tolerance は「新しいノードが現在のノードよりどれだけ速ければ切り替えるか」を決定します。tolerance を設定しない、または小さすぎる値に設定すると、数ミリ秒の揺れで頻繁にノードが切り替わり、切り替えごとに既存の接続が切断されるため、「通信が途切れ途切れになる」感覚になります。参考の書き方:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300      # 5分ごとに再テスト
    tolerance: 60      # 新しいノードが60ms以上速い場合のみ切り替え
    proxies:
      - ノードA
      - ノードB
      - ノードC

↑ 目次へ戻る

DNS 問題:解析失敗、汚染、Fake-IP の副作用

DNS はプロキシ経路の中で最も見えにくい層です:症状はよく「一部のサイトが開かない」「初回アクセスが遅く、その後正常になる」「表示される IP アドレスが奇妙」という形で現れ、直接 DNS エラーとして報告されることはありません。Clash の2種類の DNS 強化モードを理解しておくことが診断の前提です。

fake-ip と redir-host の違い

fake-ip モードでは、コアは各ドメイン問い合わせに対して即座に予約済みネットワーク帯(デフォルト 198.18.0.0/16)内の偽 IP を返し、実際の解析はトラフィックが実際に発生する際に経路の遠端で完了します——低遅延で汚染がなく、現行の主流クライアントのデフォルトです。代償として、端末側が受け取る IP が実在のアドレスではないため、実際の IP に依存する一部のプログラム(LAN 内発見、一部のオンラインゲーム、一部の銀行系アプリ)で異常が起きます。redir-host はローカルで先に実際の解析を完了してからルールにマッチさせるため互換性は良いものの、解析結果が汚染される可能性があります。どちらのモードにも絶対的な優劣はなく、症状に応じて切り替えます。

典型的な症状と対処法

• ネットワークを切り替えた後に多くのサイトが開かず、クライアント再起動で回復する:fake-ip のマッピングキャッシュと新しいネットワーク環境が一致していません。多くのクライアントには「fake-ip キャッシュのクリア」ボタンがあり、あるいは直接コアを再起動してください。
• LAN内の機器(プリンター、NAS)へのアクセスが異常:LAN内のドメインが fake-ip に取り込まれています。fake-ip-filter でローカルドメインを除外してください。下記の例を参照。
• プロキシを切ってもDNSが異常なままである:TUN モードがシステムDNSを引き継いだ後、異常終了で復元されていません。システムのネットワークサービスを再起動するか、端末を再起動してください。
• 特定のドメインが明らかに誤ったアドレスに解析される:上流のDNSが汚染されています。nameserver を暗号化DNS(DoH/DoT)に変更してください。

利用可能な DNS 設定のベースライン

dns:
  enable: true
  listen: 0.0.0.0:53
  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
  fallback-filter:
    geoip: true
    geoip-code: CN

このベースラインの考え方:中国国内の暗号化DNSをメイン解析に使い速度を確保し、海外の DoH を fallback とし、fallback-filter は GeoIP で解析結果の所属を判定します——結果が CN セグメントに含まれない場合は fallback の回答を採用し、汚染を回避します。注意点として fallback-filter は GeoIP データベースに依存しており、データベースが古いと同様に誤判定を起こします。これは第5章で触れた Geo データベースの更新と同じ話です。

↑ 目次へ戻る

システムプロキシ無効:ブラウザは正常だが一部アプリがプロキシを通らない

症状の定義:クライアントは正常に動作し、ブラウザも問題ないが、一部のアプリ(コマンドラインツール、ストアアプリ、ゲームクライアント)のトラフィックが全くプロキシを経由していない。根本原因は「システムプロキシ」がOSレベルの推奨値にすぎず、アプリはそれを読むかどうかを自由に選べ、種類によって挙動が大きく異なることにあります。

システムプロキシを読まない3種類のアプリ

コマンドラインプログラム:環境変数の書き方

# Windows PowerShell(現在のセッションのみ有効)
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# Linux / macOS(シェル設定ファイルに書けば永続化)
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 検証
curl -I https://www.gstatic.com/generate_204

UWP アプリ:ループバック制限の解除

Windows ストアアプリはデフォルトで 127.0.0.1 へのアクセスが禁止されており、システムプロキシがローカルポートを指している場合、このタイプのアプリは即座に通信不能になります。管理者権限で CheckNetIsolation LoopbackExempt -a -n=<パッケージファミリー名> を実行して個別に許可するか、GUIツールで一括チェックする方法もあります。詳しい操作手順、パッケージファミリー名の確認方法、検証手段については、ブログ記事Windows UWP アプリがプロキシを通らない場合の対処法を参照してください。

根本的な解決:TUN モード

TUN は仮想ネットワークカードを通してネットワーク層でトラフィック全体を引き継ぐため、アプリがシステムプロキシを読むかどうかに関係なくなり、「一部アプリがプロキシを通らない」問題を根本的に解決する手段です。有効化のポイント:デスクトップ端末では管理者/root 権限を付与して仮想ネットワークカードサービスをインストールする必要があります;有効化後はコアの DNS ハイジャックも同時に有効にすることを推奨します。そうしないとアプリが独自にDNSを指定した際に振り分けが不正確になります;他の VPN ソフトの仮想ネットワークカードと排他的で、同時に有効化できるのは1つだけです。Linux 環境での TUN 導入の詳細は、ブログ記事Linux での Clash 導入全手順を参考にしてください。

↑ 目次へ戻る

クライアントクラッシュ:起動失敗、強制終了、リソース異常

クラッシュ系の問題はまず3つの形態に分けます:起動と同時に終了する、動作中にランダムに強制終了する、終了はしないがメモリ/CPU使用率が異常になる。3つの診断の入口は異なります。

起動と同時に終了:ほとんどが設定の問題

クライアント GUI の起動はコアが設定を正常に読み込むことに依存しており、設定の解析に失敗した場合、一部のクライアントはエラー表示なしにそのまま終了します。診断方法:設定ディレクトリ内のアクティブな設定を最小構成(DIRECT ルールのみ)に置き換え、正常に起動できれば設定の問題であることが分かり、その後内容を段階的に追加してエラーのあるフィールドを特定します。最も一般的な発生源:

• YAML のインデントエラー——手動編集後に空白を余分または不足して打ってしまったもので、YAML はインデントに対して一切の許容がありません;
• コアの不一致——設定内で Meta/mihomo 専用フィールド(一部のルールタイプやアウトバウンドプロトコルなど)を使っているが、クライアントが動かしているのは原版コアの場合。フィールドの対応範囲対照はコアの違い比較を参照;
• ルールセット/Geo リソースのダウンロードが不完全——初回起動時に外部リソースを取得する必要があり、ネットワークが通っていないと一部のコアはエラーを出して終了します。まずダイレクト接続で初期化を完了させてください。

動作中のランダムな強制終了

1. クライアントログとシステムログを確認:Windows はイベントビューアーのアプリケーションログ、macOS はコンソールのクラッシュレポートを確認し、GUIがクラッシュしたのかコアがクラッシュしたのかを特定します。GUIがクラッシュしコアはまだ生きている(ポートに curl が通る)場合は、多くは画面層の問題で、再インストールまたはクライアント変更を試します。コアがクラッシュしている場合は設定とリソースを重点的に確認します。
2. 巨大なサブスクリプションを確認:数千ノードのサブスクリプションは低スペック端末での解析や遅延テストの際にメモリ負荷が非常に大きくなります。サブスクリプションを整理するか、自動測速をオフにして様子を見てください。
3. セキュリティソフトとの衝突:プロキシソフトの挙動特徴は誤検知されやすいため、クライアントのディレクトリをセキュリティソフトのホワイトリストに追加して再テストしてください。

メモリ/CPU使用率の異常

接続数は使用率の第一の影響因子です:P2Pダウンロードのように瞬間的に数千の接続を開くシナリオでは、メモリの上昇は正常な現象で、接続が解放されれば下がるはずです。持続的に下がらない場合は、密度の高すぎる自動測速が有効になっていないか確認してください(複数の url-test グループ × 短い interval × 大量のノード = 継続的なテストの嵐)。interval を300秒以上に緩めてください。デスクトッププラットフォームで長期常駐させる場合は、メンテナンスが活発なクライアントを優先的に選んでください——各クライアントのメンテナンス状況とリソース使用率の横断比較は横断評価ページを参照。メンテナンスが停止したクライアント(Clash for Windows など)はクラッシュしても修正の手段がないため、Clash Plus または Clash Verge Rev への移行を推奨します。

↑ 目次へ戻る

Android 専用:バックグラウンド強制終了、VPN 衝突、システム設定による干渉

Android 端のプロキシクライアントはシステムの VpnService として動作するため、故障パターンはデスクトップ端とは明確に異なります:デスクトップ端の問題は主に設定層にありますが、Android 端の問題の半分はシステムによるバックグラウンドサービス管理にあります。本章は Clash Plus、Clash Meta for Android、FlClash などのクライアントに共通する挙動を基準としています。

接続が頻繁に自動切断:バックグラウンドがシステムに回収された

画面ロックから一定時間後にプロキシが切断され、通知バーのアイコンが消えるのは、国産 ROM の積極的な省電力戦略が VPN サービスを強制終了する典型的な現象です。以下を項目ごとに設定してください:

1. システム設定 → バッテリー → クライアントを探す → 「制限なし/バックグラウンド実行を許可」に変更し、「自動管理」をオフにする;
2. 最近使用したアプリ画面でクライアントをロックする(多くの ROM でスワイプダウンまたは長押しロックに対応)、一括クリアによる誤終了を防ぐため;
3. システム設定 → アプリ → クライアント → 「自動起動」と「連動起動」を許可する;
4. クライアント内で「起動時に自動起動」を有効にし、システムの常時オン VPN(設定 → ネットワーク → VPN → 歯車アイコン → 常時オンにする VPN)と組み合わせることで、強制終了されてもシステムが自動的に再起動させます。

VPN チャネルの衝突

Android は同時刻に1つのアプリしか VPN チャネルを保持できません。別の VPN 系アプリ(「アクセラレーター」「広告フィルター」系のツールも含む)が起動すると、システムは黙って Clash のチャネルを切断し、クライアント側には「接続切断」としか表示されません。診断方法:設定 → ネットワーク → VPN で現在アクティブな VPN が何かを確認し、衝突するアプリを無効化します。同様に、「プライベート DNS」(Private DNS)を特定のホスト名に設定している場合、DNS 問い合わせがクライアントの DNS モジュールを迂回し、振り分けの不正確さを招きます。DNS 関連の問題を診断する際は、まずプライベート DNS を「自動」または「オフ」に設定してください。

インストールと更新の問題

• 「パッケージの解析エラー」と表示される:ダウンロードした APK が端末のアーキテクチャと一致していません。近年の主流機種は基本的に arm64-v8a 版を選んでください。ごく古い端末のみ armeabi-v7a が必要です。各アーキテクチャのインストーラーはダウンロードページの Android セクションにクライアントごとに掲載しています;ダウンロードの中断によるファイルの不完全さも同じエラーを起こすので、再ダウンロードしてください。
• 上書きインストールの失敗:署名が一致しない場合(異なる入手元からダウンロードした同名アプリなど)は上書きできず、アンインストール後に再インストールする必要があります。再インストール前にクライアントで設定をエクスポートし、サブスクリプションの消失を防いでください。
• インストール後にVPN認可のポップアップが出ない:一部の ROM は認可ポップアップをブロックすることがあります。システムのVPN設定でそのアプリの認可を手動で一度完了させてください。

ログの取得:adb logcat

画面上では原因が分からない場合は、adb で動作ログを取得します。PC にプラットフォームツールをインストールし、スマートフォンでUSBデバッグを有効にした後:

# エラーレベルの出力だけを見て、切断の瞬間のエラーを観察
adb logcat *:E

# アプリのパッケージ名でフィルタ(パッケージ名は実際にインストールしたクライアントを基準に)
adb shell pidof com.github.metacubex.clash.meta
adb logcat --pid <前のステップで出力されたプロセスID>

ログに VpnService revoked が出ている場合、チャネルが他のアプリに奪われたことを示します;メモリ関連の kill 記録が出ている場合は本章冒頭の省電力戦略の対処に戻ってください。モバイル端で体系的な初回設定フローが必要な場合は、設定チュートリアルに戻って手順どおりに実行してください。「インストール完了直後からうまくいかない」問題の大半は、チュートリアルの基本フローで既に回避されています。

↑ 目次へ戻る

該当する症状が見つからない場合は?

本ページが網羅しているのは、明確な再現手順のある8種類のトラブルです。問題がこの中にない場合:「初回設定がそもそも通らない」という問題であれば、設定チュートリアルに戻って最初から確認してください;クライアント自体の機能的な限界を疑う場合は、横断評価で使用しているクライアントが対応する機能をサポートしているか確認してください;クライアントの入れ替えや追加インストールが必要な場合は、ダウンロードページへ——全プラットフォームで Clash Plus を第一推奨とし、Android 端では Clash Meta for Android と FlClash も選択できます。プロトコル、コア、サブスクリプション関連の背景知識と専門的な診断は、技術ノートで継続的に更新しています。