Clashの国内・海外向けルール設定ガイド｜国内サイトは直接接続、海外サービスはプロキシ経由

ルール振り分けの前提：ルール、プロキシグループ、通信の取り込み

国内・海外の振り分けは、ページの言語で接続先を判断するものではありません。Clashのコアは接続情報をもとに上から順にルールを照合し、該当するプロキシグループへ通信を振り分けます。ドメイン名、接続先IP、プロセス情報を識別できるかどうかで、最終的な結果は変わります。国内サイトが海外のAPIを呼び出すことも、海外サイトが国内CDNを使うこともあるため、アドレスバーだけで判断せず、接続ごとに確認してください。

この記事の設定例はmihomoコアを使うクライアント向けです。旧バージョンのClashコアや一部のモバイルアプリでは、対応する設定項目が異なります。インポート前に、クライアントのコアに関する説明を確認してください。例ではローカルのルールファイルを使い、リモートルールのダウンロード障害と振り分け設定の誤りを切り分けています。

通信の取り込み：システムプロキシが対象にするのは、プロキシ設定に従うアプリです。TUNを使うと対象範囲を広げられますが、ルーティングや除外設定の影響は受けます。
ルールモード：設定で mode: rule を指定すると、rules の一覧に従って振り分けられます。グローバルモードでは、この記事で説明するルールの適用順を検証できません。
プロキシグループ：通信の出口を選択します。ドメインがグループに一致しても、そのグループでプロキシノードが選択されているとは限りません。
ルールセット：再利用できる照合条件をまとめたものです。ルールセット自体は出口を決めません。出口は、それを参照する RULE-SET ルールで指定します。

メイン設定一式：接続先を明確に定義する

設定例の環境とファイルの配置

この例では、認証不要のSOCKS5上流が 127.0.0.1:1080 で待ち受けているものとします。mihomoの待ち受け先は 127.0.0.1:7890 です。この2つのポートを互いに転送すると、プロキシループが発生します。設定ファイルだけでは、利用可能な上流がない限り海外向けのプロキシ接続はできません。

コアの作業ディレクトリに config.yaml を保存し、rules ディレクトリを作成します。後述する3つのルールファイルも作成してください。デスクトップクライアントでは、コアの作業ディレクトリが独立して管理される場合があります。相対パスの基準はそのディレクトリで、サブスクリプションファイルの保存先とは限りません。

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

proxies:
  - name: ローカル上流
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: 海外プロキシ
    type: select
    proxies:
      - ローカル上流
  - name: 国内直接接続
    type: select
    proxies:
      - DIRECT
  - name: 広告ブロック
    type: select
    proxies:
      - REJECT
      - DIRECT

rule-providers:
  ad-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/ad-domains.yaml
  cn-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/cn-domains.yaml
  overseas-services:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/overseas-services.yaml

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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
  - DOMAIN-SUFFIX,local,DIRECT
  - RULE-SET,ad-domains,広告ブロック
  - DOMAIN,cloud.tencent.com,国内直接接続
  - RULE-SET,cn-domains,国内直接接続
  - RULE-SET,overseas-services,海外プロキシ
  - MATCH,海外プロキシ

サブスクリプションのノードがすでにある場合は、「海外プロキシ」からサブスクリプション内のノードやプロキシグループを参照し、例の「ローカル上流」を置き換えられます。使用中のサブスクリプションに proxies セクション全体をそのまま上書きしないでください。クライアントによっては、サブスクリプションの更新時に設定を書き換えることがあります。継続的に変更する場合は、クライアントが対応するオーバーライドまたはマージ機能で保存してください。設定画面の名称はクライアントのバージョンによって異なります。

例でIPv6を無効にしているのは、初回の切り分け範囲を絞るためです。IPv6を振り分けに使えないという意味ではありません。また、例の上流はUDP転送に対応していません。基本的な動作確認にはブラウザーのTCPリクエストを使えますが、ゲーム、音声通話、QUICについては、上流のプロトコルと通信の取り込み方法を別途確認してください。

ルールファイルの書き方：domainとclassical

広告ドメインのルールファイル

以下の内容を rules/ad-domains.yaml として保存します。behavior: domain ではドメイン一覧の形式を使い、プロキシグループ名や DOMAIN-SUFFIX, の接頭辞は記述しません。ここでの +. は、ドメイン自体とサブドメインの両方に適用されることを表します。

payload:
  - '+.doubleclick.net'
  - '+.googlesyndication.com'

