設定上級 読了目安 12分

Clash設定ファイルの構造を徹底解説：ポート・DNS・ルールを順に確認

YAMLの階層に沿って主要項目を解説し、プロキシノード・プロキシグループ・ルールの参照関係を整理します。

まずClash設定の処理フローを理解する

Clash、Clash Meta（現在はMihomoと呼ばれることが多い）および各種GUIクライアントでは、通常YAMLファイルで動作パラメータを記述します。設定は一見、独立した項目の集合に見えますが、実際の処理は一続きのフローです。アプリの通信がローカルの待ち受けポートまたはTUNインターフェースに入り、ドメイン要求がDNSモジュールで処理され、その後の接続がrulesに従って上から順に照合されます。ルールに一致すると、接続はプロキシグループへ渡され、そこから具体的なプロキシノード、直接接続、拒否のいずれかが選択されます。

そのため、設定を読むときは特定のノードに接続できるかだけを確認してはいけません。少なくとも、通信はどこから入るのか、ドメインはどう解決されるのか、利用できる出口は何か、出口はどのようにプロキシグループへまとめられているのか、接続を最終的にどのルールが振り分けるのか、という5点を確認する必要があります。名前の参照ミスが一つあるだけでも、設定の読み込み失敗、プロキシグループが空になる、ドメインを解決できない、通信が誤った出口へ流れるといった症状につながります。

YAMLはインデントに依存します。通常は半角スペース2つで1階層を表し、タブで代用することはできません。同じ階層のキーは揃えて記述し、リスト項目はハイフンで始めます。真偽値にはtrueとfalseを使うのが無難です。コロン、シャープ、アスタリスクなどの特殊記号を含む名前は、パーサーにYAML構文として解釈されないよう引用符で囲みます。

基本項目とローカルの待ち受けポート

設定ファイルのトップレベルには通常、ポート、LANアクセス、動作モード、ログレベルを記述します。これらの項目はClashがローカルまたはLAN上のデバイスからの接続を受け付ける方法を決めますが、接続先のプロキシノードを直接決めるものではありません。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

port、socks-port、mixed-port

portはHTTPプロキシの待ち受けポート、socks-portはSOCKS5プロキシの待ち受けポートを提供します。mixed-portでは、1つのポートでHTTPとSOCKS5の両方を受け付けられます。デスクトップクライアントでは、システムプロキシの設定を簡単にするため混合ポートがよく使われます。複数のポートを同時に指定する場合は、ポート番号が他のプログラムと競合していないか、システムプロキシが実際にどのポートを指しているかを確認してください。

redir-portとtproxy-portは主に透過プロキシで使われ、OSのネットワークスタック、ルーティングルール、権限設定に依存します。すべてのプラットフォームが同じ方法で対応しているわけではありません。一般的なデスクトップ環境でシステムプロキシやクライアントのTUN機能を使って通信を取り込む場合、通常はこの2項目を手動で追加する必要はありません。

LANアクセスとコントロールインターフェース

allow-lanは、他のデバイスがこの端末の待ち受けポートを通じてプロキシを利用できるかどうかを制御します。有効にした後は、bind-address、OSのファイアウォール、デバイス間のネットワーク接続も確認してください。この端末だけで使う場合は無効のままで構いません。同じLAN上のスマートフォンやタブレットにプロキシを提供する場合は、信頼できるネットワークの範囲に制限し、待ち受けポートをインターネットへ公開しないようにします。

external-controllerはコントロールインターフェースのアドレスです。GUIや外部パネルは、ここを通じて接続、通信量、プロキシグループの状態を読み取れます。127.0.0.1で待ち受ける場合はローカル端末からのみアクセスできます。LANアドレスへ変更する場合は、十分に強力なsecretを設定し、ネットワークへのアクセス範囲も制限してください。コントロールインターフェースのポートとプロキシポートは用途が異なるため、システムプロキシをコントロールインターフェースへ向けてはいけません。

動作モードとログ

mode: ruleはルールに従って通信を振り分けるモードで、日常的な設定では最もよく使われます。globalモードではすべての接続をグローバルプロキシグループへ渡し、directモードでは接続を直接行います。GUIクライアントの「ルール」「グローバル」「直接接続」の切り替えは、通常現在の動作モードを変更しますが、元のYAMLファイルまで書き換えるとは限りません。

