前端页面部署 --- Cloudflare全栈式云服务平台

历经十余年发展，Cloudflare 已构建起覆盖全球数百个城市的边缘网络，成为集域名解析、网络代理、安全防护、内容分发、边缘计算、应用托管与零信任接入于一体的全栈式云服务平台。它以反向代理为核心形态，将网络与安全能力前置到离用户最近的边缘节点，重构了传统互联网应用的访问链路。

一、基础：DNS、代理模式与反向代理

Cloudflare 所有能力的落地，都建立在三个核心概念之上：权威 DNS、代理模式与反向代理架构。三者共同决定了流量是否经过 Cloudflare、以何种方式经过 Cloudflare。

1. 权威 DNS：流量的入口调度

DNS（域名系统）的作用是将人类可读的域名（如 www.example.com）映射为机器可识别的 IP 地址（如 192.0.2.10）。DNS 是一套分层分布式数据库，由域名空间与资源记录、权威域名服务器、递归解析器（Resolver）三部分构成。其中，权威 DNS 服务器保存特定域名区域的正式解析记录；递归 DNS 则代表用户逐级查询根服务器、顶级域服务器与权威服务器，最终返回解析结果。

当用户将域名的 Nameserver 修改为 Cloudflare 提供的服务器（如 alice.ns.cloudflare.com、bob.ns.cloudflare.com）后，Cloudflare 即成为该域名的权威 DNS 服务商，全权控制该域名下的 A/AAAA 记录、CNAME 记录、MX 邮件记录、TXT 验证记录、DNSSEC 等全部 DNS 配置。

使用 Cloudflare DNS 不等于使用 Cloudflare CDN。流量是否进入 Cloudflare 代理链路，取决于 DNS 记录是否开启代理模式。

在此基础上，Cloudflare 权威 DNS 还实现了 CNAME Flattening（CNAME 扁平化） 技术：当根域名（example.com）配置 CNAME 记录时，Cloudflare 会在权威侧递归解析 CNAME 目标，最终直接返回 IP 地址，突破了 DNS 标准中根域名不能配置 CNAME 的限制，同时提升了解析效率。

2. DNS Only 与 Proxied：两种流量模式

Cloudflare 控制台中的"云朵"状态，是区分流量模式的标识，直接决定了请求链路的走向。

灰色云：DNS Only 模式

text 复制代码

用户 → DNS 查询 → 得到源站真实 IP → 直接访问源站

该模式下，Cloudflare 仅承担权威 DNS 解析职责，不代理 HTTP 请求，不提供 CDN 缓存、WAF 防护能力，不会隐藏源站 IP，也不会在用户与源站之间终止 TLS 连接。该模式通常用于邮件服务、SSH 直连等不需要 HTTP 代理的场景。

橙色云：Proxied 代理模式

text 复制代码

用户 → DNS 查询 → 得到 Cloudflare Anycast IP
                    ↓
                Cloudflare
                    ↓
                  源站

开启代理后，DNS 查询返回的不再是源站真实 IP，而是 Cloudflare 的共享 Anycast IP。用户流量将先抵达 Cloudflare 边缘节点，经过缓存、安全校验、逻辑处理后，再由 Cloudflare 转发至源站。

橙色云的本质并非"开启加速开关"，而是将 Cloudflare 置入用户与源站之间，使其成为全链路的反向代理。

3. 反向代理：Cloudflare 的架构形态

代理分为正向代理与反向代理两类：正向代理代表客户端访问外部服务，用于隐藏客户端身份、突破网络限制；反向代理则代表后端服务器接收客户端请求，用于统一入口、安全防护、负载均衡与内容缓存。

在典型网站架构中，Cloudflare 就是标准的反向代理：浏览器认为自己直接连接了目标域名，实际连接的是 Cloudflare 边缘节点，再由 Cloudflare 代表浏览器向源站发起请求。

基于这一架构，Cloudflare 可在请求链路中完成 TLS 握手、HTTP/2 与 HTTP/3 协议处理、DDoS 流量清洗、WAF 安全检测、Bot 识别、访问限流、内容缓存、数据压缩、Workers 边缘代码执行、回源负载均衡等一系列能力，实现"一次接入，全链路赋能"。

二、Anycast 网络架构

