症状の整理：つながるのに「地域が違う」

新作ドラマの配信開始に合わせてノードを切り替えたのに、ライブラリの並びが変わらない。VPN 表示はオンなのにタイトルが出てこない、あるいは短い間だけ再生できてすぐ暗転する——こうした検索クエリは、ストリーミングの地域制限とプロキシ利用が交差する地点で非常に多くなります。ユーザー側から見ると「回線は生きているのに体験が壊れている」状態なので、単純なオン／オフの話では済みません。

Netflix のようなサービスは、入口のドメインだけでなく、CDN や計測、広告・認証まわりのホストへ細かく振り分けられた通信を前提にしています。Clash / mihomo でいうルール分流は、まさに「どのホスト名・どのフローを、どの出口に乗せるか」を決める仕組みです。ここが雑だと、たとえばメインの視聴トラフィックだけ海外ノードに乗り、別ホストが国内直結のまま残る——といった部分代理になり、リージョン判定が割れたままになります。

なぜ「全部 MATCH でプロキシ」でも直らないことがあるか

ひとつの誤解は、「最終行をプロキシにすれば全部同じ出口になるはず」という期待です。実際には次のような要因で、ログ上はプロキシ経由でもアプリから見た地域が崩れます。

第一にルールの順序です。Clash 系はリスト上から評価し、最初にマッチした行で決着がつきます。細かい例外を下に置いたり、国別直結（例：GEOIP,JP,DIRECT）を先に置きすぎると、意図せずストリーミング向けホストが直結側へ落ちます。サブスク配布の巨大ルールセットをそのまま使う場合も、自前の「動画用」例外が上書きされない位置にあると効きません。

第二にDNS と実接続のズレです。ブラウザや OS が返した IP と、実際に TLS を張る経路が一致しないと、エッジサーバの選択やリージョン推定が意図とずれます。Fake-IP を使う構成では名前解決の見え方が変わるため、ルールだけをいじっても症状が残ることがあります。DNS を「漏洩させない」こと自体はプライバシーとセットで重要ですが、本稿の焦点はどの DNS パイプでどの名前を解くかという運用設計です。プライバシー寄りの機構の全体像は、ドキュメントの Fake-IP／DNS 解説で補完できます。

第三にノードの実体です。データセンター出口はブロックやリージョン固定が入りやすく、住宅系やモバイル系と比べてカタログの振る舞いが安定しないことがあります。また、同じ国コードでも実際の ASN やピアリング状況で見え方が変わるため、「国名が合っていれば OK」では済まない場面があります。

ルール設計：解除向けだけを別プロキシグループへ

実務では、汎用プロキシとは別にストリーミング専用の proxy-groups エントリを切るのが扱いやすいです。select 型にしておけば、新作が出るたびにそのグループだけ手早くノードを切り替えられます。url-test で自動化する場合も、計測 URL と tolerance は「動画の安定性」とトレードオフになるので、頻繁な切り替えでセッションが切れないよう余裕を見ます。

ルール側では、配信事業者向けのドメイン・IP リスト（RULE-SET やコミュニティルール）をGEOIP や広い DIRECT より上に置くのが基本です。自前で足すなら、公式アプリが使う CDN 系のサフィックスもセットで拾う必要があることが多く、メンテナンスコストと引き換えに精度が上がります。ルール記法の基礎と優先順位の感覚は、YAML・ルール分流の解説記事とあわせて読むと、設定ファイルのどこを触ればよいかが掴みやすくなります。

# Concept only — replace RULE-SET URLs with ones you trust and maintain.
proxy-groups:
  - name: STREAM
    type: select
    proxies:
      - node-us-west
      - node-sg
      - DIRECT

rules:
  - RULE-SET,streaming_netflix,STREAM
  # ... broader DIRECT / GEOIP rules above MATCH ...
  - MATCH,PROXY
ヒント

