已经在用 AWS、阿里云、腾讯云了，还需要 Cloudflare 吗？

直接回答： 它们回答的不是同一个问题。AWS、阿里云、腾讯云回答的是：应用在哪里运行、数据存放在哪里、算力怎么供给、公司内部的谁有权管理。Cloudflare 架在你已经在用的那朵云前面，回答的是：全球各地的用户怎么才能走到这个应用——域名解析与路由、TLS、缓存、攻击消解、Bot 过滤，以及内部系统的身份化访问。你的服务器不用挪窝，Cloudflare 官方文档自己就把源站定义为“非 Cloudflare 拥有的物理机或虚拟机”。但重叠也确实存在：各家云都有自己的 CDN 与边缘安全产品，Cloudflare 自己也提供计算与存储。只是多数企业并不需要把应用迁出原有云才能使用这些能力。所以结论是“大体互补、局部重叠”，值得与否要结合现有架构和实际需求判断。

先把两个问题分开：它在哪儿跑，与怎么被访问

看看你实际付钱买的是什么。

云平台回答四个问题：应用在哪里执行、数据放在哪里、能拿到多少算力、组织里的谁有权去动它。控制台里的一切——实例、对象存储、托管数据库、VPC、IAM 角色、备份策略——都是为这四个问题服务的。

边缘网络回答另一批问题：曼谷或波哥大的用户能不能快速访问到这个应用、被攻击时连接能不能保住、全程是不是加密的、某个区域不健康时服务还通不通、员工打开后台是不是非得先连进 VPC。

这不是两家厂商抢同一份工作，而是同一条请求路径上的两半。这个分工在产品定义里就写得很清楚：Cloudflare 的基础文档把源站描述为“非 Cloudflare 拥有的物理机或虚拟机”，并把自己的服务描述为在“客户端与源站之间的路径上”反向代理流量。你的 EC2、阿里云 ECS、腾讯云 CVM，一个都不用动。所以“我们已经买了云”和“我们还需要一层网络”从来不矛盾。

这里必须先补一句不属于论证范围的话：上面这些并不等于你正在用的那朵云的 CDN、WAF、DDoS 或 Bot 防护不行。Amazon CloudFront、阿里云的边缘产品、腾讯云 EdgeOne 都是投入巨大、持续迭代的成熟产品，对相当多的架构来说它们本身就是正确答案。真正要判断的是一个更窄的问题：在你已有的架构上，再加一层不依附于任何一朵云的第三方边缘，值不值得——要衡量的是它的全球网络覆盖、能否同时挡在多云源站前面、产品组合方式，以及能否用一套控制面管住所有入口。这个问题的答案有时候就是“不值得”，下面那张选型表会把这种情况直接写出来。

要回答的问题	运行层（你已经在付费的那朵云）	抵达层（前面这一层网络）
负责什么	计算、存储、数据库、VPC 拓扑、IAM、备份	域名解析、TLS、任播路由、缓存、DDoS 消解、WAF、Bot 管控、零信任访问
计费单位	vCPU、存储月、IOPS、请求量	套餐加可选附加项；L3/4/7 层不限量 DDoS 防护全套餐包含（含免费套餐）
出故障的样子	应用报错、慢查询、容量到顶	用户根本连不上，或者源站前面某个东西被打满
应该放在哪	靠近数据、且在合规边界内	靠近用户
变更成本	迁移工作负载是几个月的项目	通常更低，但从来不是“改一次 DNS”：DNS 或 CNAME 调整、证书签发与部署、源站访问控制改造、缓存策略重建、业务兼容性验证、灰度切量与回滚预案，最后按主机名逐个回归测试

这两层可以有不止一种摆法。图 2 画出实际中最常见的两种，而且没有哪一种天生更好。

A 这个套路里，前面再加一层通常是增加了成本和故障模式，却没换来什么：源头只有一处、凭据只有一套、支持只找一家，用户也基本集中在一个地区。B 这个套路里，同一层边缘可以只被讨论一次，而不是每个环境重复一遍——这才是它值回票价的地方；即便如此，也只对真正被代理的主机名、以及在这些主机名上真正启用并且套餐支持的产品成立。

重叠在哪里——先把话说透

把重叠的部分先讲清楚，后面的讨论才有共同的事实基础。

