設定ガイド 読了目安 14分

Clash設定ファイルの構造を解説：ポート設定からプロキシグループまでYAMLを読み解く

基本設定、プロキシノード、プロキシグループ、ルールセット、DNSの各セクションを設定順に解説し、フィールド間の参照関係を整理します。

YAML Structure

YAMLの階層とデータ型を理解する

Clashの設定ファイルには通常YAMLが使われます。読むときは特定のノード名だけを検索せず、まずインデントが示す親子関係を確認しましょう。行頭から始まるフィールドは、proxies、proxy-groups、rules、dnsなどの主要な設定セクションです。内側にインデントされたフィールドは、直上のオブジェクトに属します。リスト項目はハイフンで始まり、同じインデント深度の項目は同列に扱われます。

mode: rule
log-level: info

proxies:
  - name: "サンプルノード"
    type: ss
    server: example.com
    port: 443

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

この設定には、2つのスカラー型フィールド、ノードのリスト、プロキシグループのリストが含まれています。name、type、serverは同じリスト内のノードオブジェクトに属します。一方、プロキシグループ内のproxiesは名前のリストであり、「サンプルノード」は別の場所に同名の定義が存在していなければなりません。

YAMLはインデントに依存するため、スペースを統一して使い、タブは使用しないでください。コロン、シャープ記号、特殊記号を含む名前や、真偽値として解釈される可能性のある名前は、引用符で囲むと安全です。コメントは#で始まり、説明のみに使われ、コアの動作には影響しません。設定フィールド名はコアが対応する表記を使う必要があります。表示名を変更してもフィールドの意味は変わりませんが、名前の参照先には影響します。

General Settings

基本設定、動作モード、リスニングポート

ファイルの冒頭には、ポート、LANアクセス、動作モード、ログレベル、コントロールインターフェースが記述されることが一般的です。これらはプログラムがトラフィックを受け取る方法や、クライアント画面がコアへ接続する方法を決めますが、特定のドメインが最終的にどのノードを経由するかは決めません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "独自のコントロールキーを設定してください"

ポートフィールドの違い

  • portは通常、HTTPプロキシの待受ポートを指定します。
  • socks-portはSOCKS5プロキシの待受ポートを指定します。
  • mixed-portは1つのポートでHTTPとSOCKSのトラフィックを受け付けます。デスクトップクライアントではこの形式がよく使われます。
  • redir-portとtproxy-portは特定の透過プロキシ方式向けです。利用できるかどうかは、OSとネットワークルールにも左右されます。

複数の待受ポートは、同じ端末上でほかのプログラムが使用しているポートと競合させないでください。デスクトップクライアントでは、ポートを画面上の設定で管理することが多いため、サブスクリプションから生成されたYAMLを直接編集した後は、クライアント側に設定の上書き機能がないかも確認しましょう。

mode: ruleはrulesを上から順に照合します。globalは通常、すべてのトラフィックをグローバルポリシーに渡し、directは直接接続します。画面上の「ルール」「グローバル」「直接接続」の切り替えは実行中にモードを変更する場合があり、元のサブスクリプションファイルへ書き戻されるとは限りません。

allow-lanは、LAN上の端末が待受ポートへアクセスできるかどうかを制御します。有効にする場合は、bind-address、OSのファイアウォール、実際のネットワーク境界も併せて制限してください。external-controllerはコントロールインターフェースのアドレスです。GUIクライアントはこれを利用して接続、ポリシー、ログの状態を読み取ります。端末外からアクセスする可能性がある場合は、secretを設定し、到達可能な範囲を制限してください。

Proxy Sources

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

proxiesには静的なノード定義を保存します。各ノードには少なくとも、一意の名前、プロトコル種別、サーバーアドレス、ポート、そしてプロトコルが要求する認証フィールドが必要です。異なるプロトコルのパラメーターは混在させられません。Shadowsocksではcipherとpassword、TrojanではパスワードやTLS関連設定、VMessとVLESSではそれぞれ異なる識別情報、伝送方式、暗号化フィールドがよく使われます。

proxies:
  - name: "Tokyo-A"
    type: trojan
    server: edge.example.com
    port: 443
    password: "example-password"
    sni: edge.example.com
    udp: true

serverは接続先、sniはTLSハンドシェイクで使うサーバー名です。両者が同じ場合もあれば、サービス側の設定で明確に指定されている場合もあります。接続に失敗したからといって、TLSフィールドを安易に入れ替えたり削除したりしないでください。プロトコルパラメーターは、サブスクリプション提供元の有効な設定と、現在のmihomoドキュメントを基準にしてください。

ノード数が多い場合、設定ではproxy-providersを使って外部のノード集合を読み込むことがよくあります。プロバイダーは指定したソースからノードを取得し、スケジュールに従って更新します。プロキシグループはuseでそれを参照します。これにより、「ノードの取得元」と「ノードの選択方法」を分離できます。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/provider.yaml"
    path: ./providers/primary.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

