ClashでNetflixとDisney+を快適に見る分割設定ガイド

NetflixとDisney+だけをプロキシへ分ける考え方

Clashで動画配信サービスを快適に利用するには、すべての通信を同じプロキシへ送るのではなく、サービスごとに経路を分ける方法が有効です。NetflixとDisney+の通信だけを動画視聴用のプロキシグループへ送り、普段使う国内ニュース、銀行、通販、社内サービスなどは直接接続に戻します。これにより、不要な通信までプロキシを経由させず、国内サービスの表示速度やログイン動作への影響を抑えられます。

この設定は、Clashのルールモードで実現します。カーネルは通信先のドメイン名やIPアドレスをルールと照合し、最初に一致したルールのポリシーへ接続を渡します。したがって、重要なのはプロキシノードの速度だけではありません。動画サービスのドメインを正しく指定すること、動画用グループを先に定義すること、最後のMATCHルールで意図しない通信を受け止めることが重要です。

動画再生では複数の通信を考慮する

動画サービスを開くとき、1つのドメインだけへ接続しているとは限りません。アカウント認証、作品情報、画像、再生マニフェスト、実際の映像セグメントが別々のホストへ分かれる場合があります。トップページは表示できるのに再生開始で止まる場合は、トップページのドメインだけをプロキシへ送っていて、動画配信ドメインがDIRECTになっている可能性があります。

一方で、関連しそうなCDNドメインをすべてプロキシへ送るのも安全な方法ではありません。大規模CDNは複数のサービスで共有されることがあり、広すぎるDOMAIN-SUFFIXを追加すると、国内の一般サイトまでプロキシへ流れることがあります。まず公式サービスの主要ドメインから始め、再生ログで不足しているホストだけを追加する運用が安定します。

動画用プロキシグループと直接接続を準備する

最初に、サブスクリプションから読み込まれた既存のノード名を確認します。設定内のproxiesまたはproxy-providersにある名前と、画面上のノード名が一致しているかを確認してください。手書き設定で存在しないノード名をグループへ登録すると、設定の読み込みに失敗したり、グループが空になったりします。

動画用グループには、手動選択型のselectを使う方法が分かりやすいでしょう。混雑時間帯にノードを切り替えたい場合はurl-testやfallbackも利用できますが、遅延測定の結果だけで動画の安定性を判断することはできません。再生中に速度が落ちる、数分ごとにバッファリングが発生する、字幕や画質変更だけ失敗する場合は、別のノードを手動で比較してください。

proxy-groups:
  - name: STREAMING
    type: select
    proxies:
      - JP-Video-01
      - SG-Video-01
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - JP-Video-01
      - SG-Video-01

上の例では、STREAMINGが動画配信用の入口です。JP-Video-01やSG-Video-01は実際の設定に存在する名前へ置き換えてください。動画用グループにDIRECTを含めると、ルールが正しく動作しているかを比較できますが、動画ドメインを直接接続しても再生条件を満たさない場合があります。検証後は、普段使うノードを先頭に置くか、手動選択にして状態を固定してください。

国内サービスをDIRECTにする理由

すべてを動画用プロキシへ送ると、国内向けの決済サイト、行政サービス、社内システム、ローカルネットワークへの接続まで遠回りになります。特にログインや本人確認を伴うサービスでは、アクセス元の地域やIPが頻繁に変わると追加認証が発生することがあります。動画ルールを限定し、最後の既定経路をDIRECTにする構成は、日常利用とのバランスを取りやすい設計です。

NetflixとDisney+のルールをYAMLに追加する

ルールは上から順番に評価されます。そのため、動画用のドメインルールは、一般的な地域ルール、広告ブロックルール、最後のMATCHより前に置いてください。すでにGEOSITE,CN,DIRECTや大規模なRULE-SETが上にある場合、動画ドメインが先にDIRECTへ分類されることがあります。ルールを追加した後は、実際の接続一覧でどのルールに一致したかを確認することが必要です。