Cloudflare 能够实现全球就近接入主要依赖 Anycast（任播）网络技术，这也是其与传统 CDN 最重要的架构差异之一。

1. Anycast 原理

传统单播（Unicast）网络中，一个 IP 地址仅对应一个物理节点；而在 Anycast 架构下，Cloudflare 全球所有边缘节点对外宣告完全相同的 IP 地址段。例如，东京、马尼拉、新加坡、洛杉矶的节点可同时宣告 104.16.x.x 这一 IP 段。

当用户访问该 IP 时，互联网的 BGP（边界网关协议）路由系统会根据路由跳数、链路质量、运营商对等关系等策略，将流量自动送往网络路径最优的 Cloudflare 边缘节点。

Anycast 选择的是 BGP 路由意义上的最优路径，不一定是地理距离最近的机房。运营商路由策略、对等互联关系、跨境链路成本等因素，都可能导致流量被调度至非地理最近的节点。

Cloudflare 全球网络通过 BGP 协议从多位置宣告相同的 Anycast IP。Anycast CDN 具备更高的可用性与路径稳定性，但运营方会损失一部分精细化流量调度能力。

2. Anycast 架构的价值

降低网络延迟

用户流量将优先进入路径最近的边缘节点，避免跨洲直连源站带来的高 RTT（往返时延）。对于缓存命中的静态内容，请求无需回源，响应延迟可降至毫秒级。

天然故障转移

当某一节点或对应路由不可用时，Cloudflare 可快速撤销该节点的 BGP 路由宣告，流量将自动切换至其他可达节点，实现无感知故障转移，提升整体服务可用性。

分布式 DDoS 防护

DDoS 攻击流量会被 Anycast 网络自动分散到全球不同边缘节点进行清洗，而非集中冲击单一源站 IP。结合全球节点的带宽池，可大幅提升攻击承载阈值。

统一网络入口

无论源站部署在自建机房、公有云（AWS/Azure/阿里云）、家用服务器还是 Kubernetes 集群，对外都可呈现为统一的 Cloudflare 网络入口，屏蔽底层基础设施差异。

三、链路拆解：一次 HTTP 请求的 Cloudflare 之旅

以用户访问 https://www.example.com/image.png 为例，请求链路可分为七个阶段，覆盖从 DNS 解析到内容返回的全流程。

第一步：DNS 解析

浏览器首先向递归 DNS 发起域名解析请求。若该域名记录开启橙色云代理，Cloudflare 权威 DNS 将返回 Cloudflare Anycast IP，而非源站真实 IP。

第二步：建立传输连接

用户向返回的 Anycast IP 建立传输层连接，支持两种主流协议：

TCP + TLS 1.3：承载 HTTP/2 流量，兼容绝大多数客户端；
QUIC + HTTP/3：基于 UDP 的多路复用安全传输协议，由 RFC 9000 标准化，具备连接迁移、队头阻塞消除等特性，在弱网环境下表现更优。

Cloudflare 是全球最早大规模落地 HTTP/3 的服务商之一，目前默认对所有代理域名开启 HTTP/3 支持。

第三步：TLS 连接终止

浏览器与 Cloudflare 边缘节点完成 TLS 握手，建立加密会话。由于 Cloudflare 需要读取 HTTP 请求内容以执行 WAF 检测、缓存匹配、Workers 逻辑处理，因此必须在边缘节点终止 TLS 连接，解密请求内容。

当前 Cloudflare 全平台默认支持 TLS 1.3 协议，相比 TLS 1.2 缩减了握手往返次数，同时强化了前向保密等安全特性。对于高并发场景，还支持 TLS 会话复用与 0-RTT 握手，进一步降低连接建立延迟。

第四步：多层安全校验

请求在进入业务逻辑前，将依次经过多层安全防护体系，概念上的执行顺序为：

text 复制代码

L3/L4 DDoS 检测
     ↓
HTTP DDoS 检测
     ↓
WAF 规则集
     ↓
Bot 行为检测
     ↓
访问限流 (Rate Limiting)
     ↓
自定义安全规则

实际内部执行流程会根据产品配置、规则类型动态调整，目标是在边缘节点直接拦截恶意请求，避免其消耗源站资源。所有安全规则的检测均基于 Cloudflare 全球威胁情报体系实时更新。

第五步：Workers 边缘代码执行

