Netflix 卡住之前，先把症狀分清楚
使用 Clash 觀看 Netflix 時，卡頓、轉圈、畫質突然下降，表面上都像「節點速度不夠」，實際上可能是 DNS、分流規則、代理模式或串流服務本身選到不同 CDN 所造成。若一開始就不停更換節點，往往只會把變因越弄越多，最後仍不知道問題究竟出在哪一層。
建議先觀察問題發生的時間與範圍。若 Netflix 首頁可以正常載入，但開始播放後持續轉圈，通常要檢查影片串流網域是否誤走直連、DNS 回覆是否把你導向不合適的 CDN，或目前節點的長連線品質不穩。若首頁、封面和登入畫面也載入很慢，則更像是節點延遲過高、系統代理沒有真正生效，或本機 DNS 被其他軟體接管。
- 只有播放時卡頓：優先檢查串流連線的命中規則、影片 CDN 與節點的實際頻寬。
- 播放幾分鐘後才停住：留意節點是否在自動測速後切換，以及 Wi-Fi、路由器或 NAT 是否出現短暫斷線。
- 畫質反覆在低畫質與高畫質之間跳動：可能是吞吐量不穩，也可能是 Netflix 根據出口 IP、DNS 地理位置或即時負載重新選擇串流伺服器。
- 瀏覽器能看，電視或手機 App 不行：不要只測瀏覽器，還要確認該裝置是否使用系統代理；許多原生 App 不會讀取瀏覽器的手動代理設定。
先記錄再修改：每次只調整一個變因，並記下節點名稱、代理模式、DNS 模式與播放結果。這樣才能做出有意義的前後對照，也避免把暫時性的網路尖峰誤認成設定改善。
先測節點與代理模式，不要急著重寫規則
Netflix 的穩定性不只取決於節點測速頁顯示的延遲數字。延遲測試通常只是對某個測試網址發出短請求，並不能代表影片 CDN 的持續下載能力。觀看串流時，更重要的是節點在連續傳輸下的實際吞吐量、封包遺失率、TCP 長連穩定性與尖峰時段表現。一個測試延遲很低的節點，可能在播放十分鐘後因共享頻寬擁塞而降速。
請先固定一個地理位置相近、來源可靠的節點，再進行測試。不要同時使用自動選擇、負載均衡與多層代理，因為這些功能可能讓每次連線使用不同出口，導致 Netflix 在重新請求影片片段時遇到不同的 IP 或路徑。若固定節點能穩定播放，而自動策略組會卡頓，問題通常在策略組的切換條件，而不是 Netflix 本身。
代理模式也需要分開驗證。一般的系統代理只會影響遵循作業系統 HTTP／HTTPS 設定的程式；瀏覽器通常會配合，但部分電視 App、遊戲、影音播放器與背景服務可能完全不理會。這時可以在 Clash 用戶端暫時啟用 TUN 模式，讓符合條件的系統流量經由虛擬網卡進入 Mihomo 核心，再關閉瀏覽器內額外設定的代理，避免雙重代理造成迴路。
不要把所有流量永久送進 TUN：TUN 能協助確認 App 是否繞過系統代理，但也可能影響區域網路、銀行服務、印表機與遊戲連線。排查完成後，請依實際需要保留，並確認區域網路與本機網段規則沒有被錯誤代理。
DNS 是畫質不穩的常見分水嶺
Clash 的 DNS 設定會影響網域解析結果，而 Netflix 等大型串流平台通常使用大量 CDN 節點。當 DNS 解析位置與代理出口位置差距太大時，服務可能把你分配到距離較遠或負載較高的伺服器。此時即使代理節點本身可以連線，播放仍可能出現長時間轉圈、首幀延遲或畫質降級。
排查時先確認 Clash 是否真的接管 DNS。若系統仍由路由器、瀏覽器安全 DNS、VPN 或其他防毒軟體直接解析，設定檔裡寫的 DNS 不一定會成為實際結果。可以在 Clash 的 DNS 日誌、連線列表或診斷頁查看請求是否經過核心；也可以暫時關閉瀏覽器的「安全 DNS」功能，再重新測試，避免瀏覽器自行建立獨立的 HTTPS DNS 連線。
不同版本的 Clash Verge、Clash Verge Rev、Mihomo Party 和 Android 客戶端，DNS 選單名稱可能不完全相同。常見模式包括系統解析、Redir-Host 與 Fake-IP。排查重點不是盲目追求某一種模式，而是確認解析、代理與規則使用的是同一套邏輯。Fake-IP 若與區域網路設備、部分影音 App 或自訂繞過規則衝突，可能造成某些連線失敗；此時可把必要網域加入 fake-ip-filter，或暫時改用另一種模式做 AB 測試。
- 先清除 Clash 的 DNS 快取，再重新開啟 Netflix，不要直接沿用舊連線。
- 確認系統時間正確；錯誤的時間可能造成 HTTPS 憑證驗證或加密 DNS 連線異常。
- 若開啟了瀏覽器安全 DNS，請先暫停它，避免 DNS 請求繞過 Clash。
- 不要使用過寬的網域關鍵字規則，把所有相關服務一律送到同一個不穩定的代理群組。
從連線紀錄找出 Netflix 實際命中的規則
分流排查最有價值的資料不是「我已經開了代理」，而是實際連線的主機名稱、命中的規則與使用的策略組。Netflix 的首頁、登入、圖片、授權和影片內容可能由不同主機提供。只把一個網站主網域加入代理，並不代表所有播放流量都會走同一條路；反過來，使用過寬的 DOMAIN-KEYWORD,netflix 也可能誤傷不需要代理的本機服務。
- 固定測試條件：選一個節點，記下目前的代理模式與 DNS 模式，先不要啟用自動切換或負載均衡。
- 清理舊連線：停止播放、清除 Clash DNS 快取，必要時重新啟動用戶端，讓新的解析與規則從零開始。
- 開啟連線列表：重新載入 Netflix 首頁、登入並播放同一部影片，觀察新增的網域、連線狀態、延遲與策略組名稱。
- 比對命中規則：確認影片播放期間出現的主機不是被
DIRECT、REJECT或錯誤的地區策略組接走；若規則集由遠端更新，還要確認更新時間與載入狀態。 - 做單項 AB 測試：只把明確屬於播放鏈路的網域改到固定代理群組，再播放相同片段，對照首幀時間、緩衝次數與畫質變化。
- 恢復最小規則：測試完成後刪除臨時的寬泛規則，保留必要例外，避免日後其他服務被錯誤導向相同節點。
如果連線列表完全沒有出現預期的 Netflix 相關主機，先不要急著增加規則，因為這可能代表播放器使用了另一個應用程式程序、流量沒有進入 Clash，或瀏覽器快取了既有連線。如果主機已經命中代理，但速度仍低，則應把焦點放回節點品質、出口地區與影音服務當下的負載，而不是繼續修改 YAML。
常見設定誤區與對照方式
| 現象 | 較可能的原因 | 建議先做的事 |
|---|---|---|
| 首頁正常，播放轉圈 | 影片 CDN 走直連或錯誤策略組 | 查看播放期間的連線規則與出口 |
| 所有裝置都很慢 | 節點擁塞、線路品質差或尖峰限速 | 固定另一節點，做相同影片的對照測試 |
| 瀏覽器正常，電視 App 卡住 | App 不遵循系統代理 | 確認 TUN、路由器代理或裝置端支援方式 |
| 開啟 Fake-IP 後部分功能失效 | 網域被錯誤映射或本機例外不足 | 檢查 fake-ip-filter，暫改模式驗證 |
| 每次重新播放結果不同 | 策略組自動換節點或 DNS 快取未一致 | 暫停自動切換，固定節點與解析路徑 |
另外，請檢查是否同時開啟多個 VPN、瀏覽器代理擴充功能、路由器透明代理與 Clash TUN。多層轉發不一定會提高速度，反而可能造成 MTU 不合、TLS 重建、DNS 回路或出口 IP 反覆變更。若你使用的是手機，還要留意省電模式是否在螢幕關閉後停止 Clash 背景服務；若是 Windows 或 macOS，則要確認防火牆沒有只允許圖形介面啟動、卻阻擋核心程序建立連線。
穩定優先的原則：串流播放通常更適合固定一個表現穩定的節點，而不是每隔幾秒追逐最低延遲。低延遲、低抖動與持續吞吐量三者之間，應以實際播放結果作為最後判斷。
最後確認：把臨時修復整理成可維護設定
完成測試後，建議把設定收斂成簡單、可理解的結構：為串流服務保留一個清楚命名的策略組，避免把太多互不相關的網域塞在同一條規則；對 DNS 使用一致的解析方式，並只為確實有需要的本機網域建立例外；若使用 TUN，則確認區域網路、區域服務與系統更新不會被不必要地代理。每次更新訂閱後，也要重新查看規則集是否被覆蓋，因為遠端設定可能改變規則優先順序。
若問題只在特定時段發生，記錄日期、時間、節點、影片畫質與連線日誌，通常比反覆重裝 Clash 更有效。若同一節點在不同網路環境表現差異很大，還應比較家用 Wi-Fi、手機熱點與有線連線，排除路由器頻道干擾、封包遺失或 ISP 尖峰壅塞。當你能回答「哪個主機、哪條規則、哪個出口、哪個時間點」時，Netflix 卡頓通常就不再是只能靠猜的問題。
相比之下，部分同類代理工具的串流排查介面較簡略，規則命中、DNS 狀態與 TUN 流量不容易放在同一處查看，遇到「瀏覽器能播、App 卻卡住」時往往只能反覆重設；Clash 官網 則更適合把節點測試、代理模式、DNS 與分流規則分開驗證，並透過清楚的操作脈絡降低誤改設定的機會。如果你想用一套較容易觀察與調整的 Clash 工具來完成本文排查，不妨前往下載 Clash 官網，再依照上述步驟逐項確認 Netflix 的播放鏈路。