設定の構造：参照関係を確認してから項目を編集

Clashの設定ファイルは、単なるノード一覧ではありません。ポートはアプリからコアへ接続を渡す方法、DNSはドメイン名の解決方法、ノードはリモート接続のパラメーターを定義します。プロキシグループが接続先をまとめ、ルールが通信を振り分けます。FlClashで使われるClash Metaコアは、mihomoとも呼ばれます。この記事ではこのコアの設定を解説します。古いコアでは一部の項目に対応していない場合があります。

覚えておきたい基本の関係は、ルールがプロキシグループを参照し、プロキシグループがノード名または組み込みの接続先を参照することです。たとえば、ルールで通信を「手動選択」に渡し、グループ内で「サンプルノード」か DIRECT を選びます。名前は完全に一致させてください。空白が1つ違うだけでも参照先が見つからなくなることがあります。

  • proxies：ノードの一覧です。プロトコル、サーバー、ポート、認証情報を記述します。
  • proxy-groups：プロキシグループの一覧です。選択できる接続先と選択方法を記述します。
  • rules：順序に従って照合するルールの一覧です。通信をどの接続先に渡すかを決めます。
  • dns と tun：それぞれ名前解決と仮想ネットワークインターフェースによる通信の取り込みを担います。どちらもノードそのものではありません。

基本項目：ポート・モード・ログ

まずはトップレベルの項目を見ていきます。次の例では、HTTPプロキシとSOCKS5の両方を受け付けるローカルの混合ポートを設定しています。ここでの 7890 は例であり、すべてのサブスクリプションやクライアントで同じポートが使われるとは限りません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
項目設定例役割
mixed-port78901つのポートでHTTPプロキシとSOCKS5プロキシを受け付けます。
allow-lanfalseこのプロキシの接続口を、LAN内で共有する目的には使用しません。
moderuleすべての通信にグローバル選択を適用せず、ルールに従って接続先を選びます。
log-levelinfo通常の動作情報を記録します。トラブルシューティング時は、一時的にdebugへ変更できます。
ipv6falseコアでのIPv6利用を制限します。OSのIPv6機能を無効にする設定ではありません。

プロキシのポートとノードのポートは別

ローカルのアプリは 127.0.0.1:7890 に接続します。一方、リモートノードのポートは 443 など、サーバー側で指定された番号です。両者を同じにする必要はありません。port はHTTPプロキシ、socks-port はSOCKSプロキシの接続口を個別に設定できます。混合ポートを使う場合、「設定をそろえる」ためだけにすべての待ち受け項目を追加する必要はありません。

設定の読み込みに成功したら、curl -I -x http://127.0.0.1:7890 https://example.com を実行し、プロキシの接続口が接続を受け付けるか確認できます。このコマンドでテストできるのはHTTPリクエストの経路です。UDPやTUN、すべてのアプリが取り込まれていることまでは確認できません。接続拒否と表示された場合は、実際の待ち受けポートとコアの稼働状況を確認してください。

DNS設定：名前解決とFake-IP

DNS設定では、ドメイン名をコアにどのように解決させるかを指定します。以下は動作を理解するための最小例です。ローカルの 1053 ポートで待ち受け、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
  nameserver:
    - https://1.1.1.1/dns-query

1053番ポートの待ち受けとシステムDNSは別の設定

listen は、コアがDNSサービスを提供するための項目です。この項目を設定しただけでは、システムDNSの接続先は自動で切り替わりません。一般的なシステムDNSの設定では、ポート番号を含むアドレスを指定できないこともあります。システムDNSの通信を取り込めるかどうかは、TUNのDNSハイジャック、システムのネットワーク設定、実際のルーティングにも左右されます。

Fake-IPは実在するサーバーのアドレスではない

