FlClash 設定フィールド完全ガイド

YAML 構造の概要：まず階層、次にフィールドを確認

ルートオブジェクト、マッピング、シーケンス

mihomo の設定ファイルでは、ルート層が 1 つの YAML マッピングになっています。マッピングは「キー、コロン、値」で構成され、たとえば mode: rule のように記述します。シーケンスはハイフンから始まり、proxies、proxy-groups、rules でよく使われます。階層はすべてインデントで表現し、同じ階層のフィールドは同じ深さにそろえる必要があります。通常は半角スペース 2 個を使い、タブは使用しません。YAML は 2 個と 4 個のどちらでも構いませんが、同じ階層でインデントが不ぞろいになるとデータ構造が変わります。パーサーがエラーを出す場合もあれば、フィールドが誤った親オブジェクトに入る場合もあります。後者は発見しにくく、ファイルは読み込めるのに特定の設定だけが効かない状態になります。

スカラー値には文字列、数値、真偽値、null があります。ポートを 7890 と書くと数値、true と false は真偽値です。ノード名、ドメイン名、モードは通常文字列として扱います。コロン、シャープ、角括弧、波括弧、または前後の空白を含む文字列は、引用符で囲むことをおすすめします。引用符のない文字列ではシャープがコメントの開始を示すため、パスワードや名前にシャープを含める場合は必ず引用してください。YAML は大文字と小文字を区別するので、Rule、RULE、rule は別の値です。フィールド名もドキュメントどおりに記述し、画面に表示される日本語名で設定キーを置き換えないでください。

# config.yaml の基本的なルート構造
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

proxies:
  - name: "サンプルノード"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"

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

rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - MATCH,DIRECT

フィールドの記述順とトラフィック処理順は同じではない

YAML マッピングは意味上、記述順に依存しません。そのため、通常は dns を proxies の前後どちらに置いても結果は変わりません。ただし、人が読むためには構造を一定に保つことが重要です。共通設定、DNS、受信待受、プロキシノード、プロキシプロバイダー、プロキシグループ、ルールプロバイダー、ルールの順に並べると管理しやすくなります。順序に意味があるのはシーケンスです。rules は上から順に照合し、最初に一致した時点で停止します。プロキシグループ内のノード順は、デフォルト項目や自動選択時の候補順に影響します。同名オブジェクトはオーバーライド時に置き換えられることもあります。

参照関係は必ず成立させてください。ルール末尾のプロキシ名は proxy-groups に存在するか、DIRECT、REJECT などの組み込みポリシーである必要があります。プロキシグループが参照するノード名は、proxies 内のノード、定義済みの別のプロキシグループ、または use で読み込んだプロキシプロバイダーに対応していなければなりません。名前を変更するときは定義箇所だけでなく、プロキシグループとルールも同時に確認します。日本語、空白、句読点も名前の一部です。「ノード選択」と「ノード選択 」は異なる文字列として扱われます。

アンカー、エイリアス、高度な YAML 記法

YAML ではアンカーとエイリアスを使って、複数の項目でパラメータを共有できます。たとえば複数のノードで udp や skip-cert-verify などのフィールドを共用できます。ただし、サブスクリプション変換ツール、オーバーライドエンジン、GUI エディターが複雑な YAML 機能を完全に保持できるとは限りません。画面から保存するとアンカーが通常のフィールドに展開されたり、マージキーが再シリアライズされたりすることがあります。複数デバイスで長期的に管理する場合は、明示的で分かりやすいフィールドを優先してください。アンカーは手動管理する独立ファイルには適していますが、頻繁にリモート更新されるサブスクリプション本文には向きません。

コメントも GUI での保存やサブスクリプション更新後に失われることがあります。重要なメンテナンス情報をサブスクリプションキャッシュだけに残さず、ルールの意図や出典を別ドキュメントに記録するか、カスタム内容を安定したオーバーライドファイルに置いてください。FlClash は設定の読み込みと管理を担当し、mihomo カーネルが実際のフィールドを解釈します。「画面では確認できるのにカーネルで採用されない」場合は、まず実行ログの解析メッセージを確認し、最終的に有効な設定を確認してください。元のサブスクリプション本文だけを調べても解決しません。

共通フィールド：ポート、LAN、モード、ログ

待受ポートの使い分け

port は HTTP プロキシの待受ポート、socks-port は SOCKS5 プロキシの待受ポート、mixed-port は同じポートで HTTP と SOCKS5 の両方を受け付けます。デスクトップ環境では通常 mixed-port だけを有効にすると、システムプロキシと異なるアプリで 1 つの入口を共用できます。複数の待受フィールドは併存できますが、ポート番号が重複したり、ほかのプログラムに使用されたりしてはいけません。FlClash の画面でポートを割り当てる場合、手動設定の値がクライアントによって上書きされることもあります。トラブル時はエディター上の元の数値だけでなく、最終的な待受アドレスと実行ログを確認してください。

redir-port や tproxy-port などは透過プロキシの経路で使われ、通常は Linux のファイアウォールルール、ルーター環境、特定のトラフィック取り込み方式に対応します。一般的なデスクトップ利用者は「より多機能にする」ために全ポートを同時に有効にする必要はありません。ポートはトラフィックを受け取る入口にすぎず、システムのルーティングを自動変更するものではありません。システムプロキシモードでは、OS がプロキシ対応アプリを HTTP または SOCKS ポートへ向ける必要があります。TUN モードは仮想ネットワークインターフェースを作成し、より広範なトラフィックを取り込みます。権限、適用範囲、切り分け方法は両者で異なります。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true
find-process-mode: strict

allow-lan と待受範囲

