#Clash トラブルシューティングガイド:症状別章立ての障害対応大全

有効化後にネットに接続できない:まず階層を分け、それから対処

「Clashを起動したら何も開けない」は最も多く、また最も曖昧な症状です。原因は4つの全く異なる階層に分かれます:ローカルネットワーク自体が切れている、クライアントが実際にはリスンしていない、システムがトラフィックをクライアントに渡していない、あるいはトラフィックはコアまで届いているがルールが失効した出口に振り向けている、のいずれかです。診断の第一原則は階層ごとに範囲を絞り込むことで、いきなりクライアントを再インストールしたりサブスクリプションを変えたりしないでください。

ステップ1:ローカル直結が正常か確認

まずクライアントのシステムプロキシまたはTUNモードをオフにし、日本国内のサイト(例:契約している通信事業者の公式サイト)に直接アクセスします。オフにしても開けない場合、問題はルーター、LANケーブル、または通信事業者側にあり、Clashとは無関係です。まず基本的なネットワークを解決してください。直結時は正常でプロキシを有効にすると全て切断される場合は、次に進んでください。

ステップ2:ポートがリスンしているか確認

Clash系クライアントはデフォルトで7890ポートにmixed-port(HTTPとSOCKSを同時に受け付ける)を開きます。以下のコマンドでポートが実際に使用されているか確認してください:

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

# macOS / Linux
lsof -i :7890

何も出力されない場合、コアの起動に失敗しています——多くは設定ファイルの解析エラーか、ポートが他のプログラムに使用されていることが原因です。クラッシュの章へ直接進んでください。ポートがリスンしている場合は、curlでプロキシ経由の接続性をテストします:

curl -x http://127.0.0.1:7890 -sS -o /dev/null -w "%{http_code}\n" \
  https://www.gstatic.com/generate_204

204が返れば「コア+現在のノード」の経路は通っており、問題はシステムプロキシ層にあります。システムプロキシ不動作の章を参照してください。タイムアウトやエラーが返る場合は出口自体に問題があるので、ノードタイムアウトを確認してください。

ステップ3:ルールの誤判定を排除

クライアントをグローバル(Global)モードに切り替えて再度試してください。グローバルモードは全ての振り分けルールをスキップし、トラフィックをすべて手動選択したノードに渡します:グローバルモードで通信できてルールモードで通信できない場合、ルールが対象ドメインを失効したポリシーグループに割り当てているか、フォールバックのMATCHルールがDIRECTを指していることを意味します。3つのモードの振り分けロジックの違いはこちらのノートで解説しています:ルール・グローバル・直結の3つのプロキシモードの選び方。

ノードタイムアウト:「一部」と「全部」を見分ける

クライアントに表示される遅延の数値は、テスト用アドレスへのHTTPリクエストにかかった時間から算出されます。よく使われるのはhttps://www.gstatic.com/generate_204です。タイムアウト表示は、この検出が制限時間内に応答を得られなかったことを意味し、原因はノードサーバー、通信プロトコル、特定ポートへのローカルネットワークの干渉、あるいはテスト用アドレス自体の不調にある可能性があります。診断の前にまず答えるべき問いは:タイムアウトしているのは一部のノードか、全ノード一括かです。

全ノードが同時にタイムアウト

全てのノードが一斉に赤くなる場合、ノード自体の問題はほぼ除外でき、優先的に疑うべきは3点です。1つ目はローカル直結が正常かどうか——前章のステップ1に戻って確認してください。2つ目はシステム時刻が正確かどうかです。多くの暗号化プロトコルは時刻のズレに敏感で、手動でタイムゾーンを変更した場合や仮想マシンの時計のズレがあると、ハンドシェイクが全滅することがあります。システム時刻を自動同期に設定してから再テストしてください。3つ目はサブスクリプション全体が期限切れ、またはサーバー側でブロックされていないかです。サブスクリプション提供元のユーザーパネルにログインして流量と有効期限を確認し、必要であればサブスクリプション失敗の章に従って設定を再取得してください。

一部のノードのみタイムアウト

