Prime Video が開かない・地域エラー？Amazon と CDN を Clash で分流（2026）

1. Netflix / Disney+ 稿との違い（Amazon との二正面）

Netflix 向けの実測稿は、独自のコンテンツ配信名前空間（例：nflxvideo.net 系など）を重点にしました。Disney+ の稿は Disney Streaming / BAMTech 系との噛み合わせです。それに対しPrime Videoでは、ユーザーが日常的に同じブラウザで Amazon の買い物・アカウントヘルプにも触れるため、単にprimevideo.com だけでは足りず、amazon.co.jp / amazon.com 側の処理と動画 CDN（多くが CloudFront や Amazon 運用ホスト）の二正面で考える必要が出やすくなります。

つまり、「Prime 用だけ専門出口に載せればよい」のが必ずしも成立しないケースがあります。ログイン処理が Amazon ドメイン群に載っており、それが国内直結や別ノードへ落ち続けている間に、視聴用だけだけ海外側ノードへ乗っていると、サービス側のセッションと整合しない症状が見えます。ルール評価の基本順序は共通なので、ルールルーティングの解説と購読取り込みの流れであるサブスク導入手順から一度押さえ直すと、この稿の細部だけ追いやすくなります。

2. 「開かない」と「開けるが地域が違う」の切り分け

まずはUI が最初から読み込めない状態なのか、一覧まで見えるのに再生が始まらないのかで重み付けします。前者はprimevideo.com やリダイレクト経由のamazon. 接続が意図した策略に載っていない、あるいはTLS だけ DNS が別経路になるといった問題が優先されます。後者は、番組一覧の応答だけ通ってaiv-delivery.net やcloudfront.net で始まる再生系ホストがDIRECT に残っている典型が検討されます。

画面上に明示的な地域関連メッセージが出るときは、その原因が出口 IP の国情報だけとは限らない点に注意してください。アカウント作成国、決済、アプリストア側の公開リージョン、メンバー登録状態など、アプリ外部の論点があります。それでもネットワーク上は名前解決と実策略のセットを統一すると原因の切り分けが楽になることは多く、技術側のメモとして価値があります。

3. 押さえる名前空間：Amazon、Prime、aiv と CloudFront

サービス側の構成はインフラ改修で変わります。ここでの列挙は切り分けの出発点として使い、実際には開発者ツールのネットワークタブ、mihomo のログ、または端末側のキャプチャに出現した名前を正としてください。Prime の表側：primevideo.com と地域に応じてamazon.co.jp やamazon.com など。配信チェーン側：過去にも登場してきた名前としてmedia-amazon.com やaiv-delivery.net が参考になりやすく、さらにセグメント取得はホスト単位ではXXXX.cloudfront.net が続く構成も珍しくありません。

CloudFront はドメインワイルドカードで一気に束ねられる一方、Amazon 共通ショップと同じ経路まで全部同じ出口に載せすぎると、買い物や配送追跡の表示まで遠回りになります。広げすぎないため、運用開始時は購読に含まれる既存の「Prime / Amazon Prime Video」関連ルールがあるか確認し、その上から足りないサフィックスをログ順にだけ追記するやり方が安全です。評価順はルール評価の一般原則どおりで、広いMATCHより前に具体的なDOMAIN-SUFFIX が来ているか確認します。

Prime Video と Amazon のストリーミングトラフィックを Clash のログで名前ごとに切り分けるイメージ — 図はイメージ用の共通 OG 資産であり、画面上の名前は実ログに依存します。

4. mihomo ルール例：ストリーミング・Amazon それぞれの策略

ひとつのパターンは、視聴用にストリーミング狙いの出口を固定し、アカウント処理は同一か、あるいは DIRECTに寄せる設計です。どちらに寄せるかは環境によります。同じグループへまとめてしまうほうがログがシンプルになりますが、逆にamazon.co.jp の広告計測や写真アップロードまで同じ出口に乗ると遅れることもあります。まず再生が止まっているホストだけをログでリストし、必要最小限のDOMAIN-SUFFIXだけを増やしてください。

構造としては、(1)Prime / Amazon に関わる名前空間用の策略グループ、(2)評価順でそれらより上に置かれたrules行、の二点がセットです。以下はYAMLの例示で、プロキシ名は自分のリストに差し替えます。YAML コメントは英語表記です。

# Split Prime Video CDN from broad MATCH; align with your outbound names
proxy-groups:
  - name: STREAM_PRIME_AMAZON
    type: select
    proxies:
      - LOW-LATENCY
      - STABLE_REGION
      - DIRECT

rules:
  - DOMAIN-SUFFIX,primevideo.com,STREAM_PRIME_AMAZON
  - DOMAIN-SUFFIX,aiv-delivery.net,STREAM_PRIME_AMAZON
  - DOMAIN-SUFFIX,media-amazon.com,STREAM_PRIME_AMAZON
  - DOMAIN-SUFFIX,cloudfront.net,STREAM_PRIME_AMAZON
  - DOMAIN-SUFFIX,amazon.co.jp,DIRECT
  - MATCH,PROXY

