摘要： Cloudflare 在 2026 年 10 月 30 日宣布「private origins」服務正式一般可用。把 proxied DNS 紀錄指向私有 IP，Cloudflare 會透過你既有的 Cloudflare One 連線抵達來源，而 WAF、快取、bot 管理和 Workers 的運作方式與公開來源完全相同。對長期「不敢暴露上網、又得接外部請求」的內部服務來說，這補上了防護缺口的關鍵一塊。
問題：內部服務的兩難
內部 API、AI agent 後端、MCP server、維運工具本來就不是設計來直接面對網際網路的，但它們常常還是得接受來自合作夥伴、客戶或 agent 的外部請求。在這項功能出現之前，要把 Cloudflare 放在這類服務前面，得暴露公開 IP、在防火牆開 port，或是在來源旁邊跑 cloudflared connector。結果就是私有應用往往缺少公開應用享有的那套防護：WAF、bot 管理、rate limiting、快取、改寫規則與 Workers。
現在的做法簡單得多：建立一條指向私有 IP 的 proxied A 或 AAAA 紀錄即可。來源保持私有 IP，不需要任何入站防火牆例外；若透過 Cloudflare WAN 連線，連 connector 軟體都不用裝。
運作方式與 API
對於 RFC 1918 私有 IPv4、RFC 6598 CGNAT（100.64.0.0/10）和 RFC 4193 唯一本地 IPv6（fc00::/7）這些位址範圍，私有路由會自動啟用且無法關閉。就 API 自動化而言，私有路由只是標準 DNS 紀錄上多一個屬性：
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"ttl": 300,
"proxied": true,
"private_routing": true
}Cloudflare 的 proxy 平台看到 private_routing 旗標後，不會嘗試直接連線公開網路上的私有 IP，而是把請求交給私有網路層，沿著你既有的連線（IPsec、GRE、Cloudflare Tunnel、CNI 或 Cloudflare Mesh）路由。TLS 終止、WAF、規則與快取仍在 Cloudflare 網路上執行，請求流程的其餘部分不變。
上線前要注意的限制與陷阱
目前 Argo Smart Routing 和 Dedicated CDN Egress IPs 不支援，來源健康檢查需要 Load Balancing。設定上有三個前置條件：帳戶需開通 Private Origins entitlement、具備 Cloudflare One 連線（除 Tunnel 外需啟用 Unified Routing），且若走 Cloudflare WAN 或 Mesh，要為 Cloudflare 的來源位址範圍設好回程路由。
Cloudflare 在 beta 期間觀察到最常見的設定失敗，就是回程路由漏設——症狀是請求逾時且來源端完全收不到東西。如果你的第一次部署卡住，先查這裡。
對 builder 的實際意義
這對兩類場景特別有用。第一是你自己 vibe-coded 出來的內部工具：以前保護它們要另開一套 Access 設定（我先前寫過用 Cloudflare Access 一次點擊保護內部應用的做法），現在公開與私有來源可以用同一套 WAF、快取與 bot 管理規則，管理面收斂了。第二是 AI agent 的私有後端與 MCP server：agent 需要從網際網路打到你的服務，但服務本身不必暴露公開 IP。
Cloudflare 也預告下一步：private-to-private 流量——私有網路上的使用者、服務和 AI agent 透過 Cloudflare 應用服務抵達另一個私有網路上的應用——目標在 2027 年初進入封閉 beta。屆時連員工開啟 wiki.company.internal 這種純內部流量，也能享受 WAF 和 rate limiting。
今天這一步的意義很務實：你為公開應用寫的那套防護設定，終於可以原封不動套到私有來源上，跑在已經營運的連線之上。如果你的帳戶還沒有 entitlement，向 account team 開通後，照開發者文件走一遍設定即可驗證。