學會在 Hetzner Cloud Console 申請 Dedicated vCPU 限制調高，掌握新加坡機房延遲優勢、CPX/CCX 選型差異、32GB RAM 分配策略，打造穩定的多客戶 WordPress 代管環境。
核心摘要
Hetzner Cloud 預設限制專案層級的 Dedicated vCPU 總配額，若需建立 CCX23（4 vCPU）、CCX33（8 vCPU）等專用 CPU 實例，必須先在 Console 提出 Limit increase 申請並通過審核。本文提供完整操作步驟、高通過率英文申請範本，並針對台灣/亞洲用戶深入分析機房選擇、CPX 與 CCX 差異、多站 WordPress 資源規劃與風險控管策略。
一、Dedicated vCPU 配額申請流程
1.1 申請入口與步驟
- 登入 Hetzner Cloud Console
- 左側選單點選 Limits
- 右上角選 Request change → Limit increase
- 資源類型選擇 Dedicated vCPU
- 填寫目標總 vCPU 數量與用途說明
- 送出等待審核（通常 1–2 個工作天）
關鍵提醒：此為專案層級總配額，非單一實例限制。若目前已用盡配額，建立新 CCX 實例仍會被阻擋。所有機房共用同一配額池。
1.2 高通過率申請範本（可直接複製）
Subject
Request for Dedicated vCPU and Server Limit Increase
Message
Hello Hetzner Cloud Team,
We would like to request an increase to our Dedicated vCPU limit and server quota for our Hetzner Cloud project.
We are a digital agency currently migrating parts of our infrastructure from AWS to Hetzner Cloud. We provide managed website hosting and web application hosting services for our clients, and we plan to deploy multiple production servers to support these workloads.
The servers will be used for legitimate client websites, web applications, staging environments, and related hosting services. We expect stable, long-term usage and monthly billing.
We would like to request an increase of our Dedicated vCPU limit to [16 / 32] vCPUs and an increase in the allowed number of cloud servers as needed for our client hosting infrastructure.
Please let us know if you require any additional information about our business, use case, or expected resource usage.
Thank you for your assistance.
Best regards,
[Your Name]
[Agency Name]
[Website URL]
1.3 填寫建議
| 情境 | 建議申請值 | 說明 |
|---|---|---|
| 先開 2 台 CCX33 | 16 vCPUs | 8×2 = 16，留有彈性 |
| 近期規擴充至 4 台 CCX33 | 32 vCPUs | 一次到位，減少二次審核 |
| Website URL | 填代管官網 | 便於審核方驗證業務合法性 |
| 表單分類 | Miscellaneous | 若只能用 Support 表單，此分類最貼近配額申請 |
二、台灣/亞洲用戶機房選擇指南
Hetzner Cloud 目前六大機房中，新加坡（sin）為亞洲唯一節點，對台灣延遲最低。
| 排名 | 機房代碼 | 相對台灣距離 | 預估 RTT | 適用場景 |
|---|---|---|---|---|
| 1 | Singapore (sin) | 最近（東南亞） | 35–70 ms | 面向台灣、亞洲客戶的網站/應用首選 |
| 2 | Hillsboro, OR (hil) | 美國西岸 | 140–190 ms | 北美西岸客群 |
| 3 | Helsinki (hel1) | 歐洲東北部 | 180–260 ms | 歐洲服務、資料合規需求 |
| 4 | Falkenstein (fsn1) | 德國東部 | 200–280 ms | 歐洲客群、Hetzner 自營機房 |
| 5 | Nuremberg (nbg1) | 德國南部 | 210–290 ms | 歐洲客群、Hetzner 自營機房 |
| 6 | Ashburn, VA (ash) | 美國東岸 | 190–250 ms | 北美東岸客群 |
實測建議：部署後從台灣辦公室/主要 ISP 用
ping、mtr或 RUM 監測實測，再決定是否需 CDN 或多區部署。
三、CPX vs CCX：共享與專用 CPU 的實戰差異
3.1 核心差異對照
| 特性 | CPX (Regular Performance) | CCX (Dedicated Performance) |
|---|---|---|
| CPU 模式 | 共享 vCPU，可突發 | 專用 vCPU，保證效能 |
| Noisy Neighbor | 可能受同宿主機其他 VM 影響 | 完全隔離，無干擾 |
| 適用工作負載 | 靜態內容、快取命中率高的站點 | WooCommerce、會員系統、高 SLA 應用 |
| 價格 | 較低 | 較高（約 2–3 倍） |
3.2 CPX62 真實承載力分析
規格：16 vCPU / 32 GB RAM / 640 GB SSD / 5 TB 月流量（新加坡）
| 部署情境 | CPX62 適合度 | 關鍵風險 |
|---|---|---|
| 20 個企業形象/內容型 WordPress、已啟用全頁快取 |  很適合 |
低，PHP/DB 壓力極小 |
| 20 個低中流量站、少量 WooCommerce |  可用需監控 |
尖峰時 CPU 爭用明顯 |
| 多個 WooCommerce/會員站/LearnDash/Elementor 編輯 |  不建議單台全放 |
動態請求同時消耗 PHP workers、DB CPU、I/O |
| 大量 cron/備份/圖片轉檔/WP-CLI 背景作業 | 不建議依賴 |
長時間佔滿 CPU，共享模式波動大 |
| 承諾高可用性/穩定效能給客戶 | 較適合 CCX 或多台 CPX |
避免單點故障波及所有客戶 |
核心觀念：CPX 的「16 核」代表並行處理能力較強，而非 16 顆始終保證滿速的實體核心。
四、20 站 WordPress 共享主機資源分配策略
4.1 RAM 分配建議（32 GB 總量）
| 用途 | 建議起始配置 | 說明 |
|---|---|---|
| OS、Nginx、Docker、安全餘裕 | 3–4 GB | 基礎系統預留 |
| MariaDB InnoDB buffer pool | 6–10 GB | 資料庫效能關鍵 |
| Redis (maxmemory + 淘汰策略) | 1–3 GB | 物件快取，避免 OOM |
| PHP-FPM + OPcache | 8–12 GB | 依各站 pm.max_children 調整 |
| Linux filesystem cache / 尖峰緩衝 | 至少 6–8 GB | 最易被忽略但關鍵 |
原則：不要把 32 GB 全配給 PHP。Filesystem cache 對多站 hosting 體感提升往往超過 CPU。
4.2 必備架構守則
- Web Server：Nginx + PHP-FPM，或 OpenLiteSpeed/LiteSpeed
- 全頁快取：Cloudflare CDN + Nginx fastcgi_cache；登入/購物車/結帳頁繞過快取
- 應用快取：每站獨立 Redis database/prefix，避免跨站 cache key 衝突
- PHP-FPM 隔離：每個客戶/站點獨立 pool，設定
pm.max_children上限，防單站拖垮全機 - 資料庫優化：啟用 slow query log；WP-Cron 改用系統 cron（
wp cron event run --due-now） - 備份策略：排程錯開、上傳至異地 S3-compatible Object Storage；禁止 20 站同時間本機壓縮
- 可用性預留：至少保留 1 台小型 VM 做監控、異地備份執行、緊急切換
五、代管業務的分階段遷移與風險控管
5.1 不建議「一口氣全上」
建議分批策略：
| 階段 | 部署配置 | 目標客群 |
|---|---|---|
| Phase 1 | CPX42 或 CPX62 (新加坡) | 一般內容型、低流量客戶站 (5–8 站) |
| Phase 2 | CPX42/CPX62 追加 | 流量較高、常更新的客戶站 |
| Phase 3 | CCX 實例 | WooCommerce、會員站、預約系統、有 SLA 要求的站 |
| Phase 4 | 獨立 DB/Redis VM | 當資料庫成為明顯瓶頸時再拆出 |
5.2 可執行驗收指標（觀察 1–2 週後再決定擴充）
- 平均 CPU 使用率 < 40%，尖峰不持續超過 70%
- RAM 可用空間 ≥ 20%，無頻繁 swap
- PHP-FPM 無
max children reached錯誤 - MariaDB slow query 不持續累積，I/O wait 維持低檔
- 各站 TTFB 與 5xx 錯誤率在流量尖峰仍正常
- 月出站流量未逼近方案額度（CPX 新加坡內含 0.5–5 TB 依方案而定）
觸發拆分條件：任一指標長期惡化 → 先拆走最吃資源的 WooCommerce/會員站至 CCX，或改放獨立 VM。不要只把同一台 shared VM 繼續升大。
六、常見問題快速參考
| 問題 | 回答 |
|---|---|
| CPX62 能跑 20 個 WordPress 嗎？ | 內容型站且有完善快取：能。含 WooCommerce/動態重站：建議拆分或改 CCX。 |
| 32 GB RAM 會浪費嗎？ | 不會。Filesystem cache、DB buffer pool、Redis、OPcache 都能有效利用。 |
| 新加坡機房流量額度如何？ | CPX 方案內含 0.5–5 TB/月，超額 €1/TB。Cloud host 網路為共享頻寬，無保證。 |
| 能否後續 rescale 升級？ | 可。Hetzner Cloud 支援線上 rescale 增加 CPU/RAM，但 CPX 仍屬共享模式。 |
| 審核被拒怎麼辦？ | 補充業務證明（官網、客戶案例、流量預估），改用 Miscellaneous 表單再申請。 |
結語
Hetzner Cloud 以極高 CP 值吸引許多代管業務遷移，但 Dedicated vCPU 配額申請 是使用 CCX 專用實例的前置關卡。掌握 新加坡機房延遲優勢、CPX/CCX 選型邏輯、多站資源隔離架構 與 分階段驗收指標，即能在控制成本前提下，為客戶交付穩定、可擴展的 WordPress 代管環境。建議以 CPX62 起步、小批量遷移、指標驅動擴充，並在關鍵業務上線前完成 CCX 配額申請，構建彈性與可靠並重的雲端基礎設施。