allow-lan は、LAN 上のデバイスが本機のプロキシポートへ接続できるかを制御します。false は、本機のアプリだけで使うデスクトップ設定でよく使用します。true にした場合も、待受アドレスを正しく設定し、OS のファイアウォールが対象ポートを許可していることを確認する必要があります。このフィールドが他のデバイスへゲートウェイやプロキシアドレスを自動設定するわけではなく、アクセス制御の代わりにもなりません。LAN にプロキシを提供する場合は、固定したプライベートアドレスを使い、信頼できるネットワークだけに制限し、認証を設定してください。待受ポートをインターネットへ直接公開しないでください。

bind-address は待受をバインドする範囲を決めます。ワイルドカードアドレスは利用可能なインターフェースで待ち受け、具体的なアドレスは指定したネットワークインターフェースに入口を限定します。モバイル端末で Wi‑Fi とモバイル通信を切り替えると、インターフェースの変化によって元のバインドアドレスが使えなくなることがあります。LAN 共有で「本機では使えるが、他のデバイスは接続を拒否される」場合は、allow-lan、バインドアドレス、ファイアウォール、同一サブネットかどうか、プロキシ種別の入力を順に確認してください。接続できても対象サイトにアクセスできない場合は、プロキシグループ、DNS、出力ノードを続けて確認します。

3 つの動作モード

mode: rule はルール一覧に従ってトラフィックの行き先を決める、日常利用の基本モードです。global はすべてのトラフィックをグローバルポリシーへ渡し、ノードが使えるかを一時的に確認するのに適しています。direct は直接接続するため、問題の原因がプロキシ経路にあるかを素早く切り分けられます。モードを切り替えてもルールは削除されず、判断の入口だけが変わります。トラブル時に一時的に切り替え、グローバルでは正常でルールだけ異常なら、ルールの一致やプロキシ参照を疑います。ダイレクトでも異常なら、ローカルネットワーク、DNS、システムの取り込み状態を確認してください。

log-level の主な値は silent、error、warning、info、debug です。通常は info で十分です。ルールの一致、DNS クエリ、ハンドシェイクの問題を調べるときだけ、一時的に debug へ上げるとよいでしょう。詳細ログは出力量を大きく増やし、対象ドメインやノードアドレスなどの実行情報を含む場合があります。調査後は通常のレベルに戻してください。ログは最初のエラーが後続の連鎖エラーより重要なことが多いため、設定読み込み、待受開始、DNS 初期化、プロキシハンドシェイクの順に確認します。

遅延測定、同時接続、プロセス識別

unified-delay は遅延テストの基準を統一し、異なるプロキシ種別の結果を比較しやすくします。測定結果はテスト URL と現在のネットワーク条件における 1 回の接続性能であり、すべてのサイトに共通する固定遅延ではありません。tcp-concurrent は対象アドレスへの複数の候補接続を並行して試行します。デュアルスタックや複数アドレスの環境では接続確立までの待ち時間を短縮できますが、追加の接続試行が発生します。ネットワークに制約がある場合、ルーターのリソースが少ない場合、接続数を厳密に制御したい場合は、無効にして比較テストしてください。

find-process-mode は、カーネルが接続元プロセスを取得する方法に影響します。プロセスルールは OS の機能と実行権限に依存し、プラットフォームによって利用しやすさが異なります。Android、macOS、Windows、Linux では、プロセスパス、パッケージ名、権限の扱いが異なるため、同じプロセスルールが全プラットフォームで完全に同じ動作をすると考えてはいけません。ドメインや IP だけで振り分けられる場合は、ネットワーク層の条件を優先するのが一般的です。アプリ単位の振り分けが必要な場合に限り、対象プラットフォームでプロセス名を検証してください。

DNS フィールド：名前解決経路、Fake-IP、振り分けの整合性

DNS 設定が解決するのは、単なる「名前解決の速さ」ではない

プロキシ環境における DNS は、ドメイン解決、ルール判定、ノードサーバーのアドレス解決、リクエストが想定した経路を回避するのを防ぐ役割を同時に担います。dns.enable でカーネルの DNS モジュールを有効にすると、クエリを設定した上流へ送れるようになります。ただし、すべてのクエリをカーネルに渡すかどうかは、TUN、システム DNS、アプリ自身の動作にも左右されます。ブラウザーが独自の暗号化 DNS を使う場合や、アプリがアドレスをキャッシュしたり固定 IP へ直接アクセスしたりする場合もあります。名前解決結果とルールが一致しないときは、まず問い合わせ経路を整理してください。アプリはどこへ問い合わせるのか、カーネルはどの上流を使うのか、ノードサーバーのドメインは誰が解決するのか、最終接続はどのルールに一致したのかを確認します。

nameserver は主な名前解決サーバーの一覧で、通常のドメイン検索に使います。default-nameserver は暗号化 DNS サーバー自身のドメインを解決するために使われ、「DNS サーバーへ接続するには、まず DNS サーバーのドメインを解決しなければならない」という循環依存を避けます。そのため、ここには直接アクセスできる IP アドレス形式のサーバーを置くのが一般的です。proxy-server-nameserver ではプロキシノードのサーバー名を専用に解決し、ノードアドレスと通常のドメイン解決を分離できます。direct-nameserver は、明確に直接接続するドメインに専用の解決経路を提供します。すべてを設定すべきかどうかは実際のネットワーク構成で判断し、フィールドを増やせば安定するとは考えないでください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://dns.google/dns-query
    - tls://1.1.1.1
  proxy-server-nameserver:
    - https://dns.google/dns-query
  respect-rules: true

Fake-IP と Redir-Host の違い

