Clash 高度設定ガイド

Chapter 02 / Policy

プロキシグループの種類と組み合わせ方

プロキシグループはノードとルールの間に位置します。ルールは通常、特定のノードへ直接紐付けず、安定したプロキシ名へリクエストを送り、プロキシグループが出口を決定します。これによりノードが変わってもルールを変更せずに済み、手動選択、自動速度テスト、フェイルオーバー、負荷分散を別々の層に分けられます。プロキシグループを設計するうえで重要なのは、名前を明確にし、階層を増やしすぎず、用途を一つに絞ることです。一つのグループに地域選択、サービス分類、自動切り替えを同時に担わせると、短期的には便利でも、後から最終的にどの経路が選ばれたか分かりにくくなります。

select、url-test、fallback、load-balance

select は手動選択グループで、共通の入口や人が固定したい出口に適しています。ノードの品質を自動判定しないため、現在のノードが停止しても選択状態が維持される場合があります。url-test は指定URLへ接続テストを行い、結果のよいノードを選ぶため、日常の自動選択に適しています。fallback はリストの前から利用可能なノードを優先するため、出口の安定性を重視し、主系と待機系を明確にしたい場合に向いています。load-balance は複数ノードへ接続を分散します。出口の変化を許容できる並列リクエストには適していますが、ログインセッション、リスク管理の厳しいサービス、送信元アドレスの固定が必要なサービスには通常向きません。

proxy-groups:
  - name: 総合選択
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: フェイルオーバー
    type: fallback
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    lazy: true

interval は検出間隔です。短すぎるとノードや端末の復帰処理が増え、モバイル端末ではバックグラウンド消費電力も増える可能性があります。長すぎると障害の発見が遅れます。tolerance は近い結果間で頻繁に切り替わるのを抑える値であり、速度を上乗せするものではなく安定性のしきい値です。lazy: true は実際に使うまでグループの検査を行わない設定で、アイドル時の負荷を抑えるのに適しています。テストURLには軽量で安定した応答を返すものを使い、ファイルのダウンロードURLをヘルスチェックに使わないでください。一度のテスト結果だけで長期的な安定性を判断することも避けます。

プロキシグループはサービスの意味に沿って命名する

まず「総合選択」を共通の出口として残し、用途ごとに「ストリーミング」「開発サービス」「メッセージング」などのグループを作ることをおすすめします。サービス用グループ内では「総合選択」、地域グループ、または DIRECT を参照し、ルールからはサービス用グループだけを参照します。こうするとノードの供給元を変更するときも、下位グループだけを調整でき、ルール層を安定させられます。グループ名に日本語を使うことはできますが、名前を変更した場合は rules、rule-providers の動作フィールド、他のプロキシグループからの参照も確認してください。大文字・小文字やスペースも識別子の一部であり、スペース1つの違いでも別名になります。

  - name: 開発サービス
    type: select
    proxies:
      - 総合選択
      - 自動選択
      - DIRECT

  - name: ストリーミング
    type: select
    proxies:
      - 総合選択
      - 自動選択

rules:
  - DOMAIN-SUFFIX,github.com,開発サービス
  - DOMAIN-SUFFIX,githubusercontent.com,開発サービス
  - MATCH,総合選択

ノードが多い場合、すべての名前を proxies に一つずつ書く必要はありません。プロキシプロバイダーの use で取り込み、フィルター式で範囲を絞れます。フィルターの精度は購読内のノード名に左右されるため、複数の供給元で命名規則が異なる場合、地域キーワードだけでは誤選択しやすくなります。まずクライアントで実際のノード名を確認してから条件を作成し、購読更新後も新しい命名が現れていないか確認してください。テスト用ノード、期限切れ表示のノード、倍率表記を除外するときは、式を広げすぎて正常なノードまで消さないようにします。

プロキシグループのトラブルシューティングは、参照関係から始めます。まずルールがマッチしたグループ名を確認し、そのグループで現在選択されている項目を開き、実際のノードまで追跡します。自動グループが切り替わらないように見える場合は、テストURLへ到達できるか、検出間隔がまだ有効か、クライアントがバックグラウンド動作を停止していないかを確認します。特定のサービスが頻繁に再ログインするなら、負荷分散グループから固定出口グループへ移してテストしてください。プロキシ層の目的は自動化を重ねることではなく、選択結果をログとグループ構成から説明できるようにすることです。

Chapter 04 / DNS

DNS設定の最適化と漏洩チェック

DNSはドメインをアドレスへ変換する方法を決め、ドメインルールが正確にマッチできるかにも直接影響します。ClashのDNSモジュールを有効にすると、アプリの問い合わせはまずローカルの待受へ入り、カーネルが設定に応じて上流のリゾルバーを選択します。確認すべき点は、問い合わせが本当にClashへ入っているか、各ドメインをどの上流へ渡すか、解決結果と後続接続が対応しているかの3つです。公開DNSを大量に並べても安定性が自動的に上がるわけではなく、結果の出所と障害範囲が分かりにくくなることがあります。