若域名或路径绑定了 Worker 脚本，请求将进入用户自定义的代码逻辑。Cloudflare Workers 支持 JavaScript、TypeScript、Rust/Wasm 等多种语言，开发者可在边缘节点完成请求头修改、身份鉴权、路由转发、动态响应生成、第三方 API 调用等操作。

示例代码：

javascript 复制代码

export default {
  async fetch(request, env) {
    return new Response("Hello from Cloudflare");
  }
}

第六步：边缘缓存匹配

Cloudflare 根据请求 URL、缓存规则、响应头、缓存键等信息，查询边缘节点是否存在可用的缓存副本。

缓存命中：直接从边缘缓存返回内容，无需访问源站，响应延迟最低；
缓存未命中：请求继续转发至源站，获取响应后，若满足缓存条件则保存至边缘缓存，再返回给用户。

HTTP 缓存涵盖缓存存储、新鲜度、年龄、Vary 响应、重新验证等机制，同时提供扩展能力支持定制化缓存策略。

第七步：回源请求转发

需要回源时，Cloudflare 将与源站建立独立的连接，发起请求并获取响应。因此，完整的 TLS 加密链路通常分为两段：

text 复制代码

用户 ⇄ Cloudflare ⇄ 源站
      TLS ①       TLS ②

Cloudflare 官方文档将两段证书明确区分：

Edge Certificate：用户到 Cloudflare 边缘的证书，由 Cloudflare 统一签发管理；
Origin Certificate：Cloudflare 到源站的证书，用于保障回源链路加密。

四、CDN 缓存体系

CDN 的价值是通过边缘缓存缩短内容传输距离，降低源站负载。

1. CDN 解决的问题

假设源站部署在美国，用户位于亚洲，无 CDN 时请求需全程跨境传输，存在四大痛点：

往返时延（RTT）高，页面加载速度慢；
跨境链路丢包对传输性能影响显著；
所有用户请求直接消耗源站带宽；
并发请求直接冲击源站计算与数据库资源。

接入 Cloudflare CDN 后，亚洲用户可直接访问就近的边缘节点，静态资源缓存命中时无需跨境回源，从根本上解决上述问题。

2. 默认缓存规则与适用资源

Cloudflare 默认仅对静态文件类型执行缓存，主要包括：

样式与脚本：CSS、JavaScript；
图片资源：PNG、JPEG、WebP、AVIF、SVG；
媒体与文件：字体、PDF、ZIP 压缩包、音视频文件。

默认情况下，HTML、JSON 等动态内容不会仅凭文件类型被缓存，需通过 Cache Rules、Workers 或源站响应头显式配置缓存策略。

3. Cache-Control：缓存策略的标准

源站可通过 Cache-Control 响应头控制缓存行为，标准指令如下：

http 复制代码

Cache-Control: public, max-age=3600
Cache-Control: private
Cache-Control: no-store
Cache-Control: no-cache

各指令的精确含义：

public：允许共享缓存（如 CDN）存储该响应；
private：仅允许私有缓存（如浏览器本地）存储，CDN 不应缓存；
no-store：禁止任何缓存存储该响应，每次都需回源；
no-cache：允许缓存存储，但再次使用前必须向源站验证有效性；
max-age：定义资源的新鲜度生命周期，单位为秒。

Cloudflare 默认不会缓存带有 private、no-store、no-cache、max-age=0 等指令的响应；同时默认不缓存非 GET 请求，包含 Set-Cookie 头的响应通常也不会进入常规缓存流程。

4. 双层缓存：浏览器缓存与边缘缓存

浏览器本地缓存与 Cloudflare 边缘缓存是两个完全独立的缓存层级，可分别配置策略。为实现定向缓存控制，Cloudflare 支持 CDN-Cache-Control、Cloudflare-CDN-Cache-Control 等扩展响应头，专门针对 CDN 节点设置缓存规则，不影响浏览器缓存行为。该机制遵循"定向 HTTP 缓存控制"标准，实现了不同缓存层级的策略解耦。

5. Request Collapsing：缓存击穿防护

当热门资源缓存失效瞬间，若同时有大量并发请求到达，会引发"缓存击穿"，所有请求同时回源压垮源站。

Cloudflare 通过 Request Collapsing（缓存锁）机制解决该问题：首个未命中的请求触发回源，其余相同请求在边缘节点等待回源结果，最终共享同一份响应。

