C1 / 完全にネット接続不可
ネット接続不可:3段階で問題の層を切り分ける
Clashを起動した後、すべてのサイトが開けない場合、すぐにノードを変えないでください。原因はおおむね3種類しかありません:ローカル回線自体が切れている、ノードが全滅している、ルールがトラフィックを誤った場所へ送っている。この3段階を踏めば、10分以内に必ずどの層に問題があるかを特定できます。
第1段階:プロキシを止めて、ローカル回線を確認する
システムプロキシをオフにするか、クライアントを終了して、普段すぐに開ける国内サイトにブラウザでアクセスしてください。開けない場合、問題はローカルネットワーク側にあり、Clashとは無関係です——まずWi-Fi、ルーター、または回線を修理してください。開けた場合は回線は正常で、第2段階に進みます。
この手順は意外と飛ばされがちで、クライアントを一日中いじった末に、実はルーターが料金未払いで再起動していただけ、というケースもあります。まず直結に切り替えることは、プロキシ問題の調査における永遠の第一歩です。
第2段階:グローバルモードに切り替え、ルールを除外する
クライアントをグローバルモード(GLOBAL)に切り替え、普段安定しているノードを手動で選び、プロキシが必要な対象サイトにアクセスしてください。通じれば、ノード自体には問題がなく、原因はルールによる振り分けにあります——ルールモードに戻し、第3段階に進みます。通じなければ、問題はノード側またはローカルの受信設定にあり、C2 ノードタイムアウトに直接進んでください。
グローバルモードは調査手段に過ぎません
特定できたら必ずルールモードに戻してください。グローバルモードを常用すると、本来直結でいいトラフィックまで地球を一周させてしまい、速度も通信量も損をします。グローバルモードとルールモードの使い分けについては、
よくある質問にも一項目あります。
第3段階:ログを開き、ルールのマッチ状況を見る
設定内でログレベルを上げ、クライアントの接続/ログパネルで、対象ドメインがどのルールにマッチし、どのポリシーグループに送られ、そのポリシーグループが現在誰を選択しているかを確認してください。よくある失敗パターンは2つあります:デフォルトのMATCHルールがDIRECTを指していて、プロキシすべきトラフィックがすべて直結になっている場合;またはDOMAIN-SUFFIXの記述が広すぎて、直結すべきでないドメインを誤って直結に振り分けている場合。
# config.yaml:調査中はログを詳細にし、終わったら元に戻す
log-level: debug
mode: rule
カーネルがそもそも起動していないと疑うなら、コマンドで直接ローカルの受信ポートを叩いてみてください(ポート番号は設定内のmixed-portに合わせてください):
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204
期待する応答は204です。curlすら通らない場合、カーネルがリスニングしていないということです——設定のポート番号が間違っているか、プロセスがそもそも起動していないかのどちらかです。C7 クラッシュに進んでください。
C2 / ノードタイムアウト
ノードタイムアウト:全滅と一部だけ赤いのは別の病気
遅延テストが真っ赤になったら、まず分類してください:すべてのノードが同時にタイムアウトするのと、一部のノードだけがタイムアウトするのとでは、原因が全く異なります。全滅はほぼこちら側の問題、一部だけ赤いのはノード自体の問題です。
全滅:まず自分側を確認する
- サブスクの期限切れまたは通信量の使い切り。プロバイダーの管理パネルにログインしてプラン状況を確認してください。全滅リストの中で最も多い原因であり、確認に10秒しかかからないので最優先で調べる価値があります。
- 速度テストのリンク自体が遮断されている。遅延テストで使うURL(よくあるのは
generate_204系)が現在のネットワークで遮断されていると、すべてのノードがタイムアウト表示になりますが、実際には使えます。別の測定用URLに変えて再テストすれば、数値が正常に戻ればこれが原因です。
- ローカルのファイアウォールがカーネルを遮断している。Windowsで初回起動時のファイアウォール許可ポップアップで「拒否」を選んでしまうと、その後カーネルがパケットを送信できず全滅します。ファイアウォールのアプリ許可リストでカーネルプロセスを許可してください。
- システム時刻のズレが大きすぎる。一部の暗号化プロトコルは端末の時刻に敏感で、許容範囲を超えるとハンドシェイクが即座に失敗します。システム時刻の自動同期をオンにし、補正後に再テストしてください。
一部だけタイムアウト:ノード自体の問題
単一のノードが常に赤い場合、多くはサーバーがオフラインになっているか回線が劣化しているためで、ノードを変えれば済みます。ある地域のノードがまとめて赤い場合、通常はその国際回線が障害中またはメンテナンス中で、しばらく待つか他の地域のノードに切り替えてください。一部だけのタイムアウトは修す価値がなく、変える価値があります。
| 現象 | 有力な原因 | 対処 |
|---|
| すべてのノードがタイムアウト、パネルではプラン正常 | 測定用URLの遮断、またはファイアウォールがカーネルを遮断 | 測定用URLを変更;カーネルプロセスを許可 |
| 全滅、ブラウザで証明書エラーも表示 | システム時刻のズレ | 時刻の自動同期をオン |
| ある地域のノードが一列に赤い | 回線障害 | 地域を変える、または回線の復旧を待つ |
| 数値は正常だが実際には接続できない | ルールが出口を誤って送っている | 回C1の第3段階に戻ってログを確認 |
遅延の数値の読み方
遅延テストが測っているのは1回のHTTPリクエストの往復時間であり、帯域幅ではありません。80msのノードが10Mbpsを出せないこともあれば、200msのノードがフルスピードで動くこともあります——遅延は「応答の速さ」を、帯域幅は「ダウンロードの速さ」を決めるもので、両者は別物です。異なるプロトコルのノード間で遅延を比較できるようにするには、統一遅延をオンにしてください:
# config.yaml
unified-delay: true
tcp-concurrent: true
自動測速ポリシーグループ内のurl、interval、toleranceの3つのパラメータがそれぞれ何を制御するかについては、ブログに実測記事があります:url-test、fallback、load-balanceの3種類のポリシーグループの違い。
C3 / サブスク失敗
サブスク失敗:エラー文言そのものが診断結果
サブスクが取得できない場合、クライアントが出すエラーのキーワードがほぼそのまま原因を示しています。まず表で対応を確認し、その後手動で検証してください。
| エラーキーワード | 意味 | 対処 |
|---|
404 / not found | サブスクURLが無効化、またはプロバイダー側でリセットされた | プロバイダーの管理パネルでサブスクリンクを再コピー |
timeout / タイムアウト | サブスクのドメインが現在のネットワークで遮断、または応答が遅い | 先に使えるノードでプロキシを繋いでからサブスクを更新 |
403 / forbidden | プロバイダーがリクエスト元のUAを制限している | プロバイダー指定のクライアントタイプで取得 |
| invalid / yaml decode error | 取得した内容が正しい設定ではない | 下記の方法で内容を手動確認 |
サブスクが実際に何を返しているか手動で確認する
クライアントのエラーは時に曖昧すぎるので、コマンドで直接サブスクをローカルに落として見てみれば、一目でわかります:
curl -sSL -A "clash.meta" "https://あなたのサブスクURL" -o sub.yaml
head -n 20 sub.yaml
最初の数行はYAML構造(proxies:、port:、proxy-groups:のようなフィールド)であるはずです。<html>で始まっている場合は、プロバイダーのエラーページや遮断ページを取得してしまったことを意味します。空白のない長い一続きの文字列であれば、base64エンコードされた汎用サブスクが返されているということで、Clashで使うにはサブスク変換が必要です。
サブスク変換のトレードオフ
変換サービスはあなたのサブスクURLを経由し、サブスクURLはアカウントの認証情報に等しいものです。プロバイダーが元から提供しているClash用サブスクが使えるなら、変換しないのが一番です。どうしても変換が必要なら、自前で変換サービスを構築するのが最優先で、それができない場合でも信頼できるインスタンスだけを使ってください。変換後にノードが全て消えたりポリシーグループが崩れたりする場合、多くは変換テンプレートとサブスク形式が一致していないためで、テンプレートを変えて再試行してください。
サブスクURL = アカウントの認証情報
グループチャットに貼らない、出自不明の変換サイトに入力しない、リンク付きのスクリーンショットを共有しない。漏洩したらすぐ管理パネルでサブスクをリセットし、古いリンクは即座に無効化してください。
C4 / 速度低下
速度低下:まず基準を立ててから最適化を語る
「遅い」はツールが最も冤罪を被りやすい症状です。基準を作らなければ、どんな最適化も憶測にすぎません。まず2回測定してください:1回は直結、1回はプロキシ経由。この2つの数値の差こそが、プロキシ経路が生む損失です。
基準の読み方
プロキシの速度が直結の3割未満なら、深く調べる価値があります。差が1〜2割程度なら、それはほぼノードの物理的な限界です——国際回線の帯域は元々ローカルの回線よりずっとコストが高く、プロキシ経由の速度が直結に追いつくことは期待しないでください。
3つのよくあるボトルネック、順番に除外する
- ノード側:帯域が小さい、回線がピーク時に混雑している。時間帯を変えて再測定してください。日中は速く夜は遅いなら、ほぼ回線の混雑と断定でき、ノードやプランを変えるしかなく、ローカル側の調整では解決しません。
- プロトコル側:異なる伝送プロトコルはオーバーヘッドと耐干渉能力が大きく異なります。UDPがノードや回線側で制限されていると、ビデオ通話やQUICに依存する一部のアプリで明らかな劣化が見られます。同じサーバー上でプロトコルを変えて比較するか、ノードがUDP転送に対応しているか確認してください。
- ローカル側:ルーターに既にプロキシを1層かけていて、さらにパソコン側でもう1層かけると、二重暗号化で損失も2倍になります。古いデバイスで重い暗号化プロトコルを使うとCPUがまず限界に達します。1層で十分、重ねて使わないでください。
カーネル側には無料で有効化できるスイッチが2つあります:並行ハンドシェイクは接続確立の時間を短縮し、統一遅延は測定を実際の体感に近づけます:
# config.yaml
tcp-concurrent: true
unified-delay: true
ピーク時の遅さへの工程的な解法
手動でのノード切り替えは戦術、ポリシーグループは戦略です。よく使う地域の複数ノードを1つの自動測速グループにまとめ、toleranceにチャタリング防止のしきい値を設定して、2つのノードの遅延が近い時に頻繁に切り替わるのを防ぎます:
proxy-groups:
- name: AUTO
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies: [節点A, 節点B, 節点C]
大容量ダウンロードのようなシーンでは、負荷分散グループでトラフィックを複数ノードに分散させることも検討できます。3種類のポリシーグループタイプの選び方は、ブログの実測記事を参照してください:url-test、fallback、load-balanceの違い。
C5 / DNSの問題
DNSの問題:「原因不明の不具合」の半分はここにある
DNS障害の典型的な症状:あるサイトは瞬時に開くのに、あるサイトはずっと読み込み中のまま;プロキシは確かに接続できているのに、検出サイトでは解決結果の出口がローカルのISPになっている;ノードを変えるとあるサイトは直り別のサイトは壊れる。こうした一見ランダムに見える現象の根本原因は、たいてい名前解決の層にあります。
2つの解決モード、まず理解してから調整する
Clash系のカーネルには2つの拡張解決モードがあります。redir-hostは従来型の経路で、まずドメインを実際のIPに解決してからルールにマッチさせるため、解決経路が長く、ローカルのこの1ホップで漏洩しやすくなります。fake-ipはカーネルが予約済みのアドレス帯(デフォルトは198.18.0.0/16)から直接「偽アドレス」を返し、実際の解決はプロキシの出口側で行います——接続確立が速く、ローカルでも実際の平文クエリが発生しないため、現在ではより推奨されるデフォルト選択です。
そのまま貼って使えるdns設定
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "+.local"
nameserver:
- https://doh.pub/dns-query
fallback:
- https://1.1.1.1/dns-query
1行ずつ説明します:fake-ip-filterは免除リストで、列挙されたドメインには偽アドレスを発行しません。LAN内デバイスの検出やプリンターなど実アドレスが必須の場面のために残しておくものです。nameserverは暗号化DNSで通常の解決を処理し、fallbackは海外ドメインの受け皿になります。2グループの役割分担を意識し、すべてのドメインを同じ上位に押し込まないでください。
漏洩の自己確認は2つの方法
プロキシが接続できていることは、DNSが漏洩していないことを意味しません。手早い方法:オンラインの漏洩検出サイトを開き、解決結果の出口の所属がローカルのISPになっていないか確認します。本格的な方法:ローカルでパケットキャプチャを行い、53番ポートで平文クエリが直接外に出ていないか観察します。両方の完全な手順と漏洩防止の書き方は、ブログの実践記事にあります:ClashのDNS漏洩検出とfake-ip漏洩防止設定。
fake-ipの副作用と解決法
fake-ipは無償ではありません:一部のアプリが偽アドレスをキャッシュしてしまい、Clashを終了して直結に戻した後もそのアプリが198.18始まりのアドレスを使い続けて壁に突っかかる、つまり「プロキシを切ったらむしろネットに繋がらない」という現象が起こります。解決法はシステムのDNSキャッシュをクリアすることです:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
経験則
ゲームプラットフォーム、LANキャスト、NASのような実IPに敏感なドメインは、すべてfake-ip-filterに追加してください。免除リストは広めに設定して構いません。プリンターまでプロキシにアドレスを求めさせないようにしましょう。
C6 / システムプロキシが無効
システムプロキシが無効:張り紙は法執行ではない
まず原理をはっきりさせておきます:「システムプロキシ」とはOSが貼り出した張り紙のようなもので——「みんな127.0.0.1のこのポートを通ってください」という提案に過ぎません。アプリはそれを見ることもできれば、見ないふりをすることもできます。ブラウザは一般的に見ますが、ターミナルは基本的に見ず、一部のクライアントソフトは独自の判断を持っています。そのためこの章では対象ごとに分けて調査する必要があります。
ブラウザがプロキシを通らない
- ブラウザのプロキシ設定が「システムプロキシを使用」になっているか確認してください。Firefoxはデフォルトで自身のプロキシ設定を使い、システムの設定を読まないため、手動で
127.0.0.1と対応するポートを指定する必要があります。
- プロキシ系の拡張機能はシステム設定を上書きします。SwitchyOmegaのような拡張機能を入れている場合は、まず無効化してからテストしてください——拡張機能に残っている古いルールが、この症状の第一の疑惑対象です。
- 別のブラウザで相互検証してください:Aブラウザは通るがBブラウザは通らないなら、原因は確実にB自身の設定にあり、クライアント側をいじる必要はありません。
ターミナルがプロキシを通らない
ターミナルプログラムは環境変数しか認識せず、システムの張り紙は認識しません。Clashを起動していてもcurl、git、パッケージマネージャーは普通に直結します。これは異常ではなく正常な動作です。現在のセッションに手動で設定してください:
# macOS / Linux(現在のセッションのみ有効、ポートはあなたの設定に合わせてください)
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
# Windows PowerShell
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
git、dockerのようなツールには独自のプロキシ設定項目があることに注意してください。環境変数だけでは全てをカバーしきれない場合があるため、繋がらない時はそれぞれの設定ファイルでもう一段確認してください。
TUNモード:一括ですべてのトラフィックを引き取る
アプリごとに個別対応したくなければ、TUNモードを使ってください:カーネルが仮想ネットワークカードを作成し、ネットワーク層で直接すべてのトラフィックを引き取るため、誰も張り紙を見ないふりはできなくなります。代償は管理者権限またはシステム認可が必要になることで、初回オンにする際は仮想ネットワークカードのインストール確認手順があります。TUNを有効にした後はシステムプロキシのスイッチをオフにすることを推奨します。トラフィックが二重処理されるのを避けるためです。ブラウザとターミナルの完全な分岐調査記録はブログを参照してください:システムプロキシが無効な場合のブラウザとターミナルの分岐調査。
C7 / クラッシュ
クラッシュ:4ステップで9割は救える
クライアントが起動しない、または起動直後に落ちる場合、9割は次の3つのいずれかに該当します:設定の解析失敗、ポートの競合、前回異常終了時に残ったカーネルの残留プロセス。以下の4ステップを順番に進めてください、飛ばさないように。
第1ステップ:ログを見る
クラッシュには必ず遺言があり、遺言はログに書かれています。クライアントの設定から「ログディレクトリを開く」または「アプリディレクトリを開く」を探し、ログの最後の数行を見てください。YAMLの解析失敗は行番号とフィールド名を直接示し、ポート競合はaddress already in useと明記されます。エラー文言に従って進める方が、当てずっぽうより10倍速いです。
第2ステップ:設定を検証する
クライアントの「新規の空白設定」機能またはデフォルト設定への復元機能で一度起動してみてください。起動できれば、原因はあなたの設定ファイルにあります——ログが示す行番号に戻ってYAMLを修正してください。よくあるエラーは3種類だけです:タブとスペースが混在したインデント、コピペで紛れ込んだ全角引用符、引用符が必要なのに付けていないフィールド値。直せない場合は、サブスクを再度インポートして、プロバイダーの元設定でローカルの変更を上書きしてください。
第3ステップ:ポートを確認する
カーネルがリスニングしているポートが他のプログラムに使われていると、起動が即座に失敗します。誰が使っているか確認してください(ポート番号はあなたの設定値に置き換えてください):
# Windows
netstat -ano | findstr 7890
# macOS / Linux
lsof -i :7890
占有しているプロセスが見つかったら、それを終了するか、Clash側のポートを変更してください:設定内のmixed-portを空いている値に変更し、保存して再起動します。
第4ステップ:残留をクリアする
前回クラッシュして終了した際、カーネルプロセスが一緒に終了せず、ポートとTUN仮想ネットワークカードを占有し続けている可能性があります。新しいインスタンスを起動すると衝突します。手動で一度クリアしてください:
# Windows(プロセス名はタスクマネージャーの実際の表示に従ってください)
taskkill /f /im mihomo*
# macOS / Linux
pkill -f mihomo
4ステップを終えてもまだ解決しない場合は、最後の手段として、完全にアンインストールしてからダウンロードセンターで最新版を再インストールし、インストーラーに破損した実行環境を丸ごと入れ替えてもらってください。WindowsとmacOSそれぞれのよくあるクラッシュ事例の対照表は、ブログに単独記事があります:起動時クラッシュのログ特定と修復手順。
C8 / モバイル専用対策
モバイル専用対策:AndroidとiOSはそれぞれ癖が違う
モバイル端末の障害はデスクトップとは別の理屈で動きます:Androidの落とし穴は権限とバックグラウンド管理に集中し、iOSの落とし穴はシステムVPNフレームワークの状態同期に集中します。それぞれ分けて説明します。
Android:3つのポイントで9割の問題を抑える
- VpnServiceの権限。Android版Clashはシステムの標準VpnServiceでローカルトンネルを構築しており、初回接続時に必ず「接続要求」の権限ウィンドウが出るので、必ず許可を選んでください。誤って拒否した場合は、システム設定のVPNページでそのアプリのVPN設定を削除し、クライアントに戻って再接続すると権限ウィンドウが再表示されます。
- バッテリー最適化の除外リスト。中国メーカー系ROMのバックグラウンド管理は非常に強力で、カーネルプロセスが強制終了されると通信も切れます。「画面ロック後数分でネットが切れる」という症状として現れます。クライアントをバッテリー最適化の除外リストに追加し、自動起動を許可することはAndroid側の必須項目です。主要メーカー各社の設定パスは、ブログにまとめがあります:VpnServiceの権限とバッテリー最適化の除外設定。
- アプリ単位のプロキシ。指定したアプリだけをトンネルに通し、他は直結にします。省電力になるだけでなく、特定アプリとVPNトンネルの互換性問題も回避できます——あるアプリがプロキシをオンにすると不安定になる場合は、まずそのアプリをトンネルから外してみてください。
AndroidのインストールパッケージはダウンロードセンターのAndroidエリアから取得してください。Clash Plusを第一に推奨します。
iOS:状態はシステム設定を基準にする
iOSはシステムのNetwork Extensionフレームワークを使い、クライアントはApp Storeからインストールします。Clash Plusを第一に推奨します。よくある落とし穴は2つあります:
- スイッチ状態が同期しない。アプリ内では接続済みと表示されているのに、ステータスバーにVPNアイコンが出ない——システム側を基準にし、「設定 → VPN」で対応する設定のスイッチを手動でオンにしてください。
- 古い設定の残留が競合する。複数のプロキシ系アプリを入れた端末では、システムのVPNリストに複数の設定が積み重なり、互いに接続の主導権を奪い合います。使わなくなった設定はきれいに削除し、現在使用中のものだけを残してください。
モバイル全般の注意
スマホがWi-Fiとモバイルデータを切り替える際、トンネルは再構築されるため、数秒間の断流は正常な現象です。継続的に断流する場合のみ、本章の手順で調査してください。