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

本ページと使い方ガイドは役割分担が明確。ガイドはインストールから初回接続成功までの基本操作をカバーし、初めて設定するユーザー向け。本ページは「すでに導入済みだが、どこかで問題が発生した」場面向けで、症状から章を特定し、上から順に手順を実行すればよい。各章の手順は発生確率の高い順に並べており、最初の数ステップで大半のケースが解決する。まだクライアントを入れていない場合はまずダウンロードページでインストーラーを取得(全プラットフォーム共通で Clash Plus を推奨)し、ガイドに沿って初期設定を済ませてから、問題が出たら本ページに戻ってきてほしい。

一、切り分けの基本方針とログの読み方

設定を触る前に、二つの習慣を身につけておく。レイヤーごとに切り分けること、そして一度に一つの変数しか変えないこと。プロキシ経路は上から下に五層に分解できる——クライアントUI、内核プロセス、設定・サブスク、リモートノード、ローカルのシステム環境。症状がどの層に出ているかで、調べる方向が決まる。「再インストール・サブスク変更・DNS変更」を順不同で試すと、単純な問題を複合障害に変えてしまうことが多い。

レイヤー切り分けの基本順序

• クライアント層:画面が正常に開くか、スイッチの状態が想定通りか、エラーダイアログが出ていないか。
• 内核層:内核プロセスが動作しているか、リスニングポートに接続できるか(第二章の curl による確認法を参照)。
• 設定層:サブスクが正常に読み込まれているか、ルールモード(Rule/Global/Direct)がどれになっているか、ルールが想定した出口に一致しているか。
• ノード層:ノードが使えるか、レイテンシテストの結果はどうか、サブスクが期限切れになっていないか。
• システム層:システムプロキシ/TUNが実際にシステムへ反映されているか、ファイアウォールや他のネットワークソフトが干渉していないか。

ログページとログレベル

ログページは切り分けの主要な情報源。多くのクライアントの既定レベルは info で、各コネクションの宛先ドメイン、ヒットしたルール、最終的な出口が確認でき、「このトラフィックがどのノードを通ったか」を判断できる。DNSやハンドシェイク層の問題を調べるときだけ一時的に debug に切り替え、確認が終わったら戻すこと。そのままにするとログ量が増えて画面の動作が明らかに重くなる。

最小構成での検証

「サブスクの複雑な設定に問題があるのでは」と疑うときは、最小構成で内核とノード自体が正常かを検証する。以下の例を minimal.yaml として保存し、任意の利用可能なノードのパラメータに置き換えて、クライアントでローカル設定として読み込む。最小構成は通るが完全なサブスクは通らない場合、問題はサブスクのルールやDNS部分にある。最小構成も通らない場合、問題はノードかシステム層にある。

mixed-port: 7890
log-level: info
mode: rule
proxies:
  - name: test-node
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
proxy-groups:
  - name: PROXY
    type: select
    proxies: [test-node]
rules:
  - MATCH,PROXY

二、プロキシをオンにするとネットに繋がらない

症状の定義:クライアントをオンにすると全てのWebサイトが開けなくなる、あるいはクライアントを終了してもネットが復旧しない。最もよくあり、かつ最も誤判断しやすい問題で、まず「プロキシ経路の障害」と「システムプロキシ設定の残留」を区別することが重要。

ステップ1:ローカルの基本ネットワークを確認

クライアントを終了し、日本国内のWebサイトに直接アクセスする。開けない場合は本体側のネットワーク自体に問題があり、プロキシとは無関係。ルーターや通信事業者側の対応を先に行う。開ける場合は次のステップへ。クライアント終了後も全体的にネットが使えない場合は、システムプロキシの残留が濃厚なので、本章の「システムプロキシ残留のクリア」節へ直接進む。

ステップ2:コマンドでブラウザを介さずプロキシポートを検証

ブラウザには独自のプロキシキャッシュや拡張機能の干渉があり、検証ツールには不向き。curl で内核のポートに直接リクエストを送れば、結果がクリーンで信頼できる:

# 内核のプロキシポートが使えるか検証
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