単一ノードのタイムアウトで最も多い原因は、そのサーバーの負荷が高い、または回線が不安定なことです。同地域の別のノードに切り替えれば解決します。特定のノードが長期間不安定な場合は、url-testタイプのポリシーグループを使い、コアに現在利用可能なノードを自動選択させることができます。書き方は以下の通りです:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港-01
      - 日本-01
      - シンガポール-01

intervalは自動再テストの間隔(秒)、toleranceは新旧ノードの遅延差がこのミリ秒数を超えた場合のみ切り替える設定で、遅延が近い2つのノード間で頻繁に切り替わるのを防ぎます。ポリシーグループの構成方法については、チュートリアルページや関連記事でより詳しく解説しています。

遅延は正常だが実際には使えない

遅延テストは「接続を確立できるか」だけを検証し、帯域幅もUDPも検証しません。ゲームや音声通話はUDP転送に依存するため、プロトコルやサーバー側でUDPサポートが有効になっていないと「遅延テストは緑色なのにゲームが切断される」というズレが発生します。この種の問題は、まずサブスクリプション提供元にノードがUDPをサポートしているか確認してください。クライアント側で対処することはできません。また、遅延の数値は「あなたからノードまで」の区間だけを反映しており、ノードから目的のサイトまでの区間が混雑している場合も、遅延は低いのにページが開かないという現象が起こります。出口の地域を変更すると、多くの場合すぐに改善します。

サブスクリプション更新失敗:まずエラーを確認し、直結かプロキシ経由かを判断

サブスクリプションは本質的にHTTP(S)アドレスであり、YAML設定または変換可能なノードリストを返します。更新に失敗するとクライアントは通常エラーを表示します。エラーの種類によって対処法は全く異なるので、闇雲に更新ボタンを繰り返し押さないでください。

サブスクリプションアドレスを手動で検証

クライアントのエラー情報が限られている場合、curlで直接取得を模擬し、問題をクライアントから切り離して確認します:

# 直結で取得
curl -sS -o sub.yaml -w "%{http_code}\n" "サブスクリプションアドレス"

# ローカルプロキシ経由で取得
curl -x http://127.0.0.1:7890 -sS -o sub.yaml -w "%{http_code}\n" "サブスクリプションアドレス"

200が返り、sub.yaml内にproxies:で始まるノードリストが見えれば、サブスクリプション自体は正常で、問題はクライアント側の設定にあります(よくあるのはUser-Agentがサーバー側で拒否されている場合で、クライアント識別子を変更して再試行してください)。2つのコマンドのうち一方だけが通る場合は、サブスクリプションのドメインがあなたのネットワーク環境で干渉を受けていることを意味するので、通る方の経路を固定して使えば十分です——多くのクライアントはサブスクリプション編集画面に「プロキシ経由で更新」のスイッチを備えています。

更新は成功したがノードが変わらない

一部のクライアントはサブスクリプションをローカルにキャッシュしているため、更新後は設定の最終更新タイムスタンプを確認してください。また注意点として、設定ファイル内の振り分けルールを手動で変更した後にサブスクリプション更新を押すと、その変更はサーバー側から配信された内容で上書きされます——長期的にルールをカスタマイズしたい場合は、サブスクリプションが書き込むファイルを直接編集するのではなく、クライアントの「設定拡張/マージスクリプト」機能を使用してください。

速度低下:ボトルネックがどの区間にあるかを特定

「遅い」という現象は、経路上のどの区間にも起因しうる、いわゆる桶の理論(最も弱い部分がボトルネックになる)です:ローカルの帯域上限、あなたからノードまでの回線品質、ノードサーバーの帯域、ノードから目的サイトまでの回線、そして暗号化プロトコル自体のオーバーヘッド。速度低下の診断で重要なのは、まずどの区間が遅いのかを見極めることで、考えずにノードを変えることではありません。

基準を作る

まずプロキシを切って生のローカル速度を測定し、数値を記録します。次にプロキシを有効にし、グローバルモードに切り替え、遅延が最も低いノードを選んでもう一度測定します。2つの数値の差が「プロキシ経路のオーバーヘッド+ノードのボトルネック」の合計です。生の速度がもともと数Mbpsしかない場合、どのノードを選んでも改善しません。生の速度が高く、プロキシ後に10分の1以下まで落ちる場合は、さらに切り分けを進めてください。

