Clash よくある質問とトラブルシューティング

Clashは一般に、ルールベースのプロキシエコシステムと設定形式を指します。mihomoは継続的にメンテナンスされている互換コアで、Clash Plus、Clash Verge Rev、FlClashなどは設定のインポート、ノードの切り替え、ログ表示を担うGUIクライアントです。接続、DNS、ルール判定、TUNトラフィックを実際に処理するのはコアです。トラブルシューティングでは、画面操作、設定内容、コアの起動失敗のどれが原因かをまず切り分けます。

普段はルールモードを優先します。通信は rules を上から順に判定され、DIRECT、PROXY、REJECTのいずれかに振り分けられます。グローバルモードは大半の接続を現在のプロキシグループに渡すため、ノード自体が使えるかを一時的に確認する用途に向いていますが、ルールの代わりに常用するものではありません。直結モードはプロキシを経由せず、問題がクライアント設定に起因するかを素早く判断できます。モードを切り替えた後は、既存接続が再利用されないよう対象アプリを再起動してください。

システムプロキシが制御できるのは、OSのプロキシ設定に従うアプリだけです。ブラウザーや多くのデスクトップアプリはそのまま利用できますが、一部のゲーム、コマンドラインツール、独自のネットワーク処理を行うアプリは迂回することがあります。TUNモードは仮想ネットワークアダプターを通じて、より広範なIP通信を取り込みます。一方で、管理者権限、ルーティングテーブル、DNSハイジャック、他の仮想アダプターとの競合にも関わります。まずシステムプロキシで基本動作を確認し、必要に応じてTUNを有効にすると原因を切り分けやすくなります。

サブスクリプションURLはリモート設定への入口で、クライアントの更新時に内容を再取得します。設定ファイルはローカルに保存され、コアが読み込むYAML文書です。サブスクリプションにはノード、プロキシグループ、ルール、DNSが含まれる場合もあれば、ノードだけを提供してクライアント側でテンプレートを適用する場合もあります。サブスクリプションから生成されたローカルファイルを直接編集しても、次回の更新で上書きされることが一般的です。長期的に保持したいカスタムルールは、クライアントが対応するオーバーライド、マージ、スクリプト機能に追加してください。

遅延テストは通常、ノードを経由してテスト先へ接続する際のハンドシェイク時間だけを測定します。利用可能な帯域、継続的なパケットロス、混雑時間帯の輻輳、対象サイトからノードまでの後半経路までは示しません。低遅延のノードでもスループットが不足することがあり、高遅延のノードのほうが大容量ファイルの転送で安定する場合もあります。ノード選びでは、まず遅延で明らかなタイムアウト候補を除外し、ページ表示、動画のバッファリング、継続的なダウンロード速度も合わせて判断してください。

クライアントの設定またはProfilesページを開き、「URLからインポート」「リモート設定」「サブスクリプションを追加」などの項目を探して、完全なURLを貼り付けてダウンロードします。インポート後は、その設定を選択して現在のアクティブ設定にする必要があります。ダウンロードしただけで切り替えていない場合、コアは古いファイルを使い続けます。初回は更新時刻、プロキシグループ、ノード一覧が表示されるかを確認し、ログで設定の読み込み完了も確認してください。サブスクリプションURLをノード名やローカルファイル選択欄に貼り付けないでください。

まず設定の更新通知とコアのログを確認します。ログインページ、エラーページ、空の内容が返っている場合、クライアントはそれを設定として解析できません。YAMLをダウンロードできてもルール部分しかない場合は、ノードは生成されません。サブスクリプションURLがチャットアプリで途中まで切り取られていないか、末尾のパラメーターや特殊文字が完全に残っているかも確認してください。ブラウザーでURLを開くのはサーバーが応答するかを確認する目的にとどめ、ページ内容を公開しないでください。URLが有効だと確認できたら、失敗した設定を削除して再インポートし、新しい設定に切り替えます。

