一、為何網頁播放會轉圈、緩衝
在瀏覽器開啟 YouTube 時，除了網址列上的主機名，頁面還會向多個子網域請求腳本、樣式、縮圖、字型與影片片段。其中實際承載影片串流的主機，常落在 *.googlevideo.com 這類 CDN 名稱上；若你的 Clash 規則只把 youtube.com 指到代理，而 googlevideo.com 仍 DIRECT 或落到另一個策略組，就可能出現半套連線：介面載得到、播放器卻長時間緩衝或反覆重新解碼。
另一常見情況是出口跳動：同一播放工作階段內，不同請求經過不同國家或不同供應商的節點，CDN 可能反覆切換邊緣節點，表現為進度列卡住、畫質無法穩定提升。此時與其只調「延遲最低」的自動選線，不如先把 YouTube 相關網域收斂到同一策略組，再於該組內挑選頻寬與穩定度較適合長串流的線路。
二、與 Gemini／泛 Google 專文的差異
站內 Google Gemini／Google API 分流專文 主要處理 gemini.google.com、googleapis.com、Generative Language 等對話與 API場景，重點在網頁與 API 主機的出口一致。YouTube 雖同屬 Google 生態，但影片播放額外依賴大量高頻寬連線與 googlevideo CDN，故障表現也更像「串流卡頓」而非單純登入或 JSON 逾時。
因此建議把「YouTube 影音用途」視為獨立規則區塊：可沿用同一套方法論（策略組、RULE 順序、DNS 對齊），但網域清單必須補齊播放與 CDN 相關後綴，而不是只複製 Gemini 文內的最小集合。兩組規則並存時，也請注意規則順序，避免較寬鬆的 GEOIP 或 MATCH 提前截斷。
| 面向 | Gemini／Google API 專文 | YouTube 網頁播放（本文） |
|---|---|---|
| 典型困擾 | 控制台載入失敗、API 握手逾時、對話中斷 | 播放器緩衝、轉圈、畫質上不去、進度列抖動 |
| 流量重心 | HTTPS API、較多短請求與 WebSocket | 大量影片分段下載，高度依賴 CDN 與長連線 |
| 規則維護重點 | googleapis、Gemini 主機、OAuth 相關網域 |
youtube.com、googlevideo.com、ggpht.com、ytimg.com 等（以實際連線為準） |
三、播放鏈路：從播放頁到 googlevideo
播放頁與 API
瀏覽器載入影片頁時，通常會請求 www.youtube.com 或地區化子網域上的 HTML 與腳本，並透過站內 API 取得播放清單與格式資訊。若這些請求與後續媒體片段請求的出口國家／ASN不一致，部分情境下會觸發額外重試或邊緣節點切換，體感上就是一直緩衝。
googlevideo 與 CDN
實際影片資料往往來自 *.googlevideo.com（主機名會隨連線與地區變化）。若此類請求未納入與播放頁相同的代理策略，最容易出現「看得到介面、影片轉圈」的分裂路由。撰寫規則時，以 DOMAIN-SUFFIX,googlevideo.com 覆蓋後綴，通常比逐條寫完整主機名更耐久；仍請以開發者工具「網路」面板核對你當下環境實際出現的主機名。
縮圖、靜態與字型
縮圖常見於 ytimg.com、ggpht.com 等；腳本與樣式可能涉及 gstatic.com。這些請求若與影片 CDN 分裂，較少直接造成「完全無法播放」，但可能加劇前端重試與載入不穩定。若你追求同一工作階段內所有 YouTube 相關請求一致出口，可將上述後綴一併納入同一策略組，並觀察是否改善體感。
四、直播與點播的連線差異
點播（VOD）多半以可快取的分段檔為主，CDN 命中與多解析度切換較常見；若節點頻寬不足，典型現象是清晰度自動下降、分段下載變慢。直播（Live）則更依賴低延遲與連續串流，對抖動與丟包更敏感；同一條線路在點播「勉強能看」、直播卻可能頻繁卡頓。若你主要觀看直播，建議在固定策略組內優先選擇丟包率低、頻寬餘裕大的節點，並避免與大量下載共用同一出口。
網頁端直播仍會走類似的 Google 主機與 googlevideo 系 CDN；差異更多在連線型態與播放器行為。排查時可先在「網路」面板區分：是初始播放清單請求失敗，還是媒體分段持續 pending；兩者對應的規則補強方向不同。
五、分流規則：建議納入的網域與後綴
以下示例以常見 Mihomo／Clash 規則格式撰寫，PROXY 請替換為你設定檔中的策略組名稱。實際主機名可能隨產品更新而增減，請務必以瀏覽器開發者工具「網路」面板與日誌交叉驗證；第三方嵌入播放器或廣告可能再引入額外網域，需依實況補條目。
若訂閱已內建「YouTube」或「Google」類規則，仍請檢查順序：較早的 GEOIP、IP-CIDR 或過寬的 DOMAIN-KEYWORD 可能讓部分子請求提前匹配完畢。對不確定的主機名，可短期以 DOMAIN 精確補網，再逐步收斂為 DOMAIN-SUFFIX。
使用 fake-ip 時，請確認 YouTube 相關網域在解析鏈上的行為與實際連線一致；若規則命中與真實出站不符，可對照 fake-ip 與 DNS 排查專文 逐步收斂。
六、節點選擇、頻寬與區域
將 YouTube 相關後綴指到同一策略組後，體感仍取決於節點品質。長影音對頻寬與連線穩定度要求高於一般網頁瀏覽，建議在該策略組內使用延遲合理、丟包較低的線路，並避免與 P2P 下載或大量平行連線搶佔同一出口。
區域方面，請選擇與你的帳號與使用情境相符、且可長期維持的區域；短時間內頻繁跨區切換節點，可能讓 CDN 與工作階段狀態更難穩定。若必須更換節點，建議在同一策略組內切換並觀察一段時間，而不是同時在多裝置、多出口之間跳轉。
| 現象 | 優先調整（網路層） |
|---|---|
| 介面正常、影片一直緩衝 | 檢查 googlevideo.com 是否仍直連或落到其他策略組；統一後綴與策略組 |
| 畫質鎖在低解析度 | 評估節點頻寬與丟包；避免與其他高流量任務共用出口 |
| 僅直播卡、點播尚可 | 優先換丟包更低、延遲更穩的節點；減少同時分頁播放 |
| 同一節點時好時壞 | 檢查是否啟用會頻繁切換出口的自動策略；改手動固定並對照日誌 |
部分節點對 HTTP／2、QUIC 或長時間 TLS 連線的支援度不同，可能表現為「首次連線慢、其後略好」。若你已鎖定網域仍不穩，可在同一策略組內對照不同供應商，而不是只調整全域規則。
七、DNS、Fake-IP 與系統／TUN 模式
完成分流規則後，建議依序驗證：
- 瀏覽器開發者工具「網路」：篩選
googlevideo相關請求是否失敗、pending 過久或被阻擋。 - 本機解析：對
youtube.com與實際影片主機檢查解析結果；若使用 fake-ip，對照 Clash 日誌中的實際連線與規則命中。 - DoH：若瀏覽器或系統繞過 Clash 直接查詢，可能導致「規則寫了後綴，連線仍不一致」。
- 模式：僅系統代理時，少數元件可能不遵循代理；若懷疑流量未進核心，可評估 TUN 與平台限制（與本站其他 TUN 排查文互補）。
企業或校園網路若攔截 DoH、注入憑證或限制 UDP，可能表現為間歇性失敗；應先釐清是否屬於資安政策範圍，再調整客戶端。
八、可復現排查順序
建議依序執行，每完成一步再進入下一步，避免同時改動多處而無法判斷有效變因。
- 確認模式：釐清系統代理、TUN 或僅瀏覽器外掛；行動裝置另需考慮 App 是否繞過系統代理。
- 開發者工具「網路」：篩選失敗或長時間 pending 的請求，記錄主機名是否落在規則清單外。
- 補齊規則：將
googlevideo.com等後綴以DOMAIN-SUFFIX納入與播放頁相同的策略組，並檢查RULE順序未被前置規則覆蓋。 - 鎖定節點：在該策略組內手動選定一個穩定節點，暫停自動輪換，確認是否排除出口跳動。
- DNS 對齊：檢查 fake-ip、DoH 與本機解析鏈是否與 Clash 設定一致。
- 日誌驗證：於 Clash 日誌確認命中規則與出站是否符合預期，再決定是否更換節點供應商。
若你在 Windows 上搭配 TUN 仍遇到整機路由異常，可再對照 Clash TUN 與 Windows 路由／防火牆排查專文，先確保流量進入核心，再微調 YouTube 規則。
九、合規與服務條款
請遵守 YouTube 與 Google 服務條款、著作權與內容政策，以及所在地法律。本文所述為一般網路一致性與客戶端設定思路，不保證特定地區或網路環境下的播放品質，亦無法繞過官方技術或商業限制；若問題仍在，請依官方支援管道與網路供應商協助排查。
十、小結
面對 YouTube 網頁播放長時間轉圈、緩衝或畫質異常，網路層可先檢查分流規則是否覆蓋 googlevideo 與播放鏈路相關後綴（含 youtube.com、ytimg.com、ggpht.com 等，並以實際連線為準），並確認節點選擇具備足夠頻寬與穩定度，且 DNS、fake-ip 與代理模式彼此對齊。與 Gemini／Google API 專文相比，本文刻意聚焦影片 CDN與串流體感，方便你分開維護兩組規則區塊。
相比只能切換少數開關的工具，Clash 生態在規則可視化、核心替換與多平台客戶端上，更利於長期維護；把 YouTube 相關網域與策略組整理清楚後，日常多半只需微調節點選擇即可。
若你尚未安裝或希望使用更易管理的客戶端，可從本站取得安裝包並匯入訂閱，再依本文補上 YouTube 與 googlevideo 相關規則與策略組。