别再把AI Agent后端暴露公网了！Cloudflare一个开关解决致命安全隐患

摘要

很多企业在部署AI Agent后端、MCP服务器或内部API时，都踩过同一个无解的坑：这些服务处理着企业核心数据，绝对不能直接暴露在公网，但又必须和公网网站一样拥有WAF防攻击、速率限制防滥用、Bot管理防爬虫、缓存加速等能力。

2026年6月10日，Cloudflare发布了Application Services for Private Origins（私有源应用服务），解决思路简单到离谱：在DNS记录上开一个开关，公网流量就会走企业已有的私有连接直达内网源站，全程带着Cloudflare的全套安全和性能服务。目前该功能处于封闭测试阶段，计划2026年第四季度正式上线。这不仅解决了当下AI服务的燃眉之急，更是未来网络基础设施的重要信号。

MCP 服务器的网络困局：需要保护，但不该暴露

以前的互联网是"里外两重天"：对外的公网网站有CDN、WAF、DDoS防护层层把关；对内的企业系统全靠VPN、防火墙和内网隔离保护，两者井水不犯河水。

但AI Agent和MCP服务器天生就打破了这个边界： - 它必须对外连通：要响应公网用户的请求、对接第三方SaaS平台、被其他AI Agent调用 - 它绝对不能暴露：手里握着企业的内部知识库、业务数据、用户凭证和API密钥 - 它协议特别复杂：不仅有普通的HTTP请求，还有AI推理常用的gRPC、流式输出的WebSocket，甚至自定义的TCP/UDP协议

这种"既要对外开门，又要锁死后门"的需求，是传统网络架构从来没有设计过的。而现在绝大多数企业的解决方案，都只能在"安全"和"能用"之间做痛苦的妥协： - 小团队图省事直接暴露公网：只开个基础防火墙，一旦被黑客扫到IP，就是全盘数据泄露 - 用Cloudflare Tunnel（cloudflared）：每个服务都要装一个连接器软件，服务多了之后运维复杂度爆炸，连接器本身还会成为单点故障 - 传统VPN+反向代理：反向代理本身又成了新的攻击目标，VPN的性能瓶颈会让AI流式输出卡成PPT - 云厂商私有连接：只能在同一个云厂商内部使用，跨云部署完全抓瞎，高级安全能力还要额外付费

结果就是，大量AI服务因为接入成本太高，干脆放弃了WAF、Bot管理和速率限制，裸奔在公网上。这也是为什么这件事值得关注：安全能力应该属于经过的流量，而不是取决于服务碰巧放在公网还是内网。

DNS 上一个开关：Cloudflare 这次做了什么

Cloudflare这次的核心观点用一句话就能说清：安全应该是到达应用的流量的属性，而不是应用恰好位于何处的偶然结果。

而实现方式简洁得出乎意料——就是在DNS记录上加了一个"使用私有网络路由"的开关。

开启这个开关之后，一切都和以前一样：用户输入域名，请求先到达Cloudflare的全球边缘节点，WAF、速率限制、缓存、Bot管理、Workers这些服务全部正常运行。唯一的变化只在最后一步：Cloudflare不再通过公网互联网把请求发给源站，而是走企业已经建好的私有连接（IPsec专线、GRE隧道、CNI链路或Cloudflare Mesh），直接送到内网的源服务器上。

这意味着什么？ 你的MCP服务器可以跑在10.0.0.50这样纯粹的内网IP上，不用申请公网IP、不用开入站防火墙规则、不用在源站装任何软件，但公网用户访问mcp.example.com时，请求依然会经过Cloudflare的全套安全过滤，再通过加密的私有通道安全到达内网。

🔧 自动识别更省心：对于RFC 1918私有地址（10.x.x.x、172.16-31.x.x、192.168.x.x）、CGNAT网段（100.64-127.x.x）和私有IPv6地址（FC00::/7），Cloudflare会自动开启私有路由开关，不用手动配置。

自动化部署也很简单：对于用脚本管理基础设施的团队，私有路由只是DNS记录上的一个额外属性，一行代码就能搞定：