よくある原因と対策

プロキシを通す必要のない通信を直結させる

速度低下の隠れた原因は、振り分けがうまくできていないことがよくあります:システム更新、ゲームのダウンロード、クラウドストレージの同期といった大容量通信は、本来出口を経由する必要がありません。ルールモードでこれらのドメインがDIRECTにヒットしているか確認し、必要であれば手動でルールを追加してください。地理系ルール(GEOIP、GEOSITE)が正しくヒットするかどうかは、ローカルのデータベースが最新かどうかに依存します。更新方法はこちらのノートを参照:GeoIPとGeoSiteデータベースの更新方法。

DNS問題:汚染、漏洩とFake-IPのトレードオフ

「ルールが効かない」「一部のサイトだけ開けない」「初回アクセスが非常に遅い」といった問題の多くは、根本原因がDNSにあります。Clashコアには専用のDNSモジュールが内蔵されており、2種類の拡張モードとnameserverの階層構成を理解すれば、大半のトラブルを解決できます。

症状の識別

典型的なDNS汚染の症状は:ドメイン名がIPに解決されるものの、そのIPには全く接続できない、あるいは解決結果が明らかに目的サイトのものではない、というものです。一方、DNS設定の不備による症状は、ドメインルール(DOMAIN-SUFFIXなど)は正常にヒットするがGEOIPルールが乱れる、あるいはノードを切り替えても依然として古いアドレスにアクセスしてしまう、というものです。nslookupやdigでローカル解決結果とパブリックDoHの解決結果を比較すれば、汚染されているかどうかを素早く確認できます。

推奨される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"
    - "time.windows.com"
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query

enhanced-mode: fake-ipは、コアが予約されたネットワークセグメントの仮アドレスを使って即座にクエリに応答することを可能にし、実際の名前解決の待ち時間を省き、ドメインルールの精確なヒットを保証します——これは多くのクライアントのデフォルトモードでもあります。その完全な動作フロー、redir-hostとの違い、除外すべき場面については、この解説記事に詳しく記載しています:Fake-IPモードの仕組み詳解。

Fake-IPの典型的な落とし穴と除外リスト

実際のIPを必要とするプログラムはFake-IP環境下で問題を起こします:LAN内デバイスの検出、NTP時刻同期、一部のゲームランチャー、コールバックが必要なP2Pアプリケーションなどです。症状としては、これらのプログラムが198.18.x.xのアドレスを受け取って動作が異常になります。解決策はFake-IPを無効化することではなく、対象のドメインをfake-ip-filterに追加し、実際の名前解決を使わせることです。設定変更後、古い仮アドレスがまだシステムにキャッシュされている場合は、Windowsではipconfig /flushdns、macOSではsudo dscacheutil -flushcacheを実行してキャッシュをクリアしてください。

システムプロキシが効かない:そもそもシステムプロキシを無視する通信がある

システムプロキシの本質は、OSレベルで「HTTP/SOCKSプロキシは127.0.0.1:7890にある」という提案を登録するものです——注意すべきは「提案」であり「強制」ではないという点です。ブラウザや多くの現代的なアプリケーションはこれに従いますが、コマンドラインツール、一部の古いソフトウェア、そしてWindowsのUWPアプリケーションはこれを無視します。この点を理解すれば、「効かない」の半分には答えが見つかります:プロキシが壊れているわけではなく、そのプログラムがそもそもプロキシを経由する仕組みを持っていないだけなのです。2種類のトラフィック引き受け方式のメカニズムの比較については、まずこちらを読むことをお勧めします:TUNモードとシステムプロキシの違い。

Windows:UWPループバック制限

Microsoft Store アプリ(UWP)はデフォルトでローカルループバックアドレスへのアクセスが禁止されています。つまりシステムプロキシが127.0.0.1を指していても、ストア版アプリの通信はClashに届きません。多くのWindowsクライアントには「UWPループバックヘルパー/Loopbackツール」が内蔵されており、対象アプリにチェックを入れれば許可されます。システム標準のコマンドで手動許可することもできます。例えばMicrosoft Storeを許可する場合:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

