YouTube 用 Clash 播放卡頓、載入失敗怎麼解決？

YouTube 播放卡頓，不一定只是網速太慢

使用 Clash 播放 YouTube 時，最常見的症狀包括影片一直轉圈、畫質自動降到 360p、播放幾秒後停住、影片頁面打不開，或是縮圖與留言區載入失敗。很多人第一反應是測速，看到下載速度仍有幾十 Mbps，便認定 YouTube 本身出問題。實際上，影片播放是否順暢，不只取決於頻寬，還與延遲、封包遺失、節點出口、DNS 解析、分流規則以及不同 CDN 連線是否走同一條路有關。

YouTube 並不是只連線到一個網域。開啟首頁時，瀏覽器可能同時請求帳戶服務、影片資訊、縮圖、廣告、留言、播放器腳本與實際影片串流；影片開始播放後，又會依照畫質與網路狀態，從不同的 Google 或 YouTube CDN 主機取得分段資料。如果 youtube.com 走代理、影片 CDN 卻直連，或者播放器相關資源命中了另一個不穩定的策略組，就可能出現「首頁正常、影片卡住」的情況。

另外，節點延遲低也不代表它適合長時間播放。測速工具通常只測一個固定網址，影片串流則是持續下載大量分段資料。某個節點在短請求上的 RTT 很漂亮，卻可能在長連線、晚間尖峰或 YouTube CDN 流量上出現限速。因此排查時，應該把問題拆成「DNS 是否正確」「規則是否命中」「節點是否適合串流」三個層次，按照順序驗證，而不是一開始就不停切換節點。

先分辨卡頓類型：頁面、影片還是音訊出問題

不同症狀通常對應不同的故障位置。若 YouTube 首頁完全打不開，或登入頁面反覆重新導向，優先檢查主要網域、DNS 與代理模式；若首頁、搜尋與縮圖都正常，只有按下播放後持續轉圈，則更應觀察影片 CDN 的連線與節點品質。若畫面可以播放但聲音斷斷續續，或畫質在高低之間快速跳動，則可能是節點丟包、頻寬不足或連線被週期性重置。

建議先用同一部影片做測試，不要每次都換影片、換瀏覽器與換節點。記錄影片的解析度、播放進度、是否開啟代理，以及卡頓發生的時間。若能在 Clash 的連線或日誌頁面同時觀察到請求主機，便能知道卡住時到底是主頁服務、影片分段，還是某個額外資源沒有成功連線。這比單純執行一次網速測試更有參考價值。

檢查 Clash 模式與 YouTube 分流規則

首先確認 Clash 目前不是直連模式。在直連模式下，即使設定檔裡有完整的代理規則，YouTube 相關請求也不一定會經過節點。若使用規則模式，則要確認實際載入的設定檔就是你正在修改的那一份；不少「我明明改了規則卻沒有作用」的案例，原因只是編輯了備份檔或未啟用的 Profile。

接著打開連線日誌，重新整理 YouTube 並播放同一部影片。觀察 youtube.com、googlevideo.com、ytimg.com 等主機最後命中的策略。不同版本、不同地區與不同播放流程可能出現額外主機，因此不要只看到 youtube.com 命中代理，就推論整個影片播放鏈都已經走代理。特別是實際影片分段經常來自 googlevideo.com，若它被 MATCH、直連或錯誤的策略組接手，就很容易形成頁面可用、影片不穩的假象。

若你的設定檔使用自訂規則，建議先採取簡單且可驗證的做法：把 YouTube 主要網域與影片 CDN 暫時交給同一個穩定的代理策略組，確認播放是否恢復，再逐步縮小規則範圍。不要一開始就加入大量來源不明的規則集，因為規則越多，越難判斷是哪一條優先級造成誤命中。完成測試後，再依照日常需求把 Google 搜尋、YouTube、其他 Google 服務拆成不同策略。

rules:
  - DOMAIN-SUFFIX,youtube.com,Streaming
  - DOMAIN-SUFFIX,googlevideo.com,Streaming
  - DOMAIN-SUFFIX,ytimg.com,Streaming
  - MATCH,DIRECT

上面的內容只是示意，Streaming 必須替換成你設定檔中真實存在的策略組名稱。若節點名稱、策略組名稱或縮排不正確，Clash 可能無法載入設定，或在介面上顯示規則卻沒有按照預期執行。修改前最好先備份設定檔，儲存後確認核心沒有報錯，再透過日誌驗證實際命中結果。

DNS、Fake-IP 與 TUN：避免解析結果和路由互相衝突

DNS 是 YouTube 卡頓排查中很容易被忽略的一環。Clash 若使用系統 DNS、瀏覽器安全 DNS 與自身 DNS 模組同時處理請求，可能造成解析結果不一致。瀏覽器取得的影片 CDN 位址與 Clash 判斷的網域不一致時，規則嗅探、Fake-IP 映射或路由選擇都可能出現延遲。這類問題的特徵通常不是完全無法連線，而是同一個節點有時順、有時卡，重新整理後結果也不固定。

如果啟用 Fake-IP，請確認 YouTube、Google 登入相關網域沒有被不必要地加入 fake-ip 過濾清單，也要確認目前使用的核心確實支援設定檔中的 DNS 欄位。若你同時啟用瀏覽器的「安全 DNS」並指定另一家解析服務，瀏覽器可能繞過 Clash 的 DNS 設計，使你在日誌中看到的結果與實際連線不一致。排查時可以暫時關閉瀏覽器端的自訂安全 DNS，讓所有解析先交給 Clash，再重新測試。