每家云都有自己的边缘产品。 官方文档里，Amazon CloudFront 是有数百个边缘节点加区域边缘缓存的 CDN；阿里云 ESA 被描述为在 DCDN 基础上升级的产品，三千多个节点、180 Tbps；腾讯云 EdgeOne 则是把 CDN、DDoS 防护、WAF、Bot 管理、四层代理、边缘函数和 DNS 打包成一个平台。这些都不是弱产品，而是投入巨大、长期演进的成熟产品线。如果你的全部家当都在一朵云里、用户也集中在它覆盖的区域，那么仅仅为了加速再加一层，往往没有必要——是否值得增加，要看你真实的架构和需求。

Cloudflare 自己也卖计算和存储。 Workers、R2、D1、KV 的存在说明“Cloudflare 只做分发”这句话严格说不成立。R2 主打的就是零出网流量费和 S3 兼容 API，确实有团队把对象存储迁过去。更靠谱的区分方式是看重心而不是看有没有：没有人会把核心交易型数据库从超大规模云搬到边缘网络上，而且 Cloudflare 的开发者平台是可选的，你可以只用它的分发与安全层，一个 Worker 都不部署。

计费要按产品逐个看，关键的问题是“它计量什么”。 有一点是真的：所有套餐（包括免费套餐）都带基础的 DDoS 自动防护，L3/L4 与 HTTP DDoS 的不限量防护不按攻击流量向你收费。但这句话经常被顺手引申成“Cloudflare 是固定费用”，那是推导不出来的——它说的是基础 DDoS 防护这一件事，不能据此认为所有产品、附加服务和合同费用都不变。托管规则集和 WAF 包含在付费套餐里而不是按规则条数计费；Bot Management、API Shield、Load Balancing、Zero Trust 席位、Log Explorer 留存、Spectrum、Magic Transit 各自有独立的套餐门槛、计量方式与账单。云厂商那一侧同理。所以逐条对比才有效：哪个套餐包含它、它计量什么、出事的那几天账单怎么动。

云的边缘产品通常不负责的四件事

用词要准确：不是“做不到”，而是“它们不是为这件事设计的”。

一、跨多个地方只有一份策略。 真实的技术栈往往是乱的：Web 层在 AWS，某个市场还有一朵阿里云，财务系统在自建机房，收购来的两个服务还在原来的账号里。逐个资源挂控制面的做法，意味着同样的安全决策要在每个环境重复一遍，各自有各自的控制台、日志格式和账单；而且每多一个“忘了配”的资源，就多一个没保护的入口。而检查型代理提供的是：对已经接入 Cloudflare 代理、并启用了对应服务的那部分业务，可以在一个控制面里集中管理边缘流量与安全策略。这个范围要划清楚：它不会替你统一管理 AWS、阿里云、腾讯云内部的 IAM、VPC 安全组、数据库账号权限，也不会接收合并各朵云自身的审计日志（CloudTrail、操作审计等）——那些仍然归属各自的云治理体系，需要另外的日志汇聚方案。

二、别再让源站暴露在公网。 只要源站还能被直接访问，攻击者就没必要从你的防护层前面走。官方文档给了不止一种答案，强度差别值得分清楚：

• 在源站防火墙放通 Cloudflare 的 IP 段最简单，但 Cloudflare 自己的文档只把它标为“中等强度”，明确指出它对 IP 伪造没有抵抗力。

• Authenticated Origin Pulls（双向校验）的本质是：Cloudflare 边缘作为客户端，向你的源站出示一张客户端证书，由源站校验它，属于边缘到源站的 mTLS；全套餐可用。请用 zone 级或按主机名配置并上传你自己的证书，而不是用共享的全局证书——只有前者才真正绑定到你的账号。它只在 Full / Full (strict) 加密模式下生效；而且它与隧道是两种互斥的源站接入形态，不能混为一谈：隧道模式下源站没有入站监听器，也就没有对象来出示这张证书。

• 隧道则彻底取消入站。 cloudflared 主动向外发起长连接到最近的数据中心，官方的表述很直接：不需要公网 IP、不需要开放入站端口、没有入站攻击面。文档里提到它能承载 HTTP、SSH、RDP 和裸 TCP，但这句话必须按场景拆开理解，否则很容易误会：

  • HTTP 服务：用 public hostname 加 ingress 规则对外发布，用户用浏览器或 API 客户端直接访问即可，这是最直观的一类。
  • SSH / RDP 这类本地客户端协议：要在前面叠加 Zero Trust 的身份校验（浏览器场景由 Zero Trust 的浏览器渲染代劳，非浏览器场景则让访问端本地跑 cloudflared 作为代理，常见做法是把用户身份映射成短时效证书），总之不是“挂到一个公网 URL 上谁都能访问”。
  • 任意 TCP 服务：通常的做法是客户端本地先跑 cloudflared 建立连接，再去连本地端口；或者由 WARP 客户端配合隧道的私网路由访问整个网段。写方案时不要暗示 TCP 服务能像网站一样开一个公网地址直接用。
  • 整个私有网络可达：这是另一种形态（隧道 + WARP + 路由条目），把一段内网地址开放给装了客户端的设备，和“发布单个主机名”完全不是一回事。

  无论哪一类，前提都是源站出网放得通——cloudflared 需要主动向外发起连接，这也是云上安全组、NAT 与代理配置要配合的地方。

