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

再現可能な切り分けの基本を整える

トラブルシューティングの第一歩は設定を変更することではなく、障害の範囲を確定することです。発生時刻、現在のネットワーク種別、クライアント名、プロキシモード、選択中のノード、接続先、エラーメッセージを記録してください。デスクトップではシステムプロキシと TUN の有効状態も、モバイル端末では VPN アイコンの表示と、バックグラウンド動作がシステムに制限されていないかも記録します。「使えない」とだけ書くと、どの手順で直ったのか判断できず、一時的な通信不安定と固定的な設定ミスも区別できません。

ネットワーク経路を6段階に分ける

通常の接続は、アプリ、OS のプロキシまたは仮想 NIC、Clash の待受ポート、ルールとプロキシグループ、リモートノード、接続先サービスを経由します。どこか一つが失敗しても、ブラウザには単なる接続タイムアウトとして表示されることがあります。近い層から順に、クライアントプロセスが動作しているか、ポートが待ち受けているか、設定が正常に読み込まれているか、プロキシグループで利用可能なノードが選択されているか、ノードが接続を確立できるか、接続先が現在の出口からのアクセスを許可しているかを確認してください。クライアント、サブスクリプション、DNS を同時に変更しないでください。複数の変数を同時に変えると、判断の根拠が失われます。

まずシステムプロキシと TUN を無効にし、ブラウザから普段利用できるサイトへ直接アクセスします。直接接続も失敗する場合は、Clash を変更する前に Wi-Fi、LAN ケーブル、ゲートウェイ、認証ページ、システム DNS を確認します。直接接続が正常なら、クライアントを起動しても、まずはシステムトラフィックを制御せず、設定の読み込みが完了するかログを確認します。最後にシステムプロキシまたは TUN を有効にし、ドメイン名と純粋な IP アドレスへのリクエストを別々に試します。ドメイン名だけ失敗して IP に到達できるなら、通常は DNS が原因です。両方とも失敗する場合は、ポート、ノード、ルーティングを引き続き確認します。

ポートとログの証拠を集める

一般的な設定では、mixed、HTTP、SOCKS のいずれかの待受ポートが開かれます。具体的な番号は現在の設定とクライアント画面を基準にし、ネット上の例だけで判断しないでください。Windows では PowerShell、macOS と Linux では lsof で待受状態を確認できます。コマンドに何も表示されない場合は、カーネルが待ち受けに失敗した、設定が読み込まれていない、またはポートが他のプログラムに使用されている可能性があります。

# Windows PowerShell：7890 を画面に表示されたポートへ置き換え
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

# ローカル HTTP プロキシ経由でテストを実行
curl -I --proxy http://127.0.0.1:7890 https://example.com

ログレベルはまず info を使用します。設定の読み込み、ルールのマッチ、DNS クエリ、接続エラーを確認するのに十分で、debug のように大量の出力がすぐ発生することもありません。1件のリクエストを追跡する必要がある場合だけ一時的にログレベルを上げ、再現後に戻してください。エラー発生前後の十数行を保存し、最後の1行だけを切り取らないことが重要です。たとえば「接続タイムアウト」の前に、ドメイン名の解決失敗、空のプロキシグループ、設定項目の非互換が記録されている場合があります。

基本手順が終わったら、次の3点に答えられる状態になっているはずです。クライアントは正常に起動したか、ローカルプロキシだけでリクエストを完了できるか、問題は特定のノードまたは特定の種類のドメインだけで起きているか。まだ答えられない場合は、高度なパラメータへ進まず、ログの収集を続けてください。安定した証拠の連鎖は、「更新」や「修復」を何度もクリックするより早く、異なるクライアントでも同じ問題を再現しやすくします。

Clash を有効にすると完全にインターネットへ接続できない

この症状では、システムプロキシまたは TUN を有効にするとブラウザ、メッセージアプリ、アプリストアが同時に接続できなくなり、制御を解除するとネットワークが戻ります。最初からノードの故障と決めつけないでください。システムの通信がローカルプロキシへ送られていても、カーネルに利用可能な出口がない、待受ポートが一致していない、ルールが空のプロキシグループへ送っているなどの原因で同じ症状が起こります。まずローカルプロキシ経路が成立していることを確認し、その後でシステムによる制御を調べます。

まずクライアント内部の状態を確認

設定画面で現在の設定が読み込まれているか、プロキシグループにノードが存在するか、アクティブなポリシーが実際にノードを選択しているかを確認します。サブスクリプションの更新後にプロキシグループ名が変わり、以前の選択状態が新しいグループに対応しなくなることがあります。画面上はルールモードに見えても、実際にはグループ内に有効な接続先がない場合があります。別のノードへ手動で切り替えて遅延テストを行うのは初期確認にすぎず、遅延テストの成功をウェブページの利用可能性と同一視しないでください。テスト先、プロトコル、実際のアクセス経路が異なる可能性があるためです。

続いてシステムプロキシを無効にし、クライアントだけを起動した状態で curl にローカルプロキシを明示指定します。このコマンドが成功すれば、カーネル、設定、ノードはおおむね正常で、問題はシステムプロキシまたはアプリ側に絞れます。connection refused が返る場合は、画面のポートと設定内の mixed-port、port が一致しているか確認します。timeout の場合はノードを引き続き確認し、proxy connect aborted や設定エラーが出る場合は起動ログを見直してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

# システムプロキシ設定に依存せずローカルプロキシを単独で検証
curl -v --proxy http://127.0.0.1:7890 https://example.com

ポート競合とループバックアドレスを確認

