Xcode Cloud 出口 IP 變更後，企業防火牆怎麼更新？2026

Apple 的 Xcode Cloud 發布說明記錄，出口 IP 範圍於 2026 年 2 月 10 日發生變更（Apple 發布說明）。因此，Xcode Cloud 出口 IP 防火牆更新應以 Apple 現行公布的範圍為依據，逐一核對程式碼託管端與防火牆 allowlist，再用實際工作流程確認存取；不要沿用舊規則，也不要以未經核實的第三方清單代替官方資料。

適合： 維護企業網路規則、程式碼託管存取限制，或負責 iOS CI/CD 安全驗收的團隊。
不適合： 只需要排查一般 Xcode 建置錯誤，且不管理網路或倉庫存取策略的讀者。

企業 IT 網路負責人：盤點防火牆、閘道及網路存取控制規則。
安全工程師：審查變更依據、影響範圍、審批與回復安排。程式碼託管平台管理員：確認倉庫限制與工作流程授權。

最後更新於 2026 年 10 月 26 日；地址範圍及適用說明核對自 Apple Xcode Cloud 發布說明與專案設定文件。這只確認 Apple 文件記載的變更，不代表你的內部規則已更新或已生效；若 Apple 後續更新相關文件，應重新核驗。

先把官方地址範圍和企業規則分開

Apple 的專案設定文件提供 Xcode Cloud 存取程式碼倉庫所需的 IP 範圍資訊。請直接開啟現行文件核對適用範圍及 IPv4、IPv6 項目，不要從舊工單、複製貼上的設定，或未經確認的第三方列表推定應放行的位址。

官方公布的是地址依據；企業實際允許哪些來源、目的地與服務，仍由你的防火牆、閘道、倉庫設定及變更程序決定。兩者必須分開留存，否則即使拿到一份最新地址清單，也無法證明它套用在正確的連線路徑上。

Xcode Cloud 的出口 IP 範圍在哪裡查？
以 Apple 的專案設定文件為準，並查看發布說明是否記載後續變更。保存核對時的文件網址、查閱日期及適用欄位；不要將本文或內部舊清單當成未來的官方地址來源。

先確認受影響的是哪一段流量：若倉庫服務位於企業網路內，防火牆或閘道可能需要檢查該服務接收連線時所用的來源限制；若問題出在其他外部服務，不能只因它與 Xcode Cloud 同時失敗，就直接把原因歸到倉庫 allowlist。Apple 另有源程式碼管理連線說明，可供你對照專案所採用的連線方式。

網路與安全團隊：界定變更範圍

網路負責人應從實際生效的規則物件著手，而非只檢查一份地址表。對自託管 Git 服務而言，需確認面向 Xcode Cloud 的連線是否經過防火牆、雲端網路控制或反向代理，以及這些元件各自使用的來源限制；只有在服務確實以 HTTPS 接收該連線時，才將相關 HTTPS 規則納入本次變更。

Xcode Cloud IP 變更後哪些防火牆規則需要複核？
逐一檢查與倉庫存取路徑有關的來源條目、目的服務、通訊協定、規則物件、變更審批與回復記錄。若你的拓撲不使用某個閘道或規則層，就不必為了套用範本而新增設定。

企業防火牆 allowlist 是否應包含整份官方清單？
不要只因清單由官方公布，就將所有項目不加判斷地加入每一個規則。先確認 Apple 文件所列範圍與你的服務入口、政策模型及協定設定是否相符；若防火牆支援分層物件，按核准的規則設計管理，並記下每一項來源與目的地的理由。NIST 的安全控制文件可供安全團隊參考存取控制與變更管理的審查方向，但不能取代企業自己的風險評估。

提醒： 不要把「短暫放寬來源限制以確認是否恢復」當成正式驗收。若必須做診斷性調整，應採用已核准的變更程序，限定範圍與時間，並在測試後確認原有控制已恢復。

企業亦可參考管理 IP allowlist 的文件了解程式碼託管端可能有獨立的網路限制；但各組織的功能與設定方式不同，應以你實際使用的倉庫服務及其管理文件為準。

程式碼託管管理員：網路放行不等於倉庫授權