text 复制代码

1000 个并发请求
      ↓
Cloudflare 缓存锁
      ↓
1 次回源请求

该机制可大幅降低缓存失效瞬间的源站压力，尤其适用于大文件分发、热点内容突发访问等场景。

补充：分层缓存体系

为进一步优化回源效率，Cloudflare 构建了三级缓存架构：

边缘节点缓存：离用户最近的接入节点，存储热门内容；
上层缓存节点（Tiered Cache）：区域级缓存节点，存储次热门内容，边缘节点未命中时优先查询上层节点，减少跨区域回源；
Cache Reserve：基于 R2 对象存储的持久化缓存层，存储低频访问的冷内容，避免源站重复响应冷请求，进一步降低回源成本。

五、安全防护体系：DDoS 防护与 WAF 的边界与协同

DDoS 防护与 WAF 是 Cloudflare 安全体系的两大组件，二者防护目标、工作层级、检测逻辑均有本质差异，无法相互替代。

1. DDoS 防护：对抗流量规模攻击

DDoS（分布式拒绝服务）攻击的核心目标是耗尽目标的网络带宽、连接表、CPU 资源、Web 线程、数据库连接或 API 配额，最终导致服务不可用。

Cloudflare DDoS Protection 覆盖 OSI 模型的多个层级：

L3：IP 层攻击，如 IP 碎片攻击；
L4：传输层攻击，如 UDP Flood、SYN Flood、ACK Flood；
L7：应用层攻击，如 HTTP GET Flood、随机子域 DNS 攻击。

其防护系统基于全球流量基线自动检测异常，并通过边缘节点直接清洗攻击流量，无需人工干预。

官方数据显示Cloudflare 可承载 Tbps 级别的 DDoS 攻击。

2. WAF：对抗应用层漏洞攻击

WAF（Web Application Firewall，Web 应用防火墙）工作在 HTTP 应用层，核心是分析请求内容的合法性，拦截针对应用漏洞的攻击行为。

例如针对请求 GET /users?id=1' OR '1'='1，WAF 可识别其 SQL 注入特征并拦截。Cloudflare WAF 可检测的攻击类型包括：

SQL 注入、XSS 跨站脚本；
路径遍历、命令注入；
恶意文件上传、已知漏洞利用；
异常 HTTP 参数与协议违规。

Cloudflare WAF 提供的能力包括：自定义规则、托管规则集（Managed Rules）、OWASP 规则集、访问限流、IP/国家/请求字段过滤、攻击评分等，可灵活适配不同业务的安全需求。

3. 二者的差异与协同关系

text 复制代码

DDoS Protection：
防止"请求量或流量规模"拖垮服务
WAF：
防止"请求内容和行为"攻击应用

典型场景区分：

每秒 100 万个格式正常的请求 → 属于 DDoS 防护范畴；
每秒 1 个精心构造的 SQL 注入请求 → 属于 WAF 防护范畴。

二者相辅相成：DDoS 防护先清洗掉海量恶意流量，WAF 再对剩余正常流量做精细化内容检测，共同构建完整的应用安全防线。

在此之外，Bot 管理是 Cloudflare 安全体系的另一重要模块，通过行为分析、设备指纹、人机验证等方式识别恶意爬虫与自动化工具，可与 WAF、DDoS 防护联动配置。

六、SSL/TLS 加密模型：端到端的信任链路

Cloudflare 作为反向代理，天然将 TLS 链路拆分为两段，不同加密模式对应不同的安全等级，需根据业务场景选型。

1. Universal SSL：边缘加密的基础

当域名开启代理后，Cloudflare 可自动签发并管理边缘证书，即 Universal SSL，免费为所有站点提供 HTTPS 访问能力。但 Universal SSL 仅解决了"用户 → Cloudflare"段的加密，"Cloudflare → 源站"段的加密仍需单独配置。

2. 四种 SSL/TLS 加密模式

Cloudflare 提供多级加密模式，安全强度逐级提升。

Flexible 模式

text 复制代码

用户 ⇄ Cloudflare → 源站
      HTTPS          HTTP

仅加密用户到 Cloudflare 的链路，Cloudflare 到源站仍为明文 HTTP 传输。该模式仅实现"部分安全"，涉及登录、个性化数据等敏感内容的站点，应使用 Full 或 Full (strict) 模式，而非 Flexible。