enhanced-mode: fake-ip は、まずアプリに予約済みアドレスプールのマッピングアドレスを返し、その後カーネルがマッピングから元のドメインを復元してルール判定を行います。アプリが対象 IP だけをネットワーク層へ渡す場合でも、カーネルがドメイン情報を保持できるため、ドメインルールやスニッフィングと組み合わせやすくなります。fake-ip-range はマッピング用アドレスプールを指定します。ローカルの実ネットワーク、コンテナネットワーク、企業 VPN のサブネットとは重複させないでください。内部アドレスが衝突すると、すべての接続ではなく特定のサブネットだけにアクセスできなくなることがあります。

redir-host は従来型の実アドレス解決に近く、アプリが対象ドメインの実 IP を取得し、カーネルが利用可能な情報に基づいて処理します。Fake-IP に対応しない機器検出、LAN サービス、特殊プロトコルでは分かりやすい一方、後続の接続段階でドメイン情報が失われ、ルール判定が DNS キャッシュやスニッフィングに依存しやすくなります。モードはアプリの互換性とルール精度を基準に選び、どちらかを万能な結論として扱う必要はありません。多くの問題ではまず Fake-IP を使い、明確に互換性のないドメインだけをフィルターへ追加する方法が現実的です。

fake-ip-filter は説明可能な範囲に保つ

フィルターに登録したドメインは Fake-IP マッピングを回避し、実際の名前解決結果を取得します。LAN デバイスの検出、時刻同期、STUN、一部のゲームプラットフォーム、機器の初期設定ではフィルターが必要になることがあります。追加する前に、明確な症状と検証方法を用意してください。たとえば Fake-IP 使用時だけ同一サブネットの機器を検出できず、該当ドメインを追加すると復旧する、といった場合です。広いトップレベルドメインや無差別なワイルドカードを入れると、多くのリクエストが実アドレス解決へ戻り、ドメインルールの可視性が下がります。デバイスごとに動作が分かれる原因にもなるため、安易に追加しないでください。

完全一致のドメイン、1 階層ワイルドカード、サフィックス一致は書き方を分ける必要があります。フィールドによってワイルドカードの対応範囲が異なるため、ルール一覧の DOMAIN-SUFFIX 構文をそのままフィルターへコピーしてはいけません。変更後はアプリの DNS キャッシュを消去して接続を作り直し、ログでクエリが想定した上流へ入ったことを確認します。ページを再読み込みするだけでは、ブラウザーの接続プールや古いキャッシュが使われ、「設定が変わっていない」と誤認することがあります。

ルールによる振り分けと DNS 上流の選択

respect-rules を有効にすると、適用可能な DNS リクエストがルール体系に従うようになります。ただし、DNS 用のプロキシポリシーは解決前に接続を確立できなければならず、再帰依存を避ける必要があります。たとえばプロキシノードのアドレスがドメインで、暗号化 DNS への接続にもそのプロキシが必要な場合、ノードのドメインは proxy-server-nameserver または直接アクセス可能なブートストラップリゾルバーで先に解決しなければなりません。「ノードアドレスの解決」と「サービスドメインの解決」を分離し、最下層に未確立のプロキシへ依存しない解決経路を必ず用意してください。

nameserver-policy はドメインごとに特定の上流を選択できます。企業内ドメイン、LAN サービス、解決元を固定したい領域に適しています。ポリシーはできるだけ狭くし、明確なサフィックスを先に照合して、共通の nameserver をフォールバックに残してください。同じドメインが複数のポリシーに一致する場合は、優先順位と最終ログを確認します。ルールプロバイダーで管理するドメイン集合を使う場合は、ルールセットの動作と DNS ポリシーフィールドがその参照方式に対応しているかも確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.internal.example":
      - 192.0.2.53
    "geosite:private":
      - system
  direct-nameserver:
    - system
  direct-nameserver-follow-policy: true

一般的な障害は層ごとに切り分けられます。ドメインをまったく解決できない場合は、DNS の待受、上流への到達性、証明書時刻を確認します。解決できるのに接続できない場合は、ルール、ポリシー、ノードを確認してください。ノードのドメインだけ失敗する場合は、ブートストラップ解決と proxy-server-nameserver を確認します。LAN デバイスに異常がある場合は、Fake-IP アドレスプールの衝突とフィルターを確認してください。新旧の結果が断続的に混ざる場合は、システム、ブラウザー、カーネルのキャッシュを消去します。より詳しい切り分けはよくある質問の DNS と接続の項目を参照してください。

プロキシノードのフィールド：共通属性、プロトコルパラメータ、トランスポート層

すべてのノードは名前、種類、サーバーから始まる

proxies は手動で定義するノードのシーケンスです。各ノードには少なくとも一意の name、プロトコルの type、サーバーの server、ポートの port が必要で、さらにプロトコル固有の認証フィールドを追加します。ノード名はプロキシグループやルールが参照する主キーなので、安定させてください。サブスクリプション更新で上流が名前を変更すると、手動のプロキシグループに未解決の参照が残ることがあります。動的ノードを大量に扱う場合は、名前をグループに固定するより、プロキシプロバイダーとフィルターで整理するほうが適しています。

server には IP アドレスまたはドメイン名を指定できます。ドメイン名はサーバー移転に対応しやすい一方、ノードアドレスの解決経路が安定している必要があります。IP アドレスなら解決を 1 回減らせますが、アドレス変更には追従できません。udp はノードが UDP を扱うかを制御しますが、実際の可用性はプロトコル、サーバー、ネットワーク経路にも左右されます。interface-name やルーティングマーク関連のフィールドは、複数のネットワークインターフェースを持つ環境で出口を固定できますが、モバイル端末でネットワークを切り替えると無効になることがあります。複数の出口が必要でない限り、プラットフォーム依存のフィールドを共有設定へ固定しないでください。