nameserver、default-nameserver、proxy-server-nameserver

nameserver は主要な上流リゾルバーです。default-nameserver はDoHやプロキシサーバー自身のドメインを解決するために使うので、通常は直接アクセスできるIP形式のリゾルバーを指定し、リゾルバーへ接続するために再びドメイン解決が必要になる事態を避けます。proxy-server-nameserver はプロキシノードのドメイン専用に使え、ノードアドレスの解決がサービス用DNSルールの影響を受けるのを防ぎます。購読ノードがドメインを使っていて、この層の解決に失敗すると、画面上では全ノードが同時に利用不可に見えることがありますが、原因はノードのプロトコルではありません。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true

  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"

respect-rules を有効にすると、DNSリクエストがプロキシルールを参照します。ただし、プロキシの解決経路がすでに動作していないと、プロキシと解決のどちらを先に用意するかという循環依存が生じる可能性があります。初期設定で上流へ到達できない場合は、まずこの項目を無効にして基本解決を確認し、その後段階的に有効化します。listen はクライアントのDNS取り込み方式と組み合わせる必要があります。デスクトップでTUNが取り込む場合、通常はLAN機器からそのポートへアクセスできるようにする必要はありません。外部向けに待ち受ける場合は、ファイアウォールとLANからのアクセス範囲も確認してください。

リゾルバー数とfallbackの動作

主要なリゾルバーは、安定したものを2〜3個選べば通常は十分です。リゾルバーごとの応答は、ネットワーク位置、CDNの振り分け、キャッシュの影響を受けるため、数を増やせば正確になるわけではありません。fallback を使う場合はフィルター条件も理解してください。条件によってはすべての問い合わせが複数経路へ送られ、待ち時間と通信量が増えます。ルールが明確な設定では、nameserver-policy でドメインごとにリゾルバーを指定するほうが、広範なフォールバック判定に頼るより説明しやすくなります。

  nameserver-policy:
    "geosite:private":
      - system
    "+.corp.example":
      - 10.0.0.53
    "geosite:cn":
      - https://dns.alidns.com/dns-query

ポリシー内のドメインマッチは、実際のルールセットの能力に合わせる必要があります。社内ドメインを内部DNSだけで解決できる場合、内部リゾルバーへの経路が直接接続であるか、社内ネットワークへ到達できることを確認してください。内部リゾルバーを共通のnameserverに入れると、社内ネットワークの外へ出た後も問い合わせがタイムアウトし続けます。特定のサフィックスにだけ使うほうが適切です。システムで他のVPN、ネットワークフィルター、セキュリティソフトを同時に動かしている場合は、Clashより先にDNSを書き換えていないかも確認します。

DNS漏洩はまず確認範囲を定義する

DNS漏洩とは一般に、指定した経路で処理されるはずの問い合わせが、システムやアプリから別のリゾルバーへ直接送信されることです。確認時は、1つのWebサイトが示すリゾルバー名だけで判断せず、システムのネットワーク設定、Clashのログ、パケットキャプチャを組み合わせます。ブラウザーが独自のセキュアDNSを使うこともあり、モバイルアプリがDoHを内蔵していることもあります。このようなリクエストは通常のHTTPS通信に見えるため、システムの53番ポートを通るとは限りません。すべてをClashへ統一したい場合は、アプリ内の独自解決を無効にするか、DoHのドメインをルールで明示的に処理します。

DNSを変更したら設定を再読み込みし、ログでDNSモジュールが正常に待ち受けていることを確認してから、通常のドメイン、社内ドメイン、ノードのドメインを個別にテストします。Webページが開かないからといって、すぐにすべてのキャッシュを消去しないでください。システム、ブラウザー、Fake-IPのマッピングが同時に変わり、変更前後を比較しにくくなります。クライアントは接続済みなのにインターネットへまったく接続できない場合は、接続済みなのにネットワークへつながらない場合のチェックリストに沿って、ノード、購読、DNS、システムプロキシ、TUNを順に確認します。

Chapter 06 / Sniffer

ドメインスニッフィングとルール復元

Clashに入る接続の中には、対象IPだけを持ち、ドメインルールに直接使えるホスト名を含まないものがあります。ドメインスニッフィングは接続初期に識別できる情報、たとえばTLS ClientHelloのSNIやHTTPリクエストのHostを確認し、取得したドメインをルールマッチに使います。完全な通信内容を読み取る機能ではなく、すべての接続でドメインを復元できるわけでもありません。暗号化されたクライアントハンドシェイク、非標準プロトコル、IPへ直接接続するリクエスト、一部のUDP通信には、スニッフィングに適したフィールドがない場合があります。

