Clash 詳細設定ガイド

プロキシグループの種類と設定例

プロキシグループはルールとノードの間に位置します。ルールが接続を渡すグループを決め、グループが使用する出口を選びます。業務ルールからノードを直接指定すれば簡単ですが、ノード名が変わるたびに参照箇所をすべて修正する必要があります。ルールから固定の業務用グループを参照し、そのグループから手動選択または自動選択のグループを参照する構成のほうが管理しやすくなります。実際の用途に合わせてグループを設計し、サイトごとに同じ階層を繰り返し作る必要はありません。

4種類のプロキシグループの使い分け

selectは手動選択用で、出口を固定したい場合や一時的な切り分けに適しています。url-testは接続テストの結果に応じて出口を自動選択し、経路の変化を許容できる一般的な通信に向いています。fallbackは設定順に利用可能な項目を選ぶ方式で、主系・予備系の切り替えが目的です。常に最速のものを選ぶわけではありません。load-balanceは複数の出口に接続を振り分けますが、1つのダウンロード接続の帯域を合算して何倍にもする機能ではありません。

接続テスト先には、安定して応答が軽く、すべての候補ノードからアクセスできるエンドポイントを選びます。テスト先自体が制限されていると、実際の通信に問題がなくてもグループ内の全ノードが異常と表示されることがあります。逆に、テスト先へ接続できても、動画配信の利用条件、業務システムへのログイン、地域制限の要件を満たすとは限りません。トラブル対処では、ヘルスチェックと実際のサービス利用確認を分けて記録してください。

業務用の入口を固定する

以下は、自動選択グループを手動選択グループに入れる例です。include-allは、設定にすでにあるプロキシ候補をまとめて追加します。完全な設定に利用可能なノードが読み込まれていることが前提です。ノードの取得元ではなく、プロキシを自動生成する機能でもありません。コードのテスト先は一般的な接続確認用エンドポイントです。現在のネットワークからアクセスできない場合は、到達可能と確認できた軽量なエンドポイントに変更してください。

proxy-groups:
  - name: 自動選択
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: ネットワーク出口
    type: select
    proxies:
      - 自動選択
      - DIRECT

intervalは秒単位で、テストの間隔を指定します。toleranceは切り替えの許容幅をミリ秒単位で指定し、近い結果の間で頻繁に切り替わるのを抑えます。間隔を短くすればよいとは限りません。バックグラウンドのリクエストが増え、短時間の変動にも反応しやすくなります。ノートPCやモバイル回線では、まず余裕のある間隔に設定し、ログを見ながら調整しましょう。テスト頻度を上げても、接続品質が保証されるわけではありません。

プロキシプロバイダーを使う場合は、定義済みのproxy-providers名をuseで参照すれば、ノード名をグループに1つずつ記述せずに済みます。プロバイダー名とノード名は異なる階層の概念です。前者は取得元を管理し、後者は具体的な接続先を示します。取得元にフィルター式を適用する場合は、元の名称が変わったときや、フィルター結果が空になったときの動作も考慮してください。変更後は設定の読み込み成功だけでなく、候補一覧も確認します。

切り替え時の注意点と復旧方法

自動グループの切り替えは通常、新しく作成される接続に反映されます。確立済みの長時間接続は、すぐに移行しない場合があります。ページを再読み込みしても古い出口が使われる場合は、該当アプリの接続をいったん終了してから再試行してください。プロキシグループが機能していないと即断しないようにしましょう。動画再生、ターミナルセッション、業務システムでは出口の変化に対する許容度が異なります。送信元アドレスの安定性が必要なサービスには、複数地域を自動で切り替えるより、手動固定のグループが適しています。

グループ同士は参照できますが、循環参照はできません。たとえば「ネットワーク出口」が「業務用」を参照し、「業務用」が再び「ネットワーク出口」を参照すると、最終的な出口が決まりません。設計時は参照をたどり、末端が実際のノードやDIRECTなどの組み込みポリシーになることを確認します。グループ名をノード名と重複させるのも避けてください。画面表示とルールの振り分け先を判別しにくくなります。