proxies:
  - name: "オフィス SOCKS"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-user"
    password: "your-password"
    udp: true

  - name: "サンプル HTTP"
    type: http
    server: gateway.example.net
    port: 8443
    username: "your-user"
    password: "your-password"
    tls: true
    skip-cert-verify: false

TLS フィールドとサーバーの識別情報

TLS に対応するプロトコルには通常、tls、servername、skip-cert-verify、ALPN、フィンガープリント関連のオプションがあります。servername は TLS ハンドシェイクで使うサーバー名であり、サーバー証明書や構成と一致させる必要があります。任意の偽装ドメインを入力する項目ではありません。skip-cert-verify: true は証明書の有効性検証を無効にするため、明確に管理されたテスト環境でのみ使用してください。通常の設定では検証を維持し、システム時刻、証明書チェーン、サーバー名、中間ネットワークの干渉を修正します。接続ログで証明書名の不一致が出た場合は、検証を無効にして隠すのではなく、まずサブスクリプションのパラメータを確認してください。

WebSocket、gRPC、HTTP/2 などのトランスポートパラメータは、通常それぞれのプロトコル固有オプションにネストして記述します。パス、Host、サービス名、リクエストヘッダーはサーバー側と一致させる必要があります。似たフィールドでも階層が異なることがあり、たとえば WebSocket のパスをノードのルートに書いただけでは自動的に有効になりません。他のクライアント設定を移行するときは、日本語ラベルだけを頼りに項目をコピーせず、mihomo が対応するノード構造と照合してください。サービス提供者が生成したサブスクリプションでは、サーバー側の要件を確認した場合を除き、元のトランスポートパラメータを維持するのが安全です。

プロトコル固有のフィールドを別のプロトコルへ流用しない

Shadowsocks ノードの中心的なフィールドは cipher と password です。Trojan はパスワード、TLS のサーバー名、トランスポートパラメータを中心に構成します。VMess では通常 uuid、暗号化オプション、トランスポート設定が必要です。VLESS は UUID が必要で、flow、Reality、その他の拡張フィールドを含む場合があります。Hysteria2 と TUIC では、UDP ベースのトランスポート、輻輳制御、帯域幅パラメータなども関係します。各プロトコルは固有の構造に従って設定してください。あるプロトコルの認証フィールドを別のプロトコルに入れても互換層にはならず、無視されるか読み込みに失敗します。

プロトコルの機能は mihomo カーネルが提供し、FlClash は設定管理とクロスプラットフォームの画面を提供します。カーネルにフィールドが存在しても、各プラットフォームのネットワーク条件が同じとは限りません。たとえば UDP ベースのプロトコルは、公共 Wi‑Fi、企業ネットワーク、通信事業者の経路によって制限されることがあります。TUN の権限やバックグラウンド実行もモバイル端末の使用感に影響します。ノードを検証するときは、まず単純な接続テストを行い、次にハンドシェイクログを確認してください。ノードの速度測定に失敗しても、サブスクリプションが無効とは限りません。テスト先に到達できない、DNS が未準備、UDP が制限されている、ポリシーが循環している可能性もあります。

ノード名、機密フィールド、共有時の注意

ノード設定にはサーバーアドレスと認証情報が含まれるため、公開の質問ページへそのまま貼り付けないでください。トラブルシューティングではフィールド構造を残し、アドレスを proxy.example.com に、パスワードや UUID を明らかなテスト値に置き換えます。プロトコル種別、階層、真偽フィールドは残してください。エラーの 1 行だけを切り出してコンテキストを隠すのも避けましょう。問題の原因がインデントや親フィールドにあることも多いためです。公開テキストにサブスクリプション URL を残してはいけません。サブスクリプション URL は通常アクセス資格情報として機能するため、漏えいした場合は投稿から削除するだけでなく、サービス側で再発行してください。

同名ノードがあると、プロキシ参照と画面上の選択が不確定になります。手動設定では名前を一意にしてください。複数のプロキシプロバイダーからノードを集約する場合は、オーバーライド段階で出典のプレフィックスやサフィックスを追加できます。名前のフィルタリングに正規表現を使う場合は、括弧、プラス記号、その他のメタ文字を考慮してください。まず少数のノードで式を検証してから、完全なサブスクリプションに適用します。クライアントを選び直す場合は、ダウンロードセンターで Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu などをプラットフォーム別に確認できます。Clash Plus は全プラットフォーム向けの第一候補です。

プロキシグループのフィールド：選択、自動テスト、フェイルオーバー、チェーン参照

プロキシグループはルールとノードの間にある判断層

proxy-groups は、ノード、組み込みアクション、他のプロキシグループを参照可能な出力先の集合としてまとめます。ルールでは通常、具体的なノードを直接指定せず、「ノード選択」「自動選択」「国外トラフィック」のような安定したグループ名を指定します。これによりサブスクリプションのノードが変わっても、候補を更新するだけで済み、すべてのルールを書き直す必要がありません。各グループには少なくとも name と type が必要です。候補は proxies で明示するか、use でプロキシプロバイダーを参照します。

select は候補を手動で選択できるため、最上位の総合入口に適しています。候補には具体的なノード、自動テストグループ、DIRECT を同時に入れられます。グループ内の先頭項目がデフォルトとして扱われることが多いものの、クライアントが前回の選択を保存している場合は、順序を変更しても現在の選択がすぐ変わるとは限りません。「ルールは正しいグループに一致するのに、ノードが違う」場合は、グループの現在の選択と保存状態を同時に確認してください。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "フェイルオーバー"
      - "オフィス SOCKS"
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies:
      - "オフィス SOCKS"
      - "サンプル HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - "オフィス SOCKS"
      - "サンプル HTTP"
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

