SG
充足
新加坡
適合東南亞開發者、區域程式碼儲存庫，以及面向亞太的依賴下載流程。團隊成員分布較廣時，也建議重新測試儲存庫下載與產物上傳。
- 連線方向
- 東南亞與亞太協作
- 目錄機型
- CDNMac M4
- 規格
- M4 · 16GB · 256GB
6 個節點的建置網路
為 iOS 建置流程挑選合適的雲端 Mac 節點
目前提供新加坡、日本（東京）、韓國（首爾）、香港、美國東岸與美國西岸共 6 個節點。每筆訂單皆為一台獨享實體主機，非虛擬機；目錄所列組合常態開放訂購，實際供應狀況以控制台即時顯示為準。
節點一覽
目錄收錄 6 個節點
一覽所有在售區域
SG
新加坡
東南亞連線方向
JP
日本（東京）
日本與東北亞連線方向
KR
韓國（首爾）
韓國與東北亞連線方向
HK
香港
東亞跨境連線方向
US-E
美國東岸
北美東岸協作方向
US-W
美國西岸
北美西岸與亞太連線方向
6 個節點
亞太 4 個，美國 2 個
1 種機型
所有節點皆可選 CDNMac M4
全年運作
服務狀態持續更新
選區方式
先檢視完整建置流程，再比較網路往返時間
開發者與節點之間的距離只是其中一環。程式碼儲存庫、依賴套件來源、產物儲存位置與團隊成員所在地，都會影響實際建置時間。
-
01
開發者所在地
若經常使用 SSH 或 VNC，建議比較本地網路連至候選節點的長期中位數與抖動，不要只看單次最低值。
-
02
程式碼儲存庫位置
儲存庫下載、子模組同步與大型檔案下載都會直接影響建置流程。節點即使靠近開發者，若離儲存庫較遠，首次檢出仍可能耗時較久。
-
03
依賴套件下載路徑
確認 CocoaPods、Swift Package Manager、npm、Flutter 與內部套件庫的連線方向，並分別記錄快取未命中與命中的結果。
-
04
團隊協作時區
規劃持續整合工作時，也要考量由誰監看佇列、處理失敗及匯出產物。跨時區團隊可將節點設在主要值班成員或核心套件庫附近。
建議至少實際建置一次並重新測試
統一儲存庫版本、依賴快取狀態與 Xcode 參數，分別記錄程式碼檢出、依賴還原、Archive 與產物上傳時間，再決定長期使用的節點。
亞太節點
4 個亞太節點，對應不同連線與依賴來源
4 個節點皆提供 CDNMac M4：M4、16GB RAM、256GB SSD。選擇節點不會改變基本機型規格，其他選項請於下單時確認。
JP
充足
日本（東京）
適合日本與東北亞地區的圖形介面操作、程式碼檢出及持續整合工作。使用跨區域套件庫時，建議另外記錄上傳階段所需時間。
- 連線方向
- 日本與東北亞協作
- 目錄機型
- CDNMac M4
- 規格
- M4 · 16GB · 256GB
KR
充足
韓國（首爾）
適合韓國當地開發者與東北亞協作流程。若經常透過遠端操作 Xcode 圖形介面，請特別留意長期延遲與抖動變化。
- 連線方向
- 韓國與東北亞協作
- 目錄機型
- CDNMac M4
- 規格
- M4 · 16GB · 256GB
HK
充足
香港
適合東亞跨境協作、程式碼同步與遠端管理。依賴套件來源分布於不同區域時，請分別測量快取未命中的下載時間與建置產物回傳時間。
- 連線方向
- 東亞跨境協作
- 目錄機型
- CDNMac M4
- 規格
- M4 · 16GB · 256GB
美國節點
依東岸或西岸的協作需求選擇，不細分其他城市
美國節點僅涵蓋美國東岸與西岸，不會將西岸再細分為未列出的城市，也不會虛構其他區域。
機型供應狀況
CDNMac M4 適用於全部 6 個節點
目前僅提供 1 種機型。矩陣僅列出在售目錄中的供應組合，不代表任何時刻的設備分配狀況；實際供應狀況以控制台即時顯示為準。
| 機型 | 新加坡 | 日本（東京） | 韓國（首爾） | 香港 | 美國東岸 | 美國西岸 |
|---|---|---|---|---|---|---|
| CDNMac M4 M4 · 16GB · 256GB | 充足 | 充足 | 充足 | 充足 | 充足 | 充足 |
延遲測試紀錄
使用一致的樣本與中位數，避免單次結果造成誤判
下表比較網路往返時間，不代表建置時間承諾。測試紀錄採用固定寬頻與 IPv4 公網，並使用相同的取樣方式；數值單位皆為毫秒。
測試日期
2026 年 9 月 24 日
網路類型
商用固定寬頻 · IPv4 公網
樣本數
每條路徑 30 次
統計方式
有效樣本中位數
| 測試地點與電信業者 | 新加坡 | 東京 | 首爾 | 香港 | 美國東岸 | 美國西岸 |
|---|---|---|---|---|---|---|
| 新加坡Singtel 固定寬頻 | 4 ms | 68 ms | 79 ms | 34 ms | 230 ms | 175 ms |
| 東京NTT 固定寬頻 | 69 ms | 4 ms | 35 ms | 49 ms | 170 ms | 112 ms |
| 首爾KT 固定寬頻 | 77 ms | 34 ms | 4 ms | 45 ms | 190 ms | 132 ms |
| 香港HKT 固定寬頻 | 35 ms | 47 ms | 42 ms | 3 ms | 218 ms | 159 ms |
| 美國東岸測試點Verizon Fios | 232 ms | 169 ms | 188 ms | 215 ms | 8 ms | 72 ms |
| 美國西岸測試點AT&T Fiber | 176 ms | 111 ms | 131 ms | 158 ms | 73 ms | 7 ms |
重新測試時，先傳送 3 次預熱請求，再保留 30 個有效樣本並計算中位數。公網路由會因電信業者、連線方式與時段而異，選擇節點前請使用自己的實際網路重複測試。
認識延遲
ICMP 數值不等於完整的建置體驗
較低的往返時間通常有助於互動操作，但它只反映網路連線的一小部分。建置、下載與圖形介面操作還會受到其他因素影響。
網路往返時間
ICMP 中位數反映測試點到節點的基本往返時間，無法直接呈現 TCP 吞吐量、封包遺失後的復原能力、跨網路壅塞或長連線穩定度。
依賴套件與建置時間
依賴套件來源的回應速度、快取命中率、儲存庫大小、編譯目標與簽署步驟都會影響總時間。建議分階段記錄，而非只保存整條工作流程的總數據。
遠端圖形介面
VNC 體驗也會受到抖動、封包遺失、畫面變化頻率與本機顯示尺寸影響。若需長時間操作圖形介面，建議實際完成編輯、封存與記錄檢視。
建議的驗證順序
先測量長期網路中位數，再下載實際使用的儲存庫，接著還原依賴套件並執行一次 Archive，最後確認產物上傳與遠端管理。四個階段的測試結果，比單次 ping 更能協助選區。