広告ルールは、元に戻せる状態にしておきましょう。サイトによっては、関連ドメインに計測、ログイン、再生用のAPIを置いているため、ブロック範囲を広げるとページの一部が表示されなくなることがあります。誤検知と分かった場合は、まず「広告ブロック」を DIRECT に切り替えて確認し、対象ドメインに例外を追加してください。最初から振り分けルールをすべて削除するのは避けましょう。

国内向けドメインのルールファイル

以下の内容を rules/cn-domains.yaml として保存します。この一覧が対象にするのは、記載されたドメインとその配下だけです。国内サイトすべてを自動判定するものではありません。ドメインを追加する際は、接続パネルで実際のリクエストを確認し、アドレスバーに表示されたドメインだけでページ内の全リソースの配信元を判断しないでください。

payload:
  - '+.baidu.com'
  - '+.bilibili.com'
  - '+.bilibili.tv'
  - '+.qq.com'
  - '+.tencent.com'
  - '+.jd.com'
  - '+.taobao.com'

ドメインの分類はルーティングの方針を示すものであり、サーバーの物理的な所在地を証明するものではありません。同じブランドでも、サービスごとに異なる地域へ配置されることがあります。海外向けサービスをプロキシ経由にする場合は、対象サービスのより具体的なドメインルールを追加し、ブランド全体に適用する直接接続ルールより前に配置してください。

海外サービスのルールファイル

以下の内容を rules/overseas-services.yaml として保存します。behavior: classical にはルールタイプを含む項目を記述できますが、項目の末尾にプロキシグループ名は書きません。参照するメイン設定で「海外プロキシ」を指定しています。

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,githubassets.com
  - DOMAIN-SUFFIX,wikipedia.org
  - DOMAIN-SUFFIX,wikimedia.org

GitHubのウェブページ、Rawコンテンツ、静的リソースのドメインを分けて記載することで、特定のリソースだけ接続先を変更しやすくなります。最終ルールの MATCH でもこれらの通信はプロキシに振り分けられますが、明示的なルールを設ける意味はあります。ログで一致したルールセットを確認でき、後から最終ルールを変更しても、これらのサービスの接続先は変わりません。

ルールの適用順：最初に一致したルールで接続先が決まる

ルールが自動的に「より具体的なものから優先」されることはありません。DOMAIN による完全一致ルールで広範囲のルールを上書きするには、前に配置する必要があります。ルールセット同士の競合も自動では解決されません。同じドメインが広告用と国内直接接続用の両方に含まれている場合、先に評価されるルールセットで結果が決まります。

順序	照合対象	この位置にする理由
1	ループバックアドレスとプライベートIPv4アドレス	ローカルサービスと一般的なLAN内の接続先を優先的に直接接続する
2	広告ドメインセット	広告と確認できたリクエストを優先してブロックする
3	特定サービスの例外	後続の広範囲なドメイン分類を上書きする
4	国内ドメインセット	明示した国内サービスを直接接続する
5	海外サービスセット	プロキシ経由にするサービスを明示する
6	MATCH	それまでのルールに一致しない接続をすべて処理する

例外ルールは、上書き対象のルールより前に配置する

メイン設定の cloud.tencent.com は、特定サービス向けのルール例です。このドメインは +.tencent.com にも一致するため、現在の接続先は変わりません。特定のサービスをプロキシ経由にする場合は、Tencentのドメイン全体をプロキシグループへ移すのではなく、この完全一致ルールのプロキシグループを「海外プロキシ」に変更してください。

広告ルールに許可例外を追加する場合は、広告ルールセットより前に配置します。反対に、MATCH,DIRECT を最初に置くと、後続の広告、国内、海外向けルールは評価されません。最終ルールは必ず最後に置いてください。

ルールの更新とGEOIPの追加：誤判定の範囲を広げない

ローカルファイルからHTTPルールソースへ切り替える

ローカルの type: file ルールセットは、指定した間隔で自動更新されません。自動更新するには type: http を使い、アクセス可能なHTTPSルールのURL、キャッシュ用の path、更新間隔の interval を設定します。たとえば interval: 86400 は86400秒、つまり24時間ごとの確認を意味し、毎日決まった時刻に更新されるわけではありません。

リモートのルールソースを選ぶ際は、まず内容の形式を確認してください。behavior: domain はドメイン一覧、behavior: classical はルールタイプ付きの項目に対応します。format: yaml を指定する場合は、payload を含むYAMLファイルが必要です。ウェブページのプレビューURL、サブスクリプション設定全体、バイナリ形式のルールファイルは、同じYAMLルールソースとして扱えません。ダウンロードに成功しても、内容の形式が違えば読み込みに失敗します。

