プロキシを一つ入れると「海外サービスは快適になったのに、国内のポータルや決済だけ妙に遅い」という体験をしたことがある方は少なくありません。原因の多くは、すべてのトラフィックを同じ出口に押し込んでいることか、ルールの並びが意図とズレていて国内通信まで迂回していることのどちらかです。Clash 系クライアント（Mihomo／Meta コアを含む）では、RULE モードを軸にドメインや IP の属性ごとに出口を切り替えられるため、「国内・生活圏の通信は素早く直結、越境だけプロキシ」というルール分流が現実的な運用になります。この記事では抽象的な用語に終始せず、評価順・代表的なマッチャー・DNS との関係までを一続きの設計図として整理します。

なぜ国内外で経路を分けるのか

プロキシ経由は往復ホップが増え、地理的にも論理的にも「遠回り」になりがちです。動画や大容量転送では帯域制限やピーク時の混雑も乗りやすく、結果として国内向けだけ応答が悪化します。一方、検閲や帯域制御、サービス区域の都合で海外サイトだけ出口を変えたい場面も多いです。ルール分流は、この二つの要求を同時に満たすための仕組みです。ポイントは「すべての通信を平均的に扱わない」ことであり、ビジネス利用でも個人利用でも、例外を明示し、残りをまとめて処理する書き方が長期的に壊れにくいです。

RULE・GLOBAL・DIRECT の使い分け

多くの GUI にはモード切替がありますが、実務の主役は RULE です。GLOBAL はトラブルシュートや「とにかく一つのノードに全部流して比較したい」検証向けで、日常運用に据えると国内外の差が消え、帯域の無駄が増えやすいです。DIRECT は意図的にプロキシを外すモードですが、運用ではルールのなかで DIRECT ポリシーを指すほうが柔軟です。つまり日常は RULE に固定し、構成ファイルの rules: が実際の振り分け表になる、と考えると迷いが減ります。

ルールは必ず上から評価される

Clash 系のルールエンジンは、一般にリストの先頭から順にマッチを探し、最初に当たった行で決定します。したがって、「国内を DIRECT にしたい」のに、その手前で広すぎる DOMAIN-SUFFIX や誤った MATCH 相当が先に来ていると、望まない出口に吸い込まれます。逆に、細かい例外をrules の上位に置き、最後に「残り全部 PROXY」の一行で締めるパターンは、可読性とデバッグの両面で扱いやすいです。購読プロファイルが巨大なルールセットを差し込む場合も、カスタム追記の位置が挙動を左右するため、フロントエンドの「ルールの結合順」を確認できるクライアントほど運用が楽になります。

主要なマッチャーと典型用途

実務で頻出するのは次のタイプです。名称はコア実装やバージョンで一部拡張がありますが、考え方は共通です。

  • DOMAIN：ホスト名が完全一致するとき。API エンドポイントなど狭い範囲をピンポイントで指定したい場合に有効です。
  • DOMAIN-SUFFIX：.example.com のように接尾辞一致。サブドメインをまとめて扱えますが、suffix を広げすぎると意図しないサイトまで巻き込みます。
  • DOMAIN-KEYWORD：ホスト名に語が含まれるか。手早い反面、誤爆しやすいので補助的に留めるのが無難です。
  • IP-CIDR / IP-CIDR6：名前解決後や接続先が IP で判明した段階で効きます。CDN の一例のように「解決結果によって国内外が切り替わる」サイトでは、ドメインルールと併用すると安定します。
  • GEOIP：割り当て国コードで振り分け。国内外の大枠を一気に作れる一方、データ鮮度と例外 IP に眼界があります。
  • MATCH（および同等の最終行）：どの行にも当たらなかった通信の受け皿。フォールバック先として必ず意識しておきます。

日本在住の利用者であれば、国内の金融・公共系、ローカル CDN、社内ドメインなどを DIRECT に寄せ、海外クラウドやグローバル SaaS を PROXY 側へ。中国本土のネットワーク構成でよく見る購読では GEOIP,CN を DIRECT にする行が先に来る例も多く、「自国／生活圏をまず直結に逃がす」という発想は地域を問わず共通です。

「国内直結・海外プロキシ」の骨格を組む

典型的な骨格は次の三段です。(1) ループバックやプライベート帯域を DIRECT、(2) 明示したいドメインや自国 GEOIP を DIRECT または国内向け専用ポリシー、(3) 残りを PROXY などにフォールバック。ここで PROXY は必ずしも固定文字列ではなく、設定内のプロキシグループ名に合わせる必要があります。名前の不一致は「ルールはあるのに接続できない」原因の首位なので、GUI のグループ名と YAML を突き合わせてから本番運用に入ってください。

サブスクリプションがすでに膨大な RULE-SET を読み込む構成の場合、追記は短く保ち、「自宅 NAS のドメインだけ先頭に足す」「測定用だけ一時的に DIRECT」など、差分として説明可能なものに留めると、プロバイダー側の更新と衝突しにくくなります。

