Clash トラブルシューティング完全ガイド

共通トラブルシューティングの流れ:まずどの層で問題が起きているか特定する

「使えない」という情報だけでは判断材料が足りません。Clash が1件の通信を処理する際には4つの段階を経ます:クライアントとカーネルが送受信を担い、システムプロキシがどの通信を渡すかを決め、ノードのリンクが通信を国外へ送り出し、ルールとDNSが各接続の実際の経路を決めます。どこか1つが切れても、ブラウザに表示されるのは同じ「アクセスできません」です。トラブルシューティングの目的は、問題がどの層にあるかを正確に突き止め、そこに対処することです——層の判断を誤れば、機場(プロキシサービス)を10個乗り換えても、システムプロキシが設定されていないだけの問題は解決しません。

第1層の確認:ログとポート

クライアントのログページを開き、レベルを info に設定します。カーネルが正常であれば、設定の読み込みとポートのリッスンに関するログが確認できます。ログが真っ白、または同じエラーが繰り返し表示される場合はクライアント自体に問題があるので、第8章へ進んでください。ログ内で覚えておくべきキーワードがいくつかあります:bind 関連は多くがポート占有、parse 関連は設定の解析失敗、dial 関連はノードへの接続失敗です。さらに以下のコマンドでポートがリッスン中か確認します:

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

HTTP 204 が返れば、クライアント・ノード・ルールの全経路が通っており、問題はシステムプロキシまたはブラウザ側にあります。タイムアウトや接続拒否の場合は、続けてノードとルールを確認してください。このコマンドは本マニュアル全体で最も使用頻度の高い確認手順なので、覚えておくと便利です。

二分法による絞り込み

3ステップで問題を最小範囲まで絞り込みます:ノードを変更(単一ノードの障害を除外)→ ネットワークを変更(スマホのテザリングに切り替え、自宅回線の遮断を除外)→ デバイスを変更(スマホで同じサブスクを導入し、端末環境の問題を除外)。各ステップで変える変数は1つだけに絞ると、結果がすぐに読み取れます。3ステップすべてを終えれば、原因の候補はほぼ1つに絞られます。

症状別クイックリファレンス

流れを読むのが面倒な方は、症状から直接該当章へ:

ネットに接続できない:プロキシは有効なのにページが開かない

最も頻出する症状です。クライアントのスイッチはすべてONになっているのに、ブラウザが軒並みタイムアウトする——以下の順番どおりに進めてください。各ステップには明確な「通過/不通過」の判定基準があるので、手順を飛ばさないようにしましょう。

ステップ1:クライアントからノードまでの経路を確認する

前章の curl コマンドで確認します。通過すればクライアント・ノード・ルールに問題はなく、ステップ3のシステムプロキシ確認に進んでください。不通過であればステップ2に進みます。

ステップ2:プロキシモードとノードを確認する

クライアントには通常3つのモードがあります:グローバル(全通信をプロキシ経由)、ルール(ルールに応じて振り分け)、直接接続(全て直結)。誤って「直接接続」に切り替わっていると「ONにしても無効」という状態になります。まずグローバルモードに切り替えて確認しましょう:グローバルモードでページが開けば経路自体は正常で、ルールが対象サイトを直接接続や無効なノードグループに振り分けているだけなので、ルールとポリシーグループを見直してください。グローバルモードでも開かない場合はノードを変えて再確認し、すべてのノードで開かなければ第3章の対応に進みます。

ステップ3:システムプロキシが実際に書き込まれているか確認する

Windows:設定 → ネットワークとインターネット → プロキシで、「プロキシサーバーを使う」がONになっており、アドレスが 127.0.0.1、ポートがクライアントの混合ポート(デフォルト 7890)と一致していることを確認します。セキュリティソフトや他のツールに設定を戻されてしまうケースはよくあります。macOS:システム設定 → ネットワーク → 使用中のネットワークインターフェース → 詳細 → プロキシで、Webプロキシとセキュアウェブプロキシのチェック状態とポートを確認します。この項目の詳しい確認方法は第7章を参照してください。

ステップ4:ファイアウォールとセキュリティソフト