ルールソースが提供するのは照合条件だけです。内容を確認していない設定全体で、現在のサブスクリプションを置き換えないでください。
初回導入時は手動で更新してログを確認してから、定期更新に切り替えます。キャッシュが必ず存在するとは限らないため、前提にしないでください。
リモートのリストを拡張した後は、広告ルール、サービスごとの例外、国内直接接続ルールの重複範囲を再確認してください。

GEOIP CNは補助として使う

コアに必要なGeoIPデータを用意できている場合は、MATCH の前に GEOIP,CN,国内直接接続 を追加すると、ドメインルールに一致しない接続を中国のIPアドレスとして分類できます。ただし、接続先IPとデータベースに依存するため、サービスごとのドメイン分類の代わりにはなりません。海外サービスが中国国内のCDNを使っていれば直接接続に分類される場合があり、中国のサービスが海外のIPアドレスを使っていればプロキシ経由のままになることもあります。

no-resolve を付けると、たとえば GEOIP,CN,国内直接接続,no-resolve の場合、ルール照合だけを目的にドメインを能動的に名前解決しません。その時点で照合に使える接続先IPがない場合、ルールが適用されないことがあります。ルール照合に伴う一部の名前解決を抑える機能であり、「国内向けサービスをより正確に判定する」設定ではありません。基本的な振り分けを先に検証できるよう、メイン設定ではGeoIPに依存していません。

検証とトラブル対処：まずルールの一致、その次に接続結果を確認

設定を4つの手順で確認する

構文とファイルを確認する。mihomoのコマンドラインを使う場合は、例のディレクトリで mihomo -t -d . -f config.yaml を実行します。デスクトップクライアントでは設定の検証機能を使い、3つのローカルルールファイルが読み込まれていることを確認してください。
通信が取り込まれていることを確認する。システムプロキシを有効にするか、下記のプロキシを明示したコマンドを使います。コマンドでは接続できるのにブラウザーの接続パネルに記録がない場合は、ルールを変更する前にブラウザーのプロキシ設定を確認してください。
現在のプロキシグループを確認する。ルールモードになっていること、「海外プロキシ」で利用可能な上流が選択されていること、「広告ブロック」で REJECT が選択されていることを確認してください。
接続し直してテストする。ルールを変更したら、既存の接続を終了してから再テストしてください。ブラウザーが古い接続を再利用することがあり、プロキシグループを切り替えても確立済みのセッションの接続先がすぐに変わるとは限りません。

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://github.com
curl -I --proxy http://127.0.0.1:7890 https://www.wikipedia.org

Windowsで curl が別のコマンドに割り当てられている場合は、curl.exe を使ってください。これらのコマンドは7890番ポート経由のリクエストをテストするものです。TUNによる通信の取り込みは検証できず、HTTPステータスコードだけでサイトの全リソースが利用可能だとは判断できません。

ルールの一致記録から問題を特定する

テスト対象	想定ルール	想定される接続先
www.baidu.com	cn-domains	国内直接接続 → DIRECT
github.com	overseas-services	海外プロキシ → ローカル上流
www.wikipedia.org	overseas-services	海外プロキシ → ローカル上流
ad.doubleclick.net	ad-domains	広告ブロック → REJECT

上の表は例の設定に基づく想定結果であり、速度や利用可能性を保証するものではありません。広告ドメインの確認では、ページが表示されるかではなく、どのルールで接続が処理されたかを確認します。ルールとプロキシグループが想定どおりなのにアクセスできない場合は、ルールの順序を繰り返し変更するのではなく、上流への接続、接続先サービス、DNSを確認してください。

DNSとTUNで起きやすい問題

ドメインルールを適用するには、コアがドメイン名を取得できる必要があります。アプリがIPアドレスへ直接接続する場合、ブラウザーが独自の暗号化DNSを使う場合、TUN環境でDNSの通信経路を正しく取り込めていない場合は、ドメインを識別できないことがあります。fake-ip は仮想IPアドレスとの対応付けによってドメインとの関連付けを補助できますが、クライアントのDNS設定、TUNのDNSリダイレクト、通信の除外設定と合わせて確認してください。項目を1つ変更するだけで、すべてのリクエストがドメイン名で照合されるわけではありません。

ログだけでは原因を特定できない場合に限り、一時的に log-level を debug に変更し、確認後は info に戻してください。ログを共有する前に、サブスクリプションURL、認証情報、個人のアクセス履歴を削除します。最終確認では、通信がコアに届いていること、想定したルールに一致していること、選択した接続先が利用可能であることをそれぞれ確認してください。3つすべてを満たせば、国内・海外向けのルール設定は完了です。