一、先對齊現象：緩衝、鎖畫質與登入異常是三件不同層次的事

YouTube 的播放體感問題，粗略可分三類。第一類是純緩衝：畫面已開始播放，但位元組下載速度追不上播放速率，緩衝圈反覆出現。第二類是看似「鎖畫質」：手動切到高解析度仍顯示不可用，或自動模式長期壓在 480p、360p；這除了頻寬不足，也很常是實際拉流的 googlevideo 主機沒有走在你預期的出口上，導致客戶端低估可支援的編碼與解析度。第三類是帳號與權杖層：已登入 Google 帳號卻反覆跳出驗證、Premium 狀態不同步、或付費方案相關頁面載入不完整；此時要優先檢查 accounts.google.com、OAuth 回跳與 API 請求是否與影片 CDN 屬於同一策略脈絡。

把問題分層的好處是：你不會一開始就把所有流量改成全域代理來「矇眼通過」。全域模式有時能掩蓋半套用代理造成的割裂，但代價是本機其他應用與區域網裝置也被迫走同一出口，除錯時更難判斷真正命中的網域。較務實的路徑是：先用連線日誌回答「哪些主機名稱真的在出現在播放當下」，再把 Clash 分流寫清楚。

在改規則前，請確認訂閱與策略群組名稱正確。若尚未匯入設定檔，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在群組名稱錯誤時空改 YAML。

二、與 Netflix、Spotify 專文有什麼不同（勿混抄）

站內Netflix 相關文章聚焦影片串流於 nflxvideo.net 等區庫與 CDN；Spotify 專文則是音訊與 scdn.co 等路徑。本文主題是 YouTube：核心影片負載位於 googlevideo 子網域樹，同時強烈依賴 Google 通用帳號與 API 命名空間。三者的排查順序可以類比（先模式、再日誌、再 DNS），但規則表不可互換。

若你關心的是其他 Google 產品（例如搜尋、雲端文件）而非影片播放器，也可參考《Gemini 與 Google 網域分流》對 google.com 家族切分的思路；但 YouTube 專屬的播放與廣告路徑，仍以本文整理的 youtube.com 與 googlevideo.com 對齊為優先。

三、為什麼「googlevideo」與「帳號網域」必須一併看

簡單講：你在瀏覽器網址列看到 youtube.com，不代表位元組都從同一棵主機樹下載。實際上，播放器會依影片與縮圖請求，向大量形如 rr1---sn-xxxxx.googlevideo.com 的主機建立連線；這些名稱通常落在 googlevideo.com 這個後綴底下（實際前綴與區域代碼請以你的日誌為準）。同時間，帳號狀態、個人化推薦、留言與部分 API 仍會經過 youtube.com、youtu.be 跳轉與 googleapis.com。

若你的規則只覆蓋 youtube.com，卻讓 googlevideo.com 落到 DIRECT、或落到另一個地理位置差很遠的節點，就很容易出現「介面正常、播放異常」或清晰度鎖定在低頻寬模式。相反地，若只有影片走了代理、帳號與 OAuth 卻直連，則可能登入迴圈或會員狀態不一致。這就是為什麼我們強調要分流 googlevideo 與帳號網域時，兩條路徑要嘛落在同一組可連通的策略群組，要嘛刻意分開但要符合你帳號預期區域與網路政策，而不是被規則表前半段的寬鬆條目隨機命中。

四、為什麼不建議只靠「開全域」解 YouTube 體感問題

全域模式短期內可能讓幾乎所有 TCP 連線都經過代理，因而掩蓋「部分網域直連、部分走代理」的半通狀態。缺點是你較難從日誌判斷究竟是哪一條主機名稱仍在走錯出口，長期維護成本高；同時部分本可直連的內容與區域網服務也會被拖進代理路徑，延遲與相容性問題可能浮現。

對 YouTube 而言，更值得做的是在規則中明確寫出你在日誌中反覆看到的後綴，例如 googlevideo.com、youtube.com、ytimg.com（縮圖與靜態資源常見方向）、以及帳號與 API 相關的 google.com、googleapis.com、gstatic.com，並把這些條目放在過寬的 MATCH 與地區直連清單之前。這樣你才能維持其他流量的細分流，而不是為了單一網站犧牲整機路由可預期性。

