現象：「地區不可用」背後多半是路徑分裂，而非只有節點慢

搜尋「Prime Video 分區」「Amazon Video 打不開」時，常見情況並不是完全連不上網路，而是網頁或 App 能載入一部分介面，播放時卻跳出地區／授權相關錯誤，或在開始播放後長時間停留在載入動畫。Amazon 將帳戶與會籍（Prime／Channels）、瀏覽器或 App 端的鑑權請求，以及實際影片片段所在的邊緣主機名拆在多個網域之下；若其中一段仍直連、或 DNS 解析與 TCP 出口的地理位置故事不一致，就很容易出現「看似同一組節點、客戶端卻判定不可用」的反覆現象。

本文沿用站內長影音串流教學同一套規則命中 → DNS／fake-ip → 分流網域置前 → 節點與裝置路徑順序，但刻意不重複 Netflix（nflxvideo 系）、Disney+（Disney 串流網域）、Max／HBO（hbomaxcdn 等）與YouTube（googlevideo）已在本站其他專文展開的主機集合；若您尚未匯入訂閱或確認 YAML 結構，可先完成 訂閱匯入，再依下文逐步收斂。

與 Netflix、Disney+、Max、YouTube：差在哪裡？

四篇既有指南都已強調「同一策略群組內介面與 CDN 要對齊」，但各平台的網域命名習慣不同，不能直接複製別站的規則表貼到 Prime Video。Netflix常見 nflxvideo／nflxext 類後綴，排查重心常在「片段 CDN 是否提早被 MATCH 送走」，詳見 Netflix 分區與節點實測。Disney+走另一套 Disney 串流與鑑權主機，路徑與 Prime 不重疊，請對照 Disney+ 分流專文。

Max（HBO）錯誤訊息與 Prime 類似（地區／方案），但 CDN 與 API 主機集合不同，請以 Max 分流教學為準。YouTube高度依賴 googlevideo 與 ytimg，演算法推薦與 Premium 判定也和 Prime 的會籍模型不同，請見 YouTube 與 googlevideo 實測。Prime／Amazon Video 這邊除了主站的 primevideo.com、amazonvideo.com 類網域外，實際播放時日誌裡經常出現含 aiv- 字首的主機名（例如與 Amazon Instant Video 傳遞鏈路相關的網域），這正是本篇要請您用連線紀錄收斂、而非只靠靜態抄表的區段。

第一步：規則模式、命中順序與系統代理／TUN

請確認長時間維持 mode: rule，並在實際嘗試播放的一段時間內開啟連線日誌。您要找的是：所有與 Prime Video／Amazon Video 播放鏈路相關的請求是否落在同一個策略群組（例如自訂的 PRIME_PROXY），還是有部份連線提早命中 GEOIP、過寬的網域規則而被送去 DIRECT。若片段仍走直連，優先調整規則由上而下的順序與規則集的載入位置，語意細節可再對照 規則分流詳解。

若您僅開系統 HTTP 代理而未使用 TUN，請留意智慧電視、電視棒或部分桌面程式可能完全不讀系統代理，導致瀏覽器正常、客製 App 卻顯示不同錯誤。此情況應評估 TUN 模式 或閘道／路由器層覆蓋，讓該裝置的預設路由與 DNS 一併納入同一出口邏輯。

第二步：DNS、fake-ip 與 DNS 洩漏一起看

在常見的 enhanced-mode: fake-ip 設定下，若將 Prime／Amazon 相關網域錯誤地列入或不列入 fake-ip-filter，搭配 nameserver-policy 將特定後綴導向與代理出口地理不一致的上游，都可能出現規則敘述與實際握手不一致。調整分流規則時請同步檢視 DNS 區塊，並在修改後清除裝置與瀏覽器的舊快取再試。

DNS 洩漏在此類場景的典型症狀是：同一個出口節點下，網頁與原生 App、或瀏覽器與電視端呈現的可用片單／錯誤碼不一致。處理原則仍是讓 DNS 查詢經過與 TCP／UDP 相同的策略路徑，避免路由器或第二張網卡悄悄指向運營商 DNS。若您使用嗅探功能輔助規則，請留意與明文規則的優先順序是否打架，必要時參考 嗅探與串流網域 專文的注意事項。

第三步：分流網域——介面、鑑權與 aiv-* 傳遞鏈

