Clashのよくある質問とトラブル対処

コアは設定の読み込み、プロキシ接続の確立、ルール照合、DNS処理を担当します。GUIクライアントはサブスクリプション管理、ポリシー切り替え、ログ確認、システムプロキシ制御を担います。mihomoはClashの設定体系を引き継ぐ現行のコア実装で、多くの新しいクライアントが実行コアとして採用しています。問題を調べる際は、クライアント名、コアの種類、設定の入手元を併せて記録してください。画面側の不具合とコアのエラーでは、対処の手順が異なります。

ルールモードは、設定内の rules の記述順に従ってリクエストの行き先を判定するため、日常利用に適しています。グローバルモードでは、ほとんどのリクエストを現在選択中のプロキシポリシーに送るため、ノードの一時的な検証に向いています。直結モードでは、プロキシノードを経由せず目的先へ直接アクセスします。サイトを開けない場合は、一時的にグローバルモードへ切り替えて比較できます。グローバルモードでは正常でルールモードだけ異常なら、システムプロキシを何度も切り替えるのではなく、ルールのマッチ結果とポリシーグループの選択を確認してください。

サブスクリプションURLは設定の提供元が管理し、クライアントは定期的に再取得して内容を置き換えます。ローカルのYAMLファイルは端末に保存され、項目の変更は利用者が管理します。更新時にはサブスクリプション設定を直接編集した内容が上書きされることが多いため、長期的に使うカスタムルールは、クライアントが対応するオーバーライド、マージ、スクリプト機能に移してください。インポート前に、URLの応答がYAMLまたはクライアント対応の設定であり、ログイン画面やエラーページ、通常のWebページではないことも確認します。

Fake-IPモードでは、まずコアがアプリに予約アドレスを返し、内部マッピングによって元のドメイン名を復元してルール照合を行います。重複した名前解決を減らしながらドメイン情報を保持できるのが一般的な利点です。一部のLAN機器、ゲーム、業務ソフト、実アドレスの検証に依存するプログラムでは互換性に問題が出る場合があります。LANアクセスに異常があるときは、まず該当ドメインを fake-ip-filter に追加してください。影響範囲が広い場合は、一時的に redir-host へ切り替えて比較し、Fake-IPのマッピングが原因か確認します。

まずクライアントのログで、最初に発生した解析エラーと行番号を確認し、その周辺のインデント、コロン、ハイフン、引用符を調べます。YAMLのインデントにはスペースを使い、リスト項目の階層も統一してください。特殊文字を含むノード名やパスワードは引用符で囲めます。proxies、proxy-groups、rules などの項目名が正しい階層にあることも確認します。サブスクリプションURLから取得した設定なら、先に応答内容を確認し、Webページのエラー情報をYAMLとして読み込まないようにしてください。

まずサブスクリプションURLをブラウザに貼り付け、内容を取得できるか確認します。応答ステータス、ファイル内容、ログインページへのリダイレクトの有無も確認してください。ブラウザでもアクセスできない場合は、設定の提供元にURLの状態を確認してもらいます。ブラウザでは取得できるのにクライアントだけ失敗する場合は、クライアントのネットワーク権限、プロキシ経路、更新間隔、ローカルキャッシュを確認します。失敗した設定の複製を削除して再インポートすることもできますが、先にオーバーライドルールをバックアップしてください。応答がJSON、HTML、空白テキストの場合は、クライアントがそのサブスクリプション形式に対応しているかも確認します。

TUNモードでは仮想ネットワークインターフェースを作成し、システムルートを変更するため、通常のシステムプロキシより高い権限が必要です。Windowsではサービスモードがインストール済みで正常に動作しているか確認し、必要なら初回設定を管理者権限で行います。macOSではネットワーク拡張機能や補助サービスの許可が必要です。Linuxでは通常、CAP_NET_ADMIN、管理者権限、利用可能なTUNデバイスが求められます。権限を修正したらクライアントを完全に終了して再起動し、ファイアウォールが新しい仮想インターフェースを遮断していないか確認してください。

まず、クライアント自体が起動していないのか、起動済みだがシステムプロキシが有効になっていないのかを切り分けます。Windowsではタスクマネージャーのスタートアップアプリ一覧で状態を確認し、インストール先の移動によってクライアントのパスが無効になっていないか調べます。macOSではログイン項目とバックグラウンド項目の権限を確認します。Linuxではデスクトップの自動起動ファイルまたはユーザーサービスを確認してください。クライアントは起動するのに通信を取り込めない場合は、起動後にシステムプロキシを自動設定する項目やTUNを自動的に有効にする項目が、別々に有効になっているかも確認します。

まず、クライアントに表示されるHTTPまたはmixedポートと、システムプロキシ設定のアドレス・ポートが一致しているか確認します。ローカルアドレスは通常 127.0.0.1 です。次に、ブラウザやアプリが独自プロキシ、拡張機能のプロキシを使っていないか、またはシステム設定を無視していないか調べます。企業ポリシー、セキュリティソフト、別のプロキシツールがシステムプロキシを上書きすることもあります。ほかのネットワークツールを終了してからシステムプロキシを一度切り替え直し、システムプロキシに確実に従うブラウザでテストしてください。一部のアプリだけ異常な場合は、そのアプリ独自のプロキシ仕様を確認します。

一部のUWPアプリは制限付きコンテナで動作し、既定ではローカルのループバックプロキシにアクセスできません。そのため、デスクトップブラウザが正常でもストアアプリが接続できるとは限りません。クライアントに付属するUWPループバックツールを使い、通信が必要なアプリだけにチェックを付けて例外を保存してください。影響範囲を抑えるため、すべての項目を一括選択するのは避けます。設定後、対象アプリを再起動します。それでも失敗する場合は、システムプロキシのポートが利用可能か確認し、対象アプリがQUIC、独自DNS、その他システムプロキシに従わない接続方式を使っていないか調べてください。

遅延テストの失敗は、ノードが完全に利用できないことを意味するとは限りません。テスト先、ネットワークの出口、プロトコルのハンドシェイクが結果に影響します。まず端末の基本的なネットワークが正常か確認し、サブスクリプションを更新して、別の地域またはプロトコルのノードと比較します。続いてログで、DNS失敗、接続タイムアウト、TLSエラー、認証失敗のどれかを確認します。多数のノードが同時にタイムアウトする場合は、ローカルネットワーク、サブスクリプションの状態、テスト先に問題がある可能性が高く、1つのノードだけ失敗する場合は、そのノードが到達不能かパラメータが変更された可能性が高いです。

まず、問題がドメイン名だけに影響するのか、IPアドレスにもアクセスできないのかを切り分けます。IPには到達できるのにドメインだけ失敗する場合は、dns.enable、nameserver、fallback、enhanced-mode、リッスンアドレスを確認し、設定内のDNSサーバーに現在のネットワークからアクセスできるか調べます。システムに残った暗号化DNS、ブラウザのセキュアDNS、ほかのローカル名前解決サービスがClashのDNSを迂回したり、ポートを占有したりすることがあります。変更後はシステムのDNSキャッシュを消去して対象アプリを再起動し、ログでリクエストがコアに入っているか確認してください。