Windowsのファイアウォールやサードパーティ製ウイルス対策ソフトがカーネルプロセスの通信をブロックしている場合があります。初回起動時に表示された「アクセスを許可しますか」で拒否を選んでいると、クライアントは動いているように見えても実際は1パケットも送信できません。ファイアウォールの許可リストにクライアントとカーネルのプロセスを追加するか、クライアントを再インストールしてポップアップで許可を選んでください。

ノードタイムアウト:遅延テストが軒並みTimeout

遅延テストが全部赤くなっても慌てないでください。「全滅」と「一部だけタイムアウト」は全く別の障害で、対処法も異なります。

全滅:原因はローカル環境かサブスクリプション側

すべてのノードが同時にタイムアウトする場合、ノードが一斉にダウンしているとは考えにくく、以下のいずれかが濃厚です:ローカルネットワークの遮断(自宅回線・学校や社内のネットワークによるプロキシポートの制限)、プランの期限切れやデータ使い切り、システム時刻のズレ。まずスマホのテザリングに切り替えて確認してください:テザリングで全て正常になれば自宅回線側の問題なので、プロトコルを変更(例:Trojan から Hysteria2 へ)するか、ポートの特徴が異なるノードに切り替えてください。

システム時刻のズレは見落としやすい原因

Trojan、VLESS、Hysteria などのプロトコルはいずれも TLS の上に成り立っており、ハンドシェイク時に証明書の有効期限を検証します。システム時刻が実際の時刻から数分ずれているだけで、TLS を使う全ノードのハンドシェイクが一斉に失敗し、ノード全滅と同じ現象になります。時刻を修正するコマンド:

# Windows(管理者権限で開いたターミナル)
w32tm /resync

# macOS
sudo sntp -sS time.apple.com

# Linux
timedatectl set-ntp true

時刻を修正した後、クライアントを再起動して再確認してください。長期間ネットにつながずに時刻同期をしていない機器(ソフトルーター、長らく電源を切っていた古い端末など)は特にこのパターンに陥りやすいです。

一部だけタイムアウト:ノード自体の問題

一部のノードだけがタイムアウトする場合、ノードのダウン、通信事業者による狙い撃ちのブロック、そのノードのプロトコル特徴がローカルネットワークに検知されている、といった原因が考えられます。まずノードを変更し、同じ地域のノードが全てタイムアウトするなら地域自体を変えてみましょう。遅延テストの仕組みにも注意が必要です:クライアントはテストURLに対してHTTPSリクエストを送り時間を計測しており、ICMP ping ではありません——テスト先のアドレス自体が到達不可の場合もTimeoutと表示されるため、設定でテストURLをより安定したアドレスに変更して再確認してみてください。

プランとサブスクリプションの状態

機場のプランが期限切れやデータ使い切りになった場合、サブスクリプションリンクやノード一覧はそのまま残っていても全て使用不可になります。機場の管理画面にログインしてプラン状況を確認してください。一部のクライアントはサブスクリプションのレスポンスヘッダーに含まれるトラフィック情報を表示できるので、あわせて確認しましょう。サブスクリプション自体が更新できない場合は第4章を参照してください。

サブスク更新失敗:サブスクリプションの更新でエラーが出る

「更新失敗」という表示は表面的なもので、クライアントには通常もっと具体的な原因が付記されています:ネットワークエラー(timeout、connection refused)、解析失敗(yaml、base64)、HTTPステータスコード(403、404)。まずエラー内容を全て読んでから該当箇所を確認しましょう。

サブスクリプションリンク自体を確認する

サブスクリプションリンクをそのままブラウザのアドレスバーに貼り付けてみてください:テキストファイルがダウンロードできればリンク自体は有効です。403 はトークン失効やプラン期限切れが多く、404 はリンクの入力ミスかサブスクリプションのリセットが原因です。手動コピーでは文字の欠落やスペースの混入が起こりやすいため、機場の管理画面から完全なリンクを再コピーしてください。典型的なサブスクリプションリンクは次のような形式です:

https://example.com/api/v1/client/subscribe?token=xxxx

トークンはアクセス用の認証情報であり、漏洩すればプランをそのまま他人に渡すのと同じです。トラブルシューティング中に完全なリンクを公開の場に貼らないよう注意してください。