# HTTP 204 が返る → 内核とノードの経路は正常、問題はシステムプロキシ層。第七章を参照
# connection refused → 内核がリスニングしていない。第八章(プロセス/ポート問題)を参照
# 長時間応答なしでタイムアウト → ノードが使えない。第三章を参照

ステップ3:ルールモードと出口を確認

プロキシページ上部のモード切り替えを誤って操作したことでも「全体的に繋がらない」状態になる:Globalモードで無効になったノードを指している場合、全トラフィックが影響を受ける。Directモードは環境によっては一部のサイトに到達できなくなる。日常的にはRuleモードを維持し、現在選択中の策略グループのノードがレイテンシテストで緑色になっているか確認する。また、サブスクに MATCH,REJECT のような全遮断ルールが誤って有効化されていないかも確認——ログページで多数のコネクションが REJECT にヒットしている場合、これが原因。

システムプロキシ残留のクリア

クライアントが異常終了(クラッシュ、強制終了)した場合、システムプロキシ設定を復元する時間がなく、システムは存在しない 127.0.0.1:7890 にトラフィックを向け続けたままになり、「クライアントを終了したら逆にネットが全部止まる」という現象になる。対処法:クライアントを再度開いて、正常に終了させ直すと通常自動的に復元される。ダメな場合は手動でクリア:Windowsは「設定 → ネットワークとインターネット → プロキシ」で「プロキシサーバーを使用する」をオフにする。macOSはコマンドで:

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

三、全ノードがタイムアウト、またはレイテンシテスト失敗

まず「全ノードがタイムアウト」なのか「一部だけタイムアウト」なのかを区別する。両者の原因はほぼ重ならない。

全ノードがタイムアウトする場合

1. 本体の時刻を確認。多くの暗号プロトコルは時刻のズレに敏感で、システム時刻と標準時刻の差が1〜2分を超えるとハンドシェイクが全て失敗する。システムの自動時刻同期をオンにし、手動でタイムゾーンを変更した場合は特に確認すること。
2. サブスクの期限切れを確認。サービス提供元は期限切れ後もノード項目自体は残すが接続を拒否することが多く、これが全ノードタイムアウトとして現れる。提供元の管理画面で有効期限を確認し、期限切れなら更新後にサブスクを再取得する。
3. ファイアウォールとセキュリティソフトを確認。Windowsで内核を初回起動した際にファイアウォール許可ダイアログを拒否していると、送信接続が無言でブロックされることがある。「Windows セキュリティ → ファイアウォールとネットワーク保護 → アプリのファイアウォール経由の許可」で内核プロセスが許可されているか確認する。サードパーティのセキュリティソフトも同様。
4. 別のネットワーク環境で交差検証。スマートフォンのテザリングにPCを繋いで再テストする。テザリングでは正常、元のネットワークでは全タイムアウトなら、そのネットワークがプロキシプロトコルを干渉していることになり、クライアントやサブスクとは無関係。

一部のノードがタイムアウトする場合

個別ノードのタイムアウトは正常な現象:ノードサーバーの障害、線路の変動、宛先ネットワーク側での遮断などが原因。対処の原則はシンプル——レイテンシが正常なノードに切り替えて使い、数時間後かサブスク更新後に再確認する。特定地域のノードが長期間全滅している場合はサービス提供元に報告する。クライアント側で対応できることはない。

レイテンシ数値の正しい理解

レイテンシテストは url-test で指定したテストアドレスに一度リクエストを送り時間を計測するもので、数値は「テスト対象への一往復」を反映し、実際のブラウジング体感と等しくはない。テストアドレス自体が到達不能なとき、健全なノードでもタイムアウト表示になる。テストアドレスは策略グループでカスタマイズできる:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [node-a, node-b]

レイテンシ数値と実体感のズレの原因(テスト対象、パケットロス、帯域のボトルネック)については、ブログで専門的に解説している:Clashレイテンシテストの仕組み解説。

四、サブスクのインポート・更新失敗

サブスク関連のエラーメッセージには多くの情報が含まれる。まずエラーキーワードで表を照らし合わせ、詳細節を確認する。

フォーマット不一致