Full 模式

text 复制代码

用户 ⇄ Cloudflare ⇄ 源站
      HTTPS          HTTPS

两段链路均采用 HTTPS 加密，但 Cloudflare 对源站证书的验证较为宽松，源站可使用自签名证书或过期证书，无法完全防范中间人攻击。

Full (strict) 模式

text 复制代码

用户 ⇄ Cloudflare ⇄ 经过证书验证的源站

两段链路均加密，且 Cloudflare 会严格校验源站证书：

证书是否在有效期内；
是否由可信 CA 或 Cloudflare Origin CA 签发；
证书域名是否与目标域名匹配。

Full (strict) 是安全性最高的标准模式，推荐在条件允许时优先使用。

补充：高级加密能力

Origin CA 证书：Cloudflare 提供的免费源站证书，仅被 Cloudflare 节点信任，用于回源链路加密，无需向公共 CA 申请，部署便捷；
Keyless SSL：企业级功能，允许用户将私钥保留在自有服务器，Cloudflare 不接触私钥即可完成 TLS 握手，满足金融、政务等高安全合规要求；
HSTS：可配置 HTTP Strict Transport Security，强制浏览器使用 HTTPS 访问，防止协议降级攻击。

七、边缘计算引擎：Workers 与 Isolate 架构

Cloudflare Workers 是部署在全球边缘节点的 Serverless 计算平台，基于 V8 Isolate 技术构建，与传统容器型 Serverless 有本质架构差异。

1. Isolate 运行时架构

传统 Serverless 平台通常基于容器或 MicroVM 隔离函数，每个函数实例对应独立的运行环境，冷启动耗时通常在百毫秒级。

Workers 采用 V8 Isolate 隔离架构：同一个 V8 运行时进程内，可管理大量相互隔离的 Isolate 实例，每个 Isolate 拥有独立的 JavaScript 内存环境，承载不同用户的代码。

text 复制代码

Cloudflare Worker Runtime
  ├─ Isolate A：用户 A 的代码
  ├─ Isolate B：用户 B 的代码
  ├─ Isolate C：用户 C 的代码
  └─ ...

Isolate 的创建开销远低于容器，可实现亚毫秒级冷启动，且单台服务器可承载上万名租户的代码，极大提升了资源利用率，降低了边缘计算的成本。

Cloudflare Workers Runtime 基于 V8 引擎与 WebAssembly 标准构建，支持完整的 Web API。

多租户 Isolate 架构存在微架构侧信道风险，Cloudflare 通过动态进程隔离等机制缓解该类风险，保障多租户安全。

2. Workers 的适用场景

Workers 轻量、低延迟的特性，使其非常适合部署在请求链路上的边缘逻辑，典型场景包括：

API 网关、JWT 身份鉴权；
请求/响应重写、边缘重定向；
A/B 测试、灰度发布；
图片处理、Webhook 处理；
轻量后端 API、多服务聚合；
反向代理、自定义缓存控制。

3. Isolate 架构的局限

Workers 并非完整的 Linux 虚拟机，存在明确的能力边界：

无完整操作系统环境，无法启动任意守护进程；
无持久化本地磁盘，状态存储需依赖配套数据产品；
CPU 执行时间、内存占用、子请求数量受套餐配额限制；
进程内状态不具备持久化可靠性，无法作为可靠存储使用。

同时，Workers 原生支持 WebAssembly，开发者可使用 Rust、C/C++、Go 等语言编写高性能逻辑，编译为 Wasm 后在边缘运行，兼顾性能与安全性。

八、全栈托管生态：Pages

围绕 Workers 边缘计算，Cloudflare 构建了完整的应用托管与数据存储产品，形成了全栈式边缘开发平台。

1. Cloudflare Pages：前端与全栈应用托管

Cloudflare Pages 是面向前端与全栈项目的托管平台，支持 Git 驱动的自动化部署。

典型工作流：

text 复制代码

GitHub 仓库
   ↓
Cloudflare 自动构建
   ↓
静态文件部署到全球边缘网络

Pages 非常适合部署个人作品集、博客、Vue/React/Vite 项目、Astro/Hugo 静态站点、MkDocs 技术文档等前端项目。