サブスクリプション用ドメインがブロックされている場合

サブスクリプションサーバーのドメイン自体がブロックされている場合、直接接続での更新は必ず失敗します。対策は2つ:クライアントの設定で「プロキシ経由でサブスクリプションを更新」を有効にする(クライアントによって名称が多少異なります)。または、一時的なノードでプロキシに接続した状態でサブスクリプションを更新する。更新に成功すれば、サブスクリプション内のノードは通常どおり使用できます。

フォーマットと解析の問題

サブスクリプションが返す内容は、Clash が認識できる YAML 設定、または変換可能なノードリストである必要があります。機場が汎用的な v2ray サブスクリプションしか提供していない場合は、専用の「Clash サブスクリプション」リンクやサブスクリプション変換サービスに切り替えてください。サブスクリプションファイルを自分で手動編集した場合は、YAMLのインデントにも注意しましょう——インデントを間違えると解析失敗のエラーになります。

自動更新の間隔

ノードリストは機場側の調整によって随時変化するため、長期間更新しないと「ノードは一覧にあるが全て使えない」という見せかけの状態になります。クライアントの設定で自動更新を有効にし、間隔は24時間前後がおすすめです。古くなりすぎず、頻繁に更新されすぎることもありません。具体的な設定手順や失敗原因のさらに詳しい解説は、ブログ記事「Clash サブスクリプション更新失敗の主な原因と自動更新の設定方法」を参照してください。

速度が遅い:つながるがカクつく

「遅い」というのは相対的な障害です:経路自体は通っているものの体感が悪い状態です。まずボトルネックの箇所を特定し、その上でノード変更、プロトコル変更、ルール調整のどれを選ぶか決めましょう。

3セグメントでのボトルネック特定

1本の接続の速度は、最も狭い箇所によって決まります:ローカルからノードまで、ノード自体の帯域幅、ノードから対象サイトまで。判断方法:同じノードで異なるサイトにアクセスしてみる——一部のサイトだけ遅い場合はそのノードから当該サイトまでの経路がボトルネック、全サイトが遅い場合はノードを変えて比較してみましょう。ノードを変えると明らかに改善する場合はノードの帯域幅かローカルからノードまでの経路の問題、どのノードに変えても遅い場合はローカルネットワークやクライアント自体を確認してください。

遅延が低い=速度が速いとは限らない

遅延は「反応の速さ」を、帯域幅は「道幅の広さ」を決めます。夜のピーク時間帯には低遅延のノードでも混雑します。速度の判断には実際のダウンロードや動画再生の状況を見るべきで、遅延の数字だけでノードを選ぶべきではありません——遅延50msのノードと150msのノードで、動画視聴では何の違いも感じないこともあります。

ポリシーグループの選択

url-test ポリシーグループは自動的に遅延が最も低いノードを選びますが、それが最も混雑しているノードである可能性もあります。負荷分散は複数のノードに接続を分散させる方式で、ダウンロード系の用途に向いています。手動選択が最も制御しやすく、遅延が近い複数のノードを試しながら、現時点で最も安定しているものを見つけられます。対象サイトがルールによって遠回りのノードグループに振り分けられている場合も速度低下の原因になります:接続パネルを開いて、その接続がどのルールに一致し、どのノードを経由しているか確認し、必要に応じてルールの順序を調整するか、そのサイト専用のノードを指定してください。

プロトコルとカーネルの違い

UDPベースの新しいプロトコル(Hysteria2、TUIC)は、パケットロスやジッターの多い回線で従来のTCPプロトコルより明らかに安定します。mihomo カーネルはこれら両プロトコルを完全にサポートしており、デスクトップ向けでおすすめの Clash Plus と Clash Verge Rev、FlClash はいずれも mihomo を内蔵しています。カーネルとプロトコルの違いについて詳しくは、ブログ記事「mihomo(Clash Meta)カーネルの特徴と純正 Clash との違い」を参照してください。

DNSの問題:解析異常と汚染

典型的な症状

プロキシには接続できるが一部のサイトが開かない、開いたサイトが「間違った地域版」になっている、広告フィルタルールが効くときと効かないときがある、nslookup が明らかに不自然なIPを返す。これらはすべてノードではなくDNS周辺の問題を示しています。