amazon.co.jp を DIRECT としたのは一例です。実環境では「Prime 視聴のために Amazon 側も同一出口へ揃える」必要があるかどうかが分岐点になります。その判断はログを見ずに決めず、症状に合わせて出口をひとつ変えながら再現性を確認するのが確実です。TUN とシステムプロキシによる差はTUN モードの解説と、必要ならテレビ端末向け LAN 共有などを扱った他稿を組み合わせてください。

5. DNS モード・fake-ip・Sniffer で名前と経路を揃える理由

fake-ip が有効な構成では、アプリやブラウザが名前の代わりに割り振られた仮アドレスだけを握ったままサーバへ進み、それがDOMAIN 評価のドメイン名と繋がらない場合が出ます。結果として一覧は問題なく読めても、TLS 復元がうまくいったセグメント取得だけ異なる経路になります。DNS の名前解決結果と、ファイヤウォール上で見える接続情報を一致させるのがこの稿での「名前と経路の整合」という呼び名です。mihomo ではenhanced-mode: fake-ip と sniffer をどう並べたかにより挙動差が表れるので、自分の構成ファイルを読み込み済み YAML の全文として通読することが重要です。

Sniffer が有効な場合、HTTPS のServer Name が復元されるとルール評価が二度目に走り、意図したDOMAIN-SUFFIX とマッチしやすくなります。一方でサービス側のHTTP/3 の利用状況により、名前が取りにくいパスもあります。そのときは QUIC を切り離す話題としてGEMINI... 系の QUIC ガイドに近い考えも参照できます。Gemini と QUIC に触れた別稿はプラットフォームは違ってもトランスポート層だけが浮いてしまうときの共通の思考法になります。

またブラウザの安全な DNS をアプリ側で固定していると、mihomo 側の名前解決と二重になります。ブラウザの DoH とシステムプロキシまわりの稿と合わせ、意図した DNS パスの一本化を確認してください。

6. 地域検知：経路だけでは説明しない層がある

経路側で期待する出口にすべての関連ホストを揃えたのに説明語が変わらない場合、残る論点としてアカウント登録情報利用プランごとのコンテンツライセンス差視聴端末の公開ストア設定などが挙がります。データセンター系 IP はストリーミング側から視聴品質を落として受け付けるだけ・あるいは接続自体を優先しないこともあり、その場合はより住宅系／ISP クラスのアウトバウンドに差し替えて試すしかありません。ここでの操作はすべて技術的比較の範囲に留めるべきであり、コンテンツ利用の合法性はサービス側の許諾の内側で判断してください。

7. 実測手順：ログと開発者ツールでホストを拾い足す

現場では次の順が扱いやすいです。（1）症状を再現しながら mihomo の debug ログまたは GUI のログを開け、問題のタイムウィンドウに出ていたホスト名列をコピーする。（2）ブラウザの場合は開発者ツールのネットワークでマニフェストとセグメントの URLまで展開してドメインの末位を確認する。（3）まず購読付属のリストに名前がなかったか確認し、なければDOMAIN-SUFFIX で追記し、評価位置はMATCH の直前側に置いたままになるかチェックする。（4）変更後DNS を含め再起動またはコア再起動後に再ログインし、ログを取りながら同じ問題が再び出るか切り替える。（5）出口を切り替えたときだけ症状が変わるなら、ルール評価以前の問題（ノード側ブロック）を疑ってよい証拠です。

自動選択系グループとの相性調整についてはurl-test とfallback に触れた別稿の整理が近いです。再生セッション中に出口が細かく変わりすぎると不安定になりやすく、Prime 視聴用には比較的固定できるノードへの手動選択を試す読者も多いです。

8. つまずきやすい点

ひとつ目はprimevideo.comだけにルールを足して CloudFront と配信名前をほったらかすケースです。表側だけ通ればプレビューまでは動くが本編だけ落ちる状態が続きます。二つ目はcloudfront.netを無差別に同じノードへ流す広げ過ぎです。名前は正しくても、他サイトのコンテンツ取得まで不必要に同じ経路になり遅れることがあります。三つ目はDNS と fake-ip・Sniffer の設定を読まずに DOMAIN だけ増やし続ける運用です。ここまで述べてきた通り、名前と実評価のズレがあるとログ行だけでは読み間違います。

すべてのサービス共通ですが、アプリ開発者側の許諾の外での地域改変を説く本文は載せません。ここにあるのは自宅構成を把握しログで原因を説明できるようにすることまでです。

9. まとめ

Prime Videoは Amazon エコシステムとの接続が濃く、名前空間だけを Netflix と同列にしないほうが切り分けが早くなります。ログイン・アカウント側の名前と視聴配信チェーン側の名前を分けつつ、mihomo の策略グループとルールの順番で希望する出口へ揃える。さらにDNS・fake-ip・Snifferを一度は通読して名前と評価のズレがない状態にする、この二段で多くの「開けない」「再生が始まらない」「地域だけおかしい」系の質問につながります。実際にはホスト名は改修次第で増減しますから、リストは固定せず自分の環境ログを正にしたメンテ可能な増分だけを残しましょう。

GUI とバックエンド世代の組み合わせで細部設定が異なるときも、共通でまず確認したいのは信頼できるクライアントへの更新です。自分のプラットフォーム向けのアプリをサイトから確実に揃えるなら、 → 無料で Clash をダウンロードし、接続構成の起点から整えるところが分かりやすい選択です。