自託管 Git 服務如何允許 Xcode Cloud 存取？
先核實服務入口實際收到的來源限制，再按 Apple 現行 IP 範圍更新適用的 allowlist；之後另行檢查專案連線設定、倉庫授權與所需憑證。Apple 的源程式碼管理設定說明可協助核對連線設定，而安全說明則提供 Xcode Cloud 安全相關資訊。兩者都不能代替你對企業倉庫權限的實際驗證。

若你的程式碼取得流程還涉及外部相依項目，不要將該路徑與倉庫存取混為一談；Apple 的相依項目提供指南說明了相關設定方向。這類連線失敗需按實際目的地和設定分別核對，不能單憑 IP 更新的時間點作結論。

CI 團隊：按步驟完成變更與驗收

更新 allowlist 後，怎樣確認工作流程能拉取倉庫？
使用包含代表性倉庫連線與建置工作的 Xcode Cloud 工作流程進行驗收，檢查執行記錄中倉庫取得與後續建置是否按預期完成。Apple 的首次工作流程設定說明及工作流程動作文件可供你對照流程設定；實際連線是否成功，仍以團隊測試記錄為準。

1. 保存基準狀態。 匯出或記錄目前防火牆、閘道、倉庫 allowlist 與相關授權設定，標示設定擁有人及回復責任人。
2. 核對 Apple 現行文件。 由負責人重新查看發布說明及專案設定文件，確認出口 IP 範圍與 IPv4、IPv6 項目；將核對時間與來源連結寫入變更單。
3. 追出實際路徑。 由網路及倉庫管理員共同確認連線經過哪些控制點、各點限制的是哪一段流量。不要假設所有規則都由同一團隊維護。
4. 分層提出變更。 在防火牆、閘道或倉庫限制中，只更新已確認受影響的規則，並在審批資料中記錄來源範圍、目的服務、協定依據與回復方式。
5. 檢查身分與倉庫權限。 倉庫管理員獨立確認專案連線及倉庫授權，避免把網路連通誤判為權限已滿足。
6. 執行代表性工作流程。 由 CI 工程師觸發實際工作流程，核對倉庫連線、程式碼拉取與建置結果，保存可審查的執行記錄。
7. 處理失敗並完成關閉。 若測試未通過，分別核對規則是否生效、倉庫授權及工作流程設定；記錄回復決定、責任人和後續監察安排。

變更單可用下列欄位保存證據，方括號內容應以團隊實際資料填寫，不是可直接套用的 IP 清單：

依據：[Apple 現行文件連結及核對日期]
受影響規則：[防火牆／閘道／倉庫規則]
來源與目的：[依核准內容填寫]
審批與回復責任人：[負責人]
驗收工作流程：[實際工作流程識別資料]
結果：[團隊測試結果及執行記錄]

經驗提醒： 若防火牆規則已變更但工作流程仍失敗，先確認規則是否已套用至正確入口，再檢查倉庫授權與工作流程設定。只有實際的企業規則檢視及工作流程測試，才能證明變更有效；Apple 文件本身不會證明你的環境已完成更新。

用條件分支決定是否放行或回復

• 若 Apple 現行文件涵蓋的範圍與企業服務入口、倉庫限制一致，且變更已獲審批，則更新對應 allowlist，再以代表性工作流程驗收。
• 若無法確認哪個入口承接 Xcode Cloud 的倉庫存取，則先暫停擴大規則範圍，由網路與倉庫管理員共同追查路徑。
• 若網路規則已核實，但倉庫拉取仍失敗，則轉查倉庫授權、專案連線與工作流程設定，不要直接擴大來源範圍。
• 若測試後仍無法證明新規則符合預期，則按變更單執行回復，保存測試記錄並重新確認故障所在層級。

完成閉環時，請確保官方資料、內部修改記錄、審批依據、工作流程驗收結果及回復責任人能互相對照；同時指定負責監察 Apple 公告並重新核驗規則的人員。你也可參考遠端 Mac 方案比較，評估其他 macOS 專屬建置任務的執行環境，但它不能代替 Xcode Cloud 的網路規則驗收。

如果驗收後仍有需要在 macOS 上執行的建置、測試或短期擴容任務，可再評估 OakVM 的遠端 Mac 租用是否符合團隊的存取與工作負載要求；若任務長期固定、持續高負載，或必須直接連接實體設備，自購硬體可能更合適。開始評估前，可透過聯絡 OakVM確認服務安排，再按你們的網路政策自行審查是否適用。