為什麼「4K」特別容易暴露路由與 DNS 問題？
YouTube 的 1080p 與 4K／高碼率並不是單純「解析度」差異：後者通常伴隨更高的瞬時頻寬需求、更長的分片下載鏈，以及更頻繁的自適應切換（ABR）。當瀏覽器或 App 向 googlevideo.com 等邊緣節點拉流時，若該連線被 分流規則誤判為直連，而您所在網路到該 CDN 路徑品質不佳，就會出現「畫面已選 4K、緩衝圈卻不停」的割裂感。反之，若只有網頁框架走代理、影片流仍直連，也可能因跨域策略組不一致導致播放會話重建、反覆重新協商。
另一個隱形因素是 DNS：FakeIP 映射若與實際連線路徑不一致，或某些 youtubei.googleapis.com、www.youtube.com 查詢落到被汙染／繞遠的上游，表面症狀會像「播放器壞了」，其實是名字解析階段就已偏航。這也是為什麼我們強調：規則與 DNS 必須一起調，而不是只換節點。
分流思路：只讓「會拉影片的那一群域名」走代理
實務上建議採用最小必要代理面：把與 YouTube 播放直接相關的域名桶（bucket）指向您的代理策略組，其餘流量維持 DIRECT，以降低延遲與頻寬爭搶。常見桶包括：（1）前端與帳號頁面：youtube.com、youtu.be；（2）影片與縮圖 CDN：googlevideo.com、ytimg.com、ggpht.com；（3）內部 API／protobuf：youtubei.googleapis.com 等 googleapis.com 子域；（4）部分環境還會看到 gstatic.com 承載腳本或字型。您不必一次背齊所有子域，但要在連線日誌裡確認：當卡住發生時，第一條命中規則是否落在上述桶之一。
若您使用內建 GEOSITE 資料，且訂閱規則集含 youtube 或更寬的 google 分類，可用一條 GEOSITE,youtube,YourProxyGroup 快速覆蓋大部分場景；但仍建議在調校期間開啟日誌，避免寬規則與後續 GEOIP 規則搶先命中。更細緻的國家／集合寫法可對照 GEOIP 與 GEOSITE 規則教學。
1Clash／Mihomo 規則：可貼上的 YAML 骨架
下列片段僅示範 rules 中與 YouTube 相關的靠前條目，請將 YourProxyGroup 替換為您設定檔內實際的策略組名稱，並與既有 proxies、proxy-groups、dns、tun 區塊合併。註解使用英文以利部分解析器相容。
# Snippet — merge into full config; comments in English for parser compatibility
rules:
- GEOSITE,youtube,YourProxyGroup
- DOMAIN-SUFFIX,googlevideo.com,YourProxyGroup
- DOMAIN-SUFFIX,ytimg.com,YourProxyGroup
- DOMAIN-SUFFIX,ggpht.com,YourProxyGroup
- DOMAIN-SUFFIX,youtu.be,YourProxyGroup
- DOMAIN-SUFFIX,youtube.com,YourProxyGroup
- DOMAIN-KEYWORD,googlevideo,YourProxyGroup
若您未使用 GEOSITE，可僅保留 DOMAIN-SUFFIX／DOMAIN-KEYWORD 列，並確保它們出現在過寬的 GEOIP,CN,DIRECT 或 MATCH 之前。記住：規則有序，命中即停；這也是多數「我寫了 googlevideo 仍直連」的根因。
已開 TUN 仍常在日誌看到純 IP？請改優先啟用 Sniffer，讓 HTTPS／QUIC 連線能還原 SNI，否則域名規則可能長期無法觸發。
2DNS 與 FakeIP：讓「名字」和「實際走的路」一致
DNS 調校請以「一次只改一個變因」為原則。若您使用 FakeIP，請確認 fake-ip-filter 是否意外排除關鍵域名、以及 tun.dns-hijack 是否覆蓋本機播放器使用的解析路徑。更多防洩漏與對照表可讀 Meta 核心 DNS 防洩漏指南。
實務上可為 youtube.com、googlevideo.com、googleapis.com 等後綴設定 nameserver-policy，指向您信任的 DoH／DoT 上游，避免某些本地 ISP DNS 對 Google 類域名回傳不理想結果。調整後請在核心日誌中比對：查詢的主機名、回傳的位址或 FakeIP 映射、以及後續連線命中的規則列是否閉環一致。
注意：將整個 google.com 無條件代理或無條件直連，常會與 Gmail、搜尋或其他服務互相牽連。本文聚焦影音播放相關桶位；若您有其他 Google 服務需求，請另行拆規則，避免「一刀切」造成次級問題。
3瀏覽器、App 與 QUIC：別忽略客戶端行為
Chromium 系瀏覽器常預設啟用 QUIC（UDP 443），部分環境下若只攔截 TCP 或規則對 UDP 處理不一致，會出現「網頁能開、影片斷斷續續」。除錯時可暫時關閉 QUIC 做對照，並在日誌確認 UDP 流是否同樣命中預期策略組。桌面 App、電視與行動裝置的實作各異，若症狀只出現在其中一類客戶端，請優先比對該平台是否繞過系統代理，必要時改以 TUN 統一接管。
硬體解碼、省電模式與背景分頁限制也會放大卡頓感；但在網路工具視角，仍應先用連線日誌排除「域名沒走代理／DNS 映射錯誤」，再處理裝置層設定。
可複現排查：從規則到節點的順序
步驟 A：確認第一條命中規則
重現一次卡頓後，記錄連線目標是域名還是 IP、命中哪一行 rules。若長期只有 IP，回到 Sniffer 與 TUN；若域名已可見卻仍走錯組，調整規則順序或收窄競爭的 GEOIP 條目。
步驟 B：對照 DNS 與 FakeIP
同時觀察解析階段：關鍵主機是否經過預期上游、FakeIP 段是否與連線一致。若出現「解析看起來正確、策略卻不符」，請檢查是否有多層 DNS 外掛或瀏覽器安全 DNS與核心搶同一條查詢。
步驟 C：節點與頻寬
當規則與 DNS 皆合理，才優先懷疑節點頻寬或高峰壅塞。4K 對單線路壓力更大，可暫時改用手動節點對照，避免將問題誤判為「Google 故障」。
小結：YouTube 高碼率卡頓，多半是「影片 CDN 域名＋API 域名」與 DNS／FakeIP 未閉環，而不是單一開關。依序收斂後再換節點，最能節省時間。
合規聲明
請在遵守 YouTube／Google 服務條款、版權與當地法規的前提下使用網路工具。本文僅討論本機路由與 DNS 除錯，不鼓勵規避區域限制、下載未授權內容或其他違規用途。
開源資訊與安裝包取得方式
Clash 生態的核心與圖形介面多為開源專案；授權條款與原始碼可至公開程式庫查閱。日常安裝或更新客戶端仍建議以 本站下載頁 為主，並搭配 設定說明文件，將「取得安裝包」與「閱讀開源倉庫」分開理解。
結語
當 YouTube 在 4K 或高碼率下頻繁緩衝，與其反覆切換「全局規則集」，不如在 Clash／Mihomo 裡建立一套可驗證流程：先用日誌確認 googlevideo 等分流規則是否靠前命中，再校準 DNS 與 FakeIP，必要時用 Sniffer 補齊 HTTPS／QUIC 下的主機名資訊。相較於只模仿他人訂閱，理解「為什麼這條流量會走這個策略組」能讓您在規則集更新後仍保有播放穩定性的自主排查能力。
若您尚未安裝客戶端，可先從本站取得程式並匯入訂閱，再依本文順序檢查；多數與 CDN 誤判相關的卡頓，都能在規則與 DNS 對齊後明顯改善。