なぜ「ルール分流」が速度の両立に効くのか

プロキシを一本化してすべての通信を遠方のノードへ送ると、地理的に近いサーバへ行くはずのトラフィックまで遠回りします。 たとえば動画 CDN や国内サービスは、意図せず海外出口から戻ってくるだけで往復が伸び、体感では「回線が遅い」より前に 経路が非効率 に見えてしまいます。

Clash 系クライアント（Mihomo／Meta カーネルを含む）は、YAML の rules で接続先ごとに出口を切り替えられます。 ここでいう分流とは、国内向けは DIRECT（直結）、海外向けや必要なドメインだけを PROXY グループへ という整理のことです。 ルールは上から評価されるため、「並べ順＝設計図」だと考えると設定の感触が掴みやすくなります。

本記事では、購読 URL から入ったテンプレートを前提に、どこを見直せば 国内の応答性 と 海外サイトの安定性 のバランスが良くなるかを順にまとめます。 特定のプロバイダ名や違法利用を前提にはしません。社内検証、開発環境、プライバシー保護など、正当な用途での参考にしてください。

先に押さえるコツ：速度優先なら、まずクライアントのモードが Rule（ルール） になっているかを確認します。 Global のままだと design した分流が効かず、国内サイトまで中継される典型パターンになります。

モードの選び方：Rule が起点

代表的なモードは名前こそ実装差がありますが、概念としては次の整理ができます。 Direct は事実上すべて直結、Global は既定のプロキシへ寄せる、Rule はルール列を評価して出口を決める、というイメージです。

「国内は速く、海外だけトンネル」という目的では、日々の既定を Rule に置くのが第一歩です。 トラブル調査のときだけ一時的に Global で切り分ける、という運用はよく行われますが、常時 Global にしておくと CDN 選択やピアリングの有利さを活かしにくくなります。

GUI によっては「システムプロキシ」「TUN」「メタルール」など複数のスイッチが並びますが、分流の肝は rules: の評価です。 TUN はキャプチャ範囲を広げる要素であり、Rule モードと対立する概念ではありません。

ルールの順序設計：早めに「確定」を置く

ルール評価は基本的に先勝ちです。したがって、誤中しやすい広い条件を先頭に置くと、下に書いた細かい例外が一生届きません。 典型的には、次のような並べ方が読みやすく、速度面の事故も起きにくいです。

  1. 社内ドメイン、イントラ向けホスト名、検証用の固定 IP／ドメインなど、絶対に直結させたい少数
  2. サブスク提供者が用意する「広告ブロック」「危険ドメイン」などの専用ポリシー（必要なら）
  3. 海外必須サービスを DOMAIN-SUFFIX や DOMAIN-KEYWORD で明示
  4. GEOIP,CN,DIRECT のような地域まとめ（購読テンプレートに含まれることが多い）
  5. 最後に MATCH で、ここまで来たトラフィックを既定のプロキシグループへ

MATCH の行き先が強すぎると、想定外のドメインもすべて海外ノードへ流れます。 逆に GEOIP,CN が古い／誤分類だと、国内資源でも DIRECT が選べないケースが出ます。 このギャップを埋めるのが、問題のあるドメインだけ上に DOMAIN ルールで足す運用です。

プライベートと LAN：192.168.0.0/16 や 10.0.0.0/8 などは誤って中継しないよう、多くのテンプレで先頭付近に DIRECT が並びます。 社内 VPN と併用する場合は、このブロックが期待どおり残っているかに注意してください。

中国圏を DIRECT に寄せる：GEOIP と現実のズレ

中国本土向けの多くの購読テンプレは、GEOIP,CN,DIRECT あるいは同等の意味を持つルールセットを同梱します。 これにより、国内のコンテンツ配信や一般的な Web サービスは、余計な RTT を増やさずに済みやすくなります。

ただし GEOIP データベースは更新タイミングや境界定義の影響を受けます。 一部のクラウドフロントは地域表示と実ノード位置が一致しないこともあり、「理屈では海外だが事実上国内ユーザー向け」なドメインはルールだけでは割り切れません。 そのようなときは、ログで遅延が出ているホスト名を特定し、DOMAIN 系の明示行 を追加するのが現実的です。

参考までに、ルールのイメージだけ示します（グループ名は環境で読み替えてください）。 

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

実際の購読では PROXY の代わりに 🚀 节点选择 のような表示名や、url-test グループ名が入ります。 重要なのは、MATCH が指している実体が本当に意図したグループか を GUI 上で確認することです。

DNS と fake-ip：ルールが「名前」で効く理由

ドメイン行のルールは、クライアントが名前解決と接続をどう扱うかとセットで理解すると安全です。 enhanced-mode: fake-ip を使う構成では、多くの場合ローカルで早い仮想的な応答を返し、その後の実接続で出口判断が固まる、といった流れになります（実装・版により細部は異なります）。

DNS の上流が遅い／不安定だと、ブラウザの最初のタイムラインだけが伸びて「プロキシが遅い」ように見えることがあります。 そのため nameserver には応答の速い信頼できる場所を、fallback にはフィルタされにくい場所を置く、といった二段構えがテンプレに入っていることが多いです。

ルールが効かないと感じたら、まず「そのホスト名がルール評価に届いているか」「解決結果が期待と一致しているか」をログで確認してください。 fake-ip と行き先ルールの組み合わせは強力ですが、上流 DNS のポリシーやハイジャック設定 が噛み合わないと、意図しないフォールバックに落ちます。 

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query

プロキシグループ：海外側の速度は「入口設計」で決まる

