YouTube 分區錯了怎麼改？Clash 節點選擇與 googlevideo 分流、DNS 實測步驟

現象：分區標籤不對、Premium 與出口不一致，或出現「僅在特定國家／地區提供」

許多使用者在 Reddit、論壇或社團會用「YouTube 地區不對」「首頁像別的國家」「買了 Premium 卻顯示與帳單地址不符」或播放列表上出現 only available in certain countries 之類提示來描述問題。與長影片平台類似，YouTube 同時看帳戶／付款與方案所在區、實際連線的 IP 所屬區域，以及實際下載影片片段時碰到的 CDN 主機是否自洽；任一段落在本機被直連、或 DNS 先在非預期上游完成解析，都可能讓客戶端得到「混在一起」的判定。

實務上 YouTube 的大量位元組往往經由 googlevideo.com 一類主機名傳遞，與 Netflix、Disney+ 等公司各自獨立的 CDN 命名習慣不同；因此只複製「串流大表」卻沒對照日誌，很容易漏掉真正在吃頻寬的那幾條Clash 分流規則。本文與站內 Netflix、Disney+、Max 分流專文在關鍵網域與排錯重點上刻意區隔，聚焦 YouTube 分區與 googlevideo 鏈路，並把節點選擇與DNS 洩漏放在同一套檢查清單裡。請在合規與服務條款允許的前提下閱讀；Clash 僅為本機代理工具，不提供遠端節點。若尚未匯入訂閱，可先完成 訂閱匯入，再依序調整下文。

為什麼「介面正確、播放卻不像同一個地區」很常見？

瀏覽器或 App 載入首頁、搜尋與註解介面時，往往走 youtube.com、youtubei.googleapis.com 等一組主機名；而按下播放後，真正拉高流量的連線可能落在 *.googlevideo.com 或其他與媒體傳遞相關的後綴上。若您的規則只寫了前者、而後者仍被寬鬆的 GEOIP 或 MATCH 送到 DIRECT，就會出現介面上的地區敘事與串流出口敘事脫節。這和「單純換一個延遲較低的節點」不是同一層問題：優先該確認的是每一段連線是否都命中您預期的策略群組。

另一種情況是 DNS 洩漏：系統或瀏覽器仍向 ISP／路由器內建 DNS 查詢，得到與代理出口地理上不一致的結果，Clash 內規則看似正確，握手時卻已帶著別條故事線。若您使用 enhanced-mode: fake-ip，還要留意 fake-ip-filter 與 nameserver-policy 是否讓部分 Google 相關查詢繞開了與其他流量一致的路徑。

第一步：規則模式、日誌與系統代理／TUN

請先確認用戶端為 mode: rule，並在實際播放一支影片的同時開啟連線日誌。檢查 youtube、googlevideo、ytimg、與日誌中新出現的 google 相關主機，是否一律落到您自訂的策略群（例如 YOUTUBE_PROXY），而不是零星仍標示為 DIRECT。若發現僅有介面走代理、片段直連，應回頭調整規則順序，把明確的 DOMAIN-SUFFIX 置於過寬規則之前，語意可對照 規則分流詳解。

若您僅啟用系統 HTTP 代理而未有 TUN，部分桌面程式、電視或遊戲機上的 YouTube 客戶端可能不讀系統代理，導致瀏覽器正常、大螢幕 App 卻像「另一個地區」。此時可評估改為 TUN 模式，讓該裝置的預設閘道與 DNS 請求納入同一套路徑；細節亦可對照站內僅瀏覽器可走代理類文章，避免把路由問題誤判成單一網站故障。

第二步：DNS、fake-ip 與 DNS 洩漏一起查

在本機使用 Clash／Mihomo 時，DNS 區塊與規則區塊應視為同一個設計。若您對 Google 相關網域使用了獨立的 nameserver-policy，請確認該上游的地區語意與您希望 YouTube 呈現的語境一致；否則可能出現「API 與 CDN 各自解讀」的割裂。調整後請清除本機與瀏覽器的舊快取，並重新開啟客戶端再測。

DNS 洩漏的實務徵兆包括：同一支手機上瀏覽器與官方 App 顯示的內容可用範圍不一致、或剛換節點後仍長時間維持舊區體驗。處理原則是讓 DNS 查詢與 TCP／QUIC 連線走同一套策略優先順序，必要時關閉實驗性的第二套 DoH、公司 VPN 或與 Clash 搶答的私人 DNS。若啟用嗅探，請一併參考 嗅探與串流網域，避免與規則匹配順序互相抵消。

第三步：分流規則——youtube 與 googlevideo 同群組

