一、先對齊現象：為什麼「已開代理」仍像半套
在 macOS 或 iOS 上，系統服務往往不是透過單一網域完成所有工作：登入與裝置信任、背景同步、推播通道、地圖與天氣資料、App 資源與韌體檢查，可能分散在多組後綴上。當你看到iCloud相片上傳進度停滯、備份顯示無法完成、或Apple Intelligence相關面板長時間轉圈時，瓶頸可能不是頻寬，而是規則命中不完整：一部分連線已走代理，另一部分仍命中 DIRECT 或被地區分流提前截走，導致用戶端在背景反覆重試。
因此請避免一開始就把所有症狀都歸因到「換一個節點」。較務實的做法是：在 Clash 連線清單中觀察，當你開啟「系統設定」中的 iCloud 頁面、強制同步相片、或觸發 Siri 與 AI 相關功能時，實際出現哪些主機名稱、各自命中哪一條規則。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。
二、為什麼要把 Apple 生態拆成「帳號／推送／iCloud／CDN」
Apple 的網路架構在公開文件與實務觀察中，大致可分成幾類責任不同的連線：與裝置推播與即時通道相關的主機名稱、與 Apple 帳號與識別服務相關的請求、與 iCloud同步與文件相關的網域，以及承載靜態資源、更新檔或邊緣加速的CDN 分流目標。它們的延遲敏感度與失敗表現並不相同：帳號握手失敗時，你可能整頁無法載入；若只有 CDN 類請求被誤直連，則可能出現「小元件能更新、大檔永遠卡住」的割裂感。
把這些類型拆開思考，才能對應到正確的Clash 分流規則順序與 DNS 設定。若你把所有 apple.com 相關後綴都丟進同一個策略群組，有時反而掩蓋問題；更細緻的做法是依連線日誌，將「必須與帳號同一出口」與「可獨立最佳化」的後綴分開，並隨時留意訂閱內建的地理直連清單是否與你的需求衝突。
三、Apple 推送與即時類連線：別讓長連線被規則拆斷
推播與裝置維持連線類服務，常涉及長時間保持的通道；當規則過寬或與 fake-ip 行為不一致時，可能出現「通知延遲、裝置顯示離線、或設定頁面顯示無法連線伺服器」等症狀。實務排查時，建議你在觸發同步或重新登入的時間點，於連線日誌中搜尋 push、apple.com 等關鍵片段，確認這些連線是否被預期的策略群組命中，而不是被一條前置的 DIRECT 規則提前截走。
若你主要使用 iPhone 或 iPad，亦可先參考《iPhone 上 Stash 匯入機場訂閱與分流規則》建立基礎分流概念，再回到本文補上 Apple 生態專用規則；行動裝置上切換行動網路與 Wi‑Fi 時，DNS 快取與 MTU 變化較大，更容易放大「看似同一套設定、卻只有某一種網路會卡住」的體感。
四、iCloud 與相片、備份、尋找：資料面與「大檔」面可能不是同一組主機
iCloud 代理場景下，使用者最常遇到的是相片同步停滯、備份無法完成、尋找或裝置列表更新延遲。這些功能在背景可能同時建立多條連線：清單與中繼資料同步是一類，實際上傳或下載大型媒體又是另一類，而後者有時會落在與前者不同的邊緣節點或內容網路上。若你只為 icloud.com 寫了規則，卻在日誌中發現大量命中在其他後綴上，就需要依實測補齊，而不是假設「一條規則就能涵蓋 iCloud」。
建議你在發生卡頓的當下開啟連線清單，依時間排序，觀察是否出現重複失敗的 TLS 握手、或同一主機名稱在 DIRECT 與代理之間來回切換。這類現象往往指向DNS 與規則打架，而不是單純節點品質問題。
五、Siri 與 Apple Intelligence：把「AI 相關網域」從一般搜尋流量拆出來
2026 年前後，與語音助理與裝置端智慧功能相關的連線，可能與一般 Safari 瀏覽或 App Store 瀏覽並行存在。實務上你不需先背完整官方網域表，而應以連線日誌為準：在啟用相關功能、開啟設定中的 AI 選項、或使用依賴雲端推論的介面時，觀察新出現的主機名稱後綴，將其以 DOMAIN-SUFFIX 納入與其他 Apple 核心服務一致或獨立的策略群組。若這類連線被誤導到與帳號驗證矛盾的出口，常見表現是功能頁可開、但實際請求逾時。
請注意：第三方懶人包清單會隨時間變動，且可能與你的訂閱規則順序衝突；最可靠的方式仍是在你自己的環境收集主機名稱後再寫規則。
六、為什麼「只開系統代理」常常仍對系統服務不完整
許多桌面環境預設只對遵循系統 HTTP 代理的程式生效；部分系統元件或背景程序可能以不同方式發起連線，或與瀏覽器走不同的解析快取。即使你已在「系統設定」中開啟代理，仍可能遇到部分連線未進入 Clash 核心，導致規則與日誌對不起來。若症狀主要發生在系統服務而非單一第三方 App，通常會優先建議驗證 TUN 模式是否能讓相關流量一致進核心。
啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認是否出現預期主機名稱。若你同時在終端機使用 curl、git 或套件管理工具，亦可對照《Mac 終端機 curl、Git、npm 仍直連？用環境變數讓指令行走 Clash》，避免把「CLI 未走代理」與「系統服務問題」混在一起排查。
七、建議排查順序（先證明流量有進核心，再談節點）
下列順序刻意把「換節點」放在中後段：先確認 Apple 相關連線有經過 Clash，且規則命中符合預期，再談線路品質。
- 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題涵蓋系統設定與背景同步，優先驗證 TUN 或等效的全域接管方式。
- 在觸發 iCloud 同步、開啟相片、或重新登入 Apple 帳號時，於連線日誌檢查是否出現
icloud.com、apple.com、mzstatic.com等常見方向，以及策略是否為預期代理群組，而非被過寬的DIRECT規則提前截走。 - 載入大型媒體或系統更新檢查時，再次檢視日誌：是否出現與 CDN 或邊緣節點相關的主機名稱，並確認它們沒有與帳號類流量拆到互相矛盾的出口。
- 檢查 DNS 模式（是否
fake-ip）、以及 Apple 相關後綴是否在fake-ip-filter或nameserver-policy中有合理設定，避免解析與連線策略互相打架。 - 在規則已正確命中的前提下，再挑選穩定、掉包低的節點；若仍長時間轉圈，才需要回到上游路由或區域性網路品質等層面。
若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Apple 生態下的Apple 服務網域對齊與分流規則設計。
八、網域怎麼收集：以日誌為準，不要只抄懶人包
Apple 會依版本、區域與服務組合調整連線目標；第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。於系統設定中觸發同步、開啟相片、檢查備份、或使用 Siri 與 AI 相關功能時，在 Clash 連線清單中依關鍵字篩選 apple、icloud、mzstatic，把重複出現的後綴整理成 DOMAIN-SUFFIX。
將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到大型檔案來自第三方邊緣網路，請只加入「該次失敗時間點實際命中」的後綴，避免把超大後綴一刀切進代理，拖慢其他網站。
九、實務上常見的主機名稱方向（以實測為準）
下列方向為多數環境下帳號、商店資源與雲端同步會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：
apple.com：官網、帳號與多數識別流程相關請求的常見根域。icloud.com：與 iCloud 服務與文件同步高度相關。mzstatic.com：常見於 App 相關靜態資源與中繼資料類請求（實際前綴可能很多）。apple-dns.net：部分環境下與解析或服務發現相關名稱可能出現（請以日誌為準）。- 推播或裝置維持連線相關環境中，日誌可能出現帶有
push片段的主機名稱；請勿假設單一關鍵字即可涵蓋。
重點在於：設定頁能開但同步永遠轉圈時，優先懷疑 iCloud 與內容路徑是否誤直連；小更新能檢查、大檔永遠失敗時，優先核對 CDN 類子網域是否與帳號類流量同一出口。
十、DNS 與 fake-ip：別讓解析鏈放大「轉圈」的感受
在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。系統服務在背景常會重試多條路徑，任一條解析被汙染或指向不理想的路徑，介面就可能長時間顯示載入中。
實務上可以分兩步：第一，確認你的 DNS 上游對相關網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後同步明顯恢復，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。
十一、分流設計檢查清單（請以你的日誌為準）
下表整理撰寫 iCloud 代理與 Apple 相關規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。
| 類型 | 常見主機名稱方向 | 設定提示 |
|---|---|---|
| 帳號與識別 | apple.com 等 | 與登入與裝置信任同一策略脈絡，避免一半走代理、一半直連。 |
| iCloud 同步 | icloud.com 等 | 同步與文件類請求需與背景重試行為一起看，注意規則是否被前置截走。 |
| 靜態與商店資源 | mzstatic.com 等 | 與大檔或資源下載相關時，確認 CDN 路徑與帳號類流量各自可達。 |
| 推播與長連線 | 日誌中帶 push 等片段的主機名稱 | 避免被過寬關鍵字規則誤傷或拆到矛盾出口。 |
| AI 與助理類 | 啟用功能時新出現的後綴 | 與一般瀏覽流量分開觀察，避免混在泛用「國外流量」規則裡難以除錯。 |
十二、分流規則範例（請替換為你的策略群組名稱）
下列 YAML 片段示範「把常見 Apple 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的 Apple 條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「帳號／iCloud」與「靜態資源／CDN」分流到不同群組，可定義 PROXY_APPLE 與 PROXY_CDN，再依日誌微調。
# Example only — replace PROXY_APPLE / PROXY_CDN with your policy group names
rules:
- DOMAIN-SUFFIX,apple.com,PROXY_APPLE
- DOMAIN-SUFFIX,icloud.com,PROXY_APPLE
- DOMAIN-SUFFIX,mzstatic.com,PROXY_CDN
- DOMAIN-SUFFIX,apple-dns.net,PROXY_APPLE若日誌中出現其他專用主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。
十三、圖形用戶端中如何少踩坑
在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 apple 或 icloud 關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。
若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Apple 專用規則，可節省大量試錯時間。
十四、小結：把「轉圈」變成可驗證的規則問題
2026 年在 Mac 或 iPhone 上遇到 Apple Intelligence與iCloud長時間同步轉圈時，可依序確認：系統服務流量是否進核心、DNS 與 fake-ip 是否一致、帳號／推送／iCloud 與 CDN 是否各自命中，以及規則順序是否被直連清單前置截走。當連線日誌能清楚對應主機名稱與策略，你就不需盲目更換節點卻無法改善體驗。
當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