五、建議排查順序（先證明流量有進核心）

下列順序刻意把「換節點」放在中後段：先確認程式流量有經過 Clash，且規則命中正確，再談線路品質。

  1. 確認 Clash 正在執行，且你使用的是系統代理或TUN；若症狀主要出現在 YouTube App／智慧電視，優先驗證該裝置是否真的走了本機 Proxy 或被閘道轉發，必要時改採閘道透明代理或 TUN。
  2. 在連線日誌中重新整理影片頁並開始播放，確認 googlevideo 相關主機是否出現在日誌內，且策略欄位命中預期群組，而不是 DIRECT 或被前置規則誤判。
  3. 檢查 DNS 模式（是否 fake-ip）、以及關鍵後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析結果與連線決策脫鉤。
  4. 把 YouTube 相關後綴與你在日誌中觀察到的 googlevideo、帳號與 API 主機名稱一併收斂到規則表前段，置於過寬的 MATCH 之前。
  5. 在規則已正確命中的前提下，再為長連線與影片下載選擇掉包少、切換不頻繁的節點；若你懷疑系統代理遺漏特定程式，請閱讀《Clash TUN 模式開啟方法》後再啟用 TUN 驗證。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文重點放在 YouTube 場景下的 googlevideo 與帳號網域對齊。

六、網域怎麼收集：不要只抄舊清單

「YouTube 分流懶人包」在社群論壇很常見，但 CDN 與邊緣命名會隨時間調整，最可靠的做法仍是自己在 Clash 連線清單或瀏覽器開發者工具網路面板中操作一輪：開啟首頁、播放一支長片、切換解析度、開啟留言與帳號選單，觀察哪些主機名稱在播放與互動瞬間大量出現。把這些名稱依後綴分組，優先為實際命中的完整後綴寫 DOMAIN-SUFFIX，比單純 DOMAIN-KEYWORD 更不易誤傷其他站點。

實務上常見方向包括：googlevideo.com（影片位元組與媒體片段）、youtube.com 與 youtu.be（頁面、API 與重新導向）、ytimg.com（縮圖與靜態）、googlevideo.com 以外的 Google 媒體邊緣（若日誌出現再加）、以及帳號與通用靜態資源的 google.com、gstatic.com、googleapis.com。是否要把整棵 google.com 都走同一群組，涉及你對其他 Google 服務的分流策略；若採較窄集合，就更需要日誌補齊遺漏子網域。

七、系統代理與 TUN：讓流量真的進核心

系統代理適合多數會讀取系統 Proxy 設定的瀏覽器。若你只在 Chrome／Edge／Safari 使用 YouTube 網頁版，開啟系統代理並指向 Clash 的 mixed 埠，通常即可。但若你發現「瀏覽器正常、手機 App 或電視盒上的 YouTube 仍緩衝或鎖畫質」，代表該程式沒有完整走系統代理，此時應考慮閘道層轉發、或在支援的桌面環境啟用 TUN 模式於網路層統一接管。

TUN 會改變路由與權限邊界，請先閱讀《Clash TUN 模式開啟方法》後再操作，並回到連線日誌確認與 YouTube 相關的連線是否都經過 Clash。無論使用何種模式，請在用戶端確認「目前啟用的設定檔」與你編輯的 YAML 為同一份。

八、DNS 與 fake-ip：為何會放大「緩衝」與「鎖畫質」感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址，再在連線階段依規則決定出口。若 DNS 與規則配合不當，可能出現解析與實際連線策略不一致，或特定 HTTPS 握手階段反覆重試。對依賴多子網域與邊緣切換的影片服務，症狀常是縮圖與介面已顯示，播放鈕卻長時間無法穩定下載位元組，或客戶端誤判頻寬而維持在低解析度自適應。

實務上可以分兩步處理：第一，確保用於解析海外網域的 DNS 上游可達且可信；第二，對反覆出問題的 googlevideo 與 YouTube 相關後綴視需要設定較穩定的解析策略（例如在用戶端支援的欄位中為特定網域指定 DoH），減少汙染或不一致造成的偶發失敗。若調整 DNS 後症狀明顯緩解，代表先前瓶頸有相當比例在解析鏈路，而非單純節點速度。

