过去想把内网服务暴露到公网，要么给服务器挂公网 IP，要么在边界部署反向代理或隧道 Connector。前者扩大攻击面，后者多一层运维负担。Cloudflare 刚进入封闭测试的 Application Services for Private Origins，思路很直接：你已经有了 IPsec VPN、GRE 隧道、CNI 插件或 Cloudflare Mesh 通路，那就直接用它们，把公网 hostname 的流量路由到私有 IP 源站——不需要公网 IP，也不需要额外 Connector 软件。
传统方案的痛点
暴露内网应用到公网，常见做法有三类：
- 公网 IP 直连：最简单，但私有 IP 暴露到互联网，安全风险陡增，云厂商的弹性 IP 也往往收费。
- 反向代理 / WAF 前置：在 DMZ 放 Nginx 或商用 WAF，再转发到内网。多了一层基础设施，配置和证书管理都是长期成本。
- 隧道 Connector：Cloudflare Tunnel、Tailscale Funnel 等方案需要在每台源站或子网跑一个 Connector 进程。Connector 本身要升级、要监控、要处理断连重试。
如果企业已经维护了站点间 IPsec 或 GRE 隧道，再叠加一层 Connector，等于两条通路做同一件事——冗余且复杂。
Private Origins 的核心机制
Application Services for Private Origins 的关键在于：复用你已有的网络通路，把 Cloudflare 边缘节点与私有源站之间的路由直接打通。
支持的通路类型：
| 通路类型 | 典型场景 |
|---|---|
| IPsec VPN | 企业站点间标准加密隧道 |
| GRE 隧道 | 与 Cloudflare Anycast GRE 的对接 |
| CNI（Container Network Interface） | Kubernetes 集群内 Pod 网络直连 |
| Cloudflare Mesh | 基于 Cloudflare Network Interconnect 的私有路由 |
工作流程可以简化为：
- 用户访问
app.example.com，DNS 解析到 Cloudflare 边缘。 - Cloudflare 边缘根据配置，将请求通过已建立的私有通路转发到内网私有 IP（如
10.0.1.50）。 - 内网服务响应，流量沿同一条通路返回边缘，再回给用户。
整个过程，源站不需要公网 IP，不需要跑 Connector，Cloudflare 边缘也不需要额外软件——只是路由决策变了。
实操：配置一条 Private Origin 路由
以下示例假设你已有一条 Cloudflare GRE 隧道（通过 Anycast GRE 或 Magic WAN 建立），现在要把公网域名 internal-api.example.com 路由到内网 10.0.1.50:8080。
1. 确认隧道与健康检查
先确认 GRE 闿道已建立且边缘能到达内网 IP：
# 在 Cloudflare 边缘侧（通过 dashboard 或 API）查看隧道状态
# 假设隧道 ID 为 <tunnel-id>
curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/{account_id}/magic/tunnels/{tunnel_id}" \
-H "Authorization: Bearer $CF_API_TOKEN" | jq '.result.status'
如果隧道状态为 up，继续下一步。
2. 配置 Private Origin hostname
通过 Cloudflare API 将公网 hostname 映射到私有 IP 源站：
# 创建 Private Origin 配置（封闭 beta API，路径可能随版本调整）
curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/app_services/private_origins" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"hostname": "internal-api.example.com",
"origin": {
"ip": "10.0.1.50",
"port": 8080
},
"path_type": "gre",
"tunnel_id": "<tunnel-id>"
}' | jq '.result'
3. DNS 侧确保 hostname 走 Cloudflare 代理
在 Cloudflare DNS Dashboard 中，确认 internal-api.example.com 的 A 记录指向任意 IP（如 192.0.2.1，这是一个文档用途的占位 IP），且 Proxy 状态为 Proxied（橙色云图标）。Cloudflare 边缘收到请求后，不会去访问这个占位 IP，而是按 Private Origin 配置走私有通路。
# 用 API 确认 DNS 记录已代理
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records?name=internal-api.example.com" \
-H "Authorization: Bearer $CF_API_TOKEN" | jq '.result[0] | {name, proxied}'
预期输出：
{
"name": "internal-api.example.com",
"proxied": true
}
4. 验证公网可达
从外部网络访问：
curl -v https://internal-api.example.com/health
如果配置正确，你将看到内网服务的响应，而源站 10.0.1.50 没有任何公网 IP，也没有运行 Connector。
与 Cloudflare Tunnel 的对比
| 维度 | Cloudflare Tunnel | Private Origins |
|---|---|---|
| 需要额外软件 | 每台源站跑 cloudflared |
不需要 |
| 网络通路 | cloudflared 自建 QUIC 隧道 |
复用已有 IPsec/GRE/CNI/Mesh |
| 适合场景 | 无现有隧道、快速接入 | 已有企业隧道、大规模内网 |
| 运维复杂度 | Connector 升级与监控 | 隧道运维不变，只加路由配置 |
| Beta 状态 | GA | 封闭 Beta |
两者不是互斥的。小规模、无隧道的团队用 Tunnel 更快上手；已有 IPsec/GRE 骨干网的企业，Private Origins 减少重复建设。
采纳建议与注意事项
- 封闭 Beta：目前需要联系 Cloudflare 申请资格，API 和配置界面可能还会调整，生产环境暂不宜全面依赖。
- 通路先行：Private Origins 不创建隧道，只利用已有通路。如果你的 IPsec 或 GRE 还没建好，先解决底层连通性。
- 安全策略不能省：流量从公网进来，即使源站没有公网 IP，仍需在 Cloudflare 侧配置 WAF 规则、Access 策略或 Rate Limiting，否则等于把内网服务裸露。
- 健康检查：建议在 Cloudflare 边缘配置对私有 IP 的健康检查（Magic WAN 支持），避免隧道中断时公网用户收到超时而非友好错误。
- 混合架构：可以同时用 Tunnel 接入零散主机，用 Private Origins 接入已有隧道覆盖的子网，在同一个 Cloudflare 账户下统一管理 hostname 与安全策略。
一句话总结：Private Origins 的价值不是"又一种隧道"，而是让你已有的隧道不再只服务站点间流量，还能直接承载公网入站——少一层 Connector，少一个公网 IP，少一份运维负担。