基本設定とプロトコルの範囲

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false

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

  skip-domain:
    - "+.push.apple.com"
    - "Mijia Cloud"

parse-pure-ip は、IPだけで表示される対象に対してプロトコルの特徴を解析することを許可します。force-dns-mapping はFake-IPマッピングと連携し、接続とDNS問い合わせの関係を復元しやすくします。override-destination は、スニッフィングで得たドメインで対象を書き換えるかどうかを決めます。全体で書き換えを有効にするとドメインルールのマッチ率が上がる可能性がありますが、元のアドレスに依存する接続で互換性問題が起きることもあります。より安全なのは、全体では無効にし、適していることを確認したHTTPなどのプロトコル範囲だけで有効にする方法です。

ポート範囲を無制限に広げないでください。HTTPスニッフィングは明確なWebポート、TLSは主に443とサービスで使う暗号化ポート、QUICは主にUDP 443を対象にします。すべてのポートをすべてのプロトコル解析器へ渡すと、無効な判定が増え、非標準のバイナリプロトコルを誤認識する可能性もあります。特殊ポートを使うサービスでは、まずログでプロトコルとポートを確認してから範囲を追加します。ポート範囲を広げても、実際に得られる情報が増えるわけではなく、解析の試行範囲だけが広がります。

スニッフィングとFake-IPの関係

Fake-IPは、DNS経由で開始される多くの接続にドメインを保持できます。スニッフィングは補助的な経路で、アプリがシステムDNSを回避したり、キャッシュされたIPへ直接接続したり、接続情報とマッピングを関連付けられなかったりする場合に、ドメインを再取得できる可能性があります。両方を有効にしても同じ処理を重複して行うわけではありません。Fake-IPは解析段階でマッピングを作り、スニッフィングは接続段階でプロトコルのメタデータを観察します。ルールマッチを調べるときは、ログで最終的に使われたのがマッピングドメイン、スニッフィングされたドメイン、元のIPのどれかを確認してください。

スニッフィングを無効にすると特定のサービスが常に MATCH に入り、有効にするとドメインルールへマッチする場合、元の接続に利用可能なドメイン情報がなかったことを示します。逆に、有効化後に誤ったポリシーへ送られる場合は、取得したドメインが共有CDN、リダイレクト先、サードパーティAPIのものではないか確認します。1つのアプリが複数のドメインへ同時にアクセスすることは多く、メインサイトのドメインだけで全接続を判断できません。ログレベルを一時的に上げて短時間テストを行い、完了後は info に戻してください。

スキップリストと互換性の境界

skip-domain は、既知の非対応ドメインを改変や解析から除外するために使います。項目は実際の障害検証に基づいて追加し、一度に広範なリストを登録しないでください。一部のデバイス探索やプッシュ通知サービスは、証明書のドメイン、接続先アドレス、サービス識別子が完全には一致しない仕組みを使います。誤った書き換えは接続の重複を引き起こす可能性があります。スキップ項目を追加したら、古い接続には新しいルールが自動適用されないため、対象アプリを再接続してください。

スニッフィング設定を検証するときは、ルールが明確なドメインを1つ選び、まず無効時のマッチ結果を記録してから、有効化後に接続を再確立して比較します。DNS、ルールセット、対象ポリシーを同時に変更しないでください。どの層の変化か判断できなくなります。システムプロキシモードでブラウザーだけをテストする場合、ブラウザーは通常すでにドメインをプロキシへ渡しているため、スニッフィングによる差は小さいことがあります。TUNでの取り込み、IPのみの接続、システムDNSを回避する場面で特に有効です。

ドメインスニッフィングはルール設計の代わりにはなりません。ドメインを復元できても、広範なルールより前に具体的なルールを置き、対応するプロキシグループが存在することを確認する必要があります。アプリが動的なサブドメインへ大量にアクセスする場合は、確認済みのサフィックスルールやルールセットを優先し、完全なドメインを追加し続けないでください。関連用語は用語ガイドで確認できます。SNI、Fake-IP、TUN、ルールモードの関係も解説しています。

Chapter 08 / Controller

外部コントロールパネルと運用保守

mihomoは外部コントロールインターフェースを提供し、クライアント画面やブラウザーのコントロールパネルからプロキシグループの確認、ノード切り替え、接続の表示、providerの更新、ログの確認を行えます。コントロールインターフェースは稼働中のカーネルを管理するもので、設定ファイルの代わりにはなりません。パネルで一時的にポリシーを切り替えるとすぐ反映されますが、ルールの追加、DNSの調整、TUNパラメーターの変更には設定の変更と再読み込みが必要です。コントロールインターフェースは設定エディターではなく、実行状態への入口と考えるのが適切です。

待受アドレス、シークレット、アクセス範囲

external-controller: 127.0.0.1:9090
secret: "your-password"