同じ端末で2つのプロキシクライアントを同時に動かすと、後から起動したカーネルがポートをバインドできないことがあります。代表的なログは address already in use、bind failed、listen error です。他のクライアントを終了してから再起動し、併用が必要なら各インスタンスに異なるポートを割り当てます。待受アドレスを無闇に LAN アドレスへ変更しないでください。ローカルで使う場合はループバック待受を優先し、LAN 端末へプロキシを提供する明確な理由がある場合だけ allow-lan を有効にします。その際はファイアウォールと信頼できるネットワーク境界も確認してください。

明示的なプロキシリクエストは成功するのに、すべてのアプリがインターネットへ接続できない場合は、システムプロキシを一度無効にしてから再度有効にし、クライアントに OS 設定を書き直させます。プロキシサーバーが 127.0.0.1 を指し、ポートがクライアントと一致しているか確認してください。以前 PAC、別の VPN、ブラウザ拡張、企業ネットワークツールを使っていた場合、複数の設定が互いに上書きしている可能性があります。ブラウザに独自プロキシが設定されていると、システム設定を迂回することもあります。一時的にブラウザを標準のネットワーク設定へ戻し、制御方式を一つだけ残してテストしてください。

TUN モード特有の分岐

TUN はシステムプロキシより広い範囲の通信を制御するため、権限、ルーティング、DNS のどれか一つが成立しないだけでも影響が大きくなります。Windows ではサービス権限と仮想 NIC の状態、macOS ではシステム拡張または VPN 構成の許可、Linux では TUN デバイスの作成とルート変更に必要な権限を確認します。デフォルトルートを作成する VPN を2つ同時に有効にしないでください。TUN を無効にしてシステムプロキシへ切り替えると復旧する場合、ノードや設定に問題があるとは限らず、仮想 NIC、ルーティングテーブル、DNS のリダイレクトを重点的に確認します。

ルールの誤判定も除外します。一度だけ短時間のテストとしてモードをグローバルに切り替えます。グローバルでは使えるのにルールモードでは使えない場合、リクエストが誤ったポリシーまたは DIRECT へ渡されています。接続ログでマッチしたルールを確認し、最終的なポリシーが MATCH になっているか、ルールセットが正常に読み込まれているか、プロキシグループが存在するかを調べます。テスト終了後はルールモードへ戻し、グローバルプロキシでルールの誤りを隠さないでください。

修復の順序は明確に保ちます。基礎ネットワークが使えること、クライアントが設定を読み込んだこと、ローカルポートが待ち受けていること、明示的なプロキシリクエストが成功することを確認し、最後にシステムプロキシまたは TUN を戻します。各段階が成功してから次へ進んでください。クライアントを変更する必要がある場合はダウンロードページでプラットフォームとアーキテクチャを確認します。移行時はサブスクリプション URL とカスタムルールを先にエクスポートし、出所の不明な設定ディレクトリ全体を直接コピーしないでください。

ノードのタイムアウト、ハンドシェイク失敗、接続リセット

ノード一覧で timeout と表示されるのは、テストリクエストが制限時間内に完了しなかったことを示すだけで、ローカルクライアントが壊れているとは限りません。ノードサーバーへ到達できない、ポートが遮断されている、ドメイン名が誤ったアドレスへ解決される、システム時刻がずれている、プロトコルパラメータが一致しない、テスト URL が現在のネットワークで利用できない、といった原因が考えられます。まず複数のノードを比較してください。1つだけ失敗するならノード側の問題を優先し、同じサブスクリプションの全ノードが失敗するなら、サブスクリプションの内容、ローカルネットワーク、プロトコル対応を確認します。

TCP、TLS、アプリケーション層の失敗を区別する

ログの i/o timeout は通常、接続または読み書きが制限時間を超えたことを示します。connection refused はリモートアドレスには到達できるものの、ポートでサービスが待ち受けていない状態です。connection reset by peer は接続確立後にリモート側または中間機器が接続をリセットしたことを示します。TLS handshake timeout はハンドシェイク段階の問題を指し、certificate や server name 関連のエラーは、システム時刻、SNI、証明書名、サブスクリプションパラメータと関係することが多いです。これらをすべて「ノードの故障」と一括りにせず、発生段階に応じて対処してください。

ノードアドレスがドメイン名の場合は、まずシステムツールで解決し、妥当な A または AAAA レコードが得られるか確認します。解決結果が頻繁に変わっても必ずしも異常ではありませんが、結果がない、プライベートアドレスが返る、現在のネットワークから到達できない IPv6 アドレスだけが返る場合は DNS を確認します。その後、接続先ポートへの TCP 接続性をテストします。コマンドで分かるのはポートへ接続できるかどうかだけで、プロトコル認証までは検証できません。ポート接続は成功してもクライアントのハンドシェイクが失敗する場合は、ノードパラメータを引き続き確認してください。

# Windows PowerShell
Resolve-DnsName node.example.net
Test-NetConnection node.example.net -Port 443

# macOS / Linux
dig node.example.net A
dig node.example.net AAAA
nc -vz node.example.net 443

時刻、プロトコル、カーネルの対応状況を確認

TLS には正確なシステム時刻が必要です。端末の時刻が大きくずれていると、証明書がまだ有効でない、または期限切れと判断されることがあります。自動時刻合わせを有効にし、接続を再確立してください。次に、サブスクリプションのプロトコル種別が現在のカーネルでサポートされているか確認します。古いクライアントや保守停止したソフトウェアは新しいフィールドを認識できず、設定の読み込み失敗、ノードの無視、ハンドシェイクパラメータの欠落として現れることがあります。この場合は、保守が続いている Clash Plus、Clash Verge Rev、FlClash、または mihomo 互換クライアントを優先してください。対応プラットフォームの選択はダウンロードページで確認できます。