「リンクは他のソフトでは使えるのに、Clashではインポート失敗またはノードが空になる」場合、9割はフォーマットの問題:Clash系クライアントが読み込むのは完全なYAML設定だが、一部のリンクはBase64エンコードされた裸のノードリストを返す。判別方法はリンクをブラウザに貼って開いてみること——proxies:、rules: のようなフィールドが見えればYAML、空白のない英数字の長い文字列に見えればBase64。サービス提供元の管理画面には通常「Clash用サブスク」専用リンクが用意されているので優先的に使う。なければサブスク変換ツールでClash形式に変換してからインポートする。各フォーマットの構造差異と変換時の注意点はブログを参照:Clashサブスクフォーマット解説。

サブスク更新時のネットワークループ問題

サブスクサーバーが一部のネットワーク環境から直接到達できず、更新リクエスト自体がプロキシを必要とする一方、プロキシはサブスク内のノードに依存する——鶏と卵の問題。多くのクライアントはサブスク設定に「プロキシ経由で更新」のスイッチを用意している:ノードがまだ使える間はオンにして更新する。ノードが全滅している場合はオフにし、サブスクサーバーに直接到達できるネットワーク(例えばスマホのテザリング)に切り替えて一度更新し、ノードが復旧したら元に戻す。

手動インポートによる最終手段

自動更新がどうしても失敗する場合の確実な回避策がある:ブラウザで直接サブスクリンクを開き、返された内容を .yaml ファイルとして保存し、クライアントの設定画面で「ローカルファイルをインポート」を選ぶ。この方法はクライアントのダウンロードロジックを経由しないため、UAやプロキシループなどネットワーク側の干渉を全て回避でき、「リンク自体が壊れているのか、クライアントのダウンロード処理が壊れているのか」を検証する際にも使える。

五、接続は正常だが速度が遅い

まずレイテンシと帯域を区別する

「遅い」には2種類ある:Webページが開くまでの待ち時間が長いのはレイテンシが高い、動画の解像度が上がらない・ダウンロード速度が低いのは帯域不足。レイテンシが低いことは帯域が大きいことを意味しない——レイテンシテストは小さなリクエストを一度送るだけで、スループットは測れない。両者の切り分け方向は異なる:レイテンシが高い場合は物理的に近いノードへの変更を優先、帯域が低い場合はノードの倍率とローカルの回線を優先的に調べる。

切り分け手順

1. ノードを変えて比較。同じサブスク内で3つ以上の異なる地域のノードをそれぞれテストする。全て遅ければ次へ。個別だけ遅ければそのノード自体の混雑であり、避ければよい。
2. 直接接続の帯域をベースラインとして測定。プロキシをオフにして、日本国内の速度測定サイトで一度計測する。直接接続自体が数十Mbpsしかない場合、プロキシがそれを超えることはないので、期待値を先に補正する。
3. 本体の帯域使用を確認。ダウンロードツール、クラウド同期、システム更新はアップロード/ダウンロード帯域を占有する。ログページや接続ページをトラフィック順に並べ、帯域を消費しているプロセスを特定する。
4. 振り分けのズレを確認。ルール設定が不適切だと国内向けトラフィックが海外ノードを迂回することがあり、「国内サイトも遅くなった」という形で現れる。ログページで国内ドメインが DIRECT にヒットしているか確認する。そうでない場合はルールセットの順序を確認する。多くはカスタムルールがGEOIPの兜底ルールより前に配置されている。
5. ピーク時間帯で交差検証。毎日特定の時間帯だけ遅い場合は線路の混雑の典型的な特徴。人気の少ない地域のノードに変える、またはサービス提供元に線路の種類を確認する。

六、DNS関連の問題

2種類の解決モードの違い

Clash系の内核がDNSを処理する強化モードには fake-ip と redir-host の2種類がある。fake-ipは 198.18.0.0/16 の予約セグメントの仮アドレスでローカルクエリに応答し、実際の解決はノード側で行われる。マッチが速く漏出も少ないため、現在の主流の既定値になっている。redir-hostはローカルで実際の解決を完了する。仕組みの詳しい解説はブログを参照:Fake-IPモードの仕組み詳解。正常に動作するDNS部分の設定はおおむね次のようになる:

dns:
  enable: true
  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

典型的な症状と対処