198.18.0.1/16 は、コア内で仮想アドレスの対応付けに使われます。アプリがこの対応アドレスを受け取ると、コアは保存されたドメイン名との関係を使って、ルールの照合と接続の確立を続けます。このアドレス帯が表示されても、すぐに名前解決のエラーと判断する必要はありません。通信が同じコアに戻っているか、対応関係が有効なままかを確認してください。

  • dns.ipv6: false は、呼び出し元にAAAAレコードを返さない設定です。トップレベルの ipv6 とは適用範囲が異なります。
  • nameserver は主要な上流DNSを指定します。ドメイン名を含む上流DNSを使う場合は、そのドメイン名自体を最初に解決する方法も考慮してください。
  • ノードの server にドメイン名を指定する場合も、名前解決が必要です。複雑な構成では、ノードのドメイン名を解決する上流DNSを proxy-server-nameserver で個別に指定できます。
  • 上流DNS、Fake-IPフィルター、TUNのハイジャックを一度に変更しないでください。一度に1項目だけ変更すれば、問題の原因を特定しやすくなります。

proxies：ノードのパラメーターをサーバー設定に合わせる

proxies はノードのリストで、各ノードは - name: から始まります。プロトコルごとに必要な項目は異なります。Shadowsocksのパスワードと暗号化方式を、UUIDやTLSの設定が必要な別のプロトコルにそのまま流用することはできません。以下ではShadowsocksノードの項目構造だけを示します。

proxies:
  - name: "サンプルノード"
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "yaml-demo-password"
    udp: true

name はプロキシグループから参照するローカル名で、日本語も使用できます。server はリモートサーバーのアドレスです。udp: true はノード設定でUDPを有効にしますが、サーバー、回線、アプリのすべてがUDP転送に対応することを保証するものではありません。

サービス提供元から完全なClashサブスクリプションを受け取っている場合、通常はノード情報も含まれているため、手動で書き直す必要はありません。もう1つよく使われる構成が proxy-providers です。ノードをプロバイダーで管理し、プロキシグループから use でプロバイダー名を参照します。プロバイダー名をノード名と取り違えて、グループ内の proxies リストに直接入れないでください。

proxy-groups：ノードをプロキシグループにまとめる

ノードを定義したら、次にプロキシグループを作成します。select はグループ内の接続先をユーザーが手動で選ぶ設定です。参照が正しいか確認するときに適しています。以下の「手動選択」には、サンプルノードと直接接続の両方を指定しています。

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

DIRECT は組み込みの直接接続先なので、トップレベルの proxies に記述する必要はありません。REJECT も組み込みの接続先で、通信を拒否します。独自のグループ名にはこれらの組み込み名を使わず、ノード名とプロキシグループ名を同じにすることも避けてください。

自動速度測定はダウンロード速度の測定ではない

url-test プロキシグループは、設定された確認先と間隔を使って候補となる接続先の応答遅延を比較します。たとえば interval: 300 は300秒間隔での確認を意味し、tolerance: 50 では切り替えの許容差をミリ秒単位で設定できます。測定結果は確認先のサイトや回線の影響を受けるため、大容量ファイルのダウンロード速度にそのまま換算することはできません。

初回の動作確認では、まず手動選択のグループを1つだけ使いましょう。ノードへの接続とルールの参照が正しいことを確認してから、自動選択やフォールバックを追加します。複数のプロキシグループを相互に参照することはできますが、AがBを参照し、BがAを参照する循環依存は避けてください。

rules：上から順に照合し、最初に一致したルールを適用

mode: rule では、通常、ルールを上から順に照合し、一致した時点で指定された接続先に通信を渡します。詳細なルールを先に置き、最後にフォールバック用のルールを置いてください。以下のドメインは照合範囲の説明用であり、特定のサイトを直接接続またはプロキシ接続すべきという意味ではありません。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,手動選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,手動選択
  • DOMAIN,example.com：この完全一致のドメインに適用します。www.example.com は自動的には含まれません。
  • DOMAIN-SUFFIX,example.org：指定したドメインとそのサブドメインに適用します。任意の文字列に対する部分一致ではありません。
  • IP-CIDR：宛先IPアドレスの範囲で照合します。例には2つのプライベートアドレス範囲を記載していますが、LAN内のアドレス範囲をすべて網羅しているわけではありません。
  • no-resolve：このIPルールのためにドメイン名を能動的に解決するのを避けます。接続全体でDNSが不要になるという意味ではありません。
  • MATCH：上のルールに一致しなかった通信をすべて受け取ります。先頭に置くと、後続のルールが照合されなくなります。

ルールが適用されない場合は、まずモードと新しい接続を確認