rules:
  # Netflix
  - DOMAIN-SUFFIX,netflix.com,STREAMING
  - DOMAIN-SUFFIX,netflix.net,STREAMING
  - DOMAIN-SUFFIX,nflxvideo.net,STREAMING
  - DOMAIN-SUFFIX,nflximg.net,STREAMING
  - DOMAIN-SUFFIX,nflxso.net,STREAMING
  - DOMAIN-SUFFIX,nflxext.com,STREAMING

  # Disney+
  - DOMAIN-SUFFIX,disneyplus.com,STREAMING
  - DOMAIN-SUFFIX,disney-plus.net,STREAMING
  - DOMAIN-SUFFIX,disney.com,STREAMING
  - DOMAIN-SUFFIX,dssott.com,STREAMING

  # そのほかの通信
  - MATCH,DIRECT

DOMAIN-SUFFIXは、指定したドメイン自身と、その下位ドメインに一致します。たとえばDOMAIN-SUFFIX,netflix.com,STREAMINGはwww.netflix.comやhelp.netflix.comにも一致します。単一のホストだけを対象にしたい場合はDOMAINを使いますが、動画サービスではサブドメインが増減するため、主要なサービスドメインにはDOMAIN-SUFFIXが使いやすいでしょう。

ただし、サービスが利用する配信ホストは地域、アプリ、OS、再生方式によって変わることがあります。上のリストを固定的な完全一覧と考えず、接続ログを確認して不足するドメインを追加してください。特にCDN関連のドメインを推測で大量に追加するのではなく、再生開始直前または再生中に新しく現れた通信だけを調べることが重要です。

FlClashで実際に設定して動作を確認する

ここでは、既存の購読設定を残しながらローカルオーバーライドを追加する流れを説明します。画面名はFlClashやClash系クライアントのバージョンによって異なるため、「Profiles」「設定を編集」「オーバーライド」「Mixin」に相当する項目を探してください。購読元のYAMLを直接書き換える方法は、次回更新時に変更が失われる可能性があるため、可能ならローカル設定として分離します。

FlClashで現在使用しているプロファイルを確認し、元のサブスクリプションURLと設定ファイルをバックアップします。
プロキシ一覧で、動画視聴に使うノードが実際に接続可能か確認します。名前に絵文字や日本語が含まれていても、YAML上の文字列と完全に一致している必要があります。
プロキシグループにSTREAMINGを追加し、少なくとも2つの候補ノードを登録します。最初はselect型にして、手動で比較できるようにします。
rulesの上部または動画用ルールを置く位置に、NetflixとDisney+のDOMAIN-SUFFIXルールを追加します。
設定を保存して再読み込みし、YAMLの解析エラー、存在しないグループ名、存在しないノード名がないかログを確認します。
FlClashのプロキシ画面でSTREAMINGを選択し、必要であればシステムプロキシまたはTUNを有効にします。
ブラウザーの既存タブを閉じ、NetflixまたはDisney+へ再接続します。接続一覧で対象ドメインがSTREAMINGへ分類されているかを確認します。

システムプロキシを使う場合、ブラウザーなどシステム設定を参照するアプリから検証を始めると切り分けが容易です。ゲーム、コンテナ、コマンドラインツール、システムプロキシを無視するアプリも対象にする場合はTUNが必要になることがあります。ただし、TUNではDNS処理や仮想インターフェースの影響範囲が広がるため、まずシステムプロキシでルールの正しさを確認し、その後にTUNへ進むのがおすすめです。

確認する場所	期待する状態	異常時に見る項目
プロキシグループ	動画用ノードまたはAUTOが選択されている	グループ名、ノード名、ノードの接続状態
接続一覧	NetflixやDisney+の通信がSTREAMINGに分類される	上にあるルール、実際の接続先ホスト名
ブラウザー	ログイン、作品一覧、再生、字幕切り替えが動作する	キャッシュ、Cookie、拡張機能、DNS
カーネルログ	接続拒否や名前解決エラーが発生していない	`dial timeout`、`connection reset`、DNSエラー

再生を安定させるノード選択とDNSの調整

動画再生では、単純なPing値よりも、継続的な帯域、パケットロス、経路の混雑、TLS接続の安定性が重要です。遅延が50 msのノードでも、数分後に速度が落ちれば視聴には向きません。反対に遅延が120 msでも、再生開始後の帯域が安定していれば実用的な場合があります。短い速度テストだけでなく、同じ作品を同じ画質条件で数分再生して比較してください。