url-test、fallback、load-balance

url-test はテスト URL へ定期的にリクエストを送り、結果に基づいて適切な候補を選びます。interval はテスト間隔です。短すぎるとノードと端末の負荷が増えます。tolerance は切り替えの許容幅を設け、数値のわずかな変動による頻繁な切り替えを防ぎます。lazy はグループが使われていない間の能動テストを減らします。テスト URL には、安定していてレスポンスが小さく、対象ネットワークから到達でき、実際の接続経路を代表するものを選んでください。最小遅延はそのテスト先へのリクエスト確立が速いことを示すだけで、帯域幅、パケットロス、対象サイトまでの経路が最適とは限りません。

fallback は候補の順序に従って利用可能な項目を選ぶため、主回線を優先し、失敗時に切り替えたい場合に適しています。すべてのリクエストを均等配分するものではなく、既存の長時間接続を無感覚に移行することもありません。load-balance は複数の候補へ接続を分散し、一般的な方式には一貫性ハッシュやラウンドロビンがあります。ログインセッションや送信元アドレスに敏感なサービスでは、同じ処理の接続が異なる出口から出る可能性があるため、ラウンドロビンには注意してください。セッションを安定させたい場合は、一貫性のある方式か手動選択のほうが制御しやすくなります。

プロキシプロバイダーと動的候補

ノードがリモートサブスクリプション由来の場合、proxy-providers でノードデータ、更新間隔、ヘルスチェックを個別に管理できます。プロキシグループは use でプロバイダーを参照します。リモートノードが追加・削除されても、グループ内の名前を逐一変更せずに済みます。プロバイダーの filter、exclude-filter、オーバーライドルールで、名前から地域、プロトコル、用途を絞り込めますが、結果は上流の命名品質に依存します。名前が安定しない場合は複数条件で段階的に分け、未フィルターの総合グループを確認用に残すほうが確実です。

ヘルスチェックとプロキシグループのテストには重複する部分があります。プロバイダー単位のヘルスチェックはノードの基本的な可用性を判定し、プロキシグループの url-test は候補を選択するために使います。両方を極端に短い間隔で設定すると、同じようなトラフィックが重複して発生します。端末の性能が限られている場合やノード数が多い場合は、プロバイダーのチェック間隔を延ばし、よく使う自動グループにより新しいテストを担当させます。すべてのノードが同時に利用不可と表示されたら、まずテスト URL、DNS、ネットワーク入口を確認し、すぐに全ノードの無効化と判断しないでください。

proxy-providers:
  remote-main:
    type: http
    url: "https://subscription.example.com/your-token"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "サブスクリプションノード"
    type: select
    use:
      - remote-main

  - name: "自動サブスクリプション"
    type: url-test
    use:
      - remote-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

チェーン参照では循環を避ける

プロキシグループは他のプロキシグループを参照でき、「サービス分類グループ → 総合選択グループ → 自動テストグループ → ノード」の階層を構築できます。たとえばストリーミンググループを単独で選択しつつ、総合選択グループへフォールバックさせることが可能です。ただし、参照チェーンが自身へ戻ってはいけません。A が B を参照し、B が A を参照すると循環が発生し、最終的な出力先を決められません。複雑な設定では、下位ノードグループ、自動グループ、総合選択グループ、サービスグループを依存順に並べ、名前で役割を明確にしてください。

組み込みポリシー DIRECT は直接接続、REJECT はリクエスト拒否を表します。プロキシグループの候補にも、ルール末尾にも指定できます。最上位の選択グループに DIRECT を入れると一時的にプロキシを迂回できますが、誤選択のリスクも増えます。固定端末向けの設定では、明確なルールに直接接続を任せ、すべてのサービスグループに繰り返し追加する必要はありません。拒否ポリシーは接続不要な対象に使いますが、範囲が広すぎるとページのリソース不足やアプリの機能障害につながるため、狭いルールから始めてください。

ルールセットと Rule Providers：分割、更新、behavior の種類

大きなルール一覧をメイン設定から分離する理由

rule-providers は、独立して読み込み・更新できるルールセットを宣言するために使います。メイン設定にはプロバイダー名、取得元、キャッシュパス、更新間隔、behavior の種類だけを残し、RULE-SET ルールから参照します。これにより、広告拒否、LAN 直結、特定サービス、地域ドメインなどを役割ごとに分離でき、メインファイルを短くして個別に更新できます。ルールセットはプロキシグループではなく、照合条件だけを提供します。一致後にどのポリシーへ送るかは、メイン設定の RULE-SET,プロバイダー名,ポリシー名 で決まります。

プロバイダーの type は通常 http または file です。リモート型には url、ローカルキャッシュの path、更新間隔の interval が必要です。ローカル型は端末上のファイルを読み込みます。キャッシュパスはプロバイダーごとに分け、同じファイルを上書きしないようにしてください。リモート更新に失敗しても、カーネルは通常既存のキャッシュを使い続けますが、初回読み込みでキャッシュがなければそのルールセットを使えないことがあります。重要な直結ルールは少数の組み込みルールとして残し、まだ取得できていないリモートファイルだけに基本的な通信を依存させないでください。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.com/private-domain.yaml
    interval: 86400

  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: https://rules.example.com/private-network.yaml
    interval: 86400

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

behavior はルールデータの解釈方法を決める