通过 Pages Functions，开发者可为 Pages 项目添加服务端动态逻辑，无需单独管理服务器，其底层基于 Workers 运行时，能力完全对齐。

与 GitHub Pages 相比，Cloudflare Pages 的能力更全面：

能力	GitHub Pages	Cloudflare Pages
静态网站托管	支持	支持
Git 自动部署	支持	支持
自定义域名	支持	支持
动态后端	不直接提供	Pages Functions / Workers
边缘计算	不提供	Workers
数据库集成	不直接提供	D1、KV、R2、Durable Objects
安全规则	有限	WAF、Access、限流等

GitHub Pages 更偏向纯静态网站托管；Cloudflare Pages 是与边缘 Serverless 深度集成的全栈应用部署平台。

2. 边缘数据产品矩阵

Cloudflare 提供四款核心数据存储产品，覆盖不同业务场景，均与 Workers、Pages 深度集成。

R2：零出口费对象存储

R2 是 S3 兼容的对象存储服务，适合存储图片、视频、模型文件、日志归档、安装包、数据集、用户上传文件等。

Cloudflare 强调 R2 不收取传统云对象存储常见的公网出口带宽费用，仅收取存储容量与操作请求费用，大幅降低了大文件分发的成本。

D1：Serverless SQL 数据库

D1 是 Cloudflare 推出的 Serverless SQL 数据库，提供 SQLite 风格的 SQL 语义，可通过 Workers、Pages 或 HTTP API 访问。

D1 适合存储用户信息、博客文章、项目列表、配置数据、元数据等结构化数据，支撑小型管理后台、轻量业务系统。

示例建表语句：

sql 复制代码

CREATE TABLE projects (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    description TEXT
);

Workers KV：全球分布式键值存储

Workers KV 是全球分布式键值存储，采用最终一致性模型，适合读多写少、允许一定传播延迟的业务场景，如配置项、用户资料、主题设置等。

text 复制代码

"site:theme" → "dark"
"user:1001:profile" → "{...}"

KV 的数据会异步同步到全球边缘节点，写入后通常在 60 秒内完成全球传播，不适合需要强一致性、实时事务的业务。

Durable Objects：有状态边缘协调

Durable Objects 用于解决边缘 Serverless 场景下的强协调与有状态计算问题。每个 Durable Object 拥有全局唯一标识，计算与存储深度耦合，提供强一致、可序列化的存储接口，可协调多个客户端连接。

适用场景：聊天室、多人游戏房间、协同编辑、实时设备状态同步、分布式锁、单用户会话协调、精确计数器等。Cloudflare 将其定位为构建有状态应用与分布式系统的基础组件。

九、内网互联与零信任：Tunnel 与 Zero Trust 架构

除了面向公网应用的加速与防护，Cloudflare 还构建了完整的企业内网接入与零信任安全体系，重新定义了远程办公与内网资源访问的模式。

1. Cloudflare Tunnel：无公网 IP 的安全接入

传统内网服务暴露到公网，需要公网 IP、端口映射、防火墙放行，存在较高安全风险。Cloudflare Tunnel 通过主动出站连接的方式，将内网服务安全接入 Cloudflare 网络。

传统暴露方案：

text 复制代码

Internet
   ↓
公网 IP
   ↓
路由器端口映射
   ↓
内网服务器

Cloudflare Tunnel 方案：

text 复制代码

内网服务器上的 cloudflared
      ↓ 主动建立出站连接
Cloudflare 全球网络
      ↓
		用户

特点：连接由内网的 cloudflared 客户端主动向外建立，通常不需要公网 IP，也不需要开放入站端口。隧道建立后，请求可双向传输，但防火墙可完全阻断所有公网入站连接，极大缩小攻击面。

基础使用命令：

bash 复制代码

cloudflared tunnel --url http://localhost:8080

该命令可将本地 http://localhost:8080 服务，通过 Cloudflare 分配的域名安全暴露到公网。

Cloudflare Tunnel 适用于家庭服务器、内部管理面板、NAS、SSH、远程桌面、企业内部服务、本地开发测试、无公网 IP 的工控机服务等场景。

2. Cloudflare Zero Trust：零信任安全架构