サブスクリプションが生成したパスワード、UUID、ポート、転送方式、TLS の有効状態、server name、ネットワーク種別を自己判断で変更しないでください。1文字違うだけでも TCP 接続は成功する一方、認証段階で必ず失敗することがあります。サブスクリプションサービスにウェブ上のノード詳細がある場合は、クライアントが解析したフィールドと一つずつ比較します。サブスクリプション変換サービスがフィールドを失っていると確認できた場合だけ、形式を変更するか提供元へ問い合わせます。

同じノード群が家庭の固定回線ではすべてタイムアウトするのに、モバイルホットスポットでは使える場合、現在の接続ネットワーク、ルーター DNS、IPv6 経路、ポートポリシーに問題がある可能性が高いです。逆方向のテストも有効です。スマートフォンのホットスポットでは失敗し固定回線では使えるなら、モバイルネットワークの IPv6、NAT、省電力制限が原因かもしれません。大量の遅延テストを連続して実行しないでください。高い同時実行数はリモート側の制限を誘発し、ログも読みにくくします。2つのノードを選び、実際のウェブリクエストを一つずつ再現してください。

テスト先と実際のアクセスを分けて判断

遅延テストは通常、固定 URL へアクセスします。そのアドレスに到達できないとノードはタイムアウトになりますが、他のウェブサイトは正常に使える可能性があります。まずブラウザで実際の接続先へアクセスし、その後でテスト URL を変更します。テスト先には安定して応答し、レスポンスが小さく、HTTPS に対応したサイトを使います。ログインが必要なページや複雑なリダイレクトが発生するページは避けてください。URL Test の間隔も適切に設定します。短すぎるとノードとバッテリーの消費が増え、長すぎると出口の変化を発見できません。

最終判断はクロスチェックに基づけます。異なるノード、異なるネットワーク、異なる接続先で、少なくとも2組の比較を作ってください。1つのノードだけ失敗するなら現在のポリシーから外し、1つのネットワークだけで全ノードが失敗するならネットワーク経路を確認し、すべてのネットワークで失敗してログに未対応フィールドが出るならクライアントの互換性を処理します。これにより、リモート障害でローカルソフトウェアを何度も再インストールすることも、ローカル DNS の問題をサブスクリプション全体の無効化と誤認することも防げます。

サブスクリプションの追加・更新と設定解析の失敗

サブスクリプションの問題は少なくとも4種類に分けられます。リンクへリクエストできない、サーバーがログインページやエラーページを返す、クライアントが対応しない設定形式が返る、ダウンロードは成功するが解析に失敗する、というものです。画面の「更新失敗」だけでは詳しい理由が表示されないことが多いため、ログまたはブラウザでレスポンスを確認する必要があります。完全なサブスクリプション URL を公開して貼り付けないでください。アカウントを識別するアクセスパラメータが含まれている可能性があります。スクリーンショットではパスとクエリパラメータを隠してください。

リンク自体にアクセスできるか確認

まず、コピー時に空白、改行、日本語の句読点が混入していないか確認します。一部のチャットアプリは長いリンクを途中で切ったり、末尾の文字を書式情報に含めたりします。リンクをプレーンテキストエディタへ貼り付け、プロトコルの先頭から末尾まで連続して完全か確認してください。ブラウザでアクセスしてログインページ、プラン案内、認証コード画面、HTML エラーページへリダイレクトされる場合、クライアントは YAML として解析できません。サブスクリプションサービスのページでリンクを再生成し、クライアント設定を変更しないでください。

ブラウザでファイルをダウンロードできる場合は、レスポンスの先頭を確認します。Clash YAML の代表的なトップレベルフィールドには proxies、proxy-groups、rules があります。リンクによってはエンコードされたテキストや別クライアント専用形式が返されるため、サーバー側で Clash、Meta、mihomo 互換の出力を選択する必要があります。ファイル拡張子だけで判断しないでください。サーバーは拡張子のない URL から設定を返すこともあります。ローカルへダウンロードしてテキストエディタで確認する場合も、インデントやタブを自動変更させないでください。

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - "Example Node"

rules:
  - MATCH,PROXY

上の例は YAML の階層を説明するためのものです。リスト項目の前はスペースでインデントし、タブは使わないでください。引用符は対になっていなければならず、同じ階層のフィールドは同じ幅でインデントします。解析ログに line と column が示された場合は、エラー行だけでなく上方向も確認してください。実際のインデントエラーは前の行にある可能性があります。duplicate key は同じマッピング内に重複フィールドがあることを示し、cannot unmarshal は、本来配列であるべき値が文字列になっているなど、フィールドの型が想定と異なる場合に表示されます。

リモート更新とローカル上書きを切り分ける

多くの GUI クライアントでは、サブスクリプションに対して上書き設定、スクリプト、追加設定を適用できます。リモートの原文は有効なのに、上書き適用後に起動できない場合、問題はローカルの加工層にあります。上書きを一時的に無効にして再読み込みし、復旧したらカスタム DNS、ルール、プロキシグループを一つずつ有効に戻します。クライアントのキャッシュ内にあるサブスクリプションファイルを直接編集しないでください。次回更新で上書きされ、問題の再現も難しくなります。長期的なカスタム設定は、クライアントが正式に提供する上書き機構へ置いてください。

