在 v2rayN 中設定串流分流，重點不是把所有流量都交給代理，而是讓 Netflix、Disney+ 等影音平台使用合適的節點，同時讓本地網站、銀行服務與區域網路維持直連。若規則順序、DNS 解析或節點品質其中一項不合適，就可能出現首頁可以開啟、影片無法播放，或畫質在幾分鐘後反覆下降的情況。
這篇指南專為已熟悉 v2rayN 基本操作的使用者整理。以下以 Xray 核心、一般系統代理和 TUN 模式為主要情境，說明如何建立影音平台專用分流、如何選擇節點、如何處理 DNS，以及如何用日誌和測試結果判斷問題究竟出在路由還是串流服務本身。
從建立「本地直連、串流代理、其他流量依需求處理」的三層規則開始，再配合 Xray 的網域匹配、DNS 策略與節點測速，完成 Netflix、Disney+ 等影音平台的穩定分流；文中也列出畫面可開啟但影片失敗、畫質下降和字幕載入異常時的具體排查順序。
先把串流分流拆成三個流量集合
影音分流最容易犯的錯，是只建立一條「Netflix 走代理」規則，卻沒有處理平台的登入網域、圖片網域、播放器 API、CDN 位址與 DNS 請求。實際播放時，瀏覽器或電視應用程式可能先存取登入服務，再連到內容授權服務，最後從不同 CDN 取得影音片段。只命中其中一個網域，結果便可能是頁面正常、影片卡在載入中。
較容易維護的方式，是先將流量分成三組。第一組是本地與區域網路流量，包括路由器管理頁面、印表機、NAS、區域網路服務，以及需要低延遲直連的本地網站。第二組是明確指定的串流平台流量，例如 Netflix、Disney+、Prime Video 或其他實際使用的服務，統一交給代理出站。第三組是未命中的一般流量，則依個人需求選擇直連或代理，不要在尚未驗證規則前直接使用過於寬泛的「全部代理」。
本機代理連接埠不一定是 10808，實際值要以 v2rayN「設定」→「參數設定」中的 HTTP 代理連接埠為準。若使用 SOCKS 代理、系統代理或 TUN，流量進入核心的方式不同，但路由規則的基本邏輯仍然相同：先排除不應代理的目標，再處理串流服務，最後才套用兜底規則。
建立 Netflix 與本地網站的路由規則
在 v2rayN 中，路由規則通常由 Xray 核心執行，規則按照排列順序由上而下判斷。第一條符合條件的規則會決定出站，因此本地直連例外必須放在寬泛規則前面，Netflix 與其他串流網域則應放在一般兜底規則前面。若先寫一條「所有網域都直連」，後面再加入 Netflix 代理規則，後者便可能永遠沒有機會生效。
確認核心類型
進入「設定」→「參數設定」，確認目前使用的 Core 類型與實際路由語法相符。本文以 Xray 核心為例，修改後先重新啟動核心。
選擇代理節點
在伺服器清單選取目標節點，執行延遲或速度測試，記下測試時間、延遲與下載表現，不要只依節點名稱判斷。
加入本地直連
在「路由設定」中先處理
geoip:private、區域網路網段與需要直連的本地網域，出站指定為 direct。加入串流代理
新增 Netflix、Disney+ 等實際使用平台的網域規則，出站指定為 proxy，並將規則放在一般兜底規則之前。
套用並驗證
儲存設定後重新啟動核心，先測試首頁，再播放影片，最後查看日誌確認請求是否由預期的代理出站建立。
平台網域可以使用完整網域、網域後綴或 geosite 類別。若目前的 geosite.dat 含有對應分類，可以使用例如 geosite:netflix 之類的規則；但不同版本的規則資料內容可能不一致，因此不能假設所有核心都包含相同分類。更穩妥的做法，是先用日誌觀察實際請求的網域，再補入必要的網域後綴。
Netflix 的播放請求不一定全部集中在單一主網域。登入、帳號、圖片、內容目錄與影音 CDN 可能使用不同網域；Disney+ 等服務也會因地區、應用程式版本與內容而改變請求路徑。規則不宜一開始就把大量不相關的 CDN 網域全部加入代理，否則會增加流量與維護成本。建議先處理平台主網域與播放測試中反覆出現的必要網域，確認功能後再逐步補充。
只將已確認的串流平台網域交給代理，其他本地與一般流量維持原有策略，流量和規則範圍較容易控制。
適合:日常觀看、有限流量方案
設定簡單，遇到網域清單不完整時較不容易漏掉播放請求，但本地網站、更新服務和大型下載也會消耗代理流量。
適合:短時間故障定位
可以降低規則覆蓋範圍，但 CDN 位址與平台請求經常變化，若缺少登入或授權網域，容易出現頁面可開啟而播放失敗。
適合:已掌握請求清單的進階使用者
DNS 解析會直接影響分流結果
路由規則需要知道目標網域或 IP，DNS 設定不當時，可能在規則判斷前就失去原始網域，也可能讓代理請求使用了不適合目前網路位置的解析結果。尤其在 TUN 模式中，如果應用程式自行解析、系統 DNS 沒有被核心接管，Xray 看到的可能只是一個 IP，原本的 domain 或 geosite 規則便不一定能命中。
若主要使用系統代理，先確認瀏覽器與應用程式的 DNS 行為是否能保留網域資訊。若使用 TUN，則要在 v2rayN 的 TUN 與 DNS 相關設定中確認 DNS 請求是否交給核心處理，並避免同時啟用多套互相衝突的 DNS 攔截工具。FakeDNS 可以協助保留網域與後續連線的關聯，但它需要完整的 DNS 與 TUN 路徑配合，並不是開啟後所有應用程式都一定能正常使用。
對於串流平台，常見的策略是讓平台網域在核心內完成匹配，再由代理出站處理後續解析；本地網域則使用直連出站與適合本地網路的 DNS。若將所有 DNS 請求都送往代理端，可能造成本地網站解析變慢；若全部由本地 DNS 處理，則可能出現平台網域解析結果與代理節點地區不一致的情況。
結論：先保留網域，再談平台分流
串流規則命中率比規則數量更重要。若日誌只看見 IP 而看不到原始網域，先處理 DNS、TUN 或嗅探設定；在網域資訊尚未恢復前，繼續增加 Netflix 網域清單通常只會讓設定變得更複雜。
節點不能只看延遲，還要看播放穩定度
v2rayN 的延遲測試通常只能反映特定測試目標的往返時間，不能直接代表 Netflix 或 Disney+ 的實際播放品質。串流服務可能使用不同的 CDN 與授權伺服器，節點到測試目標的路徑順暢，不代表到影片 CDN 同樣順暢。因此選節點時，應將延遲、持續下載速度、尖峰時段表現與 IP 可用性一起考慮。
以 1080p 觀看為例，實際需求會隨編碼、內容和播放器緩衝策略變化。若希望穩定觀看高畫質內容，測得的持續下載速度不應只剛好高於影片標稱碼率，還要預留其他背景流量、封包重傳與尖峰波動的空間。速度測試短暫衝到 80 Mbps，但播放十分鐘後降至 3 Mbps，通常不如長時間維持 15 至 25 Mbps 的節點。
- 先測持續速度：連續觀察至少 30 秒至 1 分鐘，避免只看瞬間峰值。
- 再測實際播放：登入、開始播放、拖曳進度條，觀察是否在切換片段時重新緩衝。
- 記錄尖峰時段：晚間與週末的路線壅塞可能遠高於白天，節點應在實際觀看時段驗證。
- 保留兩個備援：準備不同地區或不同線路的節點，避免單一出口故障時必須重新改規則。
節點地區也不是越遠越好。若平台需要特定內容區域，節點所在地可能影響可見片單，但距離越遠通常也會增加往返時間與封包遺失風險。若目標只是穩定播放已能存取的內容，應優先選擇路徑穩定、IP 信譽正常且在實際時段速度持續的節點，而不是盲目追求最遠地區。
系統代理與 TUN 模式的驗證方式
系統代理模式只會影響遵循系統代理設定的應用程式。瀏覽器通常較容易驗證，但部分影音應用程式、桌面播放器或背景服務可能不讀取系統代理。此時即使瀏覽器測試成功，實際播放應用程式仍可能直連。應先確認 v2rayN 的系統代理狀態，再確認應用程式是否支援該代理類型。
TUN 模式可以接管較廣泛的 TCP、UDP 流量，但需要處理權限、虛擬網卡、DNS、區域網路例外與路由循環。開啟 TUN 後，建議先以單一瀏覽器測試，不要同時開啟多個 VPN、其他透明代理或安全軟體的網路過濾功能。若出現本地網站無法連線，先確認 geoip:private 與本地網段直連規則，再檢查 TUN 的 DNS 接管狀態。
| 測試現象 | 較可能原因 | 優先檢查項目 |
|---|---|---|
| 首頁可開，影片無法播放 | 播放或授權網域沒有命中代理 | 核心日誌、平台網域規則、規則順序 |
| 影片可播但畫質下降 | 節點持續吞吐不足或尖峰壅塞 | 30 秒以上速度、封包遺失、備援節點 |
| 本地網站也走代理 | 直連例外缺失或兜底規則位置錯誤 | geoip:private、本地域名、規則排列 |
| TUN 開啟後所有 DNS 異常 | 多套 DNS 攔截互相衝突或核心未接管 | DNS 模式、虛擬網卡、系統 DNS 設定 |
驗證時不要只看瀏覽器能否載入首頁。建議依序測試本地網站、一般外部網站、串流平台登入頁、影片開始播放，以及播放中的進度拖曳。每次只修改一項設定，並記錄修改前後的節點、模式、時間和日誌關鍵字。這樣才能判斷改善來自路由規則、DNS 調整，還是單純更換了較好的節點。
常見串流問題與排查順序
如果 Netflix 顯示錯誤碼、影片無限載入或播放數分鐘後停止，先不要立即刪除所有規則。第一步是確認目前使用的活動伺服器與代理模式，第二步查看 Xray 日誌是否有 DNS 失敗、連線逾時、TLS 交握失敗或遠端重設，第三步再比較同一平台在另一個節點的結果。若只有一個節點失敗，通常應先更換節點；若所有節點都失敗，才需要深入檢查規則和 DNS。
Netflix 首頁正常，按播放卻一直轉圈？
先查看播放時新增的網域是否走 proxy。若日誌只命中直連或沒有命中平台規則，補入實際出現的授權與 CDN 網域，並確認兜底直連規則沒有排在前面。
同一節點在瀏覽器能看，應用程式卻不能看？
確認該應用程式是否遵循系統代理。若不遵循，改用 TUN 模式重新測試，同時檢查 TUN 的 DNS 接管和區域網路直連例外。
為什麼節點延遲低，影片速度仍然很慢？
延遲只反映測試請求的往返時間，無法代表串流 CDN 的持續吞吐。改用實際播放與至少 30 秒的下載觀察，並比較另一條線路。
把所有流量代理後就能解決嗎？
可以用來短暫確認是否為分流漏規則，但不適合長期使用。確認原因後，應恢復本地直連與平台代理的精確規則，避免增加流量、延遲和本地服務故障。
最後，請將穩定設定保留一份可辨識的備份，並在 v2rayN 更新訂閱後重新確認路由規則是否仍然存在。訂閱更新通常只負責節點資料，不一定會替你保留自訂分流策略。當節點名稱、核心版本或 geosite 資料發生變化時，也應重新驗證一次平台登入、播放和本地網站三個基本場景。