GEOIP を信用しすぎないための実務知識

GEOIP は便利ですが、データベースの版とコアの読み込みパスがズレていると、見かけ上ルールは効いているのに実態は古い国コード判定、ということが起きます。また CDN のエッジは国籍と一致しないことがあり、「国内ドメインなのに海外 AS の IP」みたいなケースでは DOMAIN ベースの行のほうがユーザー体感に忠直です。運用上は、問題のドメインだけログから IP を抜き出し、一時的に IP-CIDR で矯正する、という筋道がよく使われます。

ヒント：接続ログに表示されるルール名をスクショで残しておくと、のちの設定レビューで「誰が勝ったか」が一目で追えます。感覚で順序を入れ替える前に、一度事実を固定しましょう。

プロキシグループとポリシー出力の対応

ルールの各行は最終的に DIRECT、REJECT、または任意名のプロキシグループを指します。select 型のグループなら GUI でノードを選び直せますし、url-test なら遅延の良い行へ自動寄せできます。国内外分流の文脈では、「国内決済用は DIRECT 固定」「海外探索用は自動選択」のように、用途単位でグループを分けてルールから叩くと安全です。逆にグループが増えすぎると設定が霧散するので、まずは PROXY と DIRECT の二本立てから始め、本当に必要な分岐だけ増やすのが現実的です。

DNS の扱いがルール分流を裏から歪める

fake-ip を使う構成では、ブラウザが見ている名前解決と実接続で追う IP の関係が直感とズレることがあります。redir-host 系の挙動や、DoH／システム DNS の優先順位も加わると、「DOMAIN ルールは効いているはずなのに別判定になる」症状の原因が DNS に行き着くことがあります。国内サイトを直結させたいのに、解決だけが海外リゾルバに跳ねて遅延する、というパターンもあるため、DNS とルールをセットで設計するのがコツです。ログに DNS 関連の行が出るクライアントでは、まずそこでドメインがどこで解けているかを確認すると早いです。

ミニマムなルール断片のイメージ

以下は教育目的の断片です。実際のグループ名・購読構成に合わせて置き換えてください。

# Minimal rules skeleton (placeholders — align names with your profile)
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - GEOIP,JP,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve の要否はコアとルール方言によって扱いが変わります。購読側がすでに同等の行を抱えているなら重複に注意し、衝突するなら購読のマージ設定または追記位置を調整してください。

よくあるつまずきと切り分け

  • 順序逆転：広い MATCH や DOMAIN-KEYWORD が先に来て、細かい DIRECT 行に到達しない。
  • 名前解決とルールの窓がずれる：fake-ip と redir-host の切り替えをしたのにルールだけ古い前提のまま。
  • サブスク更新で差分が消える：エディタ直編集だけで済ませていて、次回取得で戻る。
  • システムプロキシと TUN の二重適用：モードを切り替えたあと、旧設定が残って挙動が混線。

いずれも、ログの一行に現れるルールヒット名と、実際に選ばれたチェーンを突き合わせれば原因がかなり絞れます。

よくある質問

Q. 国内サイトだけ遅いのはルールのせいでしょうか。A. GLOBAL に近い挙動や、誤った順序でプロキシに飛んでいる可能性が高いです。該当ホストが DIRECT になっているかログで確認し、GEOIP／DOMAIN の位置を見直してください。

Q. GEOIP の結果が期待と違います。A. データと実装の版、CDN の exit IP の差が主な要因です。問題ドメインは DOMAIN か IP-CIDR で明示的に矯正するのが確実です。

Q. ルールはどこまで細かくすべきですか。A. 例外を上にまとめ、長 tail はフォールバックで吸うのが保守に強いです。購読生成部と手書き部の役割分担を文書化しておくとチーム運用でも迷いません。

まとめ：単純な「全部プロキシ」では足りない理由

商用の一部 VPN クライアントは分岐が貧弱で、設定画面に「分割トンネル」の_on／off_しかなく、ドメイン単位の制御が粗い製品もあります。またルール言語を開示しないクローズド実装だと、国内サービスだけ遅いときに原因箇所をログで突き止められず、試行錯誤が闇雲になりがちです。更新が停滞したクライアントでは、新しいプロトコルや購読方言に追従できず、設定をいじっても挙動が変わらない、という板挟みにもなります。

Clash エコシステムでメンテされているスタックを選べば、本記事で整理したRULE の評価順、マッチャーの選び方、DNS の読み方という同じ道具箱を使い、国内外の経路を論理的に説明可能な形で保てます。GUI と YAML の両方から観察でき、ログで「どのルールが勝ったか」を追える点は、長くプロキシを運用するほど差が出る強みです。もし今の構成がグローバル前提で帯域を浪費していると感じているなら、まず RULE に戻し、ルール先頭のプライベート帯〜自国／生活圏の直結〜最終 PROXY の三段だけでも形にしてみるとよいでしょう。

公式ダウンロードページで Clash クライアントを入手する →