海外向けに単一ノードを直に指すより、url-test や fallback を挟むと、輻輳時の切り替えが楽になります。 ルールの最終行が MATCH,自動選択 のようになっている場合、その自動選択の中身が貧弱だと海外サイト全体が遅く感じます。

url-test では、計測 URL と間隔、許容タイムアウトがそのまま運用体感に直結します。 あまりに短い間隔は CPU と帯域を食い、長すぎると切り替えが遅れます。購読テンプレの既定を一度尊重し、詰まりを感じた箇所だけ調整するのが現実的です。 

proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - HK-1
      - JP-1
      - US-1
    url: http://www.gstatic.com/generate_204
    interval: 300

ルール側が AUTO-BEST を指せているかを揃えることが重要です。グループ名は一文字違いでも別物になり、結果として MATCH の大穴に落ちて意図しない経路へ流れる、というミスが起きがちです。

システムプロキシと TUN：分流の適用範囲

システムプロキシは HTTP(S) aware なアプリへ効きやすく、日常のブラウジングと相性が良いです。 一方、プロキシ非対応で Raw ソケットを張るソフトはTUN 側でキャプチャしないとルールの外に出ます。

「国内は直結なのに、特定アプリだけ遅い」場合、アプリがプロキシを見ていない可能性があります。 そのときに TUN をオンにすると、同じ Rule 設定のまま適用範囲だけが広がります。ドライバや権限の要件は OS ごとに異なるため、クライアントの公式手順に従ってください。

注意：TUN と他社 VPN、社内エンドポイント保護、仮想スイッチが競合すると、分流どころか接続不能になります。 併用時はルートテーブルや優先 NIC の順を意識し、問題が出たら一時的にキャプチャ手段を切り分けてください。

体感速度を詰める：ルール以外のチェックポイント

ルールが正しくても、ボトルネックはTLS握手、MTU、輻輳、DNS TTL、ブラウザの並列数など多岐に渡ります。 ここでは分流文脈で効きやすい項目だけ列挙します。

  • 測定の場所：遅延テスト URL が自宅から不安定な経路しか持たないと、常に悪いノードが選ばれます。複数 URL を試す価値があります。
  • プロトコルと輸送：TCP と QUIC、UDP の扱いは実装差があります。特定サイトのみ遅いなら、そのサイトが QUIC を好むかも含めて切り分けます。
  • ログの読み方：接続が DIRECT か PROXY か、どのルール行に当たったかが分かるログを一度は確認すると、思い込みが減ります。
  • 更新頻度：購読と GEOIP 類の更新が止まると、少しずつズレが蓄積します。手動更新のクセを付けると安心です。

よくあるつまずき（早見）

サポートやコミュニティで繰り返し見る論点を、症状ベースで短くまとめます。

症状 ありがちな原因 試すこと
国内動画やポータルが遅い Global 固定／広い PROXY が先頭 Rule 固定、GEOIP より上のルール順を精査
海外だけタイムアウト ノード輻輳、測定 URL 不適合 別リージョン、url-test パラメータ見直し
特定ドメインだけ挙動が変 GEOIP と実態の不一致 DOMAIN 明示ルールを上に追加
ルールを変えたのに効かない プロファイル未再読込、複数設定の取り違え アクティブな構成を GUI で再確認

よくある質問

代表的な疑問を Q&A 形式で整理しました。ここに書いた内容と、ページ先頭の構造化データは対応しています。

Rule なのに国内まで海外へ流れるのは？

ルール順か DNS が第一疑いです。広い条件が先に当たっていないか、fake-ip とドメインルールの整合を確認してください。

Global と Rule の違いは？

Global は基本的に一つの出口へ寄せ、Rule は接続ごとに出口を切り替えられます。分流の旨味は後者にあります。

GEOIP は完ぺき？

データ更新と例外があるため、重要ドメインは DOMAIN で補強するのが安全です。

DNS を触ったら壊れた

上流と enhanced-mode を段階的に戻し、実効設定を見ながら最小差分で直してください。

TUN とシステムプロキシはどちら？

ブラウザ中心なら後者、アプリ全体なら前者、という粗い分けで考えるとよいです。

海外が遅いときルール以外は？

ノード品質、輸送、TLS、測定 URL を疑い、fallback を用意してください。

まとめ：仕様が見えるクライアントに寄せる理由

ルール分流は YAML の数行というより、運用で育てる設計 に近いです。 GEOIP の更新、例外ドメインの追加、DNS の見直し、プロキシグループの冗長化——どれも日々の小さな差分の積み重ねです。

一方で、「設定画面が貧弱でログが読めない」「由来の曖昧な再パッケージに固定」という環境だと、ボトルネックがどこかすら分からず時間だけが溶けます。 名称だけ新しい単体ツールに頼ると、分流ルールと購読の更新が分散し、不整合で逆に遅くなることも珍しくありません。

Clash／Mihomo 系は、ルール・購読・プロキシグループ・DNS を同じコンフィグ空間に載せられるため、経路の可視化と修正のコストが低い のが強みです。 rule-mode と url-test、DOMAIN 例外を組み合わせれば、国内の直結メリットを活かしつつ、海外だけを切り替え可能な出口に寄せる運用が現実的になります。 クライアント入手と更新経路を公式に揃えておくと、カーネル追随やGUI差異にも振られにくくなります。 端末側を一度まとめたい場合は、当サイトの 公式ダウンロードページ から、利用 OS に合ったビルドを選ぶのが安全です。

Clash クライアントを無料ダウンロード