高度な使い方 デフォルト設定では足りなくなったとき

設定ファイルを
使いこなす。

初心者向けガイドを終えた方向けに、設定ファイルをさらに深く使いこなすための6つの方向をご紹介します:プロキシグループの自動速度テストとフェイルオーバー、ルールセットのサブスクリプション管理、DNSとドメインスニッフィングの最適化、LAN共有ゲートウェイ、複数サブスクリプションのローカル上書き、外部パネルによる設定管理。各セクションにはそのまま使えるYAMLスニペットを掲載しています。

プロキシグループの高度な使い方

プロキシグループは、ルールがヒットした際に実際にどのノードを使うかを決定します。適切に組み合わせることで、自動速度テスト、フェイルオーバー、負荷分散が実現できます。

種類動作適した用途
select リストから手動でノードを選択し、自動切り替えは行わない 特定のノードを長期的に固定して使いたい場合
url-test 定期的に速度テストを実行し、最も低遅延のノードを自動選択 常に低遅延を維持したいが、手動切り替えは避けたい場合
fallback リスト内の最初の利用可能なノードを使用し、失敗時に自動で次のノードに切り替え メインノードが不安定で、自動フェイルオーバーが必要な場合
load-balance ポリシー(ラウンドロビン / 一致性ハッシュ)に基づいて複数ノードに接続を分散 ノード数が十分にあり、帯域負荷を分散させたい場合
proxy-groups.yaml 
proxy-groups:
  # 自動速度測定、遅延が最も低いノードを選択
  - name: Auto
    type: url-test
    proxies: [HK-01, HK-02, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 300      # 300秒ごとに速度測定
    tolerance: 50      # 遅延差が50ms未満なら切り替えない、揺れを防ぐ
  # メインのグループに異常があれば順番に自動でバックアップへ切り替え
  - name: Fallback
    type: fallback
    proxies: [Auto, HK-01, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 180
  # 最終的にルールへ公開する入口、いつでも手動切り替え可能
  - name: PROXY
    type: select
    proxies: [Auto, Fallback, HK-01, SG-01, DIRECT]

ヒント:ルールでは通常、最も外側のselectグループ(上の例のPROXYなど)だけを参照し、速度テストとフェイルオーバーのロジックはその候補リストにまとめておきます。ルール自体はどのノードを使うか気にする必要がありません。

ルールセットでサブスクリプション管理を行う

Rule Providerは数百から数千件のルールを独立したファイルとしてホストし、定期的に自動更新します。1件ずつ手動でメンテナンスする必要がありません。

behaviorはルールセットに格納されるデータの種類を決定します:domain(ドメインリスト)、ipcidr(IPレンジリスト)、classical(完全なルール構文の行)。 typeはソースを決定します:httpはリモートサブスクリプションでintervalに従って自動更新、fileはローカルファイルで自分でメンテナンスする必要があります。

rule-providers.yaml 
rule-providers:
  reject:
    type: http
    behavior: domain
    url: https://example.com/reject.txt
    path: ./ruleset/reject.yaml
    interval: 86400   # 24時間ごとに自動更新
  direct:
    type: http
    behavior: classical
    url: https://example.com/direct.txt
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  # ルールセットを参照、書き方は RULE-SET,ルールセット名,ポリシー
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ヒント:人気の公開ルールセット(ACL4SSRやblackmatrix7シリーズなど)は、広告ブロック、ローカルネットワーク宛の直接接続、よく使うアプリの振り分けなど、すぐに使えるリストを既に維持しています。特別な要件がない限り、そのまま参照して自作する必要はありません。

DNS設定の最適化

DNS解決方式はルール照合の精度とアクセス速度に直接影響するため、高度な設定の中でも最も時間をかける価値がある項目です。

enhanced-modeにはfake-ipを推奨します。クライアントはまず仮想IPを返し、接続確立時に実際のドメインを復元してルール照合に使用するため、速度と精度を両立できます。fallback-filterを使うと、DNS結果がローカルISPのIP範囲に含まれる場合は採用しないようにでき、DNS汚染やハイジャックの検知・回避に役立ちます。

dns.yaml 
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver: [223.5.5.5, 119.29.29.29]   # DoH/DoTのドメイン自体を解決するための基礎DNS
  nameserver: ['https://doh.pub/dns-query', 'tls://dot.pub:853']
  fallback: ['https://1.1.1.1/dns-query', 'https://dns.google/dns-query']
  fallback-filter:
    geoip: true
    geoip-code: CN   # 指定した地域外のIPの場合のみfallbackの結果を採用(CNは例、自分の地域に置き換えること)

ヒント:fake-ipを有効にした後、一部のLANデバイス(スマートスピーカーやNASの検出など)で問題が発生する場合は、fake-ip-filterに該当ドメインを例外として追加し、常に実際のIPを返すようにできます。

ドメインスニッフィング(Sniffer)を有効にする

TUNモードでは、一部の通信に宛先IPのみが含まれドメイン情報がない場合があります。スニッフィングは通信データから実際のドメインを復元し、ドメインベースのルールを引き続き有効にします。

Snifferは通信内容を復号せずに、TLSハンドシェイク内のSNIやHTTPリクエストヘッダーのHostなどの平文フィールドを読み取ってターゲットドメインを判断し、ルールモジュールに照合させます。TUNモードやドメイン情報が伝わらない一部の転送シナリオでよく使われます。

sniffer.yaml 
sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080]
    QUIC:
      ports: [443]

他のデバイスとLAN共有する

Clashを実行しているデバイスをLAN内のプロキシゲートウェイにすることで、クライアントを個別にインストールしにくいスマートフォン、タブレット、スマートTVなどのデバイスもプロキシを共有できるようにします。

  1. allow-lanを有効にし、リスニングアドレスを0.0.0.0または具体的なLAN IPに変更します。
  2. 他のデバイスのWi-Fi設定で、HTTP / SOCKSプロキシをClashを実行しているデバイスのLAN IPとmixed-portに指定します。
  3. デバイス上のすべての通信(ブラウザだけでなく)をカバーしたい場合は、そのデバイスをルーターとして設定するか、ルーター側でポリシールーティングを設定することを検討してください。
lan.yaml 
mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  # LAN共有時はアカウントとパスワードを設定し、同一ネットワーク内の他デバイスの無断利用を防ぐことを推奨
  - user1:strong-password

ヒント:LAN共有を有効にした後は、システムのファイアウォールが該当ポートへの着信接続を許可しているか確認し、認証用のユーザー名とパスワードを優先的に設定して、公共Wi-Fi環境で不明なデバイスから接続されるのを防いでください。

複数サブスクリプションの統合とローカル上書き

サブスクリプションから取得した設定ファイルを直接変更すると、次回の更新時にプロバイダーから返される新しい内容で上書きされてしまいます。上書き機能を使ってカスタム部分を別途保持する必要があります。

ほとんどのGUIクライアント(Clash Verge、Clash for Windows系列)には「Override(上書き)」または「設定統合」機能が搭載されています:サブスクリプションから生成されたベース設定を読み込んだ後、自分で管理するローカルのYAMLスニペットを重ねて適用します。両者を統合した状態が実際に反映されます。サブスクリプション更新時にはベース部分のみが置き換えられ、上書きスニペットには影響しません。

  1. クライアントのサブスクリプション設定内でOverride(上書き)を見つけ、新しいローカル上書きファイルを作成します。
  2. 上書きファイルには追加・変更したいフィールドのみを記述します。例えば独自のrules、dns、proxy-groupsなどです。
  3. 保存後、クライアントはサブスクリプションを読み込むたびにこの上書きを自動的に重ねて適用するため、サブスクリプションを更新してもカスタム内容が失われることはなくなります。

複数のプロバイダーのサブスクリプションをお持ちの場合は、統合機能を使ってすべてのノードを1つのルールとプロキシグループにまとめ、一括で管理することもできます。

外部制御パネルで設定を管理する

RESTful APIを有効にすると、ブラウザパネル(yacd、metacubexdなど)を使って接続をリアルタイムで確認したり、ノードを切り替えたり、設定をホットリロードしたりできるため、変更ごとにクライアントを再起動する必要がなくなります。

ほとんどのGUIクライアントにはこの種のパネルが標準搭載されています。純粋なコア(Mihomo core)のみで運用している場合は、手動で外部制御を有効にしてオープンソースのパネルプロジェクトと組み合わせて使用できます。

external-controller.yaml 
external-controller: 127.0.0.1:9090
secret: 'replace-with-a-strong-secret'   # パネルアクセスキー、必ず自分で変更してください

ヒント:リスニングアドレスを127.0.0.1に保ち、十分に複雑なsecretを設定してください。このポートをインターネットに公開しないことで、設定への不正アクセスや改ざんを効果的に防げます。

FAQ

高度な設定に関するよくある質問

上書き、DNS、外部パネルに関する頻出質問

ローカル設定を変更しても、サブスクリプション更新で消えてしまうのはなぜ?

サブスクリプションを更新すると、プロバイダーから返された新しい内容で設定ファイル全体が上書きされ、直接変更したフィールドは元に戻ります。クライアントの「Override(上書き)」機能を使ってカスタム部分を別途管理することをおすすめします。サブスクリプション更新時にはプロバイダー部分のみが置き換えられ、上書き部分は自動的に再適用されます。

fake-ipとredir-hostはどちらを選ぶべき?

fake-ipはパフォーマンスが優れており、ルール照合のために実際のターゲットドメインを早く識別できるため、現在の主流のおすすめです。ただし、実際のIPの戻り値に依存する一部のシナリオ(一部のLANデバイス検出プロトコルなど)では、redir-hostや特定ドメインへのfake-ip例外設定が必要になる場合があります。

外部制御パネルを有効にすると安全性に問題はありますか?

リスニングアドレスを127.0.0.1に保ち、十分に複雑なsecretを設定していれば、リスクは非常に低くなります。外部制御ポートを0.0.0.0にバインドしてインターネットや信頼できないLANに公開することはおすすめしません。

まだ基本的な使い方に慣れていませんか?

まずは使い方ガイドをご覧ください:インストール、サブスクリプションのインポート、プロキシモード、メイン画面を詳しく解説しています。

ダウンロードページへ →

Windows / macOS / Android / iOS / Linux 全プラットフォーム対応、すべて無料。