传统企业网络基于"边界信任"模型：接入公司局域网或 VPN 后，默认用户具备较高访问权限。而零信任架构的思想是：永不信任，始终验证，无论用户来自公网还是内网，每次访问都需验证身份、设备状态、访问上下文与合规策略。

零信任架构是将安全防御重点从静态网络边界，转移到用户、资产与资源上的架构范式。

Cloudflare One（零信任产品套件）包含以下组件：

Access：应用访问控制，判断用户是否有权限访问内部应用；
Gateway：安全网关，过滤 DNS、HTTP 与网络流量；
Tunnel：内网资源连接器，将内部服务接入 Cloudflare；
WARP：终端安全客户端，为员工设备提供安全网络接入；
Browser Isolation：浏览器隔离，将恶意代码拦截在云端；
DLP：数据防泄漏，检测并阻止敏感数据外传。

其中 Cloudflare Access 是零信任应用访问的核心，可通过 Include、Require、Exclude 等规则组合身份与上下文条件，实现精细化访问控制。典型策略示例：

仅允许公司邮箱账号访问；
必须启用多因素认证（MFA）；
必须使用企业受管理设备；
仅允许指定国家/地区的 IP 访问；
仅特定用户组可访问敏感系统。

十、Cloudflare 的能力边界与局限

1. 默认不替代源站基础设施

仅将域名接入 Cloudflare 代理，源站服务器仍由用户自行管理。Cloudflare 不会自动替用户运行 Nginx、部署数据库、保存业务数据、修复源站漏洞、管理操作系统或执行服务器备份。

只有使用 Pages、Workers、R2、D1 等原生托管产品时，对应的应用与数据才真正部署在 Cloudflare 平台上。

2. 并非所有流量都适合缓存

动态 HTML、API 接口、登录态数据、带 Cookie 的个性化内容，盲目缓存会引发严重问题，例如用户 A 的个人页面被缓存后返回给用户 B，造成数据泄露。

缓存规则必须结合 URL、Cookie、Authorization 头、请求方法、用户身份、响应头等维度谨慎设计，区分可缓存的静态内容与不可缓存的动态内容。

3. 配置后不代表源站绝对安全

若攻击者通过历史 DNS 记录、邮件头、Git 提交历史、证书透明度日志等渠道获取源站真实 IP，即可绕过 Cloudflare 直接攻击源站。

因此，接入 Cloudflare 后仍需配套加固措施：

源站防火墙仅放行 Cloudflare 官方 IP 段的入站请求；
优先使用 Cloudflare Tunnel，完全关闭公网入站端口；
清理泄露源站 IP 的旧 DNS 记录与历史数据；
持续对源站系统与应用进行安全更新与加固。

4. 平台绑定与技术依赖风险

若业务深度使用 Workers、Durable Objects、D1、KV 等 Cloudflare 原生产品，应用会与 Cloudflare 平台深度绑定，迁移成本较高，架构设计时需权衡云厂商依赖风险。

5. 其他客观局限

TLS 必须在边缘终止才能实现 WAF、缓存等能力，因此 Cloudflare 位于应用数据的信任边界内；
Anycast 路由受运营商策略影响，无法保证用户始终接入地理最近的节点；
免费版存在请求次数、CPU 时间、存储容量、日志保留等配额限制，高级功能需升级付费套餐；
中国大陆地区无自建节点，跨境访问的优化效果受国际链路影响，存在一定不确定性。

总结

Cloudflare 的能力体系可从下到上划分为五层：

text 复制代码

第一层：DNS 层
域名解析与流量入口调度
第二层：网络代理层
Anycast 网络、反向代理、TLS 终止、HTTP/3 协议
第三层：安全防护层
DDoS 清洗、WAF、Bot 管理、限流、零信任
第四层：性能优化层
CDN 缓存、连接优化、分层缓存、智能路由
第五层：开发平台层
Workers、Pages、R2、D1、KV、Durable Objects

贯穿五层架构的本质是：

Cloudflare 通过权威 DNS 与 Anycast 全球网络，将自身置入用户与应用之间，在全球边缘节点上统一执行网络接入、安全防护、缓存加速与应用计算。

它重新定义了互联网应用的接入边界：开发者无需在全球部署机房，也无需自研复杂的安全与加速系统，只需接入 Cloudflare 平台，即可获得全球级的网络与安全能力，将精力聚焦于业务逻辑本身。