domain behavior はドメイン集合に使い、データには通常、完全なドメイン、ドメインサフィックス、対応するドメイン表現を記述します。ipcidr は IPv4、IPv6 のネットワークに使います。classical では、DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME など、従来のルール種別を各項目に含められます。behavior の種類はファイルの内容と一致させてください。ルール種別のプレフィックスが付いた classical ファイルを domain として宣言しても、プレフィックスが自動削除・変換されることはありません。読み込みに失敗するか、すべて一致しなくなるのが一般的です。

behavior はできるだけ狭いモデルを優先して選びます。ドメイン一覧だけなら domain、ネットワーク一覧だけなら ipcidr、混在する条件が必要な場合だけ classical を使います。明確な behavior はカーネルの最適化に役立ち、DNS 解決が必要なルールかどうかも判断しやすくなります。classical が多くの形式を収容できるからといって、すべてのルールを巨大なファイルへ詰め込まないでください。役割とデータ型で分割したほうが、一致状況を直接確認できます。

ルールセットのファイル形式とデータ内容

YAML 形式のルールセットは通常、ルートキーとして payload を持ち、その下にルールのシーケンスが続きます。domain behavior では、サフィックス表現がルートドメインとサブドメインに一致し、完全なドメインは指定したホストだけに一致します。ipcidr behavior では標準 CIDR のネットワークを記述します。classical behavior では完全なルール条件を記述しますが、ルールセットの項目に最終ポリシーは付けません。ポリシーはメイン設定から参照するときに指定します。同じルールセットを異なるポリシーへ渡すことも可能です。たとえば仕事用設定では直結、旅行用設定ではプロキシへ送れます。

# private-domain.yaml
payload:
  - "+.lan"
  - "+.local"
  - "router.example"
  - "intranet.example.org"

# private-network.yaml
payload:
  - "10.0.0.0/8"
  - "172.16.0.0/12"
  - "192.168.0.0/16"
  - "127.0.0.0/8"
  - "::1/128"
  - "fc00::/7"

format はリモートファイルの実際の形式と一致させてください。拡張子だけでは不十分なので、ダウンロード後に本文の構造とレスポンス内容を確認します。リモート URL がログインページ、レート制限の通知、HTML のエラーページを返すと、ファイルは保存できてもルールセットとして解析できないことがあります。ログに形式エラーが出たら、ブラウザーで URL を開けるかだけでなく、最終的なレスポンスを確認してください。認証が必要な非公開ルールセットでは、資格情報の更新やデバイス間同期も考慮し、実際のアクセス情報を公開サンプルへ貼り付けないでください。

更新間隔、キャッシュ、原子性

interval は秒単位の更新間隔です。ルール内容が 1 日に 1 回変わるだけなら、数分ごとに取得する必要はありません。頻繁な更新はネットワークリクエストと上流の負荷を増やし、一時的な障害でエラーを繰り返し発生させます。リモートファイルを安定してキャッシュし、ローカルでは解析可能な前回の内容を使い続け、更新失敗をログに記録する方法が現実的です。ルールの取得元を変更した後は、手動更新や該当キャッシュの削除で検証できますが、すべてのプロバイダーキャッシュを一度に削除しないでください。1 つのファイルの問題が、全ルールセットの同時利用不可に広がります。

ルールセットの更新とメイン設定の更新は、同じトランザクションではありません。メイン設定が、まだ取得に成功していないプロバイダーを先に参照すると、一時的にルールが欠落することがあります。リモートのルール内容に互換性のない変更が入った場合も、次の周期更新まで問題が表面化しないことがあります。重要な設定には、プライベートネットワークの直結や最後の MATCH など、短いメインルールのフォールバックを残してください。外部集合は適切な位置に置き、取得元を明確にし、役割を分け、戻せる状態にします。出典不明の大規模な集合は互いに上書きし、特定のドメインが断続的に誤ったポリシーへ送られる原因になります。

ルール構文：上から順に照合し、最初の一致で終了

1 つのルールの基本構造

rules は順序付きシーケンスです。従来型のルールは通常、ルール種別、照合内容、対象ポリシー、任意のパラメータで構成され、カンマで区切ります。たとえば DOMAIN-SUFFIX,example.org,ノード選択 は、example.org をサフィックスとするドメインを「ノード選択」へ送ります。カーネルは先頭から順に確認し、一致すると処理を止めます。そのため、ルール設計で重要なのは個々のルールが正しいかだけでなく、狭い範囲のルールを広い範囲のルールより前に置くことです。

MATCH には照合内容が不要で、通常は最後に置き、前のルールに一致しなかったすべてのトラフィックを受けます。途中に置くと、後続のルールは実行されません。ルールの送信先にはプロキシグループ、具体的なノード、組み込みアクションを指定できますが、保守性を考えるとプロキシグループを指すのが一般的です。ノード名が変わっても、グループに有効な候補が残っていればルールを変更せず、判断チェーンを維持できます。

rules:
  # 完全一致のドメインを優先
  - DOMAIN,api.example.org,DIRECT
  # 次にドメイン全体のサフィックスを処理
  - DOMAIN-SUFFIX,example.org,ノード選択
  # キーワードは範囲が広いため後ろに置く
  - DOMAIN-KEYWORD,example,ノード選択
  # プライベートネットワークは直接接続
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  # 最終フォールバック
  - MATCH,ノード選択

ドメインルールの範囲の違い

DOMAIN は完全なドメイン名だけに一致し、個別に扱いたい API、ログイン入口、特定ホストに適しています。DOMAIN-SUFFIX はドメインとそのサブドメインに一致し、サービス全体を振り分ける用途に向きます。DOMAIN-KEYWORD はドメイン内にキーワードが含まれるかで判断するため、範囲が広く、無関係なドメインにも一致しやすくなります。完全なドメインやサフィックスで対応できる場合は、最初からキーワードで範囲を広げないでください。