log-levelには、silent、error、warning、info、debugなどを指定できます。利用できる値は使用中のコアのバージョンに従います。ルールの一致やDNS要求を調べるときは一時的にログの詳細度を上げ、確認後は通常のレベルへ戻すと、大量のログで確認しづらくなるのを防げます。

DNSセクション：名前解決の経路とFake IP

dnsセクションは、Clashがドメイン名の解決を引き受けるか、どの上位DNSサーバーへ問い合わせるか、実アドレスとFake IPのどちらを返すかを決めます。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
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

enable、listen、上位DNSサーバー

enable: trueでコアのDNSモジュールを有効にします。listenはDNSサービスの待ち受けアドレスを指定します。入力が必要かどうかは、クライアントが問い合わせをどのように取り込むかによって異なり、GUIクライアントがこの項目を生成または上書きする場合もあります。ローカル以外のアドレスで待ち受ける前に、LANへDNSを公開することでアクセス範囲がどう変わるかを理解しておきましょう。

default-nameserverは主にDoHやDoTなど、暗号化DNSサーバー自身のドメイン名を解決するために使われます。プロキシノードのドメイン名を初回に解決する場合にも使われるため、ここには直接アクセスできるIPアドレス型のDNSを指定するのが一般的です。nameserverは通常の問い合わせに使う主要な上位DNSで、一般的なDNSアドレスやコアが対応する暗号化DNS形式を利用できます。拡張パラメータやプロトコル表記への対応はMihomoのバージョンによって異なる場合があるため、設定を移行するときはコアのドキュメントと起動ログを確認してください。

nameserver-policyでは、ドメインやルールセットごとに上位DNSを指定できます。たとえば特定のドメインだけを指定したDNSサービスで解決させることが可能です。これは「どのDNSへ問い合わせるか」を決めるものであり、プロキシルールにおける「どの出口から接続するか」とは別の概念です。DNSの問い合わせ経路と、その後の接続経路は分けて設定してください。

fake-ipとredir-host

Fake IPモードでは、まず予約アドレス範囲の一時的なアドレスをアプリへ返し、アプリが接続を開始した時点でそのアドレスを元のドメイン名へ対応付けます。これにより、コアがドメイン情報を安定して保持しやすくなり、DOMAIN、DOMAIN-SUFFIX、GeoSiteなどのドメインルールを適用できます。TUN環境では、アプリごとに異なるDNSと接続を一元的に取り込むためにもFake IPがよく使われます。

一部のLANサービス、ゲームプラットフォーム、プリンター、実際のDNS結果を必要とするアプリはFake IPに適さない場合があります。そのようなドメインはfake-ip-filterに追加し、実際の名前解決結果を返すようにします。ただし、除外範囲をむやみに広げると、多くのドメインがFake IPの対応付けを回避し、ドメインルールの追跡性が下がります。redir-hostモードは実IPを返すため互換性を把握しやすい一方、ルールの一致結果はDNSキャッシュ、接続方式、アプリの挙動に左右されます。

プロキシノードとプロキシプロバイダー

proxiesは静的なノード一覧で、各項目にはプロキシグループから参照できる出口を記述します。一般的な項目は、ノード名、プロトコル種別、サーバーアドレス、サーバーポート、認証などのプロトコル固有パラメータです。プロトコルごとに必要な項目は異なるため、typeを書き換えるだけで別の種類のノードへ変換することはできません。

proxies:
  - name: "サンプルノード A"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "example-user"
    password: "example-password"
    udp: true

nameは設定内部でノードを参照するための識別名です。プロキシグループに記述する名前は、スペース、大文字・小文字、記号を含め、ここにある名前と完全に一致させる必要があります。ノード名が重複すると、コアやクライアントによっては読み込みを拒否されたり、参照先の判別が難しくなったりするため、常に一意の名前を付けてください。

サブスクリプションには通常、多数のノードが含まれるため、proxiesへ直接展開すると管理しにくくなります。Mihomoではproxy-providersを使ってプロキシプロバイダーを定義し、プロバイダーにローカルファイルまたはリモートコンテンツを読み込ませ、そのノード一覧をプロキシグループへ渡せます。プロバイダーには通常、type、url、path、更新間隔、ヘルスチェックなどを指定します。サブスクリプションURLはアクセス用の認証情報にあたるため、公開リポジトリ、スクリーンショット、公開ログに載せないでください。

proxy-providers:
  provider-main:
    type: http
    url: "サブスクリプションサービスが提供する完全なURL"
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

