Prime Video 打不开或地区错误？Clash 分流 Amazon 与视频 CDN 实测（2026）

1. 为什么 Prime Video 特别依赖「Amazon + CDN」双轨分流

Prime Video 并不是孤立域名：登录、会员状态与风控往往落在区域性 Amazon 站点与通用 API 主机名上；而封面图、清单接口与视频流又经常经由 CloudFront 或 Amazon 视频专用 CDN 域名下发。只写一条 DOMAIN-SUFFIX,primevideo.com，有时只能解决「首页能刷出来」——一旦播放器去拉另一段主机名上的许可证或切片，请求若意外直连或落到错误策略组，就会表现为无限缓冲或地区提示。

这和 Netflix 长视频分流 里「播放域名分散」的问题是同一类：必须把整条播放链路看作一组逻辑单元。区别在于 Amazon 生态里还叠了商城账号与数字内容权限，同一浏览器会话若混用不同地区的 cookie 或站点跳转，也会放大地区检测的误判。

若你刚接触策略写法，可先读完 高级规则分流指南，再回头把本节域名段落插在过于宽泛的 GEOIP / MATCH 之前，避免「大类规则先命中、Prime 专用规则永远走不到」的顺序陷阱。

2. 两类症状：打不开 vs 能开但地区不对

打不开通常优先怀疑三类因素：TLS 握手被重置或阻断、关键主机名未走代理导致握手失败，以及 DNS 污染或解析路径与连接路径不一致。此时连接日志里常见反复失败的 443，或大量请求落到 DIRECT 后超时。

能开但地区不对则更常见于出口 IP 国家与Prime 订阅区域不一致，或播放阶段域名仍走了本地直连出口，使平台看到「前端会话在新加坡、许可证请求却在另一个地区」这类拼接信号。这与 Disney+ 仅预告或地区提示 的排错顺序相近：先确认日志里每一跳主机名是否都命中同一流媒体策略组，再谈账号区服。

移动端与电视端还要注意是否仅用系统 HTTP 代理：UDP 或系统 DNS若绕过 Clash，也会出现「App 能启动却不能播」的假阳性。必要时改用 TUN 模式或确认客户端文档推荐的接管方式，思路与 Discord 语音专文里强调的「栈是否真被接管」一致。

3. 建议在规则里优先覆盖的主机名与后缀

下列后缀在近年 Prime Video 网页端与常见 App 路径里高频出现，适合作为自定义规则的起点；真正上线前仍应以你本地连接日志为准增补子域，而不是照搬静态清单。若订阅自带流媒体分类（如部分社区的 GEOSITE Amazon / Streaming 条目），可与本节组合使用：自定义段落靠前表达明确意图，大类在后兜底。

• primevideo.com、amazonvideo.com（品牌站点与跳转）
• 面向你账号区域的 amazon.co.jp、amazon.de、amazon.com 等区域性商城域名中与登录、订单与数字内容相关的请求（可按日志收窄，不必整站粗暴 MATCH）
• media-amazon.com、aiv-cdn.net 一类常见于封面与媒体描述的路径（名称可能迭代，以嗅探与日志为准）
• 播放器阶段出现的 atv-ps.amazon.com、unagi.amazon.com 等API / 许可证边缘
• 日志中出现的 *.cloudfront.net：不建议无条件全局代理整个后缀；更稳妥是仅对你观影会话里实际出现的 CloudFront 主机名写独立规则，或交给已维护的流媒体规则集

避免单纯使用过于宽泛的 DOMAIN-KEYWORD,amazon：容易把无关商城流量全部拽进流媒体节点，徒增延迟与账单风险。更实用的做法是后缀 + 日志增量：每次客户端更新后若冒出两三枚新主机名，再在本地覆写里追加即可。

4. 专用策略组与 mihomo 规则示例

建议单独建一个面向流媒体的 select 或 url-test 策略组（示例名：📺 Streaming），只放入延迟稳定且出口国家与订阅区域一致的节点。把上一节后缀显式指向该组后，从登录到点击正片完整走一遍流程，核对日志是否仍有主机名落到 DIRECT。尚未导入订阅的用户可先完成 订阅导入教程，再叠加本节覆写。

proxy-groups:
  - name: "📺 Streaming"
    type: select
    proxies:
      - NODE-US-WEST-01
      - NODE-JP-TOKYO-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,primevideo.com,📺 Streaming
  - DOMAIN-SUFFIX,amazonvideo.com,📺 Streaming
  - DOMAIN-SUFFIX,media-amazon.com,📺 Streaming
  - DOMAIN-SUFFIX,aiv-cdn.net,📺 Streaming
  - DOMAIN,atv-ps.amazon.com,📺 Streaming
  - DOMAIN,unagi.amazon.com,📺 Streaming
  # Add REGIONAL amazon TLDs + logged CloudFront hosts explicitly
  # ... GEOIP / MATCH below

若你希望购物走直连、观影走代理，需要用更细的 DOMAIN 把二者拆开，而不是依赖单一关键词；否则很容易出现购物车正常、播放器异常或反向卡顿。长期维护时可以把 Prime 相关段落单独放在一个 yaml 片段里通过 proxy-providers / 覆写合并，便于Diff与回滚。

5. DNS、Fake-IP 与 Sniffer：避免解析与连接「各走各路」

在 Fake-IP 模式下，客户端会先拿到一段本地虚拟地址，再在真实连接阶段由内核还原域名并匹配规则。若浏览器启用了安全 DNS（DoH）、或路由器仍在下发运营商 DNS，就可能出现解析路径绕过 Clash 的情况：登录页走了代理，播放器却在另一套解析结果上直连。关于两种 DNS 模式的取舍，可对照 fake-ip 与 redir-host 专文，按你是否高度依赖域名级分流来选择。

修改 DNS 或 Fake-IP 相关段落后，务必清理本机 DNS 缓存并重启内核再测；否则旧记录会让误判延续很久，尤其在 Windows 与部分 Android 机型上更明显。

对 HTTPS，Sniffer 可通过 TLS SNI 补全早期缺失的域名信息，缓解「连接已建立却按 IP 走错策略组」的现象。示例（字段名请按你所用内核版本文档校对）：

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
  # See upstream docs for skip-domain / override-destination

流媒体是大流量场景，嗅探会带来额外 CPU 开销。实务上建议先把域名规则写全，仅在日志仍异常时短期开启 Sniffer 做对照，确认问题确实来自域名信息缺口，再决定是否常驻。

6. 地区检测：规则无误仍报错时要对齐的三件事

当连接日志显示Prime 相关主机名已稳定命中目标策略组，但界面仍提示地区不可用时，请依次核对：① 当前节点出口国家是否与Prime 会员注册区域一致；② 同一浏览器或 App 是否曾在不同地区节点之间频繁切换导致 cookie 混乱；③ 付款资料、应用商店区域等设备侧缓存是否与当前出口矛盾。

请遵守服务条款与当地法律法规；本文仅讨论网络路径与配置观测层面的技术问题，不鼓励任何规避平台合理使用政策的行为。若你为家庭成员共享网络，还要留意不同终端是否共用同一 DNS 与策略组，避免一台直连、一台代理导致会话信号不一致。

7. 排查清单（2026 实测向）