• IPでアクセスできるがドメインでは開けない:DNS解決の段階に障害がある。設定内の dns.enable が true か、nameserver に到達できるかを確認する。一時的にログを debug に切り替えれば、各クエリが誰に送られ何が返ってきたかを直接確認できる。
• あるソフトが 198.18.x.x に接続していると表示される:これはfake-ipの仮アドレスで、プロキシを経由しないプログラムがそれを取得してしまっている。該当プログラムが使うドメインを fake-ip-filter に追加し、そのクエリだけ実アドレスを返すようにする。
• LAN内のデバイス(プリンター、NAS、画面ミラーリング)に繋がらない:fake-ipがローカルのドメイン解決を横取りしている。fake-ip-filter に *.lan、+.local のようなローカルサフィックスが入っているか確認する。固定ホスト名を使う機器の場合は、そのホスト名も追加する。
• ネットワーク切り替え後に全体的な解決異常:fake-ipのキャッシュが新しいネットワーク環境と不整合になっている。クライアントで「fake-ipキャッシュのクリア」を実行する(多くのクライアントが設定画面かトップ画面にボタンを用意している)、または内核を再起動する。
• オンラインゲームやP2P系アプリの異常:この種のアプリは実IPに敏感で、fake-ip下では問題が起きやすい。該当ドメインをfilterで例外にする、または全体をredir-hostモードに切り替えてテストする。

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

システムプロキシの能力の限界

「システムプロキシ」はOSにHTTPプロキシのアドレスを登録するだけで、この設定を能動的に読み取るプログラムだけがプロキシを経由する——ブラウザや多くの一般的なデスクトップソフトは読み取るが、コマンドラインツール、一部のチャットやゲームクライアント、多くのバックグラウンドサービスは読み取らない。これは故障ではなく、仕組み上の限界。判断方法:ブラウザは正常にプロキシを経由するが特定のソフトだけ経由しない場合、そのソフトがシステム設定を読み取っていないと基本的に断定できる。

コマンドラインをプロキシ経由にする

ターミナルの git、pip、npm などのツールは環境変数でプロキシを識別する。現在のセッションで一時的に設定するには:

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" が同等の設定になる。長期的に有効にしたい場合はシェルの設定ファイルに書き込む。調査段階では一時設定のみにし、消し忘れて新たな問題を起こさないよう注意する。

頑固なアプリはTUNモードで対応

TUNモードは仮想ネットワークアダプタを作成し、ネットワーク層で全TCP/UDPトラフィックを横取りする。プログラム側の対応に依存せず、「あるソフトがどうしてもプロキシを通らない」問題を解決する汎用的な方法。両方式の比較:

システムプロキシのスイッチはオンなのにシステムに反映されない

ごく一部のケースでクライアント側では「オン」と表示されているのに、システム設定は空になっていることがある:権限不足か、他のソフトが上書きしていることが多い。管理者権限でクライアントを実行して再試行する。それでも直らない場合は、起動時にプロキシ設定を書き換えるセキュリティ系・ネットワーク高速化系のソフトが動いていないか確認する。競合している場合はどちらか一方を選ぶしかない。

八、クラッシュと異常終了

起動即終了:まず設定の解析エラーを確認

開いた瞬間に落ちる、あるいはトレイアイコンが一瞬光って消える場合、まず設定ファイルの解析失敗を疑う。YAMLはインデントやコロン後のスペースに非常に敏感で、手動で編集した設定は重点的に確認する。特定方法:クライアントのログファイル(通常データディレクトリの logs サブディレクトリにある)を開き、末尾数行の error 記録を確認する。解析エラーには行番号が表示される。あるいはサブスクを未編集のバージョンに戻し、第一章の最小構成で起動できれば設定の問題だと確認できる。

ポートが使用中

内核起動時にリスニングポートが他のプロセスに占有されている(前回の内核プロセスが正常に終了していない、または別のプロキシソフトが動いているなど)場合、起動失敗や再起動の繰り返しが発生する。占有プロセスの確認:

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

占有プロセスが見つかったら終了させる。または、クライアント設定で mixed-port を空いているポート(例えば7891)に変更してから起動する。ポートを変更した場合は、第七章で7890と書いた箇所も合わせて置き換えること。

キャッシュ破損とクリーンな再インストール