まず2～3個の候補を残す：最も速い1台だけに依存せず、混雑時に切り替えられる予備ノードを用意します。
地域を頻繁に変えない：ログインや作品情報の取得経路が変わると、表示内容や認証状態の確認が必要になることがあります。
自動選択を過信しない：url-testは指定URLへの測定結果を使うため、実際の動画CDNの混雑を完全には反映しません。
UDP対応だけで判断しない：Hysteria2やTUICなどを使う場合、ローカル回線やルーターがUDPを安定して処理できるか確認します。
同時利用を考える：複数端末で同時再生するなら、1台での速度テストではなく、合計帯域とサーバー側の接続制限を確認します。

DNSとTUNを変更するときの注意

ルールが正しいのに接続先が期待どおりにならない場合、DNSの解決結果とルール判定の関係を確認します。DNSモード、Fake-IP、Redir-Host、TUNの設定が異なると、接続一覧に表示されるアドレスやドメイン情報が変わることがあります。ドメインルールを確実に使いたい場合は、mihomoのログと接続一覧で、実際にドメイン名が復元されているかを確認してください。

DNSを変更する際は、一度に複数の設定を変えないでください。DNSサーバー、Fake-IPフィルター、TUNの自動ルートを同時に変更すると、改善した理由を判断できなくなります。まず通常のシステムプロキシでルールを確認し、次にDNS、最後にTUNという順番で検証すると、問題の範囲を小さく保てます。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.cloudflare.com/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

上のDNS例は構成の形を示すためのものです。実際には、利用中のネットワーク、mihomoのバージョン、クライアントのDNS実装に合わせて調整してください。社内ネットワークや家庭内機器を使う場合、LANドメインをFake-IPの対象外にする必要があります。DNS設定だけで特定サービスの利用条件が変わるわけではなく、名前解決が安定するかどうかを確認するための設定です。

再生できないときの切り分け

トップページは開くのに再生ボタンを押すと止まる場合、まず接続一覧を開いて、再生開始時刻の通信を確認します。NetflixやDisney+のログインページだけがSTREAMINGで、動画セグメントのホストがDIRECTなら、ルール不足の可能性があります。反対に、すべての通信がSTREAMINGへ流れているなら、ルールが広すぎるか、上位のルールを整理する必要があります。

設定読み込みエラー：インデント、コロン、グループ名、ノード名を確認します。YAMLではタブ文字を使わず、空白でインデントしてください。
ルールが一致しない：動画ドメインの実際のホスト名を接続一覧から確認し、MATCHより前に追加します。
接続はプロキシだが再生が止まる：別ノードへ切り替え、パケットロス、帯域、同時接続数、UDPの安定性を比較します。
ログインが繰り返される：端末の時刻、Cookie、ブラウザー拡張、IP地域の変化を確認します。短時間に多くの地域へ切り替えないでください。
国内サイトも遅くなった：CDN全体に対する広いルール、上位のプロキシルール、DNSの変更を確認します。
スマートフォンだけ動かない：アプリ通信がシステムプロキシを使っていない可能性があります。Clash for AndroidなどではTUNやアプリ別ルーティングの状態を確認します。

よくある質問

NetflixとDisney+を同じプロキシグループに入れてもよいですか？

はい。通信経路や必要なノードが共通しているなら、同じSTREAMINGグループで管理できます。ただし、サービスごとに安定する地域やノードが違う場合は、NETFLIXとDISNEYを分けたほうが切り分けやすくなります。

ルールを追加したのに動画だけ再生できません。何を見ればよいですか？

再生開始時の接続一覧を確認してください。トップページのドメインだけでなく、再生マニフェストや動画セグメントのホストがどのポリシーへ分類されたかを見ます。DIRECTになっているホストがあれば、必要性を確認したうえで個別にルールを追加します。

自動選択と手動選択はどちらが動画向きですか？

最初の検証には手動選択が向いています。ノードごとの再生状態を比較しやすいためです。候補を絞り込んだ後は、url-testやfallbackを試せますが、測定URLの遅延だけで再生品質を完全には判断できない点に注意してください。

TUNを有効にしないと動画配信ルールは使えませんか？

ブラウザーなどがシステムプロキシを参照する環境なら、通常はTUNなしで検証できます。システムプロキシを使わないアプリや、端末全体の通信を対象にしたい場合はTUNが必要になることがあります。まずシステムプロキシでルールを確認してからTUNへ移行すると、原因を追いやすくなります。