サブスクリプションの更新は成功したのにノードがない場合、まず返された内容に proxies が含まれているか確認し、次にクライアントが新しい設定を選択しているか確認します。ダウンロードは成功しても古い設定をアクティブなまま保持するクライアントがあり、手動切り替えが必要な場合があります。また、非互換のフィールドが一部にあるため設定全体を拒否するクライアントもあります。設定一覧の更新時刻はリクエストが実行されたことしか示さず、カーネルが適用したことの証明にはなりません。カーネルログに設定読み込み完了が表示され、プロキシグループにノードが並んで初めて更新経路が完了します。

ネットワーク、証明書、更新頻度を処理

サブスクリプションのドメイン自体がプロキシを必要とする一方、クライアントの起動にはノードを得るためにサブスクリプションが必要という循環依存が起こることがあります。最近動作したローカル設定を残し、まず旧設定でネットワークを確立してからサブスクリプションを更新してください。唯一動作する設定を削除しないでください。証明書エラーは時刻を合わせ、システムの証明書環境を確認します。企業ネットワークで管理プロキシを使っている場合は、そのネットワークの証明書とアクセスルールに従ってください。

更新ボタンを何度も押しても、サーバー側のレート制限は解消しません。HTTP 429 が出たら時間を置いて再試行します。401 または 403 は通常、リンクの失効、アカウント状態、アクセスパラメータを示します。404 はパスが存在しないことを、5xx はサーバー側の障害を示す傾向があります。クライアントが短いエラーしか表示しない場合は、開発者ログまたはコマンドラインでステータスコードを確認できますが、出力からサブスクリプション URL を隠してください。

安定した修復後の確認項目は、サブスクリプションのレスポンスが正しい形式であること、問題のある上書き設定が有効になっていないこと、ログに設定読み込み成功が出ること、プロキシグループにノードが表示されること、再起動後も同じ設定へ戻れることです。基本的な追加手順はクイックスタートで確認できます。各カーネルのフィールド互換性の境界を理解したい場合は、Clash オリジナル版・Meta・mihomo のカーネル比較を参照してください。

接続は成功するがウェブ、ダウンロード、動画が遅い

速度の問題はノード一覧の遅延だけでは判断できません。遅延は小さなリクエストの往復時間を示す値で、ダウンロード速度はリモート側の帯域、経路の混雑、パケットロス、プロトコルのオーバーヘッド、接続先の速度制限、ローカル端末の性能にも左右されます。遅延が低いノードでも帯域が小さい場合があり、少し遅延の高いノードの方が大容量ファイルに適することもあります。まず、ドメインを開くまでが遅いのか、接続確立が遅いのか、継続的なダウンロードが遅いのか、それとも動画や特定サイトだけが遅いのかを明確にします。

直接接続とプロキシ接続を比較する

同じ端末、同じネットワーク、近い時刻に、直接接続とプロキシ接続をそれぞれテストします。端末をまたいで比較したり、Wi-Fi と有線の結果を混ぜたりしないでください。小さなウェブページと継続的なダウンロードを含め、瞬間的なピークではなく安定した時間帯を記録します。直接接続も遅い場合は、無線信号、ルーターの負荷、通信事業者の経路、接続先サービスを先に確認します。プロキシだけが遅い場合は、ノードとプロトコルを比較してください。

バックグラウンド同期、システム更新、クラウドストレージへのアップロードを停止します。アップロード帯域が埋まると確認応答が遅れ、ダウンロードとウェブアクセスの両方が遅くなります。Wi-Fi ではアクセスポイントの近くで試し、2.4 GHz の干渉とプロキシの問題を区別してください。有線は正常で無線だけ遅いなら、Clash を変更する必要はありません。モバイルホットスポットでは電波の切り替えと通信プラン側の速度制限に注意し、短時間の速度測定を継続転送の品質とみなさないでください。

DNS の初動と接続の再利用を確認

ウェブページをクリックして長時間白いままなのに、その後は正常に読み込まれる場合、DNS または初回の接続ハンドシェイクが遅い可能性があります。ログでドメイン解決に時間がかかっているなら、まず DNS の章の問題を処理します。同じドメインに対して毎回大量の接続を新規確立している場合は、ブラウザ拡張、安全ソフトウェア、ネットワーク中間層が接続の再利用を妨げていないか確認します。クライアントごとの同時接続数と接続プールはカーネルが管理するため、出所不明の最適化パラメータを速度目的で無闇に適用しないでください。

プロキシグループの自動テストも誤判定を招くことがあります。URL Test は指定されたテスト先だけでノードを選び、動画サイトへの実際の経路はまったく異なる可能性があります。継続転送では2〜3個のノードを手動比較する方が確実です。Fallback は現在のノードが使えないときの切り替えに適し、Load Balance は接続ごとの出口を変えます。ログイン状態に敏感なサイトでは、出口が変わると再認証を求められることがあります。速度の切り分け中は固定ノードを優先し、自動切り替えによる変数を減らしてください。

MTU、IPv6、TUN の性能問題を見分ける

TUN モードで小さなページは開けるのに大きなファイルが停止したり、一部の画像だけ完全に読み込めなかったりする場合、MTU と経路上のフラグメントが関係している可能性があります。最初から極端に小さい MTU を設定しないでください。システムプロキシと TUN を比較し、システムプロキシは正常で TUN だけ異常なら、仮想 NIC の初期値、下位 VPN の多重化、ルーター経路を確認します。一部のネットワークでは IPv6 の到達性が不完全で、IPv6 を先に試して失敗を待った後に IPv4 へフォールバックするため遅延が生じます。ログと DNS の結果でこの過程を確認できます。

# リクエスト各段階の所要時間を確認し、name lookup、connect、start transfer を重点的に比較
curl -o /dev/null -s \
  -w "dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  --proxy http://127.0.0.1:7890 \
  https://example.com

