2025年5月02日·1 分钟
从 CDN 到平台：Cloudflare 的边缘如何扩展
了解 Cloudflare 的边缘如何从 CDN 缓存演进为安全与开发者服务平台，随着流量向网络外围集中，它承担了更多职责。
了解 Cloudflare 的边缘如何从 CDN 缓存演进为安全与开发者服务平台，随着流量向网络外围集中，它承担了更多职责。
边缘网络 是一组分布在多座城市的服务器，放在离终端用户“更近”的位置。与其让每个请求都回到公司的源站（或云区），边缘可以在就近位置响应、检查或转发该请求。
把它想像成在场馆入口处放置了客服，而不是把所有问题都推到后勤办公室。某些请求可以立即处理（比如返回缓存文件），而另一些则被安全地转发到源站。
外围 是外部互联网流量第一次接触你系统的边界：你的网站、应用、API，以及保护和路由它们的服务。历史上，许多公司把外围当成一个薄门（DNS 和负载均衡器）。今天，这里发生最多且最具风险的交互——登录、API 调用、机器人、抓取、攻击与突发流量。
随着更多工作转到线上并且越来越多集成依赖 API，把流量引导到外围以便在请求触及核心基础设施之前统一应用规则（性能优化、安全检查和访问控制）变得愈发实际。
本文按顺序展开：先讲性能（CDN），然后是边缘安全（DDoS、WAF、机器人管理、零信任），最后是开发者工具（在靠近用户的位置运行代码并处理数据）。
面向 非技术决策者：评估供应商的购买者、在做权衡的创始人，以及需要知道“为什么”和“会发生什么变化”的产品经理，而不必研读网络教材。
传统的 CDN（内容分发网络）最开始的承诺很简单：通过从离访问者更近的位置提供内容，让网站感觉更快。与其让每个请求回到源站（通常是单一区域或数据中心），CDN 在多个驻点（PoP）保存静态文件的副本——图片、CSS、JavaScript、下载文件。当用户请求某文件时，CDN 可以就近响应，降低延迟并减轻源站压力。
在本质上，“纯 CDN”部署关注三件事：
这种模式对静态站点、媒体密集型页面和请求模式可预测（相同资源反复被请求）的场景尤其有效。
早期团队用一些实用指标评估 CDN：
这些数字很重要，因为它们直接转化为用户体验和基础设施成本。
即便是基础的 CDN 也会影响请求到达你站点的方式。最常见的是通过 DNS 引入：你的域名指向 CDN，CDN 将访问者路由到就近 PoP。之后，CDN 可能充当 反向代理——终止来自用户的连接，并在需要时与源站建立单独连接。
这种“处于中间”的位置很重要。一旦某个提供商可靠地置于你源站之前并在边缘处理流量，它就能做的不仅仅是缓存文件——还能检查、过滤和调整请求。
许多现代产品不再主要是静态页面。它们是由 API 支撑的动态应用：个性化内容、实时更新、需认证的流程与频繁写操作。缓存有帮助，但无法解决所有问题——尤其是当响应因用户不同而异、依赖 cookie 或头字段，或需要即时的源站逻辑时。
这正是从“CDN”向更广泛边缘平台演进的空间所在。
互联网使用方式的重大变化把更多请求推向“边缘”（网络外围），在到达源站之前就先经过这里。现在不只是为了更快的网站——而是流量自然流动到哪里。
HTTPS 普及是一个重要推动力。一旦大多数流量被加密，企业网络内部的网络中间设备就难以 inspect 或优化这些流量。因而组织倾向于在就近用户的地方终止和管理 TLS——在为此而建的边缘服务处。
API 也改变了流量形态。现代应用是一连串小请求，来自 Web 前端、移动客户端、合作方集成和微服务。再加上机器人（好的和坏的），大量“用户”并非真人——这意味着流量需要在触及应用基础设施之前进行过滤和速率控制。
还有移动网络的现实（延迟可变、漫游、重传）以及 SaaS 的兴起。你的员工和客户不再属于单一网络边界，因此安全和性能决策转向用户实际连接的位置。
当应用、用户和服务分散在不同区域和云时，能统一强制规则的地点变少了。传统控制点（如单一数据中心防火墙）不再是默认路径。边缘成为少数几个可以将大部分请求路由通过的稳定检查点之一。
既然大量流量通过外围，它就是应用共享策略的自然位置：DDoS 过滤、机器人检测、WAF 规则、TLS 设置与访问控制。这减少了每个源站的“决策”负担，并在应用之间保持一致的保护。
在边缘集中流量可以隐藏源站 IP并减少直接暴露，这是一个重要的安全提升。代价则是依赖性：边缘的可用性与正确配置变得至关重要。许多团队把边缘视为核心基础设施的一部分——更接近控制平面，而不仅仅是简单缓存。
如需实用清单，请参见 /blog/how-to-evaluate-an-edge-platform。
传统 CDN 起始于“智能缓存”：在更靠近用户的位置存储静态文件的副本并在需要时从源站获取。它提升性能，但并未从根本上改变谁“拥有”连接。
当边缘不再只是缓存，而成为完整的反向代理时，发生了重大转变。
反向代理位于你网站或应用之前。用户连接到代理，代理再连接到你的源站。对用户而言，代理就是站点；对源站而言，代理看起来就像普通用户。
这种位置关系使得“缓存才做的事”无法做到的服务成为可能——因为每个请求在到达你的基础设施之前都可以被处理、修改或阻断。
当边缘终止 TLS（HTTPS）时，加密连接首先在边缘建立。这带来三项实际能力：
这里是一个思维模型：
user → edge (reverse proxy) → origin
把边缘放在中间会集中控制，这常常正是目标：一致的安全策略、更简单的发布和更少的“特殊情况”在各个源站。但它也增加了复杂性和依赖性：
这个架构转变将 CDN 变成了平台：一旦边缘成为代理，它就可以做远不止缓存的工作。
DDoS（分布式拒绝服务）攻击本质上是尝试以大量流量压垮站点或应用，让真实用户无法访问。攻击者不是“入侵”，而是堵住车道。
许多 DDoS 是容量型攻击：向你的 IP 地址发起大量数据以耗尽带宽或过载网络设备。如果你把防护留在源站（数据中心或云区），你已在买单——上游链路可能饱和，防火墙或负载均衡器成为瓶颈。
边缘网络的保护优势在于它把防护能力更靠近流量进入互联网的位置，而不是仅仅在你的服务器所在处。防护越分布式，攻击者就越难在单一瓶颈处堆积流量。
提供商说 DDoS 保护会“吸收并过滤”，指的是在多个驻点同时发生两件事：
关键好处是攻击的大部分影响可在你的基础设施上游被处理，从而降低你的网络或云账单成为牺牲品的风险。
速率限制是防止任一来源或行为在短时间内消耗过多资源的实用方法。例如，你可能限制：
它并不能单独阻止所有类型的 DDoS，但作为在事件中保持关键路径可用的有效“减压阀”非常有用。
在你依赖边缘 DDoS 保护前，确认：
在基本的 DDoS 过滤就位后，下一层是保护应用本身——尤其是那些“看起来正常”但带有恶意意图的请求。这就是 WAF 和机器人管理在边缘的日常作用。
WAF 会检查 HTTP/S 请求并应用设计用于阻止常见滥用模式的规则。经典示例包括：
让边缘在到达源站前过滤掉许多此类尝试，可以降低风险并减少浪费在计算与日志上的噪音。
机器人可能是有益的（搜索引擎爬虫），也可能有害（凭证填充、抓取、囤积库存、假注册）。关键差别不在于“自动化”，而在于“意图”和“行为”。真实用户的会话通常具有自然的节奏、导航流程与浏览器特征；恶意机器人常常产生高频、重复请求，探测端点，或模拟用户代理但行为异常。
因为边缘能在大量网站上观察到海量流量，它可以使用更广泛的信号来做更智能的判断，例如：
实用的上线方式是先启用监控（日志）模式以查看本应被阻止的内容和原因。用这些数据调整对已知工具与合作方的例外规则，然后逐步收紧策略——从告警到挑战，最终对确认为恶意的流量执行阻断，以减少误报并迅速提升安全。
边缘网络是一组分布在许多城市的服务器（驻点/PoP），可以让请求更靠近用户被处理。根据请求类型，边缘可能会：
实际效果是降低延迟，减轻并减少源站基础设施的暴露和负载。
外围是指“外部互联网流量第一次接触你系统的边界”——你的站点、应用和 API，经常通过 DNS 和边缘反向代理到达这里。它之所以重要，是因为：
在外围集中控制能让你在流量到达核心服务前应用一致的性能和安全规则。
经典 CDN 专注于在边缘位置缓存静态内容（图片、CSS、JS、下载文件），通过缩短物理距离和减少源站请求来提升速度并减轻源站负载。
现代边缘平台则进一步成为“完整的反向代理”，可以对大部分流量进行路由、检测、安全拦截，并在某些情况下执行计算——无论内容是否可缓存。
DNS 往往是把 CDN/边缘服务放在站点前面的最简单方式：你的域名指向提供商，流量被引导到就近的 PoP。
在许多部署中，边缘还充当反向代理：用户先与边缘建立连接，边缘在需要时再与源站连接。正是这个“在中间”的位置，使得缓存、路由和安全可在大规模下生效。
当边缘终止 TLS 时，HTTPS 加密连接在边缘建立。这带来三个实际能力：
这增强了控制力——但也使得边缘配置成为关键的可用性点。
评估 CDN 时，应选用能直接关联到用户体验和基础设施成本的指标，例如：
同时结合源站指标（CPU、请求率、出站流量）来确认 CDN 的确在关键处减轻了压力。
边缘缓解之所以通常比源站更有效，是因为许多 DDoS 攻击是**容量型（volumetric）**的——通过向你的 IP 地址发大量流量来耗尽带宽或网络设备。
分布式的边缘可以：
仅在源站防护通常意味着你在缓解生效前就已经承担了代价（链路饱和、负载均衡器过载、更高云账单）。
速率限制是在时间窗口内限制客户端（或令牌）请求数量，防止单一来源短时间内占用过多资源。
常见边缘场景包括：
它不能独自阻止所有类型的 DDoS，但作为抑制滥用峰值的有效阀门非常实用。
WAF 会检查 HTTP 请求并应用规则以阻止常见应用层攻击（例如 SQL 注入和 XSS）。机器人管理则关注识别和处理自动化流量——既包括良性机器人（搜索引擎爬虫），也包括恶意机器人（抓取、假注册、凭证填充）。
一个实用的上线流程是：
零信任的通俗说法是：不要信任网络——验证每一个请求。无论用户在办公室、酒店 Wi‑Fi 还是家庭网络，访问决策都应基于身份、设备信号和上下文，而不是流量来自何处。
在边缘，它通常体现为：
应避免的错误包括把零信任当成简单的 VPN 替代并就此结束；移除 VPN 改善可用性，但不会自动纠正薄弱的身份实践、过宽的权限或缺失的设备检查。
API 改变了边缘网络的价值，因为它们把大量“小门”暴露给外部：移动客户端、合作方集成、内部工具和自动化任务都会频繁调用 API，从而让机器流量（既有正当也有恶意）不断打到外围。
边缘若能就近路由、缓存并过滤 API 流量，就能降低延迟并避免源站在垃圾请求上浪费容量。
边缘平台通常会提供类似 API 网关的功能，例如：
优先考虑三项实用功能：、，以及，这样开发者能更快修复客户端，安全团队也能更容易区分故障与攻击。
边缘计算是指在靠近用户的服务器上运行小段代码——在请求回到源站之前就做决策、转换请求，甚至生成响应。相比仅做缓存（传统 CDN），边缘现在可以处理认证校验、重定向、个性化和请求改写等轻量逻辑，从而减少到源站的往返并降低核心系统负载。
但边缘运行时有约束：
把边缘计算当作应用的“前台柜台”来处理检查与决策，而把复杂业务逻辑留给源站，是常见的实用做法。
如果你的函数在边缘执行但每次都要去远端拿数据，延迟优势会丧失。因此边缘平台通常也提供靠近计算的存储服务：键值（KV）存储、对象存储、队列，甚至某些场景下的数据库。
常见放在边缘的数据类型包括：
评估时关注持久性与 SLA、定价模型（请求、存储 GB、操作类型）以及出站/跨区流量成本。边缘存储最适合那些能接受“短暂不一致”而获益于低延迟的场景。
随着边缘从缓存演进为平台，一个常见模式是整合：组织倾向于将 DNS、CDN、DDoS 防护、WAF、机器人控制和应用访问放到单一控制面来协调流量进入和经过外围的方式。
好处包括：更少供应商、更简洁的路由和共享的分析视图；风险在于更高的集中化（单点故障、迁移难度、归属不清）。为了既享受便利又控制风险，应把边缘视为平台：定义清晰角色、使用变更管理、分阶段发布并保留回滚计划。
选择边缘平台不仅是选一个“更快的 CDN”，而是决定在哪里检查、加速并在需要时执行关键流量。把特性和你的实际约束（用户体验、风险、开发速度）对应起来。
实用清单：
在无法将“必需”与可衡量结果（如更少事故、降低延迟、减少源站负载）关联时，把它视为可选项。建议从一个有代表性流量的应用/API 做试点（监控→执行），定义成功指标并制定 DNS 回退、旁路规则与应急路径。