Clash のDNSモジュールの仕組み

クライアント内蔵のDNSモジュールがシステムのドメイン名解決を代行し、設定された上流サーバーへ問い合わせを行い、ルールと連動して「誰が解決し、結果を誰に渡すか」を決めます。動作モードは2種類あります:redir-host は実際に解決したIPを返し、fake-ip は 198.18.0.0/16 範囲の仮想IPを返して、接続確立時にカーネルがドメイン名に基づいて転送します——解決が速く、汚染対策としても優れているため、多くのクライアントのデフォルトモードになっています。

設定例

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com

nameserver は直接接続するドメインの解決を担い、fallback はプロキシ経由のドメインの解決を担います。fake-ip-filter には実際のIPを必ず返す必要があるドメイン(LAN内デバイス、IPに敏感な一部アプリなど)を列挙します。dns セクションを変更した後は、カーネルの再起動または設定の再読み込みが必要です。多くのクライアントには設定画面にワンクリックで実行できる項目があります。

設定変更後はキャッシュをクリア

OSとブラウザの両方がDNSをキャッシュするため、古いキャッシュを消さないと新しい設定が反映されていないように見えます:

DNSリークの確認方法

プロキシを有効にした状態でDNSリークテストのサイトにアクセスします:表示される解決サーバーはプロキシの出口地域や設定した上流サーバーであるべきで、現地の通信事業者のものであってはいけません。現地の通信事業者のDNSが表示される場合は、システムのDNSが固定されていないか、ブラウザの「セキュアDNS」がシステムの解決処理を回避していないかを確認してください。

システムプロキシが効かない:スイッチはONなのに通信がプロキシを経由しない

まず「効いている」状態を確認する

システムプロキシを有効にした状態でブラウザからIP確認サイトにアクセスすると、出口はノードの所在地域として表示されるはずです。現地の通信事業者のまま表示される場合は未反映です。この確認は10秒で済むので、まずこれを行ってから先に進んでください。

Windows:プロキシ項目が上書きされていないか確認

設定 → ネットワークとインターネット → プロキシで、「プロキシサーバーを使う」がONになっており、アドレスが 127.0.0.1、ポートがクライアントと一致していることを確認します。セキュリティソフトや他のプロキシツールがこの項目を書き換えることがあります。クライアントがシステム設定に書き込むには権限が必要な場合があるため、必要に応じて管理者権限で一度実行し、クライアントに書き込み権限を与えてください。

macOS:権限とプロキシ項目

システム設定 → ネットワーク → 使用中のネットワークインターフェース → 詳細 → プロキシで、Webプロキシとセキュアウェブプロキシのチェック状態とポートを確認します。クライアントが初めてシステムプロキシを有効にする際、システムから権限リクエストのポップアップが表示されます。一度「許可しない」を選んでしまうと二度と書き込めなくなるため、「プライバシーとセキュリティ」設定で許可してから再試行してください。

ブラウザ層の干渉

SwitchyOmega のような拡張機能はブラウザのプロキシ設定を横取りし、システムプロキシと重複・競合します。どちらか一方だけを使うようにしてください。ブラウザの「セキュアDNS」はドメイン名解決をクライアントのDNSロジックから迂回させ、「IPは変わったのに内容が違う」という現象を引き起こします。確認する際はまずこれを無効にしてから再検証してください。

ターミナルや開発ツールがシステムプロキシを経由しない場合

ターミナルはデフォルトでシステムプロキシを無視するため、環境変数を明示的に設定する必要があります:

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

git、npm、pip にはそれぞれ独自のプロキシ設定項目があり、環境変数だけでは全てカバーできない場合があります。ブラウザとターミナルの両方についての詳しい確認方法は、ブログ記事「Clash のシステムプロキシが効かないときの確認方法」を参照してください。

最終手段:TUNモード

TUNモードは仮想ネットワークカードを使って端末全体の通信を横取りする方式で、システムプロキシの設定に依存せず、システムプロキシを無視するアプリ(ゲームや一部のコマンドラインツールなど)にも有効です。「プロキシ項目が上書きされる」といった繰り返し発生する問題を回避することもできます。仕組みと設定手順は、ブログ記事「Clash TUNモードの設定方法」を参照してください。