クライアント自体のリソース使用量も確認対象です。大規模なルールセット、大量のログ、短すぎるヘルスチェック間隔、複雑なスクリプトは CPU とメモリの負荷を増やし、低消費電力の端末では特に影響が出ます。まずデバッグログを無効にし、ヘルスチェック間隔を延ばし、不要な上書き設定を停止してから性能を比較します。ルーターや古いスマートフォンで完全な TUN を動かす場合、単一コアの性能が制限要因になることもあります。この場合、ノードを変更してもローカル処理のボトルネックは解消しません。

最終記録には、直接接続の結果、プロキシ接続の結果、ノード、制御モード、DNS 段階の所要時間、テスト時刻を含めます。TUN とシステムプロキシの差に問題が集中する場合は、TUN モードとシステムプロキシの仕組みの比較を参照してください。これらのデータがあれば、ノードを変更すべきか、ルールを修正すべきか、DNS を調整すべきか、ローカルの無線ネットワークを処理すべきか判断できます。

DNS の解決失敗、汚染、漏洩、循環クエリ

DNS の障害は「サーバーが見つからない」という一言だけではありません。ドメインが断続的に開けない、同じサイトでもアプリによって結果が異なる、プロキシを有効にしてもシステム解決が使われる、fake-ip アドレスをアプリが正しく処理できない、イントラネットのドメインが使えない、解決リクエストがローカルプロキシとシステムリゾルバーの間で循環する、といった症状があります。まず解決経路を図にします。アプリは誰にクエリを渡しているか、Clash は DNS を待ち受けているか、上流サーバーへ直接接続するかプロキシ経由か、最終的にどのコンポーネントが結果を返しているかを確認してください。

解決の問題か接続の問題かを確認

nslookup、dig、またはシステムの名前解決コマンドでドメインに結果があるか確認し、ログで Clash がクエリを受け取っているかを確認します。アドレスは解決できるのに接続がタイムアウトするなら、ノードまたは接続先経路の問題かもしれません。純粋な IP リクエストは使えるのにドメイン名だけ失敗するなら、DNS の可能性が高くなります。ブラウザが独自のセキュア DNS を使っていると、システムコマンドとは結果が異なる場合があります。切り分け中はブラウザ独自の DNS を一時的に無効にし、システムまたは Clash の経路へ統一してください。

# システムが現在使用している解決経路を確認
nslookup example.com

# macOS / Linux で A と AAAA レコードを確認
dig example.com A
dig example.com AAAA

# ローカル DNS の待受ポートを指定する場合
dig @127.0.0.1 -p 1053 example.com

ローカル DNS ポートが待ち受けていない場合は、設定で DNS が有効か、ポートが使用中でないか、カーネルがバインドに必要な権限を持っているか確認します。53番ポートは通常より高い権限が必要で、システムサービスとも競合しやすいため、デスクトップクライアントは内部転送や高い番号のポートを使うことがよくあります。例に合わせて無理に 53 へ変更しないでください。ログの bind failed、address already in use、permission denied は、それぞれ競合または権限の問題として処理します。

fake-ip と redir-host の境界を理解する

fake-ip はアプリへ予約アドレスを返し、カーネルがドメインとの対応関係を管理します。これによりドメイン名に基づくルールマッチがしやすくなり、解決の迂回も一部減らせます。一部の LAN 機器探索、古いプログラム、ゲームプラットフォーム、実アドレスを直接必要とするサービスは互換性がなく、fake-ip-filter への追加が必要な場合があります。すべてのドメインをフィルターへ追加しないでください。fake-ip の主な利点が失われます。ログで具体的なドメインを確認し、必要なイントラネットのサフィックス、機器探索用ドメイン、明確に非互換な項目だけを追加します。

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

例の上流サーバーは構文の説明用であり、実際の選択はネットワークの到達性とプライバシー要件に合わせます。暗号化 DNS のアドレス自体も解決が必要で、その過程は bootstrap または default-nameserver に依存します。すべてのブートストラップ解決を、プロキシ経由でないと到達できず、しかもプロキシノードのドメインもそのリゾルバーに依存するアドレスへ向けると、起動時の循環が発生します。ノードのドメインと暗号化 DNS のホスト名を、起動段階で到達可能なリゾルバーから解決できる経路を用意し、Clash が制御を引き継いだ後のリクエストを処理させるのが適切です。

DNS 漏洩と複数リゾルバーの併存を処理

いわゆる DNS 漏洩で重要なのは、テストページに何台のサーバーが表示されるかではなく、アプリのクエリが想定した経路を迂回しているかどうかです。システムプロキシは通常、プロキシに対応したアプリの接続だけを制御し、すべてのシステム DNS を自動的に制御するわけではありません。TUN と DNS リダイレクトはより広い範囲をカバーしますが、正しいルーティングへの依存も大きくなります。ブラウザのセキュア DNS、OS の暗号化 DNS、他の VPN、安全ソフトウェアを確認し、複数のコンポーネントがクエリを奪い合っていないことを確認します。詳しい検証方法はClash DNS 漏洩の検出と防止設定を参照してください。

イントラネットのドメインを解決できない場合、Clash の DNS 設定をすべて削除しないでください。企業や家庭のプライベートドメインは通常、LAN の DNS でしか解決できないため、nameserver-policy または専用ドメインルールで内部リゾルバーへ送ります。端末がそのネットワークを離れると内部リゾルバーへ到達できなくなるため、フォールバックも許可してください。検索ドメインに依存する短いホスト名は、DHCP が配布するドメインサフィックスを必要とすることがあります。完全修飾ドメイン名は使えるのに短い名前だけ失敗する場合、プロキシノードではなくシステムの検索ドメインを確認します。

