実践ClashXルール優先順位ガイド：DOMAIN-SUFFIX、GEOIP、MATCHの競合を避ける方法

ほとんどの失敗はノードの停止ではなく、ルールの「シャドウイング」によって起こります。ClashXは上から順にマッチングを行い、最初にヒットした時点で停止するため、ルールの順序は単なる書式ではなくロジックそのものです。

なぜルールがランダムに壊れて見えるのか

MATCH や GEOIP のような広範なルールが早すぎる位置にあると、特定のビジネスルールが実行されることはありません。

💡

最初のマッチが優先されます

各リクエストは最初にマッチしたルールのみを使用します。順序を間違えると、正しいルールに到達できなくなります。

典型的な症状ノードは健全なのにルーティングが不安定
期待したポリシーグループがヒットしない
ホームページは開くが、認証やメディアが失敗する
小さな編集が関係のないトラフィックを壊してしまう

⚠️

よくある間違い

MATCH を中間に置くと評価が早期に終了してしまいます。必ず最後に置いてください。

ルール優先順位のコアモデル

ファネル（漏斗）モデルを使用しましょう。精密な条件を最初に、フォールバック条件を最後に置きます。推奨される順序： DOMAIN → DOMAIN-SUFFIX → DOMAIN-KEYWORD → IP-CIDR → GEOIP → MATCH。

完全一致のドメインルールは予測可能です
重要なビジネスドメインは明示的に指定すべきです
フォールバックは一意で最終的なものである必要があります

                            
                                ルールの種類優先順位ユースケースリスク

                                DOMAIN1重要なホストメンテナンスコスト
DOMAIN-SUFFIX2サービスファミリーのルーティング過剰にマッチする可能性
DOMAIN-KEYWORD3一時的なブリッジ高い誤検出率
IP-CIDR4ネットワーク範囲no-resolve の使用
GEOIP5国のフォールバックCDNの不一致
MATCH6最終的なフォールバック必ず最後に置くこと

ルールの種類	優先順位	ユースケース	リスク
`DOMAIN`	1	重要なホスト	メンテナンスコスト
`DOMAIN-SUFFIX`	2	サービスファミリーのルーティング	過剰にマッチする可能性
`DOMAIN-KEYWORD`	3	一時的なブリッジ	高い誤検出率
`IP-CIDR`	4	ネットワーク範囲	no-resolve の使用
`GEOIP`	5	国のフォールバック	CDNの不一致
`MATCH`	6	最終的なフォールバック	必ず最後に置くこと

📌

役割の分担

DOMAIN は精密さを担当し、GEOIP と MATCH は広範なフォールバックを担当します。

DOMAIN

最速

DOMAIN-SUFFIX

高速

GEOIP

中速

MATCH

フォールバック

ファネル：ビジネスに完全一致するルール → サービスのサフィックスルール → キーワードブリッジルール → ネットワーク/地理フォールバック → MATCH。

よくある競合シナリオと解決策

ケース 1: 社内アプリがプロキシにルートされてしまう。通常、上部の GEOIP,CN,DIRECT との競合やホワイトリストの欠落が原因です。まず完全一致の社内ドメインを追加してください。

ケース 2: ストリーミングの不安定さ。1つの広範なキーワードではなく、APIドメインとメディアドメインを別々のルールに分割します。

社内システムが誤ってルーティングされる

🧨

問題のある設定

早すぎる位置にある GEOIP が認証コールバックルールをシャドウイングしています。

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - DOMAIN,sso.corp-auth.com,PROXY
  - MATCH,PROXY

✅

解決策

完全一致の SSO/API ドメインを広範なルールより前に移動します。

rules:
  - DOMAIN,sso.corp-auth.com,PROXY
  - DOMAIN,api.corp.example.com,DIRECT
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ストリーミングの地域検出が失敗する

🎬

問題のある設定

単一のキーワードルールでは、認証ドメインやメディアドメインを見逃してしまいます。

rules:
  - DOMAIN-KEYWORD,netflix,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

✅

解決策

API、メディア、メインドメインを明示的に分けます。

rules:
  - DOMAIN,api.netflix.com,PROXY_STREAM
  - DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
  - DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

国内CDNが誤ってプロキシされる

📦

問題のある設定

広範なキーワードが静的なCDNトラフィックをプロキシ経由で送ってしまいます。

✅

解決策

アプリドメインはプロキシ化しつつ、CDNのサフィックスは DIRECT に強制します。

UDPゲームが切断される

🎮

問題のある設定

ポリシーグループが安定した UDP パスを提供していません。

✅

解決策

UDP対応のゲーム専用グループを作成し、ゲームホストをそこにルートします。

実践的なテンプレート

rules:
  - DOMAIN,api.example.com,ProxyA
  - DOMAIN-SUFFIX,example.com,ProxyA
  - DOMAIN-KEYWORD,office,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ProxyB

階層構造は変えず、ポリシーグループ名だけを置き換えてください。

基本テンプレート