検証は、まずプロキシ画面で候補が空でないことを確認し、次に利用可能と分かっているノードを手動で固定し、最後に自動選択を有効にする順で行います。固定したノードが使えて自動グループだけ失敗する場合は、テスト先、フィルター条件、参照階層を確認してください。固定ノードも使えない場合は、ノード認証と基礎ネットワークに戻り、グループをさらに増やさないでください。画面の使い方はプロキシ・設定・ログ画面のガイドを参照してください。

DNS設定と名前解決の経路

DNS設定では、アプリの問い合わせを誰が受け付けるのか、上流への問い合わせを誰が行うのか、どのネットワーク経路で送信するのか、という3点を確認する必要があります。上流を暗号化DNSに変更しただけでは、すべてのアプリの問い合わせがコアに入るとは限りません。ブラウザーのセキュアDNS、システムキャッシュ、アプリ内蔵のリゾルバー、LANゲートウェイが別経路を作る場合があります。ClashのDNS漏れを検討する前に、端末の実際の問い合わせ経路を整理してください。

待ち受け、ブートストラップ、通常の名前解決を区別する

listenはコアのDNSサービスが待ち受けるアドレスを定義します。nameserverは通常の問い合わせに使う上流サーバーです。default-nameserverは上流DNSサーバー自身のホスト名を解決するなど、初期接続に必要な問い合わせに使うもので、失敗した問い合わせを何でも自動転送する万能の予備ではありません。ホスト名を使うHTTPSリゾルバーでは、まずそのホスト名を解決する必要があります。「リゾルバーに接続するには、まずリゾルバーのアドレスを解決しなければならない」という循環を避けてください。

以下は、ローカルでの診断に使いやすいDNS設定例で、専用のループバックポートを使います。OSのDNS設定を自動でこのアドレスに変更したり、アプリの通信を横取りしたりするものではありません。まずコマンドで待ち受けポートに明示的な問い合わせを行い、その後TUNやシステム設定と合わせて通信の取り込みを確認します。これにより、「DNSサービス自体の失敗」と「アプリがDNSサービスを経由していない」問題を切り分けられます。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 223.5.5.5

例のアドレスは設定の構造を示すものです。実際に使うサーバーは、利用している通信事業者、地域、アクセス方針に合わせて選んでください。nameserver-policyは特定のドメインに使うリゾルバーを指定します。社内DNSや特定地域の応答が必要なドメインに適しています。業務ドメイン全体を安易にパブリックDNSへ渡すと、内部アドレスが返らない場合があります。対象範囲はできるだけ絞り、まず単一のドメインを確認してからサブドメインへ広げましょう。

DNSの問い合わせと出口ポリシーを連携させる

DNS接続にもルーティングルールを適用する場合は、respect-rulesを検討し、ノードサーバーのホスト名を解決するためのproxy-server-nameserverも適切に設定します。ノードアドレスの解決にプロキシが必要で、プロキシの確立にはノードアドレスが必要という循環が起きる可能性があります。すべてのサブスクリプションに当てはまる共通のスイッチ設定はありません。まだ確立していないプロキシに依存しない初期接続経路を、少なくとも1つ確保することが重要です。

direct-nameserverは、DIRECT出口に関係する名前解決に使えます。ドメイン別ポリシーと併用する場合は、nameserver-policyに従うかどうかも明確にしてください。結果を確認しないまま、複数のnameserver、fallback、ポリシーマッピングを同時に設定するのは避けましょう。複雑な設定では、同じドメインへの問い合わせが複数の経路で発生し、応答元を追跡しにくくなります。

従来のfallbackとfallback-filterは、DNS応答を選択する仕組みです。「最初のDNSがタイムアウトしたら2番目へ問い合わせる」と単純に解釈できるものではありません。フィルター条件、地理情報による判定、候補となる応答が最終結果に影響します。既存環境で明確なドメイン別ポリシーにより要件を満たせるなら、まずは設定をシンプルに保ちましょう。汚染や異常な応答が再現する場合に、検証可能なケースをもとにフィルター条件を設計してください。