这里有三件事是最常被搞错的。第一，隐藏源站不等于源站无法被发现。 历史 DNS 记录、证书透明日志、多年前给出去的合作方配置、不小心提交到代码仓库里的 YAML，甚至你自己的应用向外发起的连接，都可能把它暴露出去。所以要假设它迟早会被找到，并同时在源站一侧保留控制——防火墙只放行该放行的、需要时做 IP 白名单，用隧道时就干脆不开任何入站监听。第二，别把两个认证方向混为一谈。“用户相对 Cloudflare 是谁”是在边缘判定的（零信任策略、面向访客的 mTLS、发给客户端的证书）；“Cloudflare 相对你的源站是谁”是由 Authenticated Origin Pulls 或隧道凭据判定的。这两者是不同凭据、不同生命周期，混淆的结果是加固了一条连接、另一条仍然敞着。第三，只允许 Cloudflare 的 IP 访问源站不等于强身份认证。 它校验的是一个来源地址，而不是“这确实是 Cloudflare 拿着你账号下的凭据来的”，因此 Cloudflare 自己的文档也只把它标为中等强度、且对 IP 伪造没有抵抗力。需要真正绑定到你的账号时，用的是 Authenticated Origin Pulls 或隧道凭据。第四，这些都替代不了源站自身的访问控制——没人复核的白名单会慢慢漂移，而对 DNS-only 记录而言，绕过边缘的那一层什么都没挡住。

三、内部系统，风险往往真正在这儿。 对外 Web 层通常防守得不错，真正出事的是后台管理入口、Jenkins、Grafana、客服控制台，或者一个带着生产凭据的预发环境。这是披着网络外衣的访问控制问题，给公网网站加再多 CDN 功能也帮不上忙。按身份授权、按应用下策略、用短时效会话，才是正面解法。

四、某个源站“今天不太行了”的时候怎么办。 所有流量都指向单一区域时，门口做得再多也没用。配置了健康检查和多源站池之后，一个源站在文档里的定义就是“任何拦截并处理流量的东西”——可以是另一朵云、另一个区域，也可以是只有隧道能连到的主机。于是云厂商的一次故障，从事故降级成一次切换。这条路要单独当一条采购项看：Load Balancing 是独立计费的附加服务（通常按区域/源站数量与用量计价），Cloudflare Argo Smart Routing 这类智能回源同样是独立的付费项，两者都不会因为买了某个套餐就自动包含，也不会自动出现在企业合同里。

三种接入方式，先选这个再谈功能

先把“怎么接进来”定下来，因为它会限制后面所有的选择。

接入方式	实际发生的变化	套餐要求
完整（Full）接入：Cloudflare 作为主 DNS	Cloudflare 管理全区的权威 DNS；代理是按主机名逐条开启的	全套餐；Free 与 Pro 的域名只能用这一种
CNAME 部分接入（Partial）	原有权威 DNS 服务商仍然是权威；只有被指向 Cloudflare 的主机名走代理	Business 与 Enterprise；Cloudflare Registrar 注册的域名不支持
区域传送（Zone transfers）	通过 AXFR/IXFR 在两个 DNS 服务商之间同步整个区域；Cloudflare 既可配置为主 DNS，也可配置为辅助 DNS——辅助只是其中一种配置，不是它的定义	Enterprise
子域委派（Subdomain setup）	被委派的子域名作为独立区域单独管理，配置、甚至账号都可以和根域名分开	Enterprise

套餐要求会变化：这张表是撰写时官方文档的表述，如果你的架构依赖其中某一条，请在动手前再核一遍。

四条能省掉大半争吵的澄清：