プロバイダーのヘルスチェックは、ノードの接続性を定期的にテストする機能であり、プロキシグループが自動的に最低遅延のノードを選ぶことを意味しません。自動選択の方式はプロキシグループの種類によって決まります。ヘルスチェックのURLも対象先への応答だけを示すもので、遅延値は対象サーバー、DNS、ネットワークの混雑、ノードの出口位置などの影響を受けます。

プロキシグループ：参照可能な出口へノードを整理する

proxy-groupsはノードとルールの間に位置します。ルールから変動しやすい個別ノードを直接指定するのではなく、安定したプロキシグループ名を参照するのが一般的です。ノードが更新されたり使えなくなったりしても、クライアント上でグループ内の選択肢を切り替えるだけで済み、ルール全体を書き直す必要がありません。

proxy-groups:
  - name: "ノード選択"
    type: select
    use:
      - provider-main
    proxies:
      - DIRECT

  - name: "自動速度テスト"
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: "デフォルト出口"
    type: select
    proxies:
      - "ノード選択"
      - "自動速度テスト"
      - DIRECT

よく使われるプロキシグループの種類

  • select：ユーザーがグループ内のノード、別のプロキシグループ、組み込みアクションを手動で選択します。メインの入口や固定出口が必要なサービスに適しています。
  • url-test：指定したテスト先を定期的に測定し、条件に合う低遅延ノードを自動選択します。測定結果を基準にするもので、すべての通信が同じ速度になることを示すものではありません。
  • fallback：一覧の先頭にある利用可能なノードを優先し、現在のノードが使えなくなると後続のノードへ切り替えます。固定した優先順位を重視する場合に適しています。
  • load-balance：コアが対応する方式に従い、複数のノードへ接続を分散します。1つのTCP接続の帯域を単純に合算する機能ではなく、出口が頻繁に変わると、セッションやアドレスの一貫性を必要とするサービスに影響する場合があります。

proxiesには静的ノード、別のプロキシグループ、DIRECTやREJECTなどの組み込みアクションを指定します。useはproxy-providersを参照するために使います。両者は同じプロキシグループ内で必要に応じて組み合わせられます。プロキシグループが別のプロキシグループを参照することもできますが、AがBを参照し、BがAを参照するような循環参照は避けてください。設定の検証に失敗する原因になります。

グループ名も厳密な参照対象です。ルールにデフォルト出口と記述した場合、設定内に完全に同じ名前のプロキシグループ、ノード、または組み込みポリシーが存在しなければなりません。プロキシグループ名を変更したら、rules、他のプロキシグループ、オーバーライドスクリプト内の参照も検索して合わせて修正します。

ルールセクション：順番に照合して最終出口を決める

rulesは接続を振り分ける判断表です。コアは通常、先頭から順に確認し、一致すると後続の照合を停止して、ルール末尾に指定されたポリシーへ接続を渡します。そのため、ルールは数より順番が重要です。範囲が狭く優先度の高いルールを前に置き、汎用ルールやフォールバックルールを後ろに配置します。

rules:
  - DOMAIN,example.org,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,service,デフォルト出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,デフォルト出口

よく使われるルールの種類

DOMAINは完全なドメイン名に完全一致します。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン内のキーワードで照合するため範囲が広く、意図しない一致に注意が必要です。IP-CIDRとIP-CIDR6は宛先IPのネットワーク範囲で照合し、LAN、固定サービスアドレス、明確なネットワーク範囲に適しています。

GEOIPはIP地理データベースを使って宛先アドレスを照合します。MihomoではGeoSiteやルールセットを使って大量のドメインを処理することもできますが、利用できるルール種別とデータベース形式はコアのバージョンや設定方法によって異なります。地理ルールはローカルデータベースに依存するため、データベースの欠落、パスの誤り、形式の非互換があると、読み込み時または実行ログに通知が表示されます。

no-resolveはIP系ルールでよく使われ、ルール照合時にドメインのための追加DNS解決を行わないことを示します。不要な名前解決を減らせますが、現在の接続がドメイン名だけで、照合に使える宛先IPを持たない場合は、このIPルールに一致しない可能性があります。追加するかどうかはDNSモードとルールの目的に応じて判断してください。