応答結果と問い合わせ先を分けて確認する

digがインストールされている環境では、以下のコマンドでローカルのDNS待ち受け先を確認できます。Windows標準のツールは、既定以外のポートへの対応方法が異なる場合があります。システムDNSへの問い合わせ結果を、ローカルのコアへの問い合わせ結果と取り違えないようにしてください。問い合わせ時刻、応答の種類、ログに記録された上流サーバーの選択を残し、アプリの接続状況と照らし合わせると、全体を検証できます。

dig @127.0.0.1 -p 1053 example.com A

Fake-IPモードで仮想アドレスが返るのは想定どおりの動作です。パブリックDNSの結果と異なるという理由だけで、名前解決の誤りと判断しないでください。IPv6についても、コア全体の設定、DNSがAAAAを返すか、システムのIPv6ルート、ノードがIPv6通信に対応するかを区別する必要があります。例では初回の診断項目を減らすためDNSからのIPv6応答を無効にしていますが、すべてのネットワークでIPv6を恒久的に無効化することを勧めるものではありません。

一般的なDNS漏れテストで確認できるのは、あるWebアクセスで使われた名前解決元の一部に限られ、すべてのアプリやプロトコルを網羅できるわけではありません。ブラウザーで独自のセキュアDNSを有効にしている場合は、その設定を個別に確認してください。企業端末では、組織の管理ポリシーが適用されている場合もあります。特定のテストページに合格するためにシステム設定を何度も変えないでください。保護する範囲と問い合わせを取り込む範囲を確認してから、ログ、ルーティング、アプリの動作を照合しましょう。

ドメインスニッフィングの仕組みと限界

ドメインスニッフィングは、接続がコアに入った後、対応するプロトコルの初期データから宛先ホストの情報を取り出します。代表的な情報源はHTTPのHostとTLSハンドシェイクのサーバー名です。宛先IPしか分からない接続に対して、ドメインルールを使えるようにする助けになりますが、DNSの代わりではなく、すべての暗号化通信を識別できるわけでもありません。アプリを完全に識別する機能と考えるより、追加の手がかりとして捉えるのが適切です。

通信が届いてから識別を考える

スニッフィングの対象は、コアがすでに受信した接続だけです。アプリがシステムプロキシを迂回し、TUNにも入っていない場合、スニッフィングを有効にしても通信は取り込まれません。逆に、接続に信頼できるドメイン情報がすでにあれば、追加のスニッフィングが役立つとは限りません。まずクライアントの接続画面に対象の接続が表示されることを確認し、その後ドメイン欄、適用ルール、最終的な出口を調べてください。最初からスニッフィング対象のポートを広げるのは避けましょう。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false
    QUIC:
      ports:
        - 443
      override-destination: false

この例では、スニッフィングを一般的なプロトコルのポートに絞り、元の宛先アドレスを書き換えずに識別の精度を確認します。ポートはプロトコルが使う可能性のある場所であって、通信内容を保証するものではありません。443番ポートでも、別のプロトコルが使われることがあります。すべてのポートをスニッフィング対象にすると、不要な処理が増え、標準外のサービスで起きる互換性問題も見つけにくくなります。実際の用途を確認しながら、段階的に対象を広げてください。

ドメインの識別と宛先の書き換えは別の機能

override-destinationは、スニッフィング結果で接続先を上書きするかどうかを指定します。特定のIPアドレスを必要とするサービスでは、書き換えによって別のサーバーへ接続する可能性があります。CDNを使うサイトでは、再名前解決によって選択されるアドレスが変わることもあります。振り分けの判定を改善したいだけなら、まず宛先アドレスを保持したまま接続ログでルールの動作を確認してください。実際に上書きが必要と分かってから設定すればよく、常に有効にすべき項目ではありません。

parse-pure-ipを有効にすると、宛先がIPアドレスだけの一部の通信もスニッフィング対象にできます。ただし、識別できるかどうかは、プロトコルに読み取れるドメイン情報が含まれているかによります。IPアドレスを直接指定したHTTPリクエストには、想定したドメインが含まれない場合があります。TLSでもサーバー名が取得できるとは限りません。アプリ独自の暗号化プロトコルは、HTTP、TLS、QUICの解析方式に合わない可能性があります。「HTTPSで接続している」という理由だけで識別できると判断しないでください。