# 現在許可されているリストを確認
CheckNetIsolation.exe LoopbackExempt -s

コマンドラインと開発ツール

ターミナル内のgit、pip、npm、curlはシステムプロキシの設定を読み込みません。環境変数を明示的に設定するか、TUNモードに切り替えて全体を引き受ける必要があります:

# 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:HTTPS_PROXY="http://127.0.0.1:7890"; $env:HTTP_PROXY="http://127.0.0.1:7890"

プロキシ設定が上書きされる、または反映されない

「システムプロキシ」をオンにした後、OSのプロキシ設定画面で実際に確認してください:Windowsでは「設定 → ネットワークとインターネット → プロキシ」、macOSでは「システム設定 → ネットワーク → 現在のネットワークサービス → 詳細 → プロキシ」です。アドレスが127.0.0.1:7890になっていない場合、よくある原因は次の通りです:他のプロキシソフト(または残存するドライバー)が設定を繰り返し書き換えている、macOSで現在アクティブなネットワークサービスが書き込まれたものと異なる(例えばWi-Fiに書き込まれたが実際は有線接続を使用している)。競合するソフトウェアを終了し、ネットワークサービスの優先順位を確認してからスイッチを入れ直してください。この手間を完全に回避する方法はTUNモードを有効にすることで、仮想ネットワークカードを使ってネットワーク層で全ての通信を引き受けます。代償として管理者権限が必要になり、他の仮想ネットワークカード系ソフトウェアとの互換性に注意する必要があります。

クラッシュと起動失敗:ログから答えを見つける

クライアントの「クリックしても反応しない」「起動直後に落ちる」「動作中に突然通信が切れる」といった症状には、多くの場合明確なログの手がかりがあります。むやみに再インストールするよりも、まずログを確認する方が的中率は高いです。各クライアントは設定またはトレイメニューに「ログ/アプリケーションディレクトリを開く」の入口を用意しています。診断前にログレベルをinfoまたはdebugに設定して再現してください。

起動直後に終了:まず設定を確認し、次にポートを確認

最も多い起動失敗の原因は設定ファイルの解析エラーです——YAMLはインデントとコロン後の空白に非常に敏感で、手動編集後にスペースが1つ欠けるだけで設定全体が無効になります。ログには具体的な行番号が示されるので、その行番号に従って修正してください。変更が大きい場合は、まず未編集のサブスクリプション設定に戻してクライアント自体が正常かどうかを検証し、「設定の問題」と「プログラムの問題」を区別してください。2番目に多いのはポート競合です:7890または9090(外部制御ポート)が他のプログラムに使用されている場合、ログにbind: address already in useのような表示が出ます。上記のnetstat/lsofで使用しているプロセスを見つけるか、設定で別のポートに変更してください。

動作中の通信断やクラッシュ

TUNモード下で突然通信が切れる場合、優先的に疑うべきは仮想ネットワークカードのドライバーと他のネットワークソフトウェア(仮想マシン、別のプロキシツール、一部のセキュリティソフト)との競合です。ログには通常、ネットワークカードの作成やルート書き込みの失敗記録が伴います。システムのスリープからの復帰後にネットワークが復旧しない問題は、各プラットフォームに共通する古くからの問題で、TUNまたはシステムプロキシのスイッチを入れ直すことで通常は復旧します。メモリが継続的に増加してシステムに強制終了される現象は、サブスクリプションのノード数が非常に多い、またはルールセットが多すぎる設定で多く見られます。サブスクリプションを簡素化し、不要なルールセットを減らすことで大幅に改善します。

リセットとクライアントの変更

プログラム自体の問題と確認できた場合、アンインストール後に残存するアプリケーションデータディレクトリを手動で削除してから再インストールする方が、上書きインストールより確実です(サブスクリプションアドレスは先にバックアップしておいてください)。同じサブスクリプションは異なるクライアント間で共通して使用できるため、あるクライアントがあなたのシステムで不安定な場合は、別のクライアントに変更するコストは低いです。各プラットフォームの推奨順序と違いはクライアント比較を参照し、インストールパッケージはクライアント取得ページから統一して入手してください。各プラットフォームでまずClash Plusをお勧めします。

