一、先對齊現象：登入轉圈與「初始化」多半是控制面與 CDN 拆散

Battle.net 客戶端在背景會同時建立多條連線：一邊向暴雪系網域索取帳號狀態、目錄與更新中繼資訊，另一邊向補丁與內容傳遞邊緣節點拉取大量位元組。若你的規則只覆蓋其中一類主機名稱，或客戶端程序根本沒有經過 Clash，畫面上就容易出現戰網更新失敗、進度長時間停在準備階段，或登入流程無法完成：因為控制面可能已回應「可以繼續」，但實際資料通道卻在錯誤的出口上逾時。

另一種常見組合是瀏覽器內嵌登入或網頁已走代理，而桌面客戶端仍嘗試直連，導致工作階段無法對齊。此時若盲目開啟全域代理，有時會「碰巧」全部走同一出口而暫時正常，卻讓其他本可直連的流量也繞路，延遲與相容性問題反而增加；較穩健的做法仍是依網域分流，讓 Battle.net 與 Blizzard 相關後綴一致命中同一策略脈絡。

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

二、為什麼不建議只靠「開全域」解 Battle.net 問題

全域模式會讓幾乎所有 TCP／UDP 連線都走代理出口，短期內可能掩蓋「部分網域直連、部分走代理」造成的半通狀態，但缺點也很明顯：本機其他服務、區域網裝置與部分遊戲反作弊模組可能對額外延遲或 NAT 型態敏感；同時你也較難從連線日誌判斷究竟是哪一條主機名稱出了問題。

對 暴雪戰網 Windows客戶端而言，更值得做的是：在規則中明確寫出 battle.net／blizzard 相關後綴，以及下載與補丁 CDN 常見後綴（例如部分環境會看到 akamaized.net 等邊緣名稱），並讓它們落在同一組可連通的策略群組。這樣一來，你仍可在其他流量上使用較寬鬆的 DIRECT 或細分流，而不必為了單一平台犧牲整機路由。

三、Windows 重點：Battle.net 與「只開系統代理」的落差

與典型瀏覽器不同，Battle.net 屬於獨立桌面程式，更新與下載模組不一定會完整遵循 Windows「Proxy」設定；實務上常見情況是：你已為瀏覽器設定好 Clash 的 mixed 埠，官網或帳號網頁看似正常，而背景下載仍嘗試走預設路由。要讓客戶端與其子程序一致進入核心，TUN 模式通常比單純系統代理更容易對齊行為，因為符合條件的流量會在網路層被統一接管。

啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後於連線日誌中確認與 Battle.net 相關的程序是否出現在 Mihomo 連線清單中。若你同時使用 WSL2 或 Docker Desktop，也可對照《WSL2 共用本機 Clash 代理》，理解哪些流量預設不會跟著 Windows HTTP 代理走，避免把問題誤判成單一遊戲平台故障。

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

下列順序刻意把「換節點」放在中後段：先確認 Battle.net 相關連線有經過 Clash，且規則命中符合預期，再談線路品質。

  1. 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若症狀主要出現在客戶端內登入或更新，優先驗證 TUN。
  2. 手動觸發一次「掃描與修復」或小型遊戲更新，於連線日誌中檢查出現的主機名稱是否命中預期策略，而非被過寬的 DIRECT 或地區規則提前截走。
  3. 檢查 DNS 模式（是否 fake-ip）、以及暴雪相關後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析與連線策略不一致。
  4. 將本機實測到的 battle.net、blizzard 與 CDN 後綴一併置於過寬的 MATCH 與「全域直連」類規則之前，避免半套命中。
  5. 在規則已正確命中的前提下，再為下載選擇頻寬穩定、長連線不易斷的節點，必要時與網頁瀏覽分開不同策略群組。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Battle.net 場景下的 Blizzard CDN與控制面對齊。

五、網域怎麼收集：以連線日誌為準，不要只抄過期清單

暴雪會隨時間調整邊緣節點與補丁主機命名，第三方整理的懶人包可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。Windows 上可搭配「工作管理員 → 效能 → 開啟資源監視器 → 網路」觀察客戶端連線時的遠端位址對應名稱，或在 Clash 用戶端的連線清單中依程序或關鍵字篩選 battle、blizzard、Battle.net。