教學目標是讓登入／個人化／播放授權與影片片段傳輸落在同一個 proxy-groups 條目裡，避免「首頁走代理、片段仍直連」造成區域判定錯亂。骨架上可以先用較保守、業界常見的後綴置於過寬規則之前，再以您環境日誌中實際出現的主機名補齊；切勿一次倒入來源不明的巨型規則包，以免與銀行、公司 VPN 或其他站台衝突。

YAML（示意骨架）# proxy-groups：建議單一群組集中測試節點
proxy-groups:
  - name: "PRIME_PROXY"
    type: select
    proxies:
      - "節點 A"
      - "節點 B"
      - DIRECT

rules:
  # Place BEFORE overly broad GEOIP / MATCH rules
  - DOMAIN-SUFFIX,primevideo.com,PRIME_PROXY
  - DOMAIN-SUFFIX,amazonvideo.com,PRIME_PROXY
  # Keyword catches many aiv-* style streaming hosts seen in logs (verify side effects)
  - DOMAIN-KEYWORD,aiv-,PRIME_PROXY
  # ...keep subscription rules and final MATCH fallback

上述 DOMAIN-KEYWORD,aiv- 可能比其他規則更容易誤命中非串流用途的主機名；若您發現副作用，請改為在日誌中將具體主機逐一改為 DOMAIN-SUFFIX 或 DOMAIN 單條列舉。amazon.com 底下尚有購物、AWS 控制台等大量流量，一般不建議整棵後綴粗綁進串流群組；除非您能確認環境中只有 Prime 相闊子域需要該後綴，否則請優先用播放時連線紀錄精準收斂。

第四步：節點選擇——對齊會籍區與穩定出口

儀表板上的延遲數字多半是短連線探測，與長時間影片位元率是否穩定並不等價。Prime／Amazon Video 同時看重出口 IP 地理位置是否與您的會籍／方案合理對應（此處涉及服務條款與帳務區域），以及邊緣節點是否頻繁切換導致工作階段需重新協商鑑權。建議在同一個 PRIME_PROXY 群組內做對照實驗，每次切換後完整退出 App 或清除應用程式快取再試，避免殘留 Cookie 干擾判讀。

若環境中另有公司 VPN、私人 DNS、第二張網路介面或行動熱點，請確認預設路由下 DNS 與影片連線不會被另一條鏈路悄悄帶走。這類「Clash 內規則正確、系統層卻分裂」的情況，常被誤認為節點品質問題。

網頁、手機 App 與電視／Fire TV：路徑可能完全不同

桌面瀏覽器最容易受「是否走系統代理／是否另有瀏覽器外掛代理」影響；請先統一成單一路徑再測。iOS／Android App對 VPN、私人 DNS 與「指定 App 繞過 VPN」的處理各不相同，需在系統設定中逐一確認。電視棒、智慧電視或 Fire TV 類裝置往往沒有完整 HTTP 代理選項，較適合透過 TUN、閘道路由或區網 DNS 將整機預設閘道對齊；若僅改 DNS 而未涵蓋 TCP 連線，仍會出現只有診斷頁正常、播放仍失敗的落差。

實測檢查清單：建議按順序勾選

1. 模式：確認為規則模式，並排除與其他整機 VPN 同時搶路由。
2. 日誌：播放前後檢視 Prime／Amazon Video 相關連線是否皆命中 PRIME_PROXY（或您自訂群組名稱），無孤立的 DIRECT。
3. 網域收斂：將日誌中新出現的邊緣主機（含 aiv- 類）補成置前規則；關鍵字規則若有誤命中再改為單條列舉。
4. DNS 單一路徑：暫停實驗性第二套 DNS，僅保留與 Clash 一致的上游後再測。
5. 裝置對照：瀏覽器與原生 App 各測一次，確認症狀是否一致。
6. 同群組換節點：僅在同一策略群組內切換，並重啟客戶端後再解讀結果。
7. 會籍層排除：若環境允許，以已知良好的網路直連對照，排除非網路因素（方案、付款區、裝置授權上限等）。

結語

Prime Video 在 2026 年的實務除錯裡，核心仍是讓規則、DNS 與裝置路徑講同一個故事；Amazon 系的介面網域與 aiv-* 類串流邊緣主機並存，與 Netflix、Disney+、Max、YouTube 的慣用主機集合不同，因此照搬他站規則往往只解一半。把變因收斂到「同一策略群組內該選哪個穩定節點」，長期維護會比堆疊靜態清單更省力。

若您希望從可信用戶端與官方文件起步，再逐步加上自訂規則，整體路徑會更清楚。完整入門與進階說明可參閱 教學文件。