延伸：不止网页，全协议都能保护

Cloudflare把这个"公私统一"的逻辑，延伸到了所有类型的服务上。

Spectrum（四层代理）：现在可以直接放在运行在内网的TCP/UDP服务前面，不用再搭负载均衡器做中间层。这意味着你的内部SSH跳板机、数据库、AI推理端点这些非网页服务，也能享受Cloudflare的安全保护，而且全程不用暴露公网。

Workers VPC：补上了Cloudflare侧的最后一环。运行在Cloudflare上的AI编排代码，也能通过同一条私有路径访问内网服务。不管是浏览器用户、手机APP，还是Cloudflare上的AI Agent，访问内网服务的方式完全统一，安全策略也只需要配置一次。

cloudflared 会被淘汰吗？

完全不会，两者是互补关系，不是替代关系。

如果你已经通过Cloudflare WAN或Mesh建立了企业级的私有专线，那么新的私有路由功能可以让你不用再为每个服务单独部署cloudflared，大幅降低运维成本。但如果你还没有这些专线，cloudflared依然是中小团队接入私有应用最简单、最划算的方案。

这次发布本质上是给已经有私有网络基础设施的企业"做减法"，去掉不必要的中间层，而不是替换现有的隧道技术。

当前门槛：谁能用、怎么用

需要客观说明，这个功能目前还不是所有人都能立刻用上： - 仅面向企业客户：现在处于封闭测试阶段，只有符合条件的Cloudflare Enterprise客户可以联系账户团队申请 - 需要现有私有连接：你必须已经和Cloudflare建立了私有网络连通性（IPsec、GRE、CNI或Mesh），如果连这个基础都没有，这个功能暂时帮不了你 - 网络配置要求：需要在内网中为Cloudflare的源IP段100.64.0.0/12配置回程路由 - 功能还不完善：目前只支持A/AAAA记录；Spectrum服务暂时只能搭配Cloudflare Tunnel使用，IPsec/GRE/Mesh的支持会在后续版本中增加

一个观察：AI Agent 基础设施的信号

我更在意的不是这个功能本身，而是它背后代表的行业趋势。

AI Agent和MCP服务的爆发，正在倒逼整个互联网基础设施重新思考"公网"和"私有网络"的边界。以前的架构是"非黑即白"，要么完全公开，要么完全隔离，但AI Agent刚好卡在了这个灰色地带：它既要被外部触发，又要安全地访问内部资源。

Cloudflare的这次发布，就是对这个行业痛点的第一个系统性回应。这次解决的是"公网用户访问私有AI服务"的问题，而他们正在开发的下一个功能，是"私有用户访问私有服务"，最终目标是让所有流量，不管从哪里来、到哪里去，都能享受完全一样的安全和性能服务。

这不是说AI网络架构已经彻底变天了，但这绝对是一个值得所有技术团队密切关注的信号：至少有一家全球顶级的基础设施厂商，已经开始认真对待"AI代理后端需要统一安全栈"这个需求了。

注意项

最后也要客观说清楚几个需要注意的地方： - 功能目前处于封闭测试阶段，预计2026年第四季度才会正式上线，实际功能和体验可能会有调整 - 中小企业和个人用户短期内无法使用，企业版的成本门槛不低 - 截至目前还没有第三方的独立性能测试数据，无法确定和cloudflared方案在延迟、吞吐量、可用性方面的差异 - Spectrum对IPsec/GRE/Mesh的支持，以及私有到私有流量的功能，都还没有明确的上线时间

讨论下

你们团队在部署AI Agent或者MCP服务器的时候，是怎么解决安全接入问题的？用的是cloudflared、VPN还是其他办法？如果Cloudflare这个方案正式上线了，你觉得它会最先改变哪个场景？欢迎在评论区聊聊～

参照来源

• Cloudflare Blog:  

https://blog.cloudflare.com/private-origins-dns-routing/

• Cloudflare Developer Docs:

 https://developers.cloudflare.com/dns/private-origins/

• Cloudflare Developer Docs:

https://developers.cloudflare.com/dns/private-origins/private-network-routing/