ドメインルールで照合できるかどうかは、カーネルが接続に対応するドメインを把握しているかで決まります。システムプロキシでは通常ドメインがそのまま提供され、Fake-IP ではマッピング関係を保持できます。対象 IP しかない透過接続では、DNS キャッシュやスニッフィングが必要になることがあります。ログに IP しか表示されずドメインルールに一致しない場合も、必ずしもルールの記述ミスとは限りません。DNS がカーネルで処理されているか、スニッフィングがそのプロトコルに対応しているか、アプリが固定アドレスへ直接接続していないかを確認してください。

IP、Geo、no-resolve

IP-CIDR と IP-CIDR6 は、対象アドレスが含まれるネットワークに一致します。ルール末尾の no-resolve は、この IP ルールを実行するためにドメインを追加解決しないことを示します。不要なクエリや、ルール段階での解決による副作用を減らせます。対象 IP がすでに分かっている接続なら、そのまま判定できます。プライベートネットワークや本機のアドレスは通常、早い位置で直結させ、LAN デバイスのトラフィックがリモートプロキシへ送られないようにします。

地理データベース関連のルールは、ローカルデータファイルとその更新状態に依存します。ドメイン分類と IP の地理的な帰属は別のデータソースです。あるサービスのドメインが世界各地のアドレスへ解決されることもあり、IP の地域だけでサービス分類を代用することはできません。Geo 系ルールを使う場合は適用範囲を理解し、重要なサービスには明確なドメインルールを残してください。データベースを読み込めないと該当ルールは無効になることがありますが、通常の DOMAIN や IP-CIDR ルールは動作します。ログからも切り分けの手がかりを得られます。

プロセス、ネットワーク、論理条件の組み合わせ

PROCESS-NAME、PROCESS-PATH などのプロセスルールは、デスクトップアプリ単位の振り分けに適していますが、システム権限とプラットフォームの実装に依存します。Android ではパッケージ名や OS が提供するアプリ識別方式が一般的で、iOS のシステム制約も異なります。プロセスパスの表現は Windows と Unix 系 OS でまったく異なるため、絶対パスを共有できません。クロスプラットフォーム設定にプロセスルールが必要な場合は、すべての OS のパスを 1 つの基盤ファイルへ混在させず、デバイスごとのオーバーライドで注入してください。

mihomo が対応する論理ルールでは、複数の条件を組み合わせて「すべてを満たす」「いずれかを満たす」「特定条件を除外する」といった表現ができます。組み合わせが強力になるほど、読解と切り分けのコストも増えます。実際の運用では、例外を先に書くことでルール順序から表現できる場合を優先してください。順序だけでは明確に表せない場合や、複数条件が本当に同時成立する必要がある場合に限り、論理条件を使います。複雑な式にはコメントと再現可能なテスト用ドメインを添えないと、数か月後に元の意図を判断しにくくなります。

ルール順序を安定させる基本テンプレート

説明しやすい順序は通常、本機と LAN の例外、明確な拒否、重要サービスの完全一致ルール、サービスドメインのルールセット、地域またはネットワークルール、最終フォールバックです。これは固定の正解ではありませんが、各層をなぜ次の層より先に置くのか説明できるようにします。特定の完全一致ドメインを直結する場合は、そのドメインを含むプロキシのサフィックスルールより前に置く必要があります。特定のサブドメインをプロキシへ送る場合も、親ドメイン全体を直結するルールより前に置いてください。

ルールを検証するとき、ウェブページを 1 回開くだけで判断しないでください。ブラウザーが既存接続を再利用し、DNS がキャッシュに一致することがあります。変更後は対象接続を閉じ、必要なキャッシュを消去して、ログに表示される対象、ルール種別、ポリシー名を確認します。ログの一致は正しいのに出口が想定と異なる場合は、プロキシグループをたどって確認してください。ログにドメインが表示されない場合は、DNS とスニッフィングの層へ戻ります。ルール、ポリシー選択、ノード接続は分けて判断してください。

オーバーライドとマージ：サブスクリプション更新後もローカル設定を保持する

元のサブスクリプション、生成設定、最終設定

リモートサブスクリプションは上流のデータソースです。FlClash に取り込まれた後、解析、オーバーライド、カーネルへの適合処理を経て、最終的な実行設定になります。サブスクリプションキャッシュを直接編集するとすぐに反映されたように見えますが、次回更新で新しい内容に置き換えられるのが普通です。安定して管理するには、上流が担当するノードデータと、ローカルが担当するポリシーを分けてください。サブスクリプションにはノードと基本グループを任せ、ローカルのオーバーライドでポート、DNS、グループ構成、ルール、デバイス差分を管理します。問題が発生したら、元のサブスクリプション、オーバーライドの実行、カーネルが受け入れた最終設定を分けて確認します。

オーバーライドは単純なテキスト連結ではありません。マッピング、シーケンス、同名オブジェクトにはそれぞれ異なる処理が必要です。マッピングはキー単位の置換や再帰的マージ、シーケンスは全体置換、先頭挿入、末尾追加、名前単位の処理が考えられます。現在のツールのマージ仕様が分からない場合は、まず mode の変更など、結果を確認しやすいフィールドでテストしてください。最初から完全な DNS、数十個のルール、複数のプロキシグループを追加すると、どのマージ処理が原因か分からなくなります。

マッピングの置換とシーケンスの追加の違い