將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹；若你看到下載流量落在 akamaized.net 這類 CDN 後綴，請一併納入同一策略脈絡，避免「battle.net 走代理、CDN 卻直連」造成戰網更新失敗或進度停滯。

六、實務上常見的 Blizzard／Battle.net 網域方向（以實測為準）

下列方向為多數環境下帳號、目錄與補丁會出現的典型後綴家族，實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：

  • battle.net：客戶端與補丁服務常見總樹，含區域性子網域（例如部分環境會出現 *.patch.battle.net 類命名）。
  • blizzard.com：官網、靜態與部分 API／導向相關主機名稱。
  • blizzard.gg：較新的短網域與部分流程可能會引用，是否納入請依日誌。
  • akamaized.net 或其他邊緣 CDN 後綴：大型檔案傳遞時常見；前綴與區域可能依你的網路與時間而變。
  • 若日誌中出現其他雲端或第三方邊緣主機名稱，且與更新失敗時間點重合，再個別補規則，避免過寬關鍵字誤傷。

重點在於：登入轉圈時優先核對帳號與 OAuth 相關主機是否與目錄 API 同一出口；更新卡在初始化時優先核對補丁與 CDN 後綴是否仍被前置規則打成 DIRECT 至不可達路徑。

七、DNS 與 fake-ip：別讓解析鏈放大「逾時」感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Battle.net 客戶端會在背景持續請求多個子網域，任一條解析被汙染或指向不理想的路徑，介面就會長時間停在載入或更新準備狀態。

實務上可以分兩步：第一，確認你的 DNS 上游對海外網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後症狀明顯緩解，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。

八、分流設計檢查清單（請以你的日誌為準）

下表整理撰寫 Clash 分流規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。

類型常見主機名稱方向設定提示
帳號與鑑權battle.net、blizzard.com 等與登入、帳號狀態同一策略脈絡，避免網頁走代理、API 直連。
目錄與補丁控制*.patch.battle.net 等（以日誌為準）與實際 CDN 邊緣搭配檢查；若只代理其中一條，更新可能卡住。
大型檔案 CDNakamaized.net 等下載大量位元組時常見；與控制面分開出口時易表現為初始化停滯。
內嵌登入與帳號流程相同後綴為主登入轉圈時先確認是否誤被廣告攔截或地區規則前置命中。

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

下列 YAML 片段示範「把 Battle.net 與常見下載 CDN 後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的暴雪條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「帳號與目錄」與「大型下載」分流到不同群組，可定義 PROXY_WEB 與 PROXY_DL，再依日誌微調。

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,battle.net,PROXY
  - DOMAIN-SUFFIX,blizzard.com,PROXY
  - DOMAIN-SUFFIX,blizzard.gg,PROXY
  - DOMAIN-SUFFIX,akamaized.net,PROXY

日誌中若出現其他專用主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。若你使用地區專用網域（例如部分網路環境會看到與中國大陸相關的暴雪網域後綴），請以實際連線為準個別處理，勿與國際區客戶端假設混用。

十、與 Steam、Epic 專文的差異（勿混抄規則）

站內 Steam 與 Epic 文章分別聚焦 Valve 與 Epic Games 生態網域；本文則聚焦 Battle.net 代理與暴雪系 Blizzard CDN。兩者「排查順序」類似（先 TUN、再日誌、再 DNS），但主機名稱表完全不同，直接複製 Steam 或 Epic 規則無法覆蓋戰網補丁路徑。

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

在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 battle、blizzard 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。

若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Battle.net 專用規則，可節省大量試錯時間。

十二、小結：把「轉圈與初始化」變成可驗證的規則問題

2026 年在 Windows 上遇到暴雪客戶端Battle.net 登入轉圈或戰網更新失敗、長時間卡在初始化時，可依序確認：客戶端流量是否進核心、DNS 與 fake-ip 是否一致、battle.net／blizzard 控制面與 CDN 下載網域是否一併命中，以及節點是否穩定。當連線日誌能清楚對應主機名稱與策略，你就不需盲目開啟全域代理卻仍無法對齊下載通道。

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