修復後は必要に応じてシステムとブラウザの DNS キャッシュを消去し、クライアントを一度再起動してから、システムコマンド、ブラウザ、実際のアプリを個別に検証します。ログにはクエリが想定したリスナーへ入り、上流リクエストへ到達でき、返されたアドレスと接続ルールが一致していることが示されるはずです。再起動後に再発する場合は、ログイン時に他のネットワークツールが DNS を書き換えていないか確認します。DNS の切り分けの終点は、テストページに特定の名前が表示されることではなく、解決経路が明確で、アプリの動作が一貫し、内部と外部のドメインがポリシーどおりに動くことです。

システムプロキシは有効だがアプリに反映されない

システムプロキシは、すべての通信を強制的に Clash へ送る仕組みではありません。対応するアプリへ HTTP、HTTPS、SOCKS のプロキシアドレスを通知するだけです。ブラウザは通常読み取りますが、一部のゲーム、コマンドラインツール、ストアアプリ、独自ネットワークスタックを持つソフトウェアは無視することがあります。クライアント画面に「システムプロキシ有効」と表示されても、書き込み処理が実行されたことしか示さず、対象アプリが採用した証明にはなりません。OS の設定、アプリの設定、ローカルプロキシのログを同時に確認してください。

システムに記録されたアドレスとポートを確認

システムのネットワーク設定を開き、プロキシサーバーがループバックアドレスを指し、ポートがクライアントの現在の待受ポートと一致しているか確認します。設定の変更、カーネルの切り替え、複数クライアントの併用後には、古いポートが残ることがあります。Windows ではシステムプロキシ、WinHTTP プロキシ、アプリ固有の設定を区別してください。macOS のプロキシはネットワークサービスごとに保存され、Wi-Fi と有線で異なる場合があります。Linux デスクトップ環境のグローバルプロキシも、すべての端末プログラムへ自動的に適用されるわけではありません。

# Windows：WinHTTP プロキシの状態を確認
netsh winhttp show proxy

# macOS：Wi-Fi ネットワークサービスの Web プロキシを確認
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

# Linux / 一般的なターミナル：環境変数を確認
env | grep -i proxy

コマンドラインプログラムは通常 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の環境変数を読み取りますが、対応状況はプログラムによって異なります。環境変数は設定後に起動し、その値を継承したプロセスにだけ有効です。すでに開いているターミナルやエディタには古い値が残る場合があります。設定後にターミナルを開き直し、テスト終了後は変数を消去して、クライアント終了後もコマンドが存在しないローカルポートを指し続けないようにしてください。

# 現在のターミナルで一時的に HTTP プロキシを使用
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# SOCKS5 を使用し、ドメイン名の解決をプロキシ側に任せる
export ALL_PROXY=socks5h://127.0.0.1:7890

# テスト終了後に設定を消去
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

バイパスリスト、PAC、アプリ独自プロキシを処理

システムのバイパスリストに一致するアドレスは直接接続されます。リストに広すぎるワイルドカードが含まれていると、接続先が一度も Clash に入らない可能性があります。PAC スクリプトも URL に応じて DIRECT または PROXY を返すため、キャッシュ、無効なアドレス、ルールの誤りで一部のサイトだけ反映されないことがあります。まず PAC を無効にし、固定のシステムプロキシで検証します。固定プロキシが有効なら、PAC の内容と取得状態を個別に確認してください。

ブラウザ拡張、開発ツール、コンテナ環境、IDE は独自のプロキシを設定している場合があります。独自設定の優先度がシステムプロキシより高いと、クライアントの切り替えが反映されません。対象アプリのネットワーク設定を確認し、「システム設定を使用」に戻すか、現在のローカルポートを直接入力します。システムプロキシに対応しないプログラムには TUN が適する場合がありますが、先に権限、ルーティング、DNS が前述の手順どおり機能していることを確認してください。

ルールによる直接接続と、実際に制御されていない状態を区別

アプリのリクエストが Clash の接続ログに現れ、出口が DIRECT と表示されるなら、システムプロキシは機能しており、ルールが直接接続を選択したということです。この場合はシステム設定を変更し続けるのではなく、マッチしたルールとプロキシグループを確認します。ログにリクエストがまったくない場合だけ、アプリがプロキシを迂回しているか、制御対象になっていないと判断します。一時的にグローバルモードへ切り替えればルール分岐を検証できますが、テスト後は元へ戻し、具体的なドメインまたはルールセットを修正してください。

LAN アドレスは通常、直接接続のままにします。すべての通信をログへ表示させるためにローカルネットワークのバイパスを削除すると、プリンター、NAS、ルーター管理画面、機器探索に影響する可能性があります。システムプロキシの「ローカルアドレスをバイパス」と Clash ルールのプライベートネットワーク DIRECT は併存できますが、異なる層で機能します。外部の接続先を確認するときは明確なパブリックドメインを選び、LAN の例外に影響されないようにしてください。

確認にはブラウザとコマンドラインツールを1つずつ使います。ブラウザはシステムプロキシ経由、コマンドラインは明示的なプロキシ経由でアクセスし、両方がログに現れることを確認します。その後 Clash を終了し、システムプロキシが消去されて直接接続が戻ることを確認してください。システムプロキシで対象プログラムを制御できない場合は、TUN を検討します。「システムプロキシ有効」を強制的な制御とみなさないでください。制御方式の境界はプロキシモードの比較記事で詳しく確認できます。

クライアントの起動失敗、突然の終了、カーネルの繰り返し終了

