截至 2026 年 9 月 21 日，Apple 的企業網路文件是按「主機名稱」與「TCP／UDP 連接埠」兩類資訊說明服務連線要求，而不是提供一條可涵蓋所有情境的萬用規則（Apple 企業網路主機與連接埠要求）。因此，本週不要先放行 *.apple.com：請按原始碼、依賴、Xcode 元件、簽名發布、通知與管理服務拆分規則，並讓每條規則對應真實 CI 流程驗證。生產簽名節點也應與普通構建節點使用不同的出站範圍。
本週建議時間表
- 第 1 個工作日：記錄每個失敗階段、請求目標、執行帳號、代理模式和錯誤證據。
- 第 2—3 個工作日：建立服務分類、節點信任域與最小出站規則。
- 第 4 個工作日：以 CI Runner 服務帳號完成逐層連線測試。
- 第 5 個工作日：執行完整構建、簽名、上傳及公證流程，決定放行或隔離試點。
這篇適合企業網路與安全負責人：你需要為 Mac CI 設計最小出站權限和變更審核依據。平台工程負責人：你正在交付 Xcode 27、Apple Silicon 與 CI Runner 環境。採購與基礎設施負責人：你需要判斷遠端 Mac 節點是否具備可驗證的網路交付能力。
SECTION 01 為什麼主機能上網，Xcode 27 CI 仍然會失敗？
「Mac 可以瀏覽網站」只代表某一個使用者、某一條連線和某一個應用程式曾經成功，不能證明流水線所需的全部請求都能完成。Xcode 27 CI 網路白名單至少有以下幾個容易被忽略的阻斷域：
- 執行身份不同：管理員終端可能讀到使用者的 SSH 金鑰、Keychain 憑證和代理設定，但 CI 服務帳號未必具有相同權限。
- 依賴來源不同：Git、Git LFS、Swift Package、CocoaPods、私有制品庫和 Apple 服務不是同一組網域，不能把它們全部歸入 Apple 白名單。
- 請求階段不同：下載工具鏈成功，不等於簽名認證、App Store Connect 上傳、Notary 狀態查詢和票據裝訂都能完成。
- 代理行為不同：顯式代理、透明代理、TLS 檢查、內部 CA、DNS 重寫和重新導向，都可能令同一個 URL 在終端機和 Runner 中得到不同結果。
- 信任域不同：普通 PR 可以接觸較多依賴來源；生產簽名節點則應限制程式碼來源、憑證、私鑰和出站路徑，避免不可信工作與發布權限交叉。
先把錯誤定位到網路階段，再修改規則。否則「加一個網域再重試」很容易掩蓋實際的權限、憑證或服務帳號問題。
SECTION 02 Xcode 27 CI 網路白名單按流量拆分
建議把一條完整的 iOS CI 流程拆成六類請求。下表中的目標不是預先替你填入所有網域，而是要求你從 Apple 官方文件、企業內部記錄和實際流水線日誌取得可核對的清單。
| 流量類型 | 主要用途 | 規則應記錄的內容 | 常見失敗證據 |
|---|---|---|---|
| 原始碼 | Git、Git LFS、分支與標籤拉取 | 儲存庫、協定、Runner 身份、代理路徑 | clone 失敗、權杖拒絕 |
| 依賴解析 | Swift Package、CocoaPods、私有制品庫 | 套件來源、鎖檔、快取策略、內部 DNS | resolve timeout、雜湊不符 |
| Xcode 元件 | Xcode 額外元件與模擬器執行環境 | 元件名稱、下載來源、安裝帳號 | 元件下載中斷、版本缺失 |
| 開發與管理服務 | Apple Developer、裝置管理、帳戶認證 | 服務用途、權杖範圍、審計記錄 | 認證失敗、裝置不可見 |
| 簽名與發布 | App Store Connect、上傳、公證 | 發布節點、API 金鑰、狀態查詢、日誌 | 上傳成功但狀態查不到 |
| 結果回傳 | Webhook、通知、內部 CI 控制台 | 回傳目標、來源 IP、重試規則 | Job 卡住、結果遺失 |
Xcode 元件下載應按 Apple 的元件安裝文件核對，而不是只測試 Xcode 主程式是否能啟動（Apple Xcode 額外元件下載說明）。Xcode 27 的系統條件與支援狀態則只採用 Apple Xcode 27 發布說明；不要把企業內部節點「能下載」推論成 Apple 已保證的網路相容性。
第一個阻斷域：原始碼與依賴
請以 CI 服務帳號重新執行拉取和依賴解析，不要以管理員已成功的互動式終端作為證據。驗證時同時檢查：
Package.resolved是否與提交內容一致，快取失效後能否重新解析。- Git LFS 物件是否走另一個主機或重新導向。
- 私有 Swift Package、CocoaPods 與內部制品庫是否需要不同的代理或認證。
- 企業 DNS 是否只在私網區域可解析。
- 自託管 Runner 是否透過標籤和 Runner Group 被派到正確的網路區域。
GitHub Actions 的自託管 Runner 文件說明了 Runner 的管理與路由邊界；標籤配置也會影響工作被分派到哪一類節點（自託管 Runner 說明、Runner 標籤配置）。如果依賴只存在於私網，沒有對應標籤的工作可能會被送到沒有私網出口的 Mac，最後看似是套件故障，實際上是路由錯誤。
SECTION 03 Apple 服務與簽名節點的權限應怎樣分層？
普通構建、歸檔、簽名、上傳和公證不應共用同一個信任域。你可以用以下邏輯設計節點，而不是把所有出站流量都放到一台「萬用打包機」：
- 普通構建節點：可拉取已批准的原始碼和依賴，通常不持有生產私鑰或發布權杖。
- 依賴構建節點：允許經審批的私有制品庫和套件來源，使用獨立快取與可追溯鎖檔。
- 生產簽名節點：只接收已批准的構建產物，限制分支來源、憑證範圍與出站目標。
- 災備節點：規則與生產節點保持一致，但必須以獨立測試任務驗證，不應等到主節點故障才首次連線。
App Store Connect API 金鑰的建立與權限範圍，應依 Apple 官方 API 金鑰文件配置。自動化公證則不應只測試「檔案上傳成功」；你還要驗證提交、狀態查詢、日誌取得與票據裝訂，並依 Apple Notary API 文件保留請求和結果證據。
提醒：生產簽名節點若同時下載不可信分支依賴、執行一般除錯工作並持有發布權杖，網路白名單即使寫得很窄，仍然無法消除憑證、原始碼和供應鏈交叉暴露的風險。
SECTION 04 代理、TLS 與防火牆規則怎樣驗證？
Mac CI 代理和企業防火牆白名單的驗收，不能只靠 ping 或瀏覽器開頁面。每個目標都應留下以下六層證據：
- DNS 解析：確認 CI 服務帳號取得的位址與管理員終端是否一致，並記錄是否使用內部 DNS。
- TCP 建連：確認實際協定和連接埠能否建立連線；Apple 軟體產品的 TCP／UDP 說明可作為官方核對依據（Apple 軟體產品連接埠文件）。
- TLS 握手：檢查憑證鏈、內部 CA、SNI 和代理重新導向，不要只看是否「有回應」。
- 認證授權：以實際服務帳號和最小權杖測試，分辨網路拒絕與權限拒絕。
- 業務請求：執行依賴解析、元件下載、簽名、上傳或公證等真正動作。
- 完整流水線：確認結果能回傳 CI 控制台，並保留時間、節點、日誌和規則編號。
對 Apple 端點、程式碼託管、套件來源和內部制品庫分別建立變更負責人、復核週期與回滾動作。Apple 端點清單變更時，不能只更新防火牆；還要重新跑受影響的流水線，確認簽名和發布路徑沒有被代理策略一併改壞。
SECTION 05 上線前應用哪份驗收矩陣？
先把規則轉成可審計的紀錄，再決定節點是否能進入生產。建議每一條規則至少有規則編號、目標服務、業務用途、最小權限、驗證命令或流水線、失敗日誌、審批人和復核日期。
| 節點類型 | 必驗證請求 | 不應直接假設的事項 | 驗收結果 |
|---|---|---|---|
| 普通構建節點 | 原始碼、批准依賴、編譯與結果回傳 | 能開 Apple 網頁就代表依賴完整 | 放行／限期整改 |
| 依賴構建節點 | 私有套件、LFS、快取失效後重新解析 | 公開套件與私有制品庫共用規則 | 放行／隔離試點 |
| 生產簽名節點 | 歸檔、簽名、上傳、公證、狀態與日誌 | 上傳成功就代表發布流程完成 | 放行／禁止上線 |
| 災備節點 | 與生產一致的完整流水線及重連 | 備援節點只要能 SSH 就足夠 | 放行／限期整改 |
第二步：建立可勾選的上線清單
- [ ] 已將原始碼、依賴、Xcode 元件、開發帳戶、簽名發布和結果回傳分開編號。
- [ ] 已從 Apple 官方文件核對相關主機與連接埠，沒有以全域 Apple 網域取代具體目標。
- [ ] 已用 CI 服務帳號，而不是管理員帳號，重現所有關鍵請求。
- [ ] 已分別記錄 DNS、TCP、TLS、認證、業務請求和完整流水線結果。
- [ ] 已確認代理是否進行 TLS 解密、DNS 重寫或重新導向，並保存內部 CA 證據。
- [ ] 已將普通構建與生產簽名節點分成不同網路和憑證信任域。
- [ ] 已完成 Xcode 元件下載、依賴解析、簽名、上傳、公證和票據裝訂測試。
- [ ] 已為每條規則指定審批人、變更負責人、復核日期和回滾動作。
- [ ] 已對遠端 Mac 節點測試失聯後重連，以及流水線結果是否能正常回傳。
- [ ] 若有任何關鍵證據缺失，已選擇隔離試點，而不是直接投入生產。
最後更新於 2026 年 9 月 21 日；資料核實自 Apple Xcode 27 發布說明、Apple 企業網路主機與連接埠文件、Apple Notary API 文件，以及 CI Runner 官方路由說明。若 Xcode 27 由測試版轉為正式版、Apple 服務端點改動，或企業代理政策變更，請重新執行上述驗收。
SECTION 06 常見問題與驗收邊界
Xcode 27 構建機需要放行哪些網路地址？
不要以 *.apple.com 作為最終答案。你應把 Apple 工具鏈、開發者帳戶、App Store Connect、公證和原始碼依賴分開，使用官方文件建立候選目標，再用企業 DNS、代理日誌和實際 CI 請求確認。私有 Git、Git LFS、Swift Package、CocoaPods 和內部制品庫必須有獨立規則與審批記錄。
iOS CI 存取 Apple 服務失敗時，先查哪裡？
先定位 DNS、TCP、TLS、認證、業務請求或結果回傳的失敗層，不要先擴大白名單。你應在同一台 Mac、同一個 Runner 服務帳號和同一種代理模式下重現，保存錯誤時間、目標、回應和權杖範圍。瀏覽器能開啟頁面，不能證明簽名、上傳或公證流程可用。
Mac CI 代理和企業防火牆白名單怎樣避免互相干擾？
先記錄顯式代理、透明代理、TLS 檢查、內部 CA、DNS 重寫和重新導向的實際行為，再為原始碼、依賴、Apple 服務和內部制品庫分組。每組都應有可重跑的流水線驗證，而不是只用連接測試。若管理員終端和服務帳號結果不同，優先檢查環境變數、Keychain、憑證和代理認證。
企業簽名發布節點是否需要獨立出口？
通常應該獨立設計，因為它持有比普通構建節點更敏感的簽名身份和發布權限。實際出口範圍仍要以你的 App Store Connect、公證、狀態查詢和日誌需求為準；不要讓它同時承擔不可信分支依賴下載。任何上傳成功但狀態或票據取得失敗的情況，都應判定為未完成驗收。
遠端 Mac 構建機如何證明網路白名單真的可用？
在遠端 Mac 上以實際 Runner 服務帳號完成完整流程，依次保留 DNS、TCP、TLS、認證、業務請求和流水線結果證據。測試範圍至少應包含依賴解析、Xcode 元件下載、簽名、發布、公證和失聯後重連。若供應商只能保證主機可登入，卻無法提供代理、私網依賴、隔離和恢復驗證，你應先把它列為隔離試點。
如果你目前是自行維護 Mac CI，實體採購方案的問題通常不只在硬體折舊：還包括固定資產交付週期、故障後需要現場處理、出口規則由你自行維護，以及閒置節點仍要持續承擔電力、空間和管理成本。遠端 Mac 租賃也不是所有企業的答案；長期滿載、需要實體外設或必須完全控制機房的團隊，直接採購可能更合理。但對需要先驗證 Xcode 27、Apple Silicon、企業代理、簽名隔離和失聯恢復的團隊，VPSNIX 的遠端 Mac 節點可先放入 PoC，並以同一份驗收矩陣確認網路交付，而不是只比較登入價格。你可以先查看 VPSNIX 的遠端 Mac 服務入口，再按 方案與租賃資訊核對適合測試的資源範圍；真正進入生產前，仍應要求代理、私網依賴、簽名發布和失聯恢復各自留下可審計證據。