スニッフィングを強制する場合や対象外にする場合は、force-domain、skip-domainなどで範囲を明示できます。例外には再現可能なサービスを指定してください。出所不明のドメイン一覧をそのまま設定に貼り付けないようにしましょう。共有IP、リバースプロキシ、社内ゲートウェイがある環境では、識別された名前が接続元のサービスの意図を表すとは限りません。元の宛先も合わせて確認してください。

暗号化プロトコルとプライバシー上の制限

一部のTLS環境では、暗号化クライアントハローなどにより、従来のサーバー名抽出が機能しない場合があります。QUICはUDPを使うため、TCPとは異なる処理が必要で、ノードのUDP対応状況、ルーティング、ネットワークポリシーにも左右されます。ブラウザーではアクセスできるのにクライアントがドメインを識別できない場合でも、設定ミスとは限りません。他の信頼できる情報に基づいてルールが正しく動作していれば、すべての接続にドメイン名を表示させる必要はありません。

スニッフィングはHTTPSの本文を復号する機能ではなく、通常のドメイン識別のために端末へ自己署名のルート証明書をインストールする必要もありません。読み取るのはユーザーのログインパスワードやWebページの内容ではありません。一方で、ドメイン名からアクセス先が推測できる場合があるため、ログのエクスポートやパネルの共有には注意してください。障害情報を共有する際は、個人用ドメイン、サブスクリプション情報、ノードの認証情報を削除し、ルールの問題を再現できる最小限の範囲だけを残します。

検証では、既知のドメインを使ってスニッフィングを無効にした場合と有効にした場合の両方で、新しい接続を作成し、ドメイン欄と適用ルールを比較します。Webページが開くかどうかだけでは判断できません。同じフォールバックポリシーで成功している可能性があります。有効化後に問題が起きた場合は、まず宛先の上書きを無効にし、対象ポートを絞ってください。それでも改善しない場合はスニッフィングを一時的に無効にし、DNSの関連付けとルール設定から基本経路を確認します。

金融サービスへのログイン、企業内ネットワーク、固定アドレスを必要とするサービスでは、識別範囲を広げることより安定性が重要です。明確なIPアドレスまたはドメインのルールを維持し、互換性がないと分かっているサービスには小さな範囲で例外を設定できます。スニッフィング設定の合格基準は「すべての接続に名前が表示されること」ではなく、「対象サービスが想定どおりに振り分けられ、問題が起きないこと」です。画面を整えるために実用性を損なわないようにしましょう。

外部コントローラーパネルとセキュリティ

外部コントローラーパネルは、mihomoのコントローラーAPIを通じて実行状態を取得し、プロキシグループの切り替えや接続一覧の確認を行います。プロキシの接続口でも、サブスクリプションサーバーでもありません。混合ポートはアプリの通信を受け付け、コントロールポートは管理操作を受け付けます。両者は互換性がありません。パネルを開けない場合は、静的ページが読み込めるか、コントローラーAPIに接続できるか、認証に成功するかを分けて確認してください。インターネット接続用の混合ポートをむやみに変更しないでください。

ローカル管理はループバック待ち受けから始める

デスクトップクライアント内蔵の画面を使う場合、通常は追加のコントロールポートを開放する必要はありません。ローカルパネルに接続する必要がある場合は、まずループバックアドレスを使い、LAN内の端末に管理APIを公開しないようにします。以下の認証情報は説明用の例です。実際に使う前に、自分で生成してローカルだけに保管する強固なパスワードに置き換えてください。ほかの端末からアクセスできるサービスに、例の値を使わないでください。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

external-uiは、用意済みのパネル用静的ファイルのディレクトリを指定します。パスはコアの作業ディレクトリを基準に解決され、パネルのファイルを自動生成するものではありません。ディレクトリがあっても入口ファイルがなければ、APIは正常でもページがエラーになる場合があります。パネルのファイルは信頼できるプロジェクトから取得し、説明に従ってローカルに配置してください。出所不明のページに入力したコントローラーの認証情報を、一般的なWebサイトのログイン情報と同じように扱わないでください。