• 完整接入说的是 DNS 托管，不等于所有流量自动被代理。 把权威 DNS 交给 Cloudflare，只是给了你“可以打开代理”这个选项；只有代理状态开启的主机名才会经过 Cloudflare。仍然是 DNS-only 的记录会由 Cloudflare 的 NS 正常应答，然后让用户直连你的源站，缓存、WAF、Bot 管控一个都不经过。请按这个前提盘一遍你的解析记录——“我们切到 Cloudflare 了”和“所有东西都受保护了”不是同一句话。
• 并不是所有 DNS 记录类型都能开启代理。 只有 A、AAAA、CNAME 三类记录支持代理；MX、TXT、SRV、NS 以及其他非 Web 记录类型按定义只能是 DNS-only。这也是安全评审应该从“哪些记录开了代理”这张清单开始，而不是从“域名在 Cloudflare 上”这个结论开始的原因。
• CNAME 部分接入不等于完整 DNS 托管。 原来的 DNS 服务商仍然是全区的权威服务器。动手前值得知道的两个后果：面向 DNS 基础设施的 DDoS 防护在文档里仅对完整接入提供，因为部分接入的域名没有使用 Cloudflare 的权威 NS；而要把根域名也代理进来，则要求你的权威 DNS 服务商支持 CNAME Flattening——符合 RFC 的 CNAME 记录不能放在根域名上。先确认你到底需要这几项中的哪些，再决定两种接入能不能互换。
• 区域传送是两个角色里的一个配置，而不是单一角色。 你需要明确哪一方是主 DNS、哪一方是辅助 DNS，然后通过 AXFR/IXFR 同步；如果要求注册商或另一家服务商保留权威地位，那和“Cloudflare 做辅助 DNS”是不同的配置。在采购把话写成另一种版本之前，先写清楚你买的到底是哪一种。

第二个决策是回源怎么做：源站继续留在公网，但只接受校验过的流量；或者用隧道，让源站一个入站端口都不开。这应该当成独立的一个决策，而不是某种偏好——它取决于你的网络怎么分段、能否接受纯出站的连通方式，以及你的团队能吸收多少运维变更。

从这张表可以直接得到三条经验：

• DNS 动不了（变更管控、上级域名不由你管、注册商限制）：那就得用 CNAME 部分接入，意味着至少 Business。
• 首要目标是隐藏源站：用隧道，全套餐都行，且官方有 AWS 私有子网场景的指南。
• 还缺跨源站故障切换：把它当成单独一条预算项，而不是“反正会带过来”的功能。

一个典型架构示例：跑在 GPU 上的 AI SaaS

以下不是任何客户案例，也没有任何性能数据。它只是一类足够常见的形态，画出来作为参考架构，而不是可以引用的结果。

• 业务形态。 一个图片或视频生成 API。GPU 推理跑在 AWS 实例或托管推理平台上，生成物放在对象存储里，用户分布在多个海外市场，而不是集中在某一个区域旁边。
• 真正疼的是什么。 不是带宽，而是单位成本经济学。脚本化注册消耗试用额度、昂贵端点被调用得比任何按请求数阈值都更狠、少数几个并发调用方就能把 GPU 队列占满而请求数看起来完全正常、一个泄露的试用 Key 变成的是一笔账单而不是一次事故。
• 适合放在边缘的。 绑定到昂贵端点和用户身份（而不是只看源 IP）的限流；能把自动化调用方与你自己的 SDK 流量、CLI 工具和合作方集成区分开的 Bot 管控；按你的 API 实际参数形状调优的 WAF 规则；以及在套餐与预算允许时的 API 发现与 Schema 校验，让不符合契约的请求在推理开始之前就被拒掉。能真正缓存的就缓存，而不是重新算一遍。
• 必须留在你自己系统里的。 应用侧的认证与鉴权、按租户的额度管理、用量统计与计费、以及业务风控规则——退款滥用、试用农场、账号倒卖。这些要读你自己的状态、做只有你的产品才能做的决策。代理看得见请求，但它不知道谁还欠你钱。
• 给评审的一个诚实框架。 边缘降低的是明显恶意流量的量，并在离调用方近的地方给你请求侧的控制权；额度语义和真正的滥用经济学必须存在于你自己的 API 层。买了前者就指望后者，是这类评估最常见的翻车方式。

一张很短的选型判断表

请把这张表当成分类工具，而不是购买建议。每一行仍然要对着你真实的架构、实测的流量和用户分布去核。