MATCHは最後のフォールバック項目で、ルール一覧の末尾に置きます。それまでのルールに一致しなかった接続を処理する役割です。適切なフォールバックがないと、コアのバージョンやクライアントの生成処理によって予期しない結果になる場合があります。手書きの設定ではMATCHを明示すると、デフォルトの出口が分かりやすくなります。

ルールプロバイダーと大規模なルールセット

ルールが多い場合は、rule-providersを使ってルールセットを独立したファイルに分け、RULE-SETで参照できます。ルールプロバイダーには通常、動作種別、取得元、保存パス、更新間隔、形式を指定します。参照名はプロバイダーのキー名と一致させ、ルールセットの内容形式もbehaviorに合わせる必要があります。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: "ルールの管理元が提供する完全なURL"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,デフォルト出口

ルールセットの更新に成功しても、順番が適切とは限りません。RULE-SETより前に範囲の広いルールを置いていると、接続が先に一致し、後続のルールセットが適用されない場合があります。切り分けでは、ルールファイルがダウンロード済みかだけでなく、接続詳細に表示されるルール種別、一致内容、最終ポリシーを確認してください。

TUNモードと通信の入口の関係

システムプロキシの影響を受けるのは、OSのプロキシ設定に従うプログラムだけです。ターミナルツール、ゲーム、仮想マシン、独自のネットワークスタックを実装したアプリは、システムプロキシを無視することがあります。TUNモードでは仮想ネットワークインターフェースを通じて、より広範なIP通信を取り込み、ClashのDNS、ルール、ポリシーの処理フローへ渡します。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-routeはコアによるルートの自動設定を試み、auto-detect-interfaceはデフォルトの外向きインターフェースを検出します。dns-hijackは指定したDNS通信をコアへ渡します。stackの選択肢とデフォルト動作はコアやプラットフォームによって変わり、一般的な実装にはsystem、gVisor、mixedがあります。GUIクライアントは通常、OSに合わせた適切なデフォルト値を設定するため、互換性の問題を調査している場合を除き、頻繁に切り替える必要はありません。

TUNの起動に失敗した場合は、クライアントの権限、仮想NICの状態、他のVPNやネットワークフィルタリングソフト、ルーティングテーブル、DNSの取り込み競合を順に確認します。TUNを有効にしてもアプリが直接接続する場合は、ルートの除外項目、インターフェースの選択、アプリ自身が独自のVPNを使っていないかも確認してください。TUNは通信をコアへ送り込む役割を担いますが、直接接続とプロキシ接続のどちらを使うかは、最終的にルールとプロキシグループが決めます。

設定の読み込み失敗とルールが適用されない場合の確認手順

  1. まずYAML構文を確認します。インデント、コロンの後のスペース、リストのハイフン、引用符の閉じ忘れを確認してください。パーサーが示す行番号は、エラーを発見した位置にすぎない場合があり、実際の原因が数行前にあることもあります。
  2. 次に名前の参照を確認します。ルール末尾のポリシー名、プロキシグループ内のノード名、useが参照するプロキシプロバイダー、RULE-SETが参照するルールプロバイダーを照合してください。
  3. リモートリソースの状態を確認します。サブスクリプション、プロキシプロバイダー、ルールプロバイダーの更新が成功しているか、保存先ディレクトリに書き込み権限があるか、リモートコンテンツがコアの要求する形式に合っているかを確認してください。
  4. 通信の入口を確認します。システムプロキシのポートが現在の待ち受けポートと一致している必要があります。TUNを使う場合は仮想NICとルートが確立しているかを確認し、LAN上のデバイスでは待ち受けアドレスとファイアウォールも確認してください。
  5. DNSとルールのログを確認します。まずドメインが正常に解決されているかを判断し、次にどのルールに一致し、どのプロキシグループへ入り、最終的にどのノードが選ばれたかを確認します。
  6. 設定の範囲を絞ります。複雑な設定では、一時的に利用可能なノード1つ、手動プロキシグループ1つ、少数のルールだけを残します。基本フローを確認してから、DNSポリシー、ルールセット、自動速度テストを段階的に戻してください。

管理しやすいClash設定では、参照関係を明確に保つ必要があります。ポートとTUNが通信を受け取り、DNSがドメインを解決し、ノードとプロキシプロバイダーが出口を提供し、プロキシグループが出口を整理し、ルールがポリシーを選択します。変更時はこのフローに沿って各層を確認するほうが、コア、サブスクリプション、DNS、ルールセットを同時に変更するより問題を特定しやすくなります。

Clashをダウンロード