rules:
  - DOMAIN,login.company.com,PROXY
  - DOMAIN-SUFFIX,company.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

高度なテンプレート (rule-providers)

rule-providers:
  direct:
    type: http
    behavior: classical
    url: https://example.org/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ストリーミング特化テンプレート

rules:
  - DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
  - DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

テンプレートブロック：重要なルール、シナリオ別ルール、地理フォールバック、最終キャッチオール。

🛠️

カスタマイズのコツ

一度に1つのレイヤーのみを変更し、すぐに回帰チェックを行ってください。

5分間のトラブルシューティングフロー

ログを有効にし、リクエストを1つ再現します
マッチしたルールの行を特定します
その上にある広範なルールを調査します
rule-set の同期タイムスタンプを検証します
主要ドメインで回帰テストを実行します

1分目で再現、2分目でヒット箇所の特定、3分目でシャドウイングの調査、4分目で最小限の修正、5分目で回帰テスト。

tail -f ~/Library/Logs/ClashX/clashx.log
grep "api.example.com" ~/Library/Logs/ClashX/clashx.log
grep -E "MATCH|GEOIP|DOMAIN" ~/Library/Logs/ClashX/clashx.log | tail -n 50

ステップ 1

再現

ステップ 2

特定

ステップ 3

シャドウ調査

ステップ 4

最小限の修正

ステップ 5

回帰テスト

📍

ログの場所

macOSでは通常 ~/Library/Logs/ClashX/ にあります。

チームでの協力とバージョニング

複数人で管理する場合は、ルールをレイヤーに分けましょう：ビジネスホワイトリスト、システムサービス、地理的ルーティング、最終フォールバック。すべての変更には意図、影響範囲、ロールバックのメモを含めるべきです。

各レイヤーに明確な責任を持たせることで、トラブル発生時の切り分けが迅速になります。

config/
  base.yaml
  rules/
    10-business.yaml
    20-services.yaml
    30-geo.yaml
    99-fallback.yaml

feat(rule): corp SSOコールバックの明示的なルーティングを追加
fix(rule): MATCHを最終行に移動し、キーワードのシャドウイングを軽減
chore(ruleset): ストリーミングプロバイダーを2026-02-10版に更新

🤝

共有戦略

チーム全体での一貫性と、より簡単なロールバックのために rule-providers を使用してください。

よくある質問：ルールの優先順位

Q1: no-resolve とは何ですか？

A: IPルールのために余計なDNS解決を行わないようにする設定で、LAN内の CIDR などに有用です。

Q2: MATCH はどこに置くべきですか？

A: 最終行に、一度だけです。

Q3: ローカルルールと rule-set が競合した場合は？

A: 最終的な順序で動作が決まります。最初にヒットしたものが勝ちます。

Q4: なぜサービスの一部だけが動作するのですか？

A: サブドメインによって異なるルールにヒットしている可能性があります。機能ごとに分割してください。

Q5: DOMAIN-SUFFIX と DOMAIN-KEYWORD どちらを使うべきですか？

A: DOMAIN-SUFFIX を優先し、キーワードは一時的なブリッジとして使用してください。

Q6: GEOIP を早い位置に置けますか？

A: 通常はできません。優先度の高いビジネスルールをシャドウイングしてしまう可能性があります。

Q7: 変更はいつ適用されますか？

A: リロード後です。その際ログで動作を確認してください。

Q8: チーム内での競合を避けるには？

A: レイヤー分けされたファイル、コミット規約、順序に重点を置いたレビューを行ってください。

Q9: ルールはどんどん追加すべきですか？

A: そうとは限りません。ルールは最小限かつ明示的に保ってください。広範なルールが多すぎると衝突が増えます。

Q10: すべてのホストを DOMAIN ルールにすべきですか？

A: いいえ。DOMAIN は重要なホストに限定し、サフィックスやプロバイダールールを使ってメンテナンス性を高めてください。

Q11: rule-providers はどのくらいの頻度で更新すべきですか？

A: 実用的には1日がデフォルトです。デリケートな環境では、リリースウィンドウやロールバックタグに合わせて更新してください。

Q12: 1回のコミットで最適化とリファクタリングを同時に行えますか？

A: 変更を分ける方が賢明です。まず動作に影響のない順序整理を行い、その後に最適化を行います。トラブル時の切り戻しが簡単になります。

付録：優先順位ラボ（コピーしてテスト用）

テスト用プロファイルでこれらのミニ実験を行い、順序によって動作がどう変わるかを即座に確認してみましょう。

実験 1：早すぎる MATCH

rules:
  - DOMAIN,api.example.com,PROXY
  - MATCH,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY

🧪

期待される結果

MATCH が評価を終了させてしまうため、DOMAIN-SUFFIX,example.com,PROXY は決して実行されません。

実験 2：キーワードの過剰マッチ

rules:
  - DOMAIN-KEYWORD,cdn,PROXY
  - DOMAIN-SUFFIX,assets.example.cn,DIRECT
  - MATCH,DIRECT