クライアントのクラッシュと起動不可

まずどちらが落ちているのかを見極める

画面のクラッシュとカーネルの起動失敗は別の問題です。カーネルが失敗する場合、クライアントは通常明確なメッセージを表示します(コア起動失敗、ポート占有、設定解析エラーなど)。まずそのメッセージを確認してから対処してください。画面自体が開かない場合は、まず再インストールか別のクライアントへの切り替えを検討してください。

ポート占有

混合ポートや外部制御ポートが占有されている場合——よくある占有者は前回正しく終了しなかったクライアントのプロセスです——カーネルはそのまま起動できません。占有を確認するには:

# Windows(管理者権限で開いたターミナル)
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

占有しているプロセスを終了するか、クライアントの設定でポートを別のものに変更してください。ポート変更後は、システムプロキシの設定内のポートも一致しているか必ず確認しましょう。

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

YAML はインデントに極めて敏感です:スペースを使い、タブは使ってはいけません。階層が1つずれるだけで解析失敗になります。config.yaml を手動編集した後は、クライアント内蔵の設定チェック機能やYAML検証ツールで一度確認してください。正しいノード項目の例は次のようになります:

proxies:
  - name: "ノードA"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

権限とシステムコンポーネント

Windows でTUNモードやサービスモードを使う場合はシステムサービスのインストールが必要です(クライアント内に通常ワンクリックのインストール項目があります)。macOS では拡張モードを初めて有効にする際に権限が必要です。セキュリティソフトが誤検知でカーネルファイルを隔離することもあり、その場合はホワイトリストに追加した上でクライアントを再インストールしてください。

初期化と再インストール

設定ディレクトリが破損した場合の一般的な対処法:サブスクリプションリンクをバックアップ → クライアントを終了 → 設定ディレクトリの名前を変更 → クライアントを再起動して再度サブスクリプションを導入。それでも解決しない場合はクライアントを変更してください:Windows と macOS では Clash Plus が第一候補で、Clash Verge Rev、FlClash が候補です。Clash for Windows と ClashX Meta はメンテナンスが終了しているため、新規導入にはおすすめしません。全プラットフォーム向けのクライアント一覧はダウンロードページにあります。

モバイル特有の問題:Android と iOS

Android:バックグラウンド終了が最大の原因

国産スマホのROMに搭載されたバッテリー最適化機能は、常駐するVPNプロセスを終了させることがあり、ロック画面から一定時間後にプロキシが「自動的にオフになる」という症状として現れます。対処法:設定 → アプリ → クライアントを探す → バッテリー/電力管理から「最適化しない」または「バックグラウンド動作を許可」に設定し、最近のタスク画面でクライアントをロックし、自動起動を許可してください。Clash Meta for Android、FlClash、Surfboard はすべてダウンロードページのAndroid欄にあり、全プラットフォームでは Clash Plus が第一候補です。

Android:VPNスロットの排他制御

システムは同時に1つのVPNしか動作させません。他のVPNやアクセラレーターがスロットを占有していると、クライアントの起動が失敗したり、相手を強制終了させたりすることがあります。クライアントのアプリ別プロキシ機能を使って対象範囲を絞ることで、他のツールとの競合も減らせます。

iOS:Clash Plus とシステム管理下のVPN

iOS版は App Store から Clash Plus をインストールしてください(公式サイト clashplus.io)。iOS ではVPNはシステムが管理しており、ロック画面後も通常は接続が維持されます。低電力モードや「バックグラウンドApp更新」の無効化はサブスクの自動更新や常時接続の維持に影響するため、「放置していると更新されない」場合はまずこの2点を確認してください。

デスクトップ版との設定共通性

サブスクリプションリンクは全プラットフォーム共通で使えます:同一の機場サブスクリプションをスマホとパソコンの両方に導入でき、ルールや振り分けロジックも同じです。本マニュアルの各章で解説したDNS、ルール、プロトコルに関する結論はモバイルでも同様に成り立ちます。違いはシステム層の常時接続維持や権限管理の部分だけです。

モバイル特有の症状クイックリファレンス