モバイル特有の問題:AndroidとiOSはそれぞれ異なる落とし穴がある

モバイル端末の故障モードはデスクトップとは異なります:OSがバックグラウンドプロセスとVPNチャネルの管理に対してより積極的で、問題は設定にあるのではなく、しばしばシステムのポリシーにあります。本章はプラットフォーム別に解説します。

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

AndroidクライアントはシステムのVPNインターフェースを通じて通信を引き受けます。初回起動時には「VPN接続の作成」のシステムダイアログに同意する必要があります。もしその時に拒否をタップしていると、その後「起動をタップしても反応しない」という現象が起きます——システム設定のVPN管理でアプリを見つけて再度権限を許可してください。2番目に多い問題はバックグラウンドで強制終了されることです:一部の国産カスタムOSのバッテリー最適化機能が、長期常駐するVPNサービスを強制終了することがあり、「使っているうちに切れる」「画面ロック後しばらくすると無効になる」という症状として現れます。解決策はクライアントをバッテリー最適化のホワイトリストに追加し、自動起動とバックグラウンド動作を許可し、最近使用したアプリ一覧でロックしておくことです。またシステムの「常時オンVPN」と「VPNなしでの接続をブロック」のオプションにも注意してください:前者は生存率を高め、後者はクライアントが異常終了した際に直接ネット接続を切断します。接続断の診断時にはこの2つのスイッチの状態も確認してください。個別アプリのプロキシ設定(アクセス制御)の誤設定も故障と誤判定されやすいものです——特定のアプリだけプロキシを経由しない場合は、まずそのアプリがリストから除外されていないか確認してください。

iOS:App Store経由で取得、設定サイズに注意

iOSではネットワーク拡張(Network Extension)を通じて通信を引き受けており、システムはこの種の拡張に対するバックグラウンドメモリ制限が非常に厳しいです。サブスクリプションのノード数が多すぎる、または大量のルールセットが付属している場合、拡張プロセスが上限超過でシステムに終了され、「接続スイッチが自動的にオフに戻る」という症状として現れます。対策は設定を簡素化することです:サブスクリプション提供元にノード数の少ない簡易版サブスクリプションを提供してもらう、またはクライアント側で不要なルールを削減してください。iOSクライアントはApp Storeから取得し、まずClash Plus(公式サイト clashplus.io)をお勧めします。ストアの入口と説明はダウンロードページのiOSセクションを参照してください。Wi-Fiとモバイルデータ通信を切り替えた後の短時間の通信断は、拡張がチャネルを再構築する正常な現象です。数秒経っても回復しない場合は、スイッチを手動で入れ直してください。

もう一つの発想:パソコンにモバイル端末の代わりにプロキシさせる

テレビ、ゲーム機、またはクライアントをインストールしにくい端末には、「1台のパソコンでClashを動かし、家中で共有する」方式が使えます:allow-lanを有効にした後、他の端末のプロキシ設定をパソコンのLAN内IPアドレスとmixed-portに向けるだけです。完全な手順(bind-addressの値やファイアウォールの許可設定を含む)はこちらのノートを参照:ClashのLAN内プロキシ共有設定。

まだ解決しない場合:次のステップ

症状別の章を確認しても解決しない場合は、この順序で進めてください:第一に、ログレベルをdebugに設定して問題を再現してください。ログに記録された元のエラー内容は、現象そのものよりも情報量が多いことがよくあります。第二に、最小構成での検証を行います——クリーンな設定に変える、クライアントを変える、ネットワーク環境を変える、この3つの変数をそれぞれ1つずつ変更していけば、問題を具体的な箇所に絞り込めます。第三に、よくある質問ページを分類ごとに一通り確認してください。細かい問題(自動起動、設定ファイルの場所、モード切り替えが反映されないなど)の多くはそこに直接的な答えがあります。基本操作に不安がある場合は、使用ガイドに戻って本線の流れをもう一度やり直してください。「トラブル」と思っていたものの多くは、実はどこかのステップが飛ばされていただけということがよくあります。