2026 年 10 月 30 日，Cloudflare 宣布面向私有源站的应用服务能力正式可用，让公网请求能够经现有网络连接抵达内网源站。对维护 AI Agent 后端、MCP 工具和内部 API 的团队，这提供了一条保留源站私有地址、对外提供应用入口的路径。本文拆解请求链路、开通条件与试点方法，帮助你判断现有网络是否适合接入。

Cloudflare 私有源站架构概念图：外部请求经过边缘入口与私有网络路径抵达内网服务，响应沿回程返回

原创 AI 架构概念图，仅说明请求与回程关系，不代表真实控制台或部署效果。

[配图建议：地面上的外部访问入口，通过中间代理连接地下内网机房，并画出返回路径 + 明亮建筑剖面插画，标注“架构概念图”]

一、变化发生在“代理到源站”的这一段

根据 10 月 30 日官方公告，团队可以把启用代理的 DNS 记录指向私有 IP，通过已有的 Cloudflare One 网络连接访问源站，并在入口使用 WAF、缓存、机器人管理或 Workers 等应用服务。

这里最容易混淆的，是两个不同问题：外部能否访问应用入口，以及外部能否直接连接源站。 应用可以有公开的域名入口，实际处理请求的服务器仍位于私有网络。访问者面对入口，入口通过已配置的连接寻找后端。

用一家小型 AI 产品团队举例：知识检索服务运行在内网，合作方的 Agent 需要调用其中一个查询接口。团队想开放的是这项能力，而不是把承载数据库、管理接口和其他服务的整台机器都当作公网入口。

这项能力的价值，在于让应用入口与后端所在网络有更灵活的组合。它并不替团队决定应该开放哪个接口，也不自动赋予合作方业务权限。

还要分清时间：这次是正式可用，并非首次出现。Cloudflare 在 6 月 10 日的封闭测试介绍中，已经说明了将现有 WAN 或 Mesh 连接用于公网到私有源站访问的思路。那篇文章也指出，Cloudflare Tunnel 早已能通过 cloudflared 连接私有应用，因此不能把本次更新理解为首次支持“内网服务对外提供入口”。

[配图建议：将一条请求链路拆成“访问者到入口”和“入口到私有源站”两段，高亮本次关注的后半段 + 清晰的双段网络图]

二、对 AI 工具团队，真正要设计的是调用边界

私有网络路由文档说明，这项设置用于将公开主机名的 HTTP/HTTPS 流量，经配置好的连接路由到私有源站；DNS 记录需要是启用代理的 A 或 AAAA 类型。

因此，理解它时可以把请求分成三层：入口处理请求、私有连接负责送达、后端应用决定是否执行。 三层各自解决问题，也各自可能失败。

继续用知识库 MCP 工具作场景分析。一个查询请求到了入口，仍需知道调用者属于哪个租户、能读哪些资料，以及本次请求允许调用哪项工具。网络连通解决了“送到哪里”，业务鉴权解决“谁能做什么”。

对这个场景，建议先明确三条边界：

  • 开放能力边界： 试点只提供读取公开测试资料的查询功能，把管理和写入接口留在独立范围。
  • 身份边界： 用独立测试身份验证授权结果，避免仅凭请求来自代理网络就认定用户可信。
  • 数据边界： 按调用者区分响应，审查缓存策略，避免把某个用户的结果作为所有人的共享内容。

这些是架构建议，不是产品默认替你完成的设置。尤其对于 MCP，工具描述、鉴权与执行权限仍需要应用自己组织，接入网络代理不会自动改变这些约定。

这里也没有理由预设性能结论。增加或调整请求路径后，实际等待时间取决于网络、入口规则和后端处理。比起先期待“更快”，试点更值得确认的是：请求是否走了预期路径，身份是否正确传递，错误能否被定位到具体一层。

[配图建议：把一次知识库查询分成网络送达、身份验证、数据权限三层，在每层放一个待验证的问题 + 克制的分层信息图]

三、正式可用后，仍有开通条件和功能边界