127.0.0.1にバインドすると、そのアドレスを使って本機からのみアクセスできます。すべてのインターフェースで待ち受ける設定にすると、LAN内や到達可能なほかのネットワークからもポートへアクセスできる可能性があります。実際に到達できるかは、ファイアウォールとネットワーク構成によります。allow-lanは主にプロキシの待ち受け範囲に影響し、コントロールポート全体を制御するスイッチではありません。これを無効にしても、コントロールポートの待ち受けやアクセス制限の代わりにはなりません。

接続、認証、ブラウザーの制限を切り分ける

APIへの接続が拒否される場合は、まずコアが実行中か、待ち受けアドレスが正しいか、ポートが使用中でないかを確認してください。接続できても認証エラーになる場合は、ファイアウォールを調整し続けるのではなく、パネルに保存したコントロール用パスワードを確認します。パネルの画面は表示されるのにデータを取得できない場合は、ブラウザーのクロスオリジン制限や、ページとAPIのアドレスの不一致が原因かもしれません。ブラウザーの開発者ツールで該当リクエストの結果を確認してください。

HTTPSのページからHTTPのコントロールAPIへアクセスすると、混在コンテンツ制限を受ける場合があります。同じ端末上の同一オリジンでローカルに配置する方法を優先し、クロスオリジン設定の必要性を減らしてください。リバースプロキシ経由が必須の場合は、TLS、認証、オリジン制限をそれぞれどの層が担うか明確にします。ブラウザーのエラーを消すために任意のオリジンを許可しないでください。また、コントロール用パスワードを公開URLに含めるのも避けましょう。アドレスが履歴、ログ、共有内容に残る可能性があります。

複数端末から管理する必要がある場合は、管理された安全なトンネルを使うか、信頼できる管理ネットワーク内だけで公開し、システムファイアウォールでアクセス可能な端末を絞ってください。コントロールAPIを直接インターネットに公開すると、状態の確認だけでなく、使用中のポリシーや設定にも影響を及ぼす危険があります。パスワードを設定するだけでは、通信の暗号化、総当たり攻撃への対策、パネルの配布元の信頼性まで確保したことにはなりません。

設定変更を一通り検証する

パネルでグループを切り替えたら、クライアント画面と新しい接続の実際の出口が同じように変わったか確認します。パネルから動作モードを変更した場合は、現在のルール検証に影響がないかも確認してください。パネルの表示、設定ファイル、実行中の状態が常に一致するとは限りません。画面上の選択がクライアントに保存される場合もあれば、再読み込み時に上書きされる場合もあります。継続して反映させたい設定は、コントロールAPI上で一時変更するのではなく、管理元が明確な設定層に戻して変更してください。

ログはトラブル対処に必要な最小範囲に保ちます。デバッグ時だけ一時的に詳細度を上げ、再現後は通常のレベルに戻してください。大量のアクセスドメインを長時間記録し続けないようにしましょう。資料を共有する前に、ノード認証情報、サブスクリプションURL、コントロール用パスワード、個人のアクセス履歴が含まれていないか確認します。管理用認証情報を誤って公開した場合は、実際に使用している値を変更し、パネルに保存された古い値も削除してください。スクリーンショットから文字を消すだけでは不十分です。

ガイド全体の最終確認は、設定の読み込み成功、ノードの利用可能性、プロキシグループの参照関係に循環がないこと、ルールの一致結果、DNS経路の明確さ、想定どおりのTUN通信取り込み、スニッフィングによる互換性問題がないこと、必要な範囲だけでコントロールAPIにアクセスできること、の順に進めます。変更は一度に1項目に絞り、いつでも戻せる状態を残すほうが、設定を次々に追加するより管理しやすくなります。原因を特定できない場合は、個人情報を伏せたログを添えてトラブル対処カテゴリで症状ごとに確認してください。