Prime Video 打不開或地區錯誤？Clash 分流 Amazon 與影片 CDN 實測（2026）

1. 為什麼要單獨談 Prime Video：與 Netflix、Disney+ 的差異

長影音平台的流量結構有共通點——外壳頁面、鑑權、DRM 與分片影片常常分拆在不同網域——但每家的後綴表不同。Netflix以 nflx 系後綴為辨識核心；Disney+大量依賴 BAMTECH／bamgrid 等鑑權鏈路。相較之下，Prime Video緊密綁在 Amazon 帳戶體系上：瀏覽器裡除了 primevideo.com，你還可能看到 amazon.com（或各地區 amazon.co.jp、amazon.co.uk 等）底下的播放與裝置註冊相關子域，以及 媒體 CDN如 aiv-cdn.net、media-amazon.com。只把官方「品牌首頁」丟進代理，常會出現看得到列表、點正片就失敗的半套狀況。

本篇與 Notion × AWS CloudFront 那類「SaaS＋CDN」文的分工在於：Prime Video 更重帳戶與裝置鑑權鏈，且錯誤訊息常直接指向地區檢測。讀者可把本篇視為站內串流矩陣的一塊拼圖，規則思維可與 Netflix、Disney+ 兩篇對照閱讀，但網域表請勿混用。

2. 兩條主線：完全打不開 vs 能開但地區檢測失敗

第一條主線：打不開或長時間轉圈。常見於 DNS 被污染或走錯出口、TLS 交握被截斷、或某些子域仍直連卻被本機或上游擋下。此時請優先蒐集失敗請求的 Host，而不是只看首頁是否能開；Prime Video 的關鍵請求往往落在猜不到的子域上。

第二條主線：能登入、介面正常，但播放時跳地區錯誤或片庫與預期不符。這類情況除了 Clash 分流與 DNS，還必須檢視帳戶註冊地、付款方式、Prime 方案是否涵蓋該區影音庫。代理能穩定控制的是出站 IP 與解析路徑；無法替你合併兩個不相容的授權區域。若錯誤明確寫帳單或權限，請先處理帳戶層，再回頭微調規則。

3. Amazon 登入、Prime Video 與常見媒體 CDN 網域

下列為 2026 年實務設定與社群規則集中仍常出現在播放鏈路的後綴與用途，供你對照日誌增刪。Amazon 會調整 CDN 與 API 主機名，以下清單不是保固；以你環境實測為準。

• 影音品牌與入口：primevideo.com（網頁與 App 導流、行銷與帳戶相關頁面常見）。
• Amazon 全球站與區域站（鑑權／裝置／帳戶）：amazon.com 及各區 amazon.co.jp、amazon.co.uk、amazon.de 等；實務日誌中常以 atv-ps.amazon.*、unagi.amazon.* 等子域形式出現（完整字串請以連線紀錄為準）。
• 影音相關後綴：amazonvideo.com、aiv-cdn.net、aiv-delivery.net（與歷史案即時影片分發相關，仍常被規則集收錄）。
• 靜態與媒體承載：media-amazon.com 等（縮圖、中繼資料與片段資源路徑可能經此類主機）。

4. mihomo 規則範例：後綴整包與「不要整包 amazon.com」的理由

在 mihomo 中，與其他長影音文相同，建議將「會誤傷的直連／地區規則」放在後方，把Prime Video 專用策略組置前。下列為示意 YAML，策略組名稱與節點請替換為你的實際環境；註解使用英文以利版本控管。

proxy-groups:
  - name: 🎬 Prime Video
    type: select
    proxies:
      - Streaming-Node-A
      - Streaming-Node-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,primevideo.com,🎬 Prime Video
  - DOMAIN-SUFFIX,amazonvideo.com,🎬 Prime Video
  - DOMAIN-SUFFIX,aiv-cdn.net,🎬 Prime Video
  - DOMAIN-SUFFIX,aiv-delivery.net,🎬 Prime Video
  - DOMAIN-SUFFIX,media-amazon.com,🎬 Prime Video
  # Optional: REGIONAL amazon TLDs used by your account, e.g. amazon.co.jp
  # - DOMAIN-SUFFIX,amazon.co.jp,🎬 Prime Video
  # Use logs to confirm whether you need full amazon.com or only specific subdomains
  # ... your GEOIP DIRECT and MATCH rules below

5. DNS、Fake-IP 與 nameserver-policy 校準

串流媒體場景裡，DNS 與策略分裂會表現為「解析看起來正確、播放仍失敗」或「憑證／重定向異常」。請同步檢查：是否啟用 fake-ip；nameserver-policy 是否為 primevideo.com、amazonvideo.com 等指定了與播放策略組不一致的解析通道；以及本機瀏覽器是否另開 DoH 繞過 Clash。若你對 Fake-IP 與規則的銜接不熟，建議先讀 fake-ip 與 redir-host 專文，再把同一套檢查表套用到本篇網域。

實務上，許多「只卡在最後一哩播放」的案例，收斂在某一條鑑權或分片 URL 仍走直連／命中錯誤的兜底規則，而不是單純換節點能解。請以日誌中的 DOMAIN／IP／策略組名稱三相對照，並在調整 Fake-IP 後重新跑一次完整播放流程，避免舊連線快取誤導判斷。

6. CloudFront 與 Sniffer：規則看到 IP 時怎麼辦

Amazon 系服務大量使用 CloudFront 與其他 CDN，日誌中可能出現 *.cloudfront.net 這類主機名。通常不建議把整個 cloudfront.net 後綴一把丟進單一策略組——會誤傷其他網站與下載來源。較穩的做法是：依失敗請求的完整 Host 精準加規則，或啟用 mihomo Sniffer，在 TLS 等條件下還原 SNI，讓維度重新回到「網域規則」而非只看 IP。

Sniffer 設定過寬可能帶來相容性與隱私權衡，請與你的 TUN／系統代理模式一併驗證。若你同時在排查 HTTP/3 行為，可交叉閱讀 Gemini 與 QUIC 實測中的對照思路；客戶端亦可能走 QUIC／UDP，與純 TCP API 流量不完全相同。

7. 地區檢測與節點品質：代理能做到哪裡

地區檢測往往綜合帳戶、付款、商店區域與實際出站 IP。Clash 能穩定做的是讓你連到 Prime Video 相關主機時，出站路徑與你選擇的目標區域一致，並在隨播放切換 CDN 時盡量維持同一策略組。若節點 IP 被標為資料中心或濫用嚴重，平台可能拒絕發片或降級畫質，這屬節點品質與風控，不一定靠多寫幾條規則就能解。

同一工作階段內頻繁切換出口，也可能導致會話失效或裝置重新驗證；排查時請先固定一組「已知可用於該區」的節點，再動規則與 DNS，避免變因堆疊。

8. 驗證清單與常見誤區

完成設定後建議依序確認：① 從首頁到正片，日誌中出現的 Host 是否皆命中同一策略組；② 訂閱規則集是否有粗粒度條目把部分 Amazon 後綴直連；③ nameserver-policy 與 Fake-IP 是否與目標區域一致；④ 開啟 Sniffer 前後，命中是否由 IP 兜底改為網域命中；⑤ 智慧電視或電視盒是否使用不同 DNS 或區域網路。若官方公告大範圍故障，請先排除平台事件再調本地設定。

常見誤區包括：只測首頁、忽略鑑權子域；把帳單／方案問題誤判成純 DNS；以及一把代理整個 amazon.com 後才發現購物與物流通知被拖慢。若你尚未完成訂閱匯入，可先依 訂閱匯入教學建立基底，再把本篇規則合併至清單前段後重測。