九、分流設計檢查清單（請以實測網域為準）

下表提供規劃 Clash 分流規則時的思考方向；欄位中的範例可能隨產品更新而變動，務必以你自己的連線日誌為準。

類型常見主機名稱方向（範例）設定提示
影片位元組與媒體*.googlevideo.com 等YouTube 緩衝時優先核對此類主機是否誤直連或被截到錯誤群組。
網頁與 APIyoutube.com、youtu.be介面與部分 API 請求宜與播放決策同一策略脈絡，避免頁面走代理、媒體直連。
帳號與 OAuthaccounts.google.com、google.com 相關子域登入、驗證與 Premium 狀態若與影片 CDN 出口不一致，易出現反覆驗證。
靜態與共用 APIgstatic.com、googleapis.com播放器腳本、字型與 API 呼叫常被忽略；半載入時請一併檢查。
縮圖與靜態圖像ytimg.com 等僅畫面「看起來卡、但沒有緩衝圈」時，對照此類資源是否被擋或走錯出口。

十、分流規則範例（請替換為你的策略群組名稱）

下列 YAML 片段示範「把常見 YouTube／Google 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為你實際的策略群組名稱，並留意規則順序：更具體的條目應置於過寬的 MATCH 與地區直連清單之前。若你在日誌中看到其他專用後綴，請以 DOMAIN-SUFFIX 逐條補上，而不要只靠單一關鍵字。

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,youtube.com,PROXY
  - DOMAIN-SUFFIX,ytimg.com,PROXY
  - DOMAIN-SUFFIX,googlevideo.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,google.com,PROXY

其中 DOMAIN-SUFFIX,google.com,PROXY 覆蓋面極大，是否整棵走代理應審慎評估你的整體上網習慣；較保守的做法是先用日誌鎖定與播放同秒出現的 accounts.google.com、oauth 相關子網域，再用更精準條目收斂。重點是不要讓 googlevideo 與帳號路徑在不知情的情況下落到互相矛盾的出口。

十一、節點品質與「技術連通」以外的提醒

影片串流常伴隨長連線與大量分段請求；短時間延遲低、但間歇掉包或策略群組頻繁自動切換，會讓 TLS 工作階段重建，介面上就像無限緩衝或解析度無法爬升。較務實的做法是：在規則已正確命中的前提下，為 YouTube 相關策略選用一段時間內穩定可達的中繼。

同時請理解：本文僅討論網路路徑與 Clash 分流技術層面的排查；帳號註冊地、內容授權、Premium 方案與當地合規仍受平台政策約束，讀者需自行遵守適用地區法律與服務條款。若你希望比較不同傳輸協定在弱網下的表現，也可參考《Shadowsocks vs Trojan vs Hysteria2》。

十二、圖形用戶端中如何少踩坑

在 Clash Verge Rev 等圖形用戶端中，建議開啟即時連線清單，篩選包含 googlevideo、youtube 或 ytimg 的主機名稱，逐條確認策略與最終出口。若某條顯示為 DIRECT，請回到規則表檢查是否有前置的地理分流、廣告清單或「繞過區域網」規則攔截了該網域。

若你尚未完成桌面端基礎設定，可先依《Clash Verge Rev 完整設定教學》把訂閱與系統代理跑通，再回到本文補上 YouTube 專用規則，會最省時間。

十三、小結：把「YouTube 緩衝與鎖畫質」變成可驗證的規則問題

2026 年搜尋 YouTube Clash、googlevideo、YouTube 緩衝 或 清晰度鎖定 時，可依序確認：模式是否覆蓋網頁與 App、DNS 與 fake-ip 是否一致、googlevideo 與帳號／API 網域是否一併命中，以及節點是否穩定。依序驗證後，你會在連線日誌中看到明確證據，而不是盲目更換節點卻無法改善播放體驗。

當你希望把連線觀測、規則編輯與核心更新集中在同一套成熟用戶端時，官方維護的桌面方案通常能顯著降低手寫 YAML 的低階錯誤，也讓 Clash 分流規則的迭代更安全。相較其他同類工具，Clash 在規則透明度與日誌對照上的體驗通常更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