ブラウザ拡張や別プロファイルで「そのサイトだけシステムプロキシを無視」していると、Clash 側のルールがそもそも効きません。症状がブラウザ限定か、アプリ全体かを先に切り分けると早いです。

DNS／名前解決：ストリーミング用にクエリ経路を揃える

分流の相棒が DNS です。nameserver-policy で特定サフィックスのクエリだけ、信頼できるアップストリームへ寄せる構成は、地域判定のブレを減らすのに効くことがあります。一方で、フォールバックやフィルタを多用しすぎると遅延やタイムアウトが増えるので、「本当に必要な名前だけ政策を分ける」ほうが運用は楽です。

Fake-IP を使う場合、fake-ip-filter に載った名前は通常解決に回るため、ストリーミング関連を誤って列挙していないかも確認ポイントです。TUN と併用するときは、OS の DNS がコアに集まっているか（ハイジャックや仮想 NIC の状態）を合わせて見ます。ここは「漏洩を防ぐ」話題とも接続しますが、本稿ではカタログ地域の一貫性という目的語を中心に置いています。DNS のプライバシー面を主題に据えた深掘りは、前述のドキュメント該当セクションで体系化されています。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query
  nameserver-policy:
    # example: send Netflix-related suffixes to a resolver you control
    "+.nflxvideo.net": https://dns.example/dns-query
    "+.netflix.com": https://dns.example/dns-query

ノード選定：リージョン検出が「国コードだけ」では済まない理由

解除という言葉でまとめられる要件でも、求めるのは「回線が通ること」だけではなく、サービス側のリージョン検出と折り合いがつくことです。同一プロバイダの中でも、サーバの所在地・ピア・混雑で体感が変わるため、ストリーミング専用グループで 2〜3 候補を常備し、新作のたびに差し替えられるようにしておくとストレスが減ります。

また、IPv6 が有効な環境では IPv4 だけのノード設計と組み合わさって、意図しない経路が生まれることがあります。ルールと DNS を直した次にまだずれる場合は、OS のスタックやデュアルスタックの挙動も疑う価値があります。

切り分けチェックリスト（短時間で試せる順）

  1. ルールヒット：ログを一時的に詳細化し、対象ドメインが本当に STREAM（仮）側に落ちているか確認する。
  2. 広い DIRECT の位置：GEOIP や国内向け直結が先に勝っていないか見直す。
  3. DNS の集約：クエリがコアの設定どおりに流れているか、別クライアントが DNS を横取りしていないか。
  4. ノードの入れ替え：同じ国表示でも別サーバに変えてカタログが追従するか試す。
  5. アプリ境界：ブラウザだけ不調なら拡張・プロファイル・別の DNS over HTTPS 設定を疑う。
注意

利用規約・法令・契約は国やサービスごとに異なります。本稿はネットワーク設定の一般的な説明であり、特定サービスの利用を推奨・保証するものではありません。

まとめ

「プロキシはオンなのに地域がおかしい」は、ストリーミング時代ならではの典型的な不具合です。Clash では解除に関わるホストだけを上のルールで捕捉し、専用プロキシグループに流す設計が効きやすく、その裏側ではDNS の経路と Fake-IP の例外まで含めて一貫させる必要があります。ノードの種類と経路の組み合わせまで見ると、説明不能に見えた症状も段階的にほどけていきます。

ルール記法やグループの型の復習は関連記事へ、DNS のプライバシー視点はドキュメントへ、と役割を分けて読むと、既存コンテンツと内容が重複せずに学習コストを抑えられます。GUI クライアントで試行錯誤する場合も、最終的には YAML のどこを動かしたかが説明できる状態にしておくと、サブスク更新後のトラブルに強くなります。

安定したクライアントからルール検証を始めたい場合は、クライアントのダウンロードページで OS に合ったビルドを選ぶと手順が短くなります。オープンソースのリポジトリは挙動の理解に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると、コアと UI の対応関係が追いやすいです。→ 無料で Clash をダウンロードし、分流設定の検証を始める