元の設定に完全な dns マッピングがあり、ローカルオーバーライドで dns.enable: true だけを指定するとします。再帰的マージなら既存の nameserver などの子項目が残りますが、全体置換では enable だけが残る可能性があります。どちらも特定の「オーバーライド」の定義には合致するため、FlClash の現在のオーバーライド方式と最終プレビューを基準にしてください。重要な DNS セクションを完全に制御したい場合は、部分マージに依存せず、目的の構造全体を明示したほうが安定します。

rules は順序付きシーケンスです。単純な追加は、MATCH より前に補足ルールを正しく入れたい場合に適しています。ただし元の一覧が MATCH で終わっている場合、末尾に追加した新しいルールは永遠に一致しません。先頭挿入は LAN の例外や完全一致の上書きに適し、全体置換はルール体系を完全に自分で管理したい場合に適しています。プロキシグループのシーケンスを名前でマージする場合は、同名グループが置換、拡張、重複オブジェクトの生成のどれになるかも確認してください。同名グループが 2 つあると、画面表示と参照結果が分かりにくくなります。

# 基本設定：base.yaml
mixed-port: 7890
mode: rule

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

rules:
  - MATCH,ノード選択

# ローカルオーバーライド対象：override.yaml
log-level: info
ipv6: false

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query

ルールの挿入位置を明確にする

サブスクリプションへカスタムルールを追加するときは、例外、通常の分類、フォールバックのどれに当たるかを先に判断します。例外ルールは通常先頭へ、サービスルールはより広い集合より前へ、フォールバックは末尾だけに置きます。スクリプトによるオーバーライドに対応している場合は、元のリストから MATCH の位置を探し、その前へ新しいルールを挿入できます。MATCH が見つからない場合は警告を記録し、追加するかどうかを判断してください。黙って末尾に追加して、構造が正しいと決めつけてはいけません。

重複排除は行全体のテキスト比較だけでは不十分です。照合条件が同じでも異なるポリシーを指す 2 つのルールは、重複ではなく競合を意味します。同じドメインの完全一致ルールとサフィックスルールも重複ではありません。まずルール種別と照合内容で競合を特定し、その後ローカルの優先順位に基づいて残す位置を決めます。自動削除の前には、確認可能な結果を出力してください。規模の小さいカスタムルールなら、過度な自動化より明示的で読みやすい構成を保つほうが適切です。

デバイス差分は最外層に置く

クロスプラットフォームで設定を共有する場合、ノード、プロキシグループ、大部分のドメインルールは共用できます。一方、TUN、プロセスパス、ネットワークインターフェース、LAN 待受、システム DNS の取り込みはデバイスによる差が大きい部分です。プラットフォームに依存しない基盤層を 1 つ用意し、Windows、macOS、Android、Linux には軽量なデバイス別オーバーライドを適用することをおすすめします。こうすれば、あるプラットフォームが認識しない、または不要なフィールドを同じファイルへ詰め込まずに済みます。

たとえばデスクトップではプロセスルールが必要でも、Android ではアプリの機能に応じた処理のほうが適しています。Linux ルーターでは透過プロキシポートを使うことがありますが、通常の Windows デスクトップでは mixed-port または TUN だけで足ります。macOS のネットワーク拡張にはシステムの許可が必要で、設定フィールドだけで承認を代替することはできません。プラットフォームのインストールや権限に関する内容は、クイックスタートとmacOS ネットワーク拡張の設定ガイドを確認してください。YAML だけでシステム要件を回避しようとしないでください。

サブスクリプション更新後の確認リスト

更新完了後は、まずサブスクリプションの取得に成功したことを確認し、次にノード数と名前の構成が想定どおり変化したかを確認します。その後、オーバーライドでエラーが発生していないこと、最終設定に DNS、プロキシグループ、ルールが残っていることを確認してください。最後にカーネルを起動し、待受、DNS 初期化、ルールプロバイダー、プロキシプロバイダーの読み込み状態を確認します。設定の読み込み後はプロキシグループの現在の選択も確認してください。上流でノードが削除されると、保存済みの古い選択が無効になったり、別の項目へ戻ったりすることがあります。

自動更新に失敗しても、間隔を何度も短くして解決しようとしないでください。サブスクリプション URL が有効か、ネットワーク接続にプロキシが必要か、DNS でサブスクリプションサーバーを解決できるか、更新リクエストがプロキシループになっていないか、クライアントがバックグラウンドでシステムに制限されていないかを確認します。詳しくはClash サブスクリプション更新失敗と自動更新の設定を参照してください。クライアントプロジェクトのメンテナンスが終了し、移行が必要な場合は設定エクスポートとクライアント移行チェックリストを確認してください。

元に戻せるメンテナンス方法

毎回、役割が明確な設定セクションを 1 つだけ変更し、直前の動作するファイルを残してください。名前には基盤層、DNS 層、ルール層、デバイス層など用途とプラットフォームを反映できますが、動的な日付や一時的な状態をプロキシグループ名に入れないでください。ルールの参照が頻繁に変わる原因になります。更新前に現在のプロキシ選択を記録し、更新後は重要なドメイン、LAN アクセス、DNS 経路、1 つのプロキシ対象を確認します。テストには直結とプロキシの両方を含め、ウェブページが開くだけで判断しないでください。

オーバーライドが次第に説明しにくくなったら、パッチを追加し続けるのではなく整理する段階です。無効になったルールソースを削除し、役割が重複するプロキシグループを統合し、デバイス固有のフィールドを基盤層から移し、外部プロバイダーごとに用途を記録してください。設定ガイドの目的は利用可能なフィールドをすべて詰め込むことではなく、各リクエストを「入口、DNS、ルール、プロキシグループ、ノード」の経路に沿って明確に説明できるようにすることです。基本設定が完了したら、クイックスタートへ戻って接続を確認するか、よくある質問で症状別に切り分けを続けてください。