external-ui: ./ui
external-ui-name: dashboard

ローカルだけで使う場合、コントロールアドレスは 127.0.0.1 で待ち受けさせます。0.0.0.0 にすると他のネットワークインターフェースからの接続も受け付けるため、LANからの管理が明確に必要で、ファイアウォールを設定している場合だけ使用してください。secret はインターフェースの認証に使います。自分で生成した独立した値を使い、購読アクセス用のパラメーターや他のアカウントと共有しないでください。パネルページとコントロールインターフェースを別の場所に配置することはできますが、ブラウザーがインターフェースのアドレスへアクセスでき、プロトコル、セキュアコンテキスト、CORSの条件を満たす必要があります。

リモート管理でコントロールポートを公共ネットワークへ直接公開しないでください。信頼できるLANからアクセスするか、管理された安全なトンネルを経由して端末のネットワークへ入る方法がより安全です。家庭のルーター上で動くClashの状態を見るだけなら、送信元アドレスを制限し、ファイアウォールルールを維持してください。コントロールインターフェースでは出口の切り替え、接続の終了、実行情報の取得ができるため、アクセス範囲はルーター管理画面と同じ慎重さで管理します。

接続ページとログを組み合わせる方法

接続一覧には通常、送信元、宛先、プロトコル、ルール、ポリシーチェーン、通信状態が表示されます。特定のアプリを調べるときは、まず表示範囲をクリアするか宛先で絞り込み、その後にリクエストを1回再現します。ポリシーチェーンからは、リクエストが最初に入ったサービス用グループと、最終的に到達したノードが分かります。ルール欄からは、どのルールがマッチしたかを確認できます。ページが開かないのに接続一覧へ記録がまったくない場合、問題はカーネルへ入る前に発生している可能性が高いため、システムプロキシ、TUNルート、アプリ自身のプロキシ設定を確認します。

日常利用ではログレベルを info に保ちます。DNS、ハンドシェイク、スニッフィングの詳細を特定するときだけ、短時間 debug へ切り替え、1回再現したらすぐ戻してください。詳細ログを長時間有効にすると出力量が増え、本当のエラーが大量の正常記録に埋もれます。ログを共有する前に、購読URL、社内ドメイン、宛先アドレス、認証フィールドを確認し、障害発生時刻に関係する部分だけを抜き出してください。

providerの更新とポリシー状態

コントロールパネルでは通常、プロキシプロバイダーとルールプロバイダーを手動更新できます。更新ボタンは対象リソースの更新を開始するだけで、設定全体の再読み込みを意味しません。プロキシproviderを更新すると、新しいノードはそれを参照するプロキシグループへ入りますが、現在の接続がすべて自動移行するわけではありません。ルールproviderを更新すると、新しいリクエストは新ルールでマッチしますが、既存の長時間接続は元のポリシーを維持する場合があります。更新結果を確認するときは、テスト接続を再確立し、ボタンの回転が完了したかだけでなくproviderの最終エラー状態も確認してください。

選択したポリシーの保存は、profile.store-selected とクライアントのデータディレクトリへの書き込み権限に依存します。再起動するたびにデフォルトノードへ戻る場合は、まず最終設定にこの項目が存在するか確認し、次にクライアントが実行ディレクトリへ書き込めるか確認します。複数の設定で同じグループ名を使っていると、保存状態によって切り替え後の結果がデフォルト設定と異なって見えることもあります。テストでは、名前の分かりやすい新しいグループを作り、保存機能が正常に動くことを確認してから古い状態を処理してください。

再現可能な保守手順

日常の保守は4段階に固定できます。まず購読とproviderを更新し、すべてのリソースの読み込み完了を確認します。次に「総合選択」と主要サービス用グループに利用可能なメンバーが残っているか確認します。その後、1つのドメインリクエストとTUNが必要なアプリ1つを使ってルールチェーンを確認し、最後に通常のログレベルへ戻して現在利用できる設定をエクスポートします。更新後に異常が出たら、まず変更範囲を比較します。ノードだけが変わったならproviderとプロキシグループを確認し、ルールセットだけが変わったならマッチ順を確認します。クライアントの更新やシステムネットワークの変更後は、権限とルートを重点的に確認してください。

コントロールパネルへ接続できない場合は、まずカーネルが動作していることを確認し、次にコントロールアドレス、ポートの使用状況、シークレットを確認します。ブラウザーでローカルのパネルを開きながら、リモート端末のインターフェースへ接続する場合は、アドレスがブラウザーを実行している端末の 127.0.0.1 になっていないかも確認してください。クライアントにコントロールページが内蔵されている場合は、まず内蔵入口を使います。通常は現在のポートと認証情報が自動処理されます。クライアントを選び直す場合は、比較ガイドでプラットフォームごとの差異を確認し、インストーラーはダウンロードページから入手してください。