背景
許多企業內部服務（如內部 API、AI 代理後端、MCP 伺服器（Model Context Protocol 伺服器，讓 AI 模型能存取外部資料與工具的介面））原本設計為不直接面對網際網路，但仍需接受來自合作夥伴或客戶的請求。過去若要將 Cloudflare 的防護功能應用於這些服務，通常需要暴露公網 IP、開啟防火牆端口，或在來源端執行 cloudflared 軟體（Cloudflare 提供的輕量級代理程式，用於建立安全隧道）。這導致私有應用無法享有與公開應用相同的 WAF（網頁應用防火牆）、機器人管理、速率限制、快取、流量加速、重寫規則及 Workers 等保護與控制功能。 官方原文・Cloudflare Blog
發生什麼事
Cloudflare 於 10 月 30 日宣布「Cloudflare services for private origins」正式推出（generally available）。該功能先前於 6 月進入封閉測試階段，當時僅限符合資格的客戶透過帳戶團隊申請。現在，客戶需具備 Private Origins 權限並透過帳戶團隊啟用，將代理（proxied）的 A 或 AAAA DNS 記錄指向私有 IP，Cloudflare 即可透過現有的 Cloudflare One 連線（Cloudflare 的零信任網路安全平台服務）存取來源。 官方原文・Cloudflare Blog
重點內容
啟用私有來源服務後，來源端保持私有 IP，無需開啟入站防火牆例外規則。若使用 Cloudflare WAN（基於 Cloudflare 網路的軟體定義廣域網路服務） 或 Cloudflare Mesh（Cloudflare 提供的網路網格服務，用於連接私有網路資源），來源端甚至無需執行任何連接器軟體。Cloudflare 的應用服務（包括 WAF 與託管規則、機器人管理、速率限制、快取、轉換與重寫規則、Workers）將如同處理公開來源般運作。TLS 終止、WAF、規則與快取仍在 Cloudflare 網路端執行。 官方原文・Cloudflare Blog
在技術實現上，當 DNS 記錄指向 RFC 1918 私有 IPv4 位址（標準定義的內部網路專用 IPv4 位址範圍）、RFC 6598 CGNAT 位址（运营商級網路位址轉換專用的 IPv4 位址範圍）（100.64.0.0/10）或 RFC 4193 唯一本地 IPv6 位址（僅在本地網路內有效的 IPv6 位址範圍）（fc00::/7）時，「使用私有網路路由」設定會自動啟用，且無法透過 API 關閉。Cloudflare 的代理平台會查詢 Origin API，若回應中包含 private_routing 標記，請求將被轉發至私有網路層，透過客戶現有的 IPsec（網路層加密通訊協定，用於建立安全通道）、GRE（通用路由封裝協定，用於在網路間傳輸封包）、Cloudflare Tunnel（Cloudflare 提供的安全隧道服務，無需開放入站端口）、CNI（Cloudflare Network Interconnect，實體網路互連服務） 或 Cloudflare Mesh 連線進行路由。 原文
對使用者的意義
開發者與企業可透過 API 自動化部署，只需在標準 DNS 記錄中新增 private_routing 屬性。開始使用需具備 Private Origins 權限、Cloudflare One 連線（IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh）以及帳戶啟用 Unified Routing（統一路由功能，整合網路流量管理設定）。若透過 Cloudflare WAN 或 Cloudflare Mesh 連線，還需設定 Cloudflare 來源範圍（IPv4 為 100.64.0.0/12，IPv6 為 2606:4700:cf1:5000::/64）的回傳路由。官方指出，測試期間最常見的設定失敗原因是缺少此回傳路由。 官方原文・Cloudflare Blog
限制與未定事項
目前 Argo Smart Routing（Cloudflare 的智慧路由優化服務） 與 Aegis（Cloudflare 的網路安全防護服務） 不支援此功能，且來源健康檢查需要 Load Balancing（負載平衡服務，用於分散流量與健康檢查） 支援。此外，今日發布僅涵蓋從公開網路到達私有來源的流量。Cloudflare 正在開發「私有對私有」流量功能，讓私有網路上的使用者、服務與 AI 代理能透過 Cloudflare 應用服務存取其他私有網路上的應用，目標於 2027 年初進入封閉測試。 官方原文・Cloudflare Blog