実行中にランダムにクラッシュする、画面が白くなる、設定が変更できない場合は、クライアントのキャッシュクリアを試す:クライアントを終了し、データディレクトリに入って cache を名前に含むキャッシュ系サブディレクトリを削除する(profiles(サブスクと設定)は残す)。それでも安定しない場合はクリーンな再インストールを行う:先にprofilesディレクトリをバックアップし、アンインストール後に残った データディレクトリを手動で削除、ダウンロードページから現行バージョンを取得してインストールし、バックアップしたサブスクファイルを戻す。クライアント間の安定性や機能差が気になる場合は選び方ガイドを参考に別のクライアントで交差検証してもよい。

クラッシュの規則性の記録方法

不定期に発生するクラッシュは最も調査が難しい。以下の3つを記録しておくとよい:クラッシュ直前に何をしていたか、その時TUNをオンにしていたか、ログファイルの最後20行。この3つがあれば、自分で調べる場合もコミュニティに相談する場合も効率が大きく上がる。

九、モバイル特有の問題(Android / iOS)

Android:VPN権限とバックグラウンド生存

Androidクライアント(第一推奨はClash Plus。代替はダウンロードページのAndroid欄を参照)はシステムのVPNインターフェース経由でトラフィックを横取りする。初回起動時は必ず「VPN接続の作成」のシステムダイアログに同意する必要がある。その際に拒否した場合は「設定 → ネットワーク → VPN」で該当アプリの項目を削除し、再度権限を付与する。接続アイコン(ステータスバーの鍵/VPNマーク)は出ているのにトラフィックが流れない場合は、クライアント内のアプリ別プロキシ設定を確認する——ブラックリストモードで除外されたアプリ、ホワイトリストモードでチェックされていないアプリは、いずれもプロキシを経由しない。

「使っているうちに切れる」の大半はシステムの省電力機構がバックグラウンドを終了させているのが原因:日本国内の一部端末メーカーのカスタムシステムも含め、多くのAndroid端末は既定でバックグラウンドプロセスを積極的に回収する。対処セット:クライアントを電池最適化のホワイトリストに入れる(「制限なし」に設定)、マルチタスク画面でアプリをロックする、自動起動を許可する。この3つを設定してもまだ頻繁に切れる場合は、クライアント内の「常駐通知」系オプションをオンにしてプロセス優先度を上げる。

iOS:Network Extensionのメモリ制約

iOSクライアントはApp Store経由で配布され、第一推奨はClash Plus(ダウンロードページのiOS欄にストアリンクを直接掲載)。iOSのプロキシはNetwork Extension内で動作し、システムはこの拡張プロセスに厳しいメモリ上限を設けている——サブスク内のノード数が多すぎる、ルールセットが大きすぎる場合、拡張プロセスがシステムに強制終了され、「VPNアイコンが1〜2秒表示されてすぐ消える」「頻繁に自動切断される」という現象が起きる。対処法:サービス提供元に軽量版サブスクを提供してもらう、または変換サービスで使わない地域のノードや冗長なルールセットを削って設定サイズを圧縮する。ルールモードでは万行単位の平文リストではなくGEOIP/GEOSITEのようなコンパクトなルールを優先的に使う。

もう一つよくあるiOSの現象:Wi-Fiとモバイルデータの切り替え後に一時的にネットが使えなくなる。これはネットワーク切り替えに伴いVPNトンネルが再構築されるプロセスで、数秒待てば復旧する。長期間復旧しない場合はクライアントで手動で再接続すること。

モバイルデータとWi-Fiの挙動差

同じスマートフォンでWi-Fiでは正常、モバイルデータでは全ノードがタイムアウト(あるいは逆)の場合、いずれかのネットワークがプロキシトラフィックを干渉していることを意味し、クライアントとは無関係:通信事業者側のネットワークが特定ポートやプロトコルを遮断している可能性、公共Wi-Fiは強制ポータルや遮断がある可能性がある。この差を使って交差検証すれば、問題を「ネットワーク環境」に素早く帰着させ、アプリの再インストールに時間を浪費せずに済む。モバイル端末の初回インストールの完全な流れと権限設定の順序については、ブログで一通りまとめている:Clashクライアント初回インストール完全ガイド。