企业现状	是否值得考虑 Cloudflare	判断依据
只用一家云厂商，用户集中在一个地区	不一定	这家云自己的 CDN、WAF 和边缘产品通常已经够用，仅为加速再叠一层往往是重复采购
多云部署，用户分布在全球	值得评估	跨云流量管理，以及在不同源站之间统一施加边缘策略
AI SaaS，API 调用频繁	值得评估	API 滥用与异常流量控制、Bot 管理、贴近用户的限流
AI 图片或视频生成，推理成本高	值得评估	在昂贵算力之前拦掉自动化滥用与异常流量
已经有 CDN，但源站仍暴露在公网	值得评估	源站访问控制、Authenticated Origin Pulls 与隧道

第一行的“不一定”是要害：如果你的家当真的都在一处，诚实的答案往往就是留在那里。 只有当需求越过了源站边界、策略边界或者访问控制边界，论证才会重新成立。

什么时候才需要 Cloudflare Enterprise？

它不是身份的象征，也不是人数到了某个门槛就该买的东西。只有当某个说得出口的具体需求落在“仅限 Enterprise”那一侧时才值得评估：

• 更复杂的规则定制。 更深的 WAF 表达式复杂度、定制逻辑、能贴合业务流程调优的托管规则集。
• 企业级 Bot Management 与 API 安全。 带反馈调优的行为式 Bot 检测，以及面向 API 的发现、Schema 校验和正向安全模型——具体能力和授权取决于合同，而不是一个笼统的套餐名字。
• 多域名、多业务、多团队的治理。 一个组织下多个账号与团队、权限委派、生产与预发隔离，以及覆盖全局的审计要求。
• 企业级支持、服务承诺与具体合同条件。 明确的对接路径、响应时限、升级通道，以及谈出来的而不是点选出来的商务条款。
• 有明确套餐门槛的产品。 Magic Transit 就是例子：它不是默认可用的，需要单独的订阅与条件。
• 复杂架构下的技术工作。 当涉及多云、存量网络和内部应用时，需要设计评审、迁移规划和持续调优。

有两句话要说清楚。第一，很多能力并不在 Enterprise 才有——完整 DNS 接入、隧道、Authenticated Origin Pulls、L3/4 与 HTTP 的不限量 DDoS 防护，以及 WAF 的很大一部分都不是 Enterprise 专属，所以从这里起步、之后再升级是条正常的路。第二，Enterprise 不是什么都自动包含——Bot、API 安全的某些模块、分析深度、部分支持服务经常是单独的计价项。请以报价单而不是套餐页为准。

按三条路径来框会更实用：

• 基础需求。 现有架构没有明显问题，只需要基础 CDN 或基础防护。云原生边缘服务可能就够了，或者用较低的 Cloudflare 套餐、只启用少量功能。不要买超过需求的东西。
• 进阶需求。 需要认真的 WAF 调优、Bot 管控、API 安全、访问策略，或者因为 DNS 不能动而需要 CNAME 部分接入。很多公司最终落在这里，无论这在你的情况里对应哪个套餐名字。
• Enterprise 需求。 出现了具体硬需求：深度定制规则、规模化的 Bot 与 API 治理、多团队权限治理、谈判 SLA 条款，或者 Magic Transit。需求出现时就评估，没出现时就不买。

一条不容易踩坑的落地顺序

1. 先盘一遍你到底有多少个源站——哪朵云、哪个区域、公网 IP 是多少、谁在管。多数组织都能找出一个没人记得的，而出事时先被打中的往往就是它。
2. DNS 先定。 后面所有事都依赖这一个选择，事后改比一开始就做对麻烦得多。
3. 先定好源站怎么验证对面是谁——放通 IP、双向证书、还是隧道——并且在切换之前实施。切换完才补白名单，意味着中间那段时间的防护是装饰性的。
4. 一个主机名先切，再铺开。 变更单一、爆炸半径可观察，不必在半夜拼人品。
5. 从外部验证源站已经不能被直接访问。 如果还能，上面几条都不承重。
6. 如果某处仍保留着云自己的边缘产品，先决定哪一层日志算权威，并确认另一层没有把你规则依赖的客户端 IP 改掉。两个各自重写头部的独立层，是一笔没有到期日的排查税。

边界与不适用的情况