TUN 模式則要另外確認路由是否重複接管。系統代理主要影響遵循系統設定的應用程式；TUN 會在更底層接收流量，若同時存在 VPN、企業端點防護、虛擬網卡或其他網路加速工具，可能產生路由迴圈、DNS 洩漏或 MTU 不合。建議一次只保留一種主要接管方式：先用系統代理確認瀏覽器播放正常，再開啟 TUN；如果開啟 TUN 後才出現卡頓，就把問題範圍鎖定在虛擬網卡、路由與 MTU，而不是重新懷疑每一個節點。

重要：不要為了「讓所有網域都走代理」而盲目關閉 DNS 保護、嗅探或路由排除。這些設定各自有用途，應以連線日誌和實際請求為依據逐項調整。

如何選適合 YouTube 的節點，而不是只看延遲

對串流而言，節點選擇至少要觀察四件事：延遲、持續下載速度、封包遺失率與尖峰時段穩定性。url-test 通常能協助你從一組節點中選出探針網址回應較快的成員，但探針結果不一定等同 YouTube 實際播放速度。某些節點對測試網址很快，卻對影片 CDN 的出口擁塞；另一些節點延遲略高，反而能穩定維持 1080p 播放。

測試時請固定影片與畫質，讓影片先播放三至五分鐘，再觀察「統計資料」或播放器顯示的實際連線速度。不要只看開始播放的前十秒，因為播放器通常會先預載一小段緩衝資料，足以掩蓋後續的限速。可以依序測試自動選擇、手動指定的鄰近地區節點，以及另一個地區的節點，並把結果記錄下來。若只有晚間卡頓，通常比較接近節點擁塞或供應商尖峰限速，而不是 YAML 規則突然失效。

• 優先測試連線穩定、持續速度高的節點，不要只追求最低 Ping。
• 若自動選擇頻繁切換，播放期間可能反覆建立新連線，應改用固定節點測試。
• 同一策略組中不要放入品質差異過大的節點，避免自動選擇結果忽快忽慢。
• 若只在某個瀏覽器卡頓，先停用擴充功能、硬體加速或瀏覽器自訂 DNS 做交叉測試。

仍然卡頓時：MTU、QUIC 與瀏覽器快取

當規則、DNS 與節點都確認無誤，才適合處理進階因素。部分網路環境對 UDP 或 QUIC 的支援不穩，瀏覽器可能優先使用 HTTP/3，導致影片開始播放後頻繁重連。你可以先以同一個瀏覽器測試停用 QUIC，或暫時改用另一個網路環境比較結果。這不是所有卡頓都適用的萬用解法；如果停用後沒有改善，應恢復原設定，避免把真正的問題藏在瀏覽器層。

TUN 使用者也可以留意 MTU。MTU 過大時，某些 VPN、行動網路或隧道環境可能發生分片與重傳，表面上仍能開啟網頁，長時間串流卻會出現畫面停住。不要直接套用別人的 MTU 數字，應先確認你的網路介面、隧道方式與核心文件，再從保守值逐步測試。每次只改一個參數，並在固定影片上觀察結果，否則很難知道改善究竟來自 MTU、節點切換，還是偶然的網路波動。

最後清理瀏覽器快取與網站資料，尤其是你曾經反覆切換代理、改用安全 DNS 或安裝播放器擴充功能時。快取通常不是 Clash 卡頓的根本原因，但損壞的 Service Worker、過期的播放器腳本或擴充功能攔截，確實可能讓頁面表現與另一個瀏覽器不同。建議用無痕視窗進行一次對照測試；若無痕模式正常，再逐項恢復擴充功能，而不是直接重裝 Clash。

常見問題

網速測試很快，為什麼 YouTube 還是會卡？

網速測試只代表測試伺服器到你目前出口的結果，不能保證 YouTube 影片 CDN 也使用同一條路徑。節點擁塞、封包遺失、影片 CDN 限速或 DNS 解析到較差的出口，都可能讓實際播放速度遠低於測速結果。請用固定影片觀察持續播放速度，並在 Clash 日誌確認影片連線的命中規則。

YouTube 一定要全部走代理嗎？

不一定。重點是讓實際需要代理的 YouTube 主機與影片 CDN 命中正確策略，而不是無條件把所有 Google 服務送往同一個節點。過度寬泛的規則可能增加延遲，也可能讓登入、搜尋與其他服務互相干擾。先用日誌確認需求，再逐步收斂網域範圍會比較穩定。

開啟 TUN 後反而更卡，該怎麼辦？

先關閉 TUN，保留系統代理，用同一部影片測試。如果卡頓消失，問題可能與虛擬網卡、路由衝突、DNS 接管或 MTU 有關。請確認沒有同時啟用其他 VPN、加速器或企業網路工具，並逐項檢查 TUN 的路由與 DNS 設定。

自動選節點一直切換，會影響播放嗎？

會。節點切換可能使現有影片連線中斷，播放器需要重新建立串流並重新緩衝。排查期間建議先手動固定一個穩定節點；確認規則與 DNS 沒問題後，再評估使用 url-test 或 fallback，並調整健康檢查頻率與候選節點品質。

相較於只提供簡單系統代理開關的部分工具，或需要手動維護大量規則、卻缺少清楚連線日誌的舊式客戶端，Clash V.CORE 更適合用來處理 YouTube 這種同時涉及主頁、播放器與 CDN 的播放問題：你可以查看實際命中規則、分離 DNS 與 TUN 設定，並用策略組固定或測試不同節點。當你希望把本文的排查流程落實到日常使用，直接前往下載 Clash V.CORE，再依照自己的裝置與核心版本建立一份可驗證、可回溯的播放設定，通常會比反覆更換不明工具更容易找出真正原因。