已有域名和 DNS 管理权，不代表账户已获得这项能力。 最新公告要求账户启用 Private Origins 权益，并具备受支持的 Cloudflare One 连接；通常还需启用 Unified Routing，使用 Cloudflare Tunnel 的情况例外。

对已运行相关私有连接的团队，这可能是一项可复用现有基础设施的增量能力。对只有一台服务器、尚未建立连接的独立开发者，投入则包括接入、路由、运维与权限配置，应该先向账户团队确认适用资格与费用，再决定是否试点。

连接方式也影响部署责任。6 月的架构介绍区分了 WAN、Mesh 与 Tunnel 路径：不能把“源站无需运行连接器”扩写为“整个网络不需要任何连接组件”。选择方案时，应画出连接器或网络设备放在哪里、谁维护，以及发生故障时由谁接手。

当前还有具体限制：公告列明 Argo Smart Routing、Dedicated CDN Egress IPs 不受支持，源站健康检查需要 Load Balancing。依赖这些功能的项目，应先确认替代方案，不能直接套用“与公网源站相同”的宣传概括。

另外，本次覆盖公网请求到私有源站，私有网络之间的应用服务路径仍是后续计划。 不应把路线图写成现成功能。

资料核对时还有一个值得注意的差异：文档概览仍显示 Beta，并标注最后更新于 5 月 7 日，早于 10 月公告。本文按更新的公告判断发布阶段；具体账户资格与配置仍应向账户团队核实，不据旧页面或“正式可用”四个字推断所有套餐都可直接启用。

[配图建议：并列展示账户权益、现有连接、路由模式、所需应用功能四项接入条件 + 简洁架构评估清单，不绘制虚构价格]

四、最小试点：验证完整请求，而不只看域名解析

建议用独立测试主机名和只读测试接口，先写下预期行为：谁可以调用、谁应被拒绝、后端应该看到什么请求，以及失败时去哪一层找日志。这样，试点的验收对象就是可核对的结果。

官方 WAN 接入指南把验证拆成连接健康、外部请求和源站流量等环节。按你实际选择的连接方式实施，不要把 WAN 专用设置照搬到其他路径。

一份小范围验收清单可以包括：

  1. 确认前提。 记录账户权益、连接方式、源站地址和返回路径，由对应维护者核实。
  2. 确认入口。 检查代理状态与私有网络路由设置，使用单独的测试主机名避免影响现有应用。
  3. 确认送达。 从外部测试客户端发起请求，在源站日志中对应到同一次调用，核对状态与响应内容。
  4. 确认拒绝。 使用未授权测试身份，检查应用是否按预期拒绝，并观察是否发生错误缓存。
  5. 确认故障定位。 留存入口和源站记录，能够区分路由超时、应用拒绝及后端处理错误。

如果请求超时，先不要反复改 AI 工具配置。官方排障文档建议检查连接健康、源站可路由性、DNS 代理和私有路由设置；缺失返回路由也是明确列出的故障原因。

试点的成功标准应是：授权请求抵达并得到正确结果，未授权请求被拒绝，返回路径可解释，故障能分层定位。能解析域名，距离证明整条链路可用还有一步；能连通，也距离证明业务权限正确还有一步。

[配图建议：以一次测试请求为主线，将外部状态、入口日志、源站日志与返回结果连接起来 + 横向验收流程图]

总结：先画清路径，再决定是否接入

已经使用 Cloudflare 私有连接、又需要向合作方提供 AI 工具接口的团队，值得评估这项增量能力。尚未建立相关网络的小团队，可以先核实开通与维护成本，再比较现有方案。今天最有价值的一步，是画出一条只读测试请求的去程、回程和权限检查点，而不是立即改动生产域名。

你的 AI 工具接入难点，更多在网络连通，还是调用者权限和日志追踪？这个答案会决定试点该先验证哪一层。

[配图建议：一张简洁的请求路线草图，标注入口、私有路径、权限检查与回程 + 浅色技术手账风格]

资料核查：2026 年 10 月 31 日（Asia/Shanghai）。本文依据 10 月 30 日公告及实际读取的官方文档分析，未在账户中部署或进行性能实测；封面为 AI 生成的架构概念图。