クライアントのクラッシュでは、まず GUI の終了、カーネルプロセスの終了、OS による強制終了を区別します。画面は閉じたのにプロキシが使えるなら、カーネルがバックグラウンドで動き続けている可能性があります。画面は正常でもポートを待ち受けないなら、カーネルの起動失敗かもしれません。プログラム全体が突然消える場合は、システムのクラッシュレポート、メモリの圧迫、安全ポリシーも確認します。ログを保存する前に何度も再起動しないでください。連続起動で最も重要な初回エラーが上書きされることがあります。

空の設定と直前の変更から確認する

クラッシュ直前の最後の操作を思い出します。サブスクリプションの更新、TUN の有効化、上書き設定の追加、カーネルの切り替え、クライアントのアップグレード、テーマの変更などです。セーフモードがある場合は、最後の設定を自動読み込みしない状態で起動します。ない場合は設定ディレクトリをバックアップし、直近の設定を移動してから空の環境で起動してください。空の設定で起動できるなら、プログラム本体はおおむね正常で、サブスクリプションと上書き設定を一つずつ戻します。空の設定でもクラッシュするなら、ランタイム、権限、インストールファイル、システムログを確認します。

設定が原因のカーネル終了では、解析エラー、未知のフィールド、存在しないノードを参照するプロキシグループ、ルールセットファイルの欠落、ポートのバインド失敗などがログに残ります。「カーネルが終了しました」という後続メッセージだけでなく、ログに最初に出た fatal または error を処理してください。設定がサブスクリプション由来なら、まずローカルの上書き設定を無効にします。特定のサブスクリプションだけで起きる場合は、機密情報を除いた最小設定を保存して切り分けます。ログを共有する前にノードのパスワードとサブスクリプションパラメータを削除してください。

ポート、ファイル権限、ディスク状態を確認

ポートの使用中状態により、カーネルが起動直後に終了することがあります。他のプロキシプログラムを完全に終了し、タスクマネージャーまたはアクティビティモニタに古いカーネルが残っていないか確認します。設定ディレクトリへ書き込めないと、クライアントはキャッシュ、データベース、ログを更新できません。ディスク容量不足でも書き込みに失敗します。すべての権限問題を回避するために常時管理者として実行するのではなく、設定ディレクトリを現在のユーザーが読み書きできる場所に置き、TUN に必要な昇格操作はクライアントの正式な仕組みで行ってください。

Windows ではイベントビューアーのアプリケーションエラーを確認し、障害モジュールを記録します。macOS ではシステムが生成したクラッシュレポートを確認します。Linux デスクトップではターミナルからクライアントを起動すると、ライブラリ不足、権限、グラフィックバックエンドのエラーが表示されることがあります。サーバー環境で mihomo を動かしている場合は systemd で最新ログを確認し、終了コードと再起動回数を確認してください。

# Linux：サービス状態と最新ログを確認
systemctl status mihomo --no-pager
journalctl -u mihomo -n 120 --no-pager

# 設定構文を確認し、パスは実際のインストール先に合わせて変更
mihomo -t -f /etc/mihomo/config.yaml

アップグレード、移行、互換性への対応

クライアント間の移行でプログラムのデータディレクトリ全体をコピーしないでください。クライアントによってデータベース、画面設定、上書き形式、カーネルのパスが異なります。サブスクリプション URL、カスタムルール、必要な DNS 断片をエクスポートし、新しいクライアントで設定を作り直す方が安全です。デスクトップではまず Clash Plus を選び、必要に応じて Clash Verge Rev、FlClash、Clash Nyanpasu も利用できます。Clash for Windows と ClashX Meta は保守が終了しているため、新しい設定の互換性問題を処理する第一候補には適しません。

アップグレード後に起動できない場合は、リリースノートで設定ディレクトリ、カーネルインターフェース、システム要件が変更されていないか確認します。本サイトでは本文に具体的なバージョン番号を固定せず、現在利用できるインストーラーをダウンロードページでまとめて提供しています。再インストール前にユーザー設定をバックアップし、システムの通常の手順でアンインストールしてから、対応アーキテクチャのソフトウェアをインストールします。ARM と x64 のインストーラーを混在させないでください。macOS では Apple Silicon と Intel も区別します。アーキテクチャが違うインストーラーは起動できない場合があるほか、変換実行で動いても性能や拡張権限の問題が出ることがあります。

システムのセキュリティソフトにブロックされた場合は、明確なブロックイベントとファイルパスを確認し、推測で保護機能全体を無効にしないでください。企業管理端末では VPN の作成、ネットワーク拡張のインストール、未承認プログラムの実行が禁止されていることがあり、その制限は端末管理者が処理する必要があります。ファイルが隔離された場合は、まずダウンロード元が本サイトの対応クライアント入口であることを確認し、システムポリシーに従って復元または再インストールします。不明な転載サイトから不足コンポーネントを補わないでください。

クラッシュ修復の確認は「画面が開く」だけでは不十分です。カーネルが継続して動作すること、ローカルポートが安定して待ち受けること、設定が構文チェックを通ること、システムプロキシを正常に切り替えられることを確認し、システム再起動後にも再検証します。空の設定では安定し、特定のカスタム設定を戻すと再び終了するなら、その部分をさらに絞り込み、最小の発生条件を特定してください。複数のクライアントを何度もインストールするより、確実な結論に到達しやすくなります。

Android・iOS モバイル端末の専用トラブルシューティング