まずシステムプロキシを無効にし、サブスクリプションURLへ直接アクセスできるか確認します。プロキシ経由でしかアクセスできない場合は、利用可能な古い設定を有効にしてから更新してください。システム時刻、サブスクリプションの有効期限、サーバーの稼働状況も確認します。時刻のずれがHTTPS接続に影響することがあります。クライアントに更新用プロキシを設定している場合は、そのプロキシグループに現在利用できるノードがあるかも確認してください。それでもタイムアウトするなら、URLをコピーして新しいリモート設定を作成し、古い項目のキャッシュ、誤ったリクエストヘッダー、破損したメタデータを切り分けます。

まずログに示された行番号と列番号を確認し、その位置の1行前も調べます。インデントや引用符の誤りは、次の行で初めて報告されることがよくあります。YAMLのインデントにはスペースを使い、タブを混在させないでください。通常、コロンの後にはスペースが必要で、特殊文字を含む名前は正しく引用します。プロキシグループが参照するノード名は、proxies内の名前と完全に一致していなければなりません。変更前に元ファイルを保存し、まずクライアントの設定チェック機能を使ってください。一度に1か所だけ変更すると、複数の構文エラーが重なるのを防げます。

TUNは仮想ネットワークアダプターを作成または制御し、ルーティングとDNSを変更するため、通常は権限の昇格が必要です。クライアントを完全に終了し、管理者として起動してからTUNを再度有効にしてください。設定画面だけを管理者権限で開き、コアを再起動していない場合は不十分なことがあります。クライアントがサービスモードに対応しているなら、設定画面からサービスをインストールして起動します。企業端末ではセキュリティポリシーの制限を受ける場合もあるため、システムイベントとクライアントログを確認し、仮想アダプタードライバーの再インストールを繰り返さないでください。

まずクライアントに表示されるHTTPまたはmixedのリッスンアドレスとポートを確認します。一般的なローカルアドレスは127.0.0.1ですが、ポートは現在の設定に従ってください。環境変数に対応するツールでは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定できます。システムプロキシだけを認識するツールは、システムプロキシを有効にしてからターミナルを再起動します。TUN使用時は、多くのアプリで個別の変数設定は不要です。切り分けでは、ツール固有の詳細ログオプションを実行し、リクエストが環境変数、システムプロキシ、直結のどれを通っているか確認してください。

ルールでは、より具体的なDOMAINまたはDOMAIN-SUFFIXの項目を一般的なルールより前に置き、ポリシー欄を既存のプロキシグループ名に設定します。対象ドメインのルールはGEOIP、GEOSITE、MATCHより前に置かなければなりません。そうしないと、先に広い条件へ一致します。変更後に設定を再読み込みし、接続履歴で一致したルールとポリシーを確認してください。サブスクリプション更新で元ファイルが上書きされる場合は、オーバーライドまたはルールマージ機能でカスタムルールを保存します。

まず接続履歴でアプリがアクセスしているドメインを確認し、Fake-IPに適さないドメインをfake-ip-filterへ追加します。その後、システムDNSキャッシュを消去してアプリを再起動してください。LAN機器の検出、プリンター、一部のログインコンポーネント、実際のDNS応答に依存するアプリは影響を受けやすい傾向があります。最初からFake-IP全体を無効にせず、まずは単一ドメインを除外してください。ドメインマッピングの利点を保ちながら、どの名前解決経路に互換性の問題があるかを確認できます。

クライアントの接続またはConnectionsページを開き、対象のリクエストを再実行して、ドメイン、宛先アドレス、プロセス、一致したルール、最終ポリシーを確認します。プロセス情報がない場合は、ドメインと時刻から範囲を絞り込みます。常にMATCHになる場合、前方のドメイン、IP、ルールセットに一致していない可能性があります。ルールは正しいのに出口が異なる場合は、そのルールが指すプロキシグループで現在選択されているノードを確認してください。既存接続は自動的に再構築されないため、ルール変更後は元の接続を閉じてから再テストします。

クライアントでLAN接続の許可を有効にし、リッスンアドレスが127.0.0.1だけに制限されていないことを確認します。他の機器のプロキシサーバーには、このPCのLAN IPアドレスとクライアントが実際に待ち受けているポートを入力し、localhostは指定しません。その後、Windowsファイアウォールが現在のネットワーク種類でアプリの通信を許可しているか確認します。信頼できるLANでのみ有効にし、ルーター経由で待ち受けポートをインターネットへ直接公開しないでください。テスト終了後はLANアクセスを無効にできます。