🧪

期待される結果

cdn を含むドメインは早期に捕捉されるため、下にある特定の DIRECT ルールがシャドウイングされます。

実験 3：明示的な認証ホストを最初に

rules:
  - DOMAIN,auth.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

認証ホストを明示的に最初に置くことで、ログインとビジネスのトラフィックを独立して、確定的にルーティングできます。

実験 4：早すぎる位置の GEOIP

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN,api.global-service.com,PROXY
  - MATCH,PROXY

🧪

期待される結果

CN IP スペースに解決されるリクエストは、明示的なドメインルールに達する前に DIRECT としてルーティングされる可能性があります。

実験 5：メディアドメインとAPIドメインの分割

rules:
  - DOMAIN,api.stream.example,PROXY_STREAM
  - DOMAIN-SUFFIX,media.stream.example,PROXY_STREAM
  - DOMAIN-SUFFIX,img.stream.example,DIRECT
  - MATCH,PROXY

🧪

期待される結果

コントロールプレーンとデータプレーンで異なるルートを使用でき、挙動が安定します。

実験 6：no-resolve を伴う明示的な LAN 範囲

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

🧪

期待される結果

社内ネットワークトラフィックが直接接続され、不要なDNS解決のオーバーヘッドを避けることができます。

実験 7：フォールバックは一度だけ

rules:
  - DOMAIN,critical.example,PROXY
  - MATCH,PROXY
  - MATCH,DIRECT

🧪

期待される結果

2つ目の MATCH には到達できません。明確さと安全性のために削除すべきです。

ラボ 1

ターミナルのルール動作

ラボ 2

キーワードの過剰マッチ

ラボ 3

明示的ホストの利点

ラボ 4

GEOIP 配置のリスク

ラボ 5

ドメイン分割の安定性

ルールのリリースチェックリスト（チームワークフロー）

正しいルールだけでは不十分です。更新や協力作業の後でも安定していなければなりません。

                            リリース前に必ず確認すること
                            最後に MATCH が1つだけあるか。
重要なビジネスドメインが広範な地理ルールより上に置かれているか。
目的、影響範囲、ロールバックプランが記録されているか。
主要サービス、一般的なサイト、LANフローで回帰テストを行ったか。

                        

まとめ

安定したルーティングは、確定的なルールの順序から始まります。ノードの品質も重要ですが、優先順位の設計がそれ以上に重要です。

リリースの前に、重要なドメインのヒット検証、末尾の MATCH 検証、そして小規模な回帰検証の3つを行ってください。

ルールの順序を「書式」ではなく「アーキテクチャ」として扱うことで、トラブルシューティングにかかる時間は劇的に短縮されます。

CyberGhost VPN検証済

この記事は役に立ちましたか？

✓フィードバックありがとうございます！

タグ:ClashXRule PriorityTraffic RoutingDOMAIN-SUFFIXGEOIP

なぜルールがランダムに壊れて見えるのか

典型的な症状

ルール優先順位のコアモデル

よくある競合シナリオと解決策

社内システムが誤ってルーティングされる

ストリーミングの地域検出が失敗する

国内CDNが誤ってプロキシされる

UDPゲームが切断される

実践的なテンプレート

基本テンプレート

高度なテンプレート (rule-providers)

ストリーミング特化テンプレート

5分間のトラブルシューティングフロー

チームでの協力とバージョニング

よくある質問：ルールの優先順位

Q1: no-resolve とは何ですか？

Q2: MATCH はどこに置くべきですか？

Q3: ローカルルールと rule-set が競合した場合は？

Q4: なぜサービスの一部だけが動作するのですか？

Q5: DOMAIN-SUFFIX と DOMAIN-KEYWORD どちらを使うべきですか？

Q6: GEOIP を早い位置に置けますか？

Q7: 変更はいつ適用されますか？

Q8: チーム内での競合を避けるには？

Q9: ルールはどんどん追加すべきですか？

Q10: すべてのホストを DOMAIN ルールにすべきですか？

Q11: rule-providers はどのくらいの頻度で更新すべきですか？

Q12: 1回のコミットで最適化とリファクタリングを同時に行えますか？

付録：優先順位ラボ（コピーしてテスト用）

実験 1：早すぎる MATCH

実験 2：キーワードの過剰マッチ

実験 3：明示的な認証ホストを最初に

実験 4：早すぎる位置の GEOIP

実験 5：メディアドメインとAPIドメインの分割

実験 6：no-resolve を伴う明示的な LAN 範囲

実験 7：フォールバックは一度だけ

ルールのリリースチェックリスト（チームワークフロー）

リリース前に必ず確認すること

まとめ

この記事は役に立ちましたか？

関連記事

ClashX DNSリーク防止チェックリスト：ブラウザ層からシステム層まで

ClashXプロキシグループ戦略：自動選択、フォールバック、手動オーバーライド

ClashX TUNモードを有効にする方法：高度な設定とトラブルシューティング