primaryはプロバイダーのキー名で、後からプロキシグループが参照します。pathはローカルキャッシュの保存先、intervalは更新間隔を指定します。ヘルスチェックは指定された条件でノードの接続性や遅延を確認するだけで、実際のサービスサイトが必ず利用できることを保証するものではなく、認証パラメーターを自動修正するものでもありません。

Policy Groups

プロキシグループとノード・ルールのつながり

proxy-groupsは設定全体のディスパッチ層です。ルールにサーバーアドレスを直接記述するのではなく、通常はトラフィックをプロキシグループへ渡し、グループがノード、組み込みポリシー、または別のプロキシグループを選択します。この層を理解すると、画面に複数階層の選択肢が表示される理由も分かります。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "Tokyo-A"
      - DIRECT

  - name: "自動選択"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "メディアサービス"
    type: select
    proxies:
      - "ノード選択"
      - DIRECT

1つ目のグループはselectを使い、利用者が画面上でメンバーを選択します。2つ目はurl-testを使い、プロバイダーprimaryのノードからテスト結果に基づいて選択します。3つ目はサーバーを直接列挙せず、「ノード選択」を参照するため、参照関係をたどって最終的な出口へ到達します。

proxiesには静的ノード、組み込みポリシー、ほかのプロキシグループを列挙します。useはproxy-providersを参照するために使います。どちらもメンバーの供給元になりますが、対象となるオブジェクトの種類は異なります。よくある間違いは、プロバイダー名をproxiesに入れたり、ノード名をuseに書いたりすることです。

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

select
手動で選択する入口を提供します。全体の出口、アプリ別の分類、固定したいポリシーに適しています。
url-test
指定したテストURLと間隔でメンバーを検査し、通常はテスト結果の良いノードを選びます。
fallback
メンバーを順番に確認し、先のメンバーが利用できない場合は後続のメンバーへ切り替えます。
load-balance
設定した方式に従って複数のメンバーへ接続を振り分けます。適性は、利用するサービスのセッション特性に左右されます。

DIRECTやREJECTなどは組み込みポリシーなので、proxiesで定義する必要はありません。カスタム名は大文字・小文字、空白、記号を含めて完全に一致させる必要があります。プロキシグループは入れ子にできますが、循環参照は作れません。循環すると、コアが明確な出口を決定できなくなります。

Routing Rules

ルールの照合順序とルールセットの参照

rulesはトラフィックをどのポリシーへ渡すかを決めます。ルールモードでは、コアが通常上から順に確認し、1つのルールに一致すると照合を停止します。そのため、具体的なドメインや明確なネットワーク範囲は、より広いルールより前に置き、最終的なフォールバックルールは末尾に配置します。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,ノード選択
  - DOMAIN-KEYWORD,media,メディアサービス
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

DOMAINは完全一致のドメイン、DOMAIN-SUFFIXは指定ドメインとそのサブドメイン、DOMAIN-KEYWORDはドメイン内のキーワードに基づいて照合します。IP-CIDRは対象のIPv4ネットワーク範囲で判断し、IPv6には対応するIPv6ルール種別を使えます。GEOIPは地理データベースを使ってIPの所属地域を判定します。MATCHは最後のフォールバックなので、ルールの末尾に置いてください。

ルールの最後には通常、「ノード選択」「メディアサービス」、DIRECT、REJECTなどの転送先ポリシー名を指定します。転送先の名前がproxy-groupsに存在しない場合、ルールの構文が正しく見えても、読み込み時にエラーになったり、意図した通りに動作しなかったりします。

大量のルールはrule-providersにまとめられます。ルールプロバイダーで取得元、キャッシュパス、形式、更新間隔を定義し、メインのルール領域からRULE-SETで呼び出します。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://example.com/private-network.yaml"
    path: ./ruleset/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,ノード選択

behaviorはルールセットのマッチ形式を示します。一般的な値にはdomain、ipcidr、classicalがあります。ルールファイルの実際の内容は、この指定と一致していなければなりません。classicalは比較的完全な従来型ルール表現に対応し、domainとipcidrはそれぞれ対応する種類のデータ集合に適しています。

DNS Pipeline

DNSセクションがドメイン解決に関わる仕組み

DNS設定は、2つのサーバーアドレスを入力するだけのものではありません。ドメインの解決方法、ドメインとIPの間でルールを関連付ける方法、TUN環境でトラフィックを安定してコアへ送れるかどうかに影響します。mihomoでよく使われるフィールドには、有効化状態、待受アドレス、解決モード、デフォルトリゾルバー、主要リゾルバー、フォールバックリゾルバー、ドメイン別に振り分けるネームサーバーポリシーがあります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

default-nameserverは、DoHやDoTサーバー自体のドメインを解決するために使われることが多く、通常は直接アクセスできるIPアドレスのリゾルバーを指定します。nameserverは主要な問い合わせ先です。fallbackを使うか、結果をどう絞り込むかは、現在のコアのバージョンと関連するフィルター設定にも左右されます。