• 这些都不代表你的应用安全了。 输入校验、鉴权、参数化查询、密钥管理仍然是你的活。给一个有鉴权漏洞的应用加 CDN，只会让它把同一个错误结果更快地缓存返回出去。
• 坚持单一治理边界是合理选择。 如果组织要求一套 IAM、一条审计线、一份采购关系，那么把检查留在已用的云里可能才是正解——即使技术上不那么顺手。这句话在评审会上值得说出口。
• 数据驻留可能强制要求区域化的答案。 有些合规要求确实指向在特定司法辖区内部完成检查，而不是走全球任播边缘。
• 叠加两层边缘是决策，不是默认值。 双重 TLS 终结、互相打架的缓存策略、两层 Bot 挑战都是真实成本，而且难受的是真实用户。
• 套餐门槛会变。 以上均依据当前文档；采购时再核实一遍，别以文章为准。

FAQ

我们已经买了 CloudFront / ESA / EdgeOne，再买一家是不是重复缴费？ 在分发这一层有时确实是——如果家当全在一朵云里、用户也在它覆盖的区域、目标又只是缓存和静态加速，那第二层边缘很难讲清楚。但当需求跨了边界：多个源站在不同地方、源站不该再对公网可见、攻击不该变成一笔账单、内部系统需要访问策略——论证就重新成立。请对着这四条判断，而不是只对着性能。

加了 Cloudflare 是不是等于要把应用迁出 AWS / 阿里云 / 腾讯云？ 不是。它架在现有的东西前面，不改变你的算力、数据或账号；如果用 CNAME 部分接入，连 DNS 都不用动。

DNS 能留在原地吗？ 可以，用 CNAME 部分接入，要求 Business 及以上。Free 与 Pro 走完整接入，需要把权威 DNS 交给 Cloudflare。

多一跳会不会更慢？ 对远离单一区域源站的用户来说通常是变快：缓存命中、往返次数减少、路由更好，收益大于多出来的一跳。如果用户和源站本来就在同一个国家、并且已经由那朵云自己的边缘服务着，收益会变小，甚至可能变差。按市场实测再定。

我们多云，它具体帮在哪？ 在它代理的那部分流量、以及你启用的那些产品范围内，你可以把一部分边缘安全与流量策略在一个控制面里管理，不用在每个云账号里重复同一套决策——这是它能统一的实际范围，而不是“整套安全问题一份策略、一种日志、一张账单”。日志留存、权限、可用功能和分析能力仍然按产品和套餐各不相同。其次是故障切换：源站池可以混合不同来源，于是某一家的故障变成一次路由调整，而不是一次事故。

必须上 Enterprise 吗？ 通常一开始不需要。完整 DNS 接入、隧道、Authenticated Origin Pulls、L3/4 与 HTTP 的不限量 DDoS 防护在低套餐都有，WAF 的大部分也不是 Enterprise 专属；Business 解锁的是“CNAME 部分接入（DNS 留在原地）”，以及正则表达式和更丰富的限流维度。只有当出现具体硬需求时才轮到 Enterprise：深度定制规则、规模化的 Bot 管理与 API 安全、多团队与多域名治理、需要谈判的 SLA 与响应条款，或者 Magic Transit 这类有明确套餐门槛的服务。请对着需求判断，而不是对着公司规模；完整清单见上文那一节，具体条目请以报价单为准。

加了 Cloudflare，是不是就要关掉 CloudFront / ESA / EdgeOne？ 不一定。迁移期两边并行很常见，也有团队长期保留某个云 CDN 只服务特定工作负载，而由 Cloudflare 挡住公网入口。但叠两层不是免费的：每多一层就多一次 TLS 终结、多一层头部重写、多一处配置漂移的可能，所以要写清楚哪些主机名走哪一层。尤其要确认下游那一层保留并校验了真实的客户端 IP，否则你的规则、限流和日志用的都是上一跳代理而不是用户。

这是不是又在问“CDN 和云原生边缘谁优先”？ 不是，而且这个区别在评审会上很关键。“哪家 CDN”是个分发问题，用“多少个节点、命中率多少”就能用实测定论；而本文这个问题是关于请求路径各自归谁，它由架构决定——你有几个源站、其中有没有需要从公网隐身、访问控制应该放在哪一层。

这不就是“Cloudflare WAF 与 AWS WAF 怎么选”吗？ 相关，但那篇更窄：它问的是由哪一层检查请求，这篇问的是整条请求路径各自归谁。

延伸阅读

• Cloudflare WAF 与 AWS WAF 有什么区别？
• 网站遭受 DDoS 攻击时，CDN 能否解决问题？
• 出海企业如何选择 DDoS 防护服务？
• 怎么区分正常 Bot 与真实用户？
• API Key 泄露之后该怎么办？
• AI SaaS 的接口滥用，和普通 API 有什么不同？
• CDN 能力
• 全球网络加速方案