クライアントがグローバルモードの場合、ルールモードで想定した結果にはなりません。ルールモードに切り替えたうえで、接続ログに表示される宛先ドメイン、適用されたルール、実際の接続先を確認してください。利用可能なドメイン情報がなくIPアドレスだけの接続では、想定したドメインルールに一致するとは限りません。

ルールや選択先を変更した後は、新しい接続でテストしてください。ブラウザーが既存のTCP接続やQUIC接続を再利用することがあります。設定を書き換えても、既存の接続が新しいルールに合わせて自動的に作り直されるわけではありません。必要に応じて該当する接続を閉じてから再試行し、同じセッションを何度も再読み込みするだけで済ませないようにしましょう。

TUN：通信の取り込み口であり、ルールやDNSの代わりではない

TUNモードでは、仮想ネットワークインターフェースを通じて通信をコアに渡します。システムプロキシの設定を参照しないアプリで役立ちます。mixed-port とは異なる接続方式ですが、取り込んだ通信の接続先は、引き続きプロキシグループとルールで決まります。以下は無効のまま、mihomoでよく使われる項目の構造だけを示します。

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

auto-route はルートの自動設定に、auto-detect-interface は出力インターフェースの自動検出に使います。対応状況や動作はシステムとコアのバージョンによって異なります。dns-hijack の any:53 は取り込んだ通常のDNS通信を処理する設定です。これを根拠に、アプリ内蔵のDoHやすべての暗号化DNS通信も取り込めるとは言えません。

TUNを有効にするには、通常、システムの許可が必要です。FlClashの画面上のスイッチが最終的な設定の生成に関わる場合もあるため、サブスクリプション内の enable だけで実行状態を判断しないでください。仮想ネットワークインターフェース、ルート、クライアントの状態、接続ログをあわせて確認しましょう。システムで他のVPNも動作している場合は、最初に現在の状態を記録し、1つずつ無効にして比較してください。通信の取り込み口を同時に複数変更しないようにします。

インデントの確認と最小構成の設定例

YAMLではインデントで構造を表します。半角スペース2つに統一し、Tabは使わないことをおすすめします。トップレベルの dns、proxies、proxy-groups、rules は同じ位置にそろえます。同じノード内の type、server、port も同じ階層に配置してください。

  1. コロンの後のスペースを確認します。mode: rule はキーと値の形式です。mode:rule は通常の文字列として扱われる場合があります。
  2. リストのハイフンを確認します。ノード、グループ内の候補、ルールはいずれもリストですが、それぞれ所属する階層が異なります。
  3. 特殊文字を確認します。パスワードや名前に # や「コロンの後にスペース」などが含まれる場合は、適切な引用符で囲んでください。ダブルクォートで囲んだ文字列では、バックスラッシュのエスケープにも注意が必要です。
  4. キーの重複を確認します。ファイルの末尾に2つ目のトップレベル rules を追加しないでください。既存のリストにルールをまとめます。キーが重複するとエラーになったり、設定が上書きされたりすることがあります。
  5. 参照する名前を確認します。「手動選択」と「手動選択 」は別の名前です。ノード名やプロキシグループ名を変更した場合は、参照している箇所もあわせて変更してください。

まず直接接続の構成を確認し、その後で実際のノードを追加

以下は単独で使える最小構成の設定例で、すべての通信が最終的に直接接続されます。リモートプロキシ機能はありませんが、ローカルコピーでポート、プロキシグループ、ルールの基本構造を確認するのに使えます。普段使っている設定を上書きして、サブスクリプションの代わりにしないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

単独のmihomoプログラムを使う場合は、mihomo -t -f ./config.yaml を実行して指定ファイルを検査できます。検査に通っても、コアが設定を読み込めることが分かるだけです。ノード認証が正しいこと、上流DNSに接続できること、ルートが適用されていることまでは確認できません。FlClashで管理している設定は、クライアント内で再読み込みして実際のエラーを確認してください。

設定を続ける場合は、高度な設定の解説でプロキシグループ、ルール、TUNの関係を確認できます。サブスクリプションのインポートから始める場合は、設定ガイドに沿ってインポートとモード選択を進めてください。設定ファイルに記述されている内容だけでなく、クライアントの実際の動作状態と接続ログも確認しましょう。