enhanced-mode: fake-ipは、予約済みアドレス範囲のマッピングアドレスをアプリへ返し、コアがドメイン情報を保持したまま後続の転送を行えるようにします。ドメインルールの判定には有利ですが、一部のLANサービス、デバイス検出、ゲームプラットフォーム、実アドレスを必要とするプログラムではfake-ip-filterへの追加が必要になる場合があります。もう1つの一般的なモードがredir-hostです。処理経路が異なるため、OS、クライアントの実装、アプリの互換性を踏まえて選択してください。

DNS障害は、必ずしも「名前解決できない」という形で現れるとは限りません。ブラウザーはすでに結果を受け取っていても、誤ったルールによって利用できないポリシーへ接続している場合があります。また、システムDNS、ブラウザーのセキュアDNS、コアのDNSが同時に存在し、実際の問い合わせが想定した経路を通らないこともあります。切り分けでは、アプリのリクエスト入口、DNSの待受状態、解決ログ、最終的に一致したルールをそれぞれ確認してください。

Traffic Capture

TUNモードとシステムプロキシの設定範囲

システムプロキシの影響を受けるのは、OSのプロキシ設定に従うアプリだけです。一部のコマンドラインツール、ゲーム、独自のネットワークスタックを使うプログラム、UDPトラフィックはシステムプロキシを迂回することがあります。TUNモードは仮想ネットワークインターフェースでより多くのシステムトラフィックを受け取り、DNS、ルール、プロキシグループへ渡します。

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

stackはTUNのネットワークスタック実装を決めます。利用できる値や推奨設定は、プラットフォームとmihomoのバージョンによって変わります。auto-routeはルートの自動設定を試み、auto-detect-interfaceはデフォルトのネットワークインターフェースを検出します。TUNの有効化には通常、対応するシステム権限が必要です。クライアントはサービスモードや補助コンポーネントを通じて権限処理を行う場合があります。

TUNはトラフィックの入口にすぎず、ルールやプロキシグループの代わりにはなりません。トラフィックがコアに入った後も、ドメイン解決、スニッフィング設定、ルール照合、ポリシー選択を経ます。TUNを有効にしてLAN上の端末へアクセスできなくなった場合は、すべてのルールを削除するのではなく、プライベートネットワーク範囲の直接接続ルール、ルート除外設定、DNSのリダイレクト範囲を確認してください。

システムプロキシとTUNは、クライアントで一元管理できます。実際の利用では、ネットワークを制御するツールを複数同時に動かさないようにし、スリープ復帰、ネットワーク切り替え、VPNインターフェースの変化後にデフォルトルートが更新されているかにも注意してください。TUNを無効にした後もネットワークに問題が残る場合は、クライアントがシステムプロキシとルートの状態を復元したか確認しましょう。

Validation

設定変更後の検証とトラブルシューティング

設定ファイルをテキストエディターで開けるからといって、コアが読み込めるとは限りません。確実に変更するには、一度に1つの論理単位だけを編集し、復元可能なバージョンを残してください。クライアントに設定チェック、コアログ、上書きプレビューがある場合は、個別の断片ではなく、マージ後の最終YAMLを確認します。

  1. YAMLの構造を確認：インデント、リストのハイフン、引用符、コロンの位置を確認し、重要なトップレベルフィールドが重複して上書きされていないか確認します。
  2. 名前の参照を確認：ルールの転送先、プロキシグループのメンバー、useで指定するプロバイダー名、RULE-SET名を1つずつ照合します。
  3. 外部リソースを確認：プロキシプロバイダーとルールプロバイダーが更新できること、ローカルのキャッシュパスに書き込めること、取得内容の形式が宣言と一致することを確認します。
  4. 実行ログを確認：読み込みエラーではフィールド名やオブジェクト名が示されることが多く、接続エラーではDNS、ルールの一致結果、ノードのハンドシェイク情報を併せて判断する必要があります。
  5. 最小構成でテスト：まずDIRECT、次に単一の静的ノード、その後にプロキシグループとルールセットをテストし、問題の範囲を段階的に絞り込みます。

頻出するエラー

  • プロキシグループが、名前を変更したノードやサブスクリプション更新で削除されたノードを参照している。
  • ルールが存在しないプロキシグループを指している、または名前に余分な空白が入っている。
  • proxy-providersは定義されているが、プロキシグループからuseで参照されていない。
  • RULE-SET名とrule-providersのキー名が一致していない。
  • 広範囲のルールが具体的なルールより前にあり、後続のルールが一致する機会を失っている。
  • DNSの待受ポートが競合している、またはアプリのリクエストがコア管理の解決経路に入っていない。
  • サブスクリプションのキャッシュを直接編集したため、更新後にカスタム内容が新しいサブスクリプションの結果で置き換えられている。

完全な設定は、1本の参照チェーンとして理解できます。アプリのトラフィックはシステムプロキシ、透過プロキシ、またはTUNからコアへ入り、DNSセクションがドメインを解決します。rulesとルールプロバイダーが転送先ポリシーを決め、proxy-groupsが静的ノードまたはプロキシプロバイダーから出口を選び、最後に具体的なプロトコルノードが接続を確立します。この流れに沿って読むほうが、フィールドを1つずつ暗記するより設定の断点を見つけやすくなります。

Clash をダウンロード