モバイルクライアントはシステム VPN インターフェースで通信を制御するため、問題は設定構文そのものよりも OS のライフサイクル管理に起因することがあります。画面消灯後の切断、Wi-Fi からモバイルデータへの切り替え後の停止、一部アプリだけの接続失敗、VPN アイコンの繰り返し消失では、バックグラウンド権限、常時接続 VPN、低電力モード、データセーバー、他の VPN との競合を確認します。モバイル端末では通常、一度に1つの VPN トンネルしか維持できません。広告ブロッカー、企業 VPN、Clash クライアントが同じインターフェースを同時に使用することはできません。

Android：バックグラウンド、VPN 権限、アプリごとの分岐

Android では初回接続時に VPN の許可ダイアログが表示されます。許可していないと、クライアントへ設定を追加できてもシステムトンネルは確立できません。接続ボタンを押すとすぐ未接続へ戻る場合は、許可が取り消されていないか確認します。一部メーカーの OS は画面消灯後にバックグラウンドプロセスを制限するため、クライアントをバックグラウンド実行可能、またはバッテリー最適化の対象外にし、自動起動も許可してください。設定名は端末により異なりますが、トンネル動作中にシステムがクライアントを停止させないことが目的です。

一部のアプリだけがプロキシを通らない場合は、アプリごとの分岐または VPN バイパスリストを確認します。アプリ単位のプロキシでは、指定したアプリだけをプロキシするか、指定したアプリを除外するかを選べます。モードを逆にすると、多くのアプリが直接接続になります。「VPN を使用しない接続をブロック」を有効にする前に、起動時とネットワーク切り替え後にクライアントが確実に再接続できることを確認してください。切り分け中はこの制限を無効にし、安定後に必要に応じて有効にします。

Wi-Fi からモバイルデータへ切り替えた後に復旧しない場合は、まずトンネルを切断して再接続し、ノードのドメイン名が再解決され接続が再確立されるかログで確認します。モバイルネットワークが IPv6 を優先する一方、ノードのドメインや DNS 経路が IPv4 にしか対応していない可能性があります。プライベート DNS とクライアント DNS が同時に動いていることもあります。Android のプライベート DNS を一時的に自動へ戻し、クライアント標準の DNS 経路で再テストしてください。復旧したら、どちらの解決機構を残すか判断します。

iOS：VPN 構成、オンデマンド接続、ネットワーク切り替え

iOS で初めて有効にする際は、VPN 構成の追加を許可する必要があります。システム設定に同種の構成が複数ある場合は、Clash Plus に対応する項目が有効か確認してください。本サイトではモバイル向けに Clash Plus を第一におすすめしています。アプリは App Store からインストールでき、公式情報はiOS ダウンロード入口で確認できます。接続後に VPN 状態が表示されない場合は、システムの VPN 画面へ戻り、接続を試行しているのかすぐ切断されているのかを確認してから、クライアントのログを読みます。

低電力モードとシステムによるリソース回収はバックグラウンド維持に影響することがありますが、通常の Network Extension はシステムが管理します。クライアントを手動で強制終了するとトンネルが停止する可能性があるため、切り分け中はマルチタスク画面から頻繁にアプリを閉じないでください。オンデマンド接続ルールの設定が不適切だと、Wi-Fi では接続するのにモバイルデータでは切断する、特定のネットワークで再接続を繰り返す、といった症状が出ます。まず複雑なオンデマンドルールを無効にし、手動で安定した接続を作ってから、ネットワーク条件を一つずつ戻します。

モバイル端末のサブスクリプションと証明書の問題

モバイルブラウザでサブスクリプション URL をコピーすると、実際のリンクではなくページに表示されたテキストをコピーしてしまうことがあります。サービスページのコピー用ボタンを使い、貼り付け後に先頭と末尾を確認してください。スクリーンショットから書き写さないでください。Wi-Fi では更新に失敗するのにモバイルデータでは成功する場合、現在の Wi-Fi の認証ページと DNS を確認します。逆の場合はモバイルデータの権限を確認します。システム設定でクライアントのモバイルデータ利用が禁止されていると、トンネル画面は表示されてもサブスクリプション更新とノード接続が失敗します。

システム時刻はモバイル端末の TLS にも影響します。日付とタイムゾーンを自動設定にしてください。公衆 Wi-Fi ではウェブ認証が必要なことがあり、VPN が先に通信を制御すると認証ページが表示されない場合があります。その際は Clash を切断してネットワークへログインし、直接接続でウェブページが開くことを確認してからトンネルを作成します。公衆ネットワークを離れた後に認証状態が残る場合は、プロキシ設定を変更するより Wi-Fi を一度オフにして再度オンにする方が効果的です。

モバイル端末では最終的に4段階で確認します。Wi-Fi で接続してアクセスし、モバイルデータへ切り替えてアクセスを続け、数分間ロックした後にアクセスを復旧し、クライアントを再起動してサブスクリプションを再読み込みします。各段階で VPN アイコンとログを確認してください。同じネットワーク、同じサブスクリプションで Android と iOS の両方が失敗するなら、問題はノードまたはサブスクリプション側にある可能性が高いです。1台だけ失敗するなら、その端末の権限、DNS、システム制限を確認します。再インストールが必要な場合、Android はAndroid ダウンロードエリアから Clash Plus、Clash Meta for Android、FlClash、Surfboard を選べます。iOS は Clash Plus のストア入口を利用してください。

切り分け完了後は、短い記録を残してください。端末の OS、クライアント、制御モード、問題が起きたネットワーク、ログのキーワード、行った変更、最終結果を記録します。同じ症状が再発したら、すべての設定をやり直すのではなく、検証済みの手順を再利用します。クライアント間の関係やカーネルの出所が関係する場合は、Clash オープンソース生态系のプロジェクト関係図を参照し、GUI クライアント、カーネル、モバイル実装を混同しないようにしてください。