Netflix の地域エラー・プロキシ検知と Clash：2026 年、分流ルール・DNS・ノードで視聴環境を整える
Netflix を Clash と併用するとき、PC のブラウザでは再生できるのにスマート TV やゲーム機のアプリだけエラーになる、ログイン後に別の地域のカタログへ飛ぶ、プロキシや VPN の利用を示唆するメッセージが出る——といった差は珍しくありません。原因は単一ではなく、端末ごとの DNS の取り方、システムプロキシと TUN のどちらに乗るか、動画 CDN への実際の出口（ノード）がバラバラになることに集約されがちです。本記事では 2026 年時点で実務的な 分流ルール、ストリーミング向けノード選び、DNS（fake-ip を含む）の考え方を整理し、既存の ゲーム分流（Steam / Epic）や 対話型 AI 分流とは棲み分けできる「メインストリーム動画」の切り口にします。各サービスの利用規約と法令を遵守したうえで、自分が利用権限を持つ範囲でのネットワーク整理を前提とします。
なぜブラウザだけ通って TV だけ失敗するのか
同じ家の同じ回線でも、ブラウザは OS のプロキシ設定や拡張機能に従いやすく、TV・メディアボックス・ゲーム機はそもそも HTTP プロキシを読まず、独自の DNS キャッシュやハードコードに近いリゾルバを持つことがあります。Clash を PC だけで動かし「LAN 共有」やルータ経由で TV に届ける構成では、どのマシンが権威 DNS に問い合わせているかが一気に複雑になります。
典型的なパターンは次のような対比です。
- ブラウザだけ成功：その端末だけ Clash の TUN またはシステムプロキシに乗り、
Ruleで Netflix 系ドメインが意図したポリシーグループへ流れている。 - TV アプリだけ失敗：TV がルータの DNSやISP の DNSを直接使い、地域判定や CDN の入口がブラウザ経路と食い違う。あるいは TV 側トラフィックがまったくプロキシに乗っていない。
- カタログが頻繁に切り替わる：複数の端末やプロファイルで出口の国・ASN がバラバラで、セッションやクッキーと実際の動画取得経路の組み合わせが不安定。
切り分けの第一歩は「失敗している端末のパケットが、どの DNS とどのゲートウェイを通っているか」を揃えることです。全屋プロキシを検討する場合は OpenWrt / OpenClash のようにLAN 全体の DNS と転送を一か所で管理するほうが再現性が高い場面があります。
ストリーミング向け分流ルールの置き方
Netflix はドメインと CDN が動的で、購読ルールセットのカテゴリ名はクライアントやルール提供者ごとに異なります。重要なのは名前より順序です。ローカルで明示したい行は、広い GEOIP や最終 MATCH より上に置き、競合する広域ブロック（広告・追跡カテゴリなど）が HTTPS の依存ドメインを落としていないかも確認します。
ゲーム分流との違い
低遅延 UDP を守る Steam / Epic のプロセス分流とは目的が違います。動画は帯域の安定と長めの TLS セッション、複数ホストへの順次フェッチが主戦場。対戦用に選んだ「ping は良いが帯域が細い」ノードは、4K のバッファリングには向かないことがあります。
ルールを自作する場合、実際の接続ログに出るホスト名を見ながら狭いドメインから足すほうが、誤って無関係なトラフィックを巻き込みにくいです。リモートルールをマージしたあとは、ローカルの上書きがマージ結果の先頭側に残っているかを必ず確認してください。
# Illustrative — replace STREAMING-GROUP with your policy group name
rules:
- DOMAIN-SUFFIX,netflix.com,STREAMING-GROUP
- DOMAIN-SUFFIX,nflxvideo.net,STREAMING-GROUP
- DOMAIN-SUFFIX,nflxso.net,STREAMING-GROUP
- MATCH,DIRECT
上記は概念例です。実運用では購読ルールの RULE-SET やクライアント固有のストリーミング分類と組み合わせ、自宅環境でログに出た名前へ追従させます。
ストリーミング向けノード選び（2026 年の現実）
動画配信事業者はデータセンター由来の IP や既知の商用 VPN 出口に対して厳しめの判定を行うことがあり、画面上では「利用できません」「プロキシの使用が検出されました」などと表示されることがあります。技術的には出口の ASN・リスクスコア・過去の乱用履歴などが絡むと考えられ、ノードの地理表示と実際のピアリング品質も一致しないことは珍しくありません。
実務的には次のような観点でポリシーグループを分けると切り分けがしやすいです。
- 一般ブラウジング用：遅延より到達性。ルールのデフォルト出口。
- 動画・大容量向け：帯域と安定優先。
url-testやfallbackの間隔は短すぎると余計な切り替えで再生が止まるので、クライアントの推奨に合わせて調整。 - 国内直結（DIRECT）：利用規約上ローカルコンテンツのみ、などポリシーが明確なトラフィック。
遵守事項
本記事は技術的な接続の整理を説明するものであり、サービス利用規約や著作権法・輸出規制などに抵触する利用を推奨するものではありません。契約上許された地域・プランの範囲内でご利用ください。
DNS、fake-ip、専用 DNS の考え方
Clash 系では fake-ip モードがデフォルトに近い構成として広く使われます。ドメインを早い段階で仮アドレスにマップし、実接続時に本解決へ寄せる流れはルールマッチの一貫性に効きますが、アプリが OS の DNS 結果だけを信じる端末では挙動差が出ます。TV が「別の国のローカル DNS」に直接問い合わせていると、PC 側の Clash DNS と二重の真実になり、カタログや DRM ハンドシェイクが不整合を起こしがちです。
対策の方向性は次のようなレイヤーに分けて考えると迷いにくいです。
- Clash 内 DNS：
nameserverとfallback、DoH のタイムアウト、fake-ip-filter（ローカルや STUN などを除外）を整理する。 - OS・ルータの DNS：全屋構成では、LAN クライアントがどの IP を DNS サーバとして見ているかを Clash または dnsmasq 側に寄せる。
- 専用 DNS という言葉：ストリーミング向けに別プロバイダを足す場合でも、ルールでその問い合わせ自体が意図した出口から出るかをログで確認する。DNS だけ直結・動画だけプロキシ、のような分断は不具合の温床です。
接続はあるのにブラウザだけ真っ白、という症状のときは DNS と fake-ip の詳細を先に読み、変数を一つずつ戻すのが安全です。
TUN と TV・ゲーム機：プロキシを「見えない場所」まで届ける
システムプロキシ非対応のデバイスを同じポリシーで扱うには、TUN モードやゲートウェイ機器での透過プロキシが必要になることが多いです。Windows で土台を作る場合は Clash for Windows のセットアップ、macOS は Clash Verge Rev を参照し、権限とネットワーク拡張を終えてから TV 側の検証に進むと手戻りが減ります。
モバイルやタブレットでアプリのみ失敗するときは、端末の「プライベート DNS」設定や分割トンネル型 VPNとの競合も疑います。複数のネットワークスタックが同時に有効だと、見かけ上 Clash はオンでも実トラフィックが別経路に抜けることがあります。
IPv6 と DNS リークの見落とし
2026 年も、IPv6 が有効な回線でIPv4 だけをトンネルに載せ、IPv6 は ISP 直出しのままになると、地域判定や CDN 選択が意図とズレます。ルータの IPv6 設定、OS の優先度、Clash の ipv6 スイッチを含め、「どのプロトコルで名前解決と実通信が行われているか」を一度スナップショットとして確認しておく価値があります。
症状別のチェック項目
| 症状 | まず見る場所 |
|---|---|
| ブラウザは OK、TV はエラー | TV の DNS・ゲートウェイ、全屋プロキシの有無、TUN の対象範囲 |
| プロキシ検出の表示 | 出口 IP の種類、同一ノードの使い回し過多、別アプリとの VPN 競合 |
| カタログが頻繁に変わる | 複数端末の出口国、セッション維持できるノードか、DNS の一貫性 |
| 再生開始直後だけ失敗 | 帯域不足、TLS ハンドシェイクの遅延、fallback の切り替わり間隔 |
よくある質問
Global モードにすれば直るのでは？
短時間の切り分けなら有効なこともありますが、日常運用では不要なトラフィックまで同じ出口に乗り、速度・検知リスク・ログのノイズが増えます。Rule とストリーミング用グループのほうが長期的に安定しやすいです。
SmartDNS 的な製品と併用してよいか
併用自体は可能ですが、誰が権威解決を握るかが衝突しやすいです。Clash の DNS 設定と役割を文書化し、一方を明示的にオフにして挙動を比較してください。
4K だけ止まる
帯域とバッファ、CDN エッジの選択が主因になりがちです。ノードを切り替えつつ、同じタイトルで低画質が通るかを見ると切り分けが速いです。
まとめ：ルール・ノード・DNS の三本柱
Netflix まわりの不具合は、画面の文言ほど単純ではありませんが、分流ルールの順序、ストリーミングに適した出口の選び方、fake-ip を含む DNS 設計の三本を揃えると、「ブラウザだけ」「TV だけ」といった差をかなり減らせます。ゲームや AI ツール向けに既にルールを分けているなら、同じ Clash の上に動画専用ポリシーグループを足すだけで運用が分かりやすくなります。