目標是讓介面、授權與實際影片片段落在同一個 proxy-groups 條目，避免「首頁代理、googlevideo 直連」的典型分裂。撰寫時仍遵守由上而下命中即停；下列骨架僅供教學，實際後綴請以您實測日誌為準，勿盲目貼上過大的第三方清單，以免與其他業務流量衝突。

YAML（示意骨架）# proxy-groups：建議單一群組集中測試節點
proxy-groups:
  - name: "YOUTUBE_PROXY"
    type: select
    proxies:
      - "節點 A"
      - "節點 B"
      - DIRECT

rules:
  # 依連線日誌收斂，勿靜態猜測
  - DOMAIN-SUFFIX,youtube.com,YOUTUBE_PROXY
  - DOMAIN-SUFFIX,googlevideo.com,YOUTUBE_PROXY
  - DOMAIN-SUFFIX,ytimg.com,YOUTUBE_PROXY
  - DOMAIN-SUFFIX,ggpht.com,YOUTUBE_PROXY
  # ...其餘維持原訂閱與兜底 MATCH

部分環境還會出現 googleusercontent、與 API 相關的 googleapis 子域；是否納入同一群組，應以播放一次影片時日誌中反覆出現的主機名為準。與 Netflix 分流相比，YouTube 更依賴 googlevideo 這類媒體承載名稱，關鍵字維護重心不同。長期維護建議採「日誌收斂→置前 DOMAIN-SUFFIX」的循環，而不是一次導入不可解釋的萬用表。

第四步：節點選擇與「地區故事」一致性

儀表板延遲僅反映短連線探測，與長影片位元率穩定性不等價。節點選擇時應在同一策略群內對照實驗：每次切換後完全關閉 YouTube App 或分頁、必要時清除 App 暫存，再重新載入，否則工作階段可能沿用舊的邊緣導向。若您使用家庭方案或跨區方案，亦須理解帳單國家／語系設定與出口 IP 的組合在服務條款下的含義——技術上對齊規則與 DNS 後，若仍提示方案不符，才較可能屬帳戶層問題。

請留意您是否同時開啟第二條 VPN、公司 Split Tunnel、或行動熱點。若作業系統層把某類流量優先送往另一介面，會出現「Clash 日誌看似正確、客戶端仍讀到別的出口」的錯覺；此時應檢查路由表與預設閘道，而不是反覆更換訂閱裡的標籤名稱。

瀏覽器、手機 App 與大螢幕：路徑常常不同

桌面瀏覽器最容易受「外掛代理與 Clash 並存」影響，建議測試時先統一為單一路徑。Android／iOS App對 VPN、本機代理與私人 DNS 的處理各異，部分 OEM 還會對特定 App 繞行 VPN，需逐項在系統設定確認。智慧電視、電視棒與遊戲機常缺乏完整 HTTP 代理設定，若只改路由器 DNS 而未讓 TCP／QUIC 走同一策略，仍會發生診斷頁正確、播放仍異常的落差。高解析或 HDR、直播與 Shorts 往往會觸發額外子網域，若畫質卡在低位，除頻寬外亦可把「是否仍有 googlevideo 直連」列為優先假設。

實測檢查清單

1. 模式：確認為規則模式，並排除與其他整機 VPN 的競爭。
2. 日誌：播放前後檢視 youtube 與 googlevideo 是否皆命中 YOUTUBE_PROXY（或自訂群組）。
3. 規則收斂：將日誌中新主機名補成置前的 DOMAIN-SUFFIX，避免被寬規則提前帶走。
4. DNS 單一路徑：暫停多餘 DoH／第二 DNS，僅保留與 Clash 協調後的上游再測。
5. 洩漏檢查：瀏覽器與官方 App 各測一次，對照是否仍出現內容可用範圍不一致。
6. 同群組換節點：僅在同一策略群組內切換，並重啟客戶端後再判讀。
7. 帳戶層：在允許時以已知良好網路直連對照，區分技術設定與付款／方案限制。

結語

修正 YouTube 分區相關困擾時，請把 googlevideo 與介面網域放在同一個Clash 分流敘事裡，並與 DNS 洩漏、fake-ip 政策一併檢視；相比只盯著節點選擇上的延遲數字，先確保日誌中無「片段直連」往往更有效。長期維護採日誌驅動的置前規則，通常比靜態巨型表更穩定，也較容易與 Netflix、Disney+ 等其他媒體規則並存而不打架。

若您希望從可信用戶端與文件起步，再逐步加上自訂規則，整體路徑會更清楚。完整入門與進階說明可參閱 教學文件。