Cloudflare 完全指南：产品、用途、架构与最佳实践

版本：2026 综合版｜定位：面向开发者、运维工程师与架构师的 Cloudflare 全景用途总结
说明：本文聚焦「Cloudflare 能做什么、怎么用、什么时候用」，按产品线与用途分类展开，配官方文档索引与选型建议，内容力求全面而克制。

第 1 章什么是 Cloudflare
第 2 章核心价值与全局架构
第 3 章 CDN 与全球加速
第 4 章智能 DNS 托管
第 5 章网络安全体系（DDoS / WAF / Bot / 速率限制）
第 6 章零信任安全（Zero Trust）
第 7 章边缘计算平台（Workers / Pages / R2 / D1）
第 8 章图像与视频交付
第 9 章邮件与通信保护
第 10 章网络与连接（Tunnel / WARP / Magic Transit）
第 11 章开发与部署工具
第 12 章可观测性与分析
第 13 章行业与场景方案
第 14 章成本模型与套餐选型
第 15 章最佳实践与常见误区
第 16 章关键概念速查表
第 17 章官方文档索引
第 18 章深度专题：常见故障排查与 FAQ
附录 A 术语表与缩写
附录 B 快速决策树

第 1 章什么是 Cloudflare

1.1 一句话定义

Cloudflare 是一家全球性的云网络平台（Edge Network / Network-as-a-Service），它并不是传统意义上只做 CDN 的厂商，而是把「内容分发」「安全防护」「域名解析」「边缘计算」「零信任接入」「网络互联」六大类能力统一建设在分布全球的边缘节点（Edge PoP）之上，对外以一套「DNS + 反向代理网关」的形式交付。

通俗地讲：当你在 Cloudflare 上接入一个域名，互联网上针对它的流量会先经过 Cloudflare 遍布全球的数十个乃至数百个数据中心（在许多城市甚至每个主流运营商都设有节点），在边缘先完成加速、过滤、缓存、计算、防御，再回源到你的真实服务器。你的源站 IP 因此被隐藏，流量被净化，访问体验被加速。对很多个人站长来说，第一次接触 Cloudflare 往往就是从「换个 NS、点亮橙云、网站突然变快也攻不动了」这个朴素体验开始的。

1.2 为什么它如此特殊

Cloudflare 的特殊性源于它的架构位置，即「站在网络中间」：

它同时站在用户与服务器之间（On-Path）：全球流量默认经过它，这使它天然能同时做「安全」和「性能」两件事——传统 WAF 往往需要额外的引流或旁路，传统 CDN 只能专注缓存，而 Cloudflare 因为「流量本来就路过它」，所以安全与加速是同一份能力的两个侧面。
它是全球最大的 Anycast 网络之一：任何节点 IP 在全球范围都是「最近的」，用户总能访问到距离自己最近的节点，延迟被压缩到个位数甚至亚毫秒级，这是它在解析与加速上「快」的根本原因。
它是 DNS 生态的深度参与者：Cloudflare 是多个顶级域名（如 .DE、.NJ、.PT 等）的权威 DNS 运营方之一，与顶级 ISP 建有直连（Peering）。这意味着它的 DNS 解析几乎不可能被针对「域名服务器」层面的攻击打垮——这在实际被 DDoS 时是巨大的底气。
边缘即计算（Edge Computing）：Cloudflare Workers 让开发者把代码部署到离用户最近的节点上运行，业务响应从「回到遥远的源站」变成「就在用户旁边的边缘完成」，这是其从 CDN 向「全球无服务器平台」演进的关键跳板。

1.3 发展历程与规模

2010 年：由 Matthew Prince、Michelle Zatlyn 与 Lee Holloway 创立，最初定位是解决 IP 地址枯竭与 IPv6 过渡问题，后来演化成完整的网络平台。
2015–2020：从 CDN 厂商跃升为 DDoS 防护与权威 DNS 的头部玩家；推出 Workers（边缘计算）、WAF 托管规则，并连续多年在免费套餐提供一线防护。
2020–2024：发力零信任远程访问（Access / Tunnel / WARP）、R2 对象存储、D1 关系数据库、Workers AI 与 Queues，把「边缘计算」从概念落地为一个完整灵活的开发平台。
当前规模：全球超过 300 个城市设有节点，数据中心遍布 120 多个国家和地区，防御峰值容量达到每秒数 Tbps（多次公开演示抵御超过 2 Tbps 甚至更高的单次攻击）。数以千万计的免费域名与上百万企业级付费客户，全球约两成以上的网站流量流经 Cloudflare。

1.4 它解决的核心问题（按痛点对应）

问题域	Cloudflare 的答案
网站访问慢、跨国跨运营商延迟高	全球 Anycast CDN + 智能缓存 + Argo 智能回源
源站 IP 被扫描、被直接攻击	隐藏源站 IP + 源站只信任 CF 回源段
DDoS 把服务打挂	全网 Anycast 清洗，容量几乎无限
恶意爬虫、CC 攻击、刷接口、抢购	Bot 管理 + 速率限制 + WAF 规则
数据泄露、内部系统裸奔公网	零信任 Access + Tunnel + 网络过滤
部署上线慢、运维复杂	边缘 Workers + Pages + 一键部署 + IaC
邮件被钓鱼、发送域名被冒用	邮件安全（DMARC / 邮件流 / 反钓鱼）
个人没有钱也想安全上线	免费套餐覆盖 DNS / CDN / HTTPS / 基础 DDoS

1.5 对读者的意义

阅读本文后，你将能够：

知道 Cloudflare 每一大类产品是干什么的、在什么场景用、怎么选；
拿到可直接套用的配置起始点与常见坑；
遇到「源站暴露」「缓存不生效」「发不了信」「非标端口」等典型问题时有清晰的解决思路；
有一个按需跳转的官方文档清单，方便深入。

第 2 章核心价值与全局架构

2.1 一张图理解 Cloudflare 怎样「插进」你的系统

用户 ──► 全球任意 Cloudflare 边缘节点（流量在此被处理）
               │
               ├─ ① 安全层：DDoS 清洗 / WAF / Bot / 速率限制 / TLS 终止
               ├─ ② 加速层：静态缓存 / 动态加速 / Argo / 图片优化
               ├─ ③ 计算层：Workers / Pages Functions / R2 / D1 / KV
               │
               ▼ 仅放行真实请求
            你的源站（真实服务器：Nginx / VPS / 云主机 / SaaS）

关键认知：源站不再直接面向用户，它只信任 Cloudflare 的边缘。 这带来三重收益：

安全收益：源站 IP 不暴露，攻击者无法绕过边缘直击源站；即便被扫到，源站防火墙也只放行 CF 回源段。
性能收益：静态资源在边缘缓存，用户离节点近，回源只有在缓存未命中时才发生；动态请求也有 Argo 优化路径。
可观测收益：所有流量在边缘有统一日志与分析，不必在每台服务器各自埋点，排查问题有 cf-ray 这种全局唯一 ID。

2.2 Anycast 技术

Cloudflare 使用 Anycast 路由：多个数据中心共享同一个 IP 段，通过 BGP 让用户自动连接到「最近」或「路由代价最低」的节点。相比传统「一个 IP 指向一台机器/一个机房」的 Unicast：

就近接入：用户访问自动路由到地理位置与网络距离最近的节点，延迟最优。
天然抗 DDoS：攻击流量被分散到全球任意一个节点，单点容量压力被数百节点摊薄；即使某节点被打垮，BGP 自动收敛，流量转向其他节点，服务整体不中断。
零手工故障切换：节点宕机由路由协议自动处理，无需人工干预，稳定性天然高。

理解 Anycast，就能理解为什么 Cloudflare 说「我们不怕容量型攻击」——因为攻击者的带宽要打爆的不是一个机房，而是被摊薄到全世界几十上百个机房，这在成本上几乎不可能。

2.3 分层产品体系总览

Cloudflare 的产品可以按「链路层 → 应用层 → 平台层」归纳成一张总表，后续章节逐一展开：

层级	产品族	代表产品
连通层	CDN / 加速 / 负载	CDN、Argo Smart Routing、Load Balancing
安全层	防护	DDoS 防护、WAF、Bot 管理、速率限制、Page Shield
网络层	连接	DNS、Magic Transit、Cloudflare Tunnel、WARP、Magic WAN
计算层	边缘开发	Workers、Pages、R2、D1、KV、Durable Objects、Queues、Workers AI
数据/媒体	内容交付	Images、Stream、Snippets、Polish
企业安全	零信任	Access、Gateway（DNS 过滤）、Zero Trust 套件、BSSO
邮箱	邮件安全	Email Routing、DMARC 管理、Area 1 邮件安全
观测	分析日志	Analytics、Logpush、Web Analytics、RUM

2.4 免费与付费的统一底座

Cloudflare 最核心的观念是 Freemium（免费增值）：DNS、基础 CDN、基础 DDoS 防护、Universal SSL、限定量的 Workers、Email Routing、临时 Tunnel 等在免费套餐（Free）下即可使用。这对个人站长与独立开发者极为友好——你可以用接近零的成本获得过去需要购买商业 CDN + WAF 才能获得的一线能力。付费套餐（Pro / Business / Enterprise）逐级解锁更高级的 WAF 规则配额、Bot 管理、Argo、负载均衡与 SLA，详细配比见第 14 章。

2.5 为什么个人开发者也应关注

即便你不是企业，Cloudflare 对个人开发者吸引力也极高：

免费托管静态站（Pages），绑定 GitHub 即可自动构建上线。
免费 DNS + CDN + HTTPS，把自建服务托在 CF 后面，既隐藏源站 IP 又统一入口。
免费边缘函数（Workers 每日免费额度），可做转发、鉴权、定时任务。
免费内网穿透（Cloudflare Tunnel），替代传统端口转发，甚至无需公网 IP。
免费邮件转发（Email Routing），把自定义域名邮件转到任意邮箱，打造形象邮箱。

这些恰好覆盖个人运维者最常用的高频需求——这也是本文要系统整理 Cloudflare 用途的直接动因。

第 3 章 CDN 与全球加速

3.1 CDN 基本原理与 Cloudflare 的实现

CDN（Content Delivery Network，内容分发网络）把内容分发并缓存到离用户最近的节点，减少回源、降低延迟。Cloudflare CDN 的特点：

全站反向代理：默认对整站流量做代理（不只静态资源），/ 下所有路径都经过边缘，因此「隐藏源站 + 统一入口」是默认行为。
智能缓存：基于 HTTP 缓存语义（Cache-Control、Expires、ETag、Last-Modified）与 CF 自身的缓存规则，命中则从边缘返回，未命中才回源。
默认缓存范围：对常见静态扩展名（.js/.css/.png/.jpg/.gif/.webp/.woff2/.otf 等）默认缓存；对 HTML 与动态接口是否缓存取决于套餐、规则与响应缓存头。
缓存清除（Purge）：支持按 URL、按 Cache Tag、按主机名即时清除边缘缓存；企业版还可按前缀清除。清除是全边缘立即生效，但需注意作用域，避免误清。

3.2 缓存层级：浏览器缓存 → 边缘缓存 → 源站

1
2
3

客户端（浏览器缓存，二级）
    └─► Cloudflare 边缘缓存（一级，快速命中）
         └─► 回源（Origin，真实服务器 / 对象存储 / SaaS）

Cache Everything：对任意内容（包括看似动态的 URL）开启全量缓存，需配合 Cache-Control: max-age 或 CF 的 Edge Cache TTL 控制缓存时长。
Cache Key：默认按 URL + 部分响应头区分缓存条目；可通过规则自定义 cache key，以支持 ?v= 版本化、多语言、多设备、促销参数等场景，避免把不同版本混淆成同一条缓存。
绕过缓存：对需要实时性的接口（登录态、购物车、支付回调、验证码）在源站设置 Cache-Control: no-store，或让 CF 按规则跳过——否则会出现「更新了内容但用户看到旧版」的经典问题。

3.3 动态内容加速：Argo Smart Routing

传统 CDN 对静态资源收益明显，但对动态接口（必须实时回源）收益有限。Argo Smart Routing（现已并入 Flow/Orbit 等名称）利用 Cloudflare 全球网络实时监控各条链路质量，选择拥塞最小、跳数最优的回源路径（而非常规 AS 级最优路由），可显著降低动态请求的往返延迟。

适用：API、实时数据、登录鉴权等必须实时回源的动态流量。
收益：在跨国、多跳、跨运营商场景下，回源延迟可减少约 10%–40%。
注意：Argo 是付费增值能力（Pro 套餐起），按流量额外计价；对以国内为主要用户、且源站在海外的场景，结合站点位置评估是否值得。

3.4 图片与媒体交付优化

Cloudflare 在媒体交付上有专门一层的优化能力：

Image Resizing / 参数式处理：在边缘按需裁剪、缩放、转换 WebP/AVIF，支持 ?w=&h=&fit=&quality= 这类 URL 参数，避免客户端加载整张原图再摆缩，显著省流量、提速。
Polish（图片压缩优化）：默认对经过的图片自动转 WebP 与压缩，分「无损」与「有损」档；对以图片为主的站点可明显减小体积。
Stream（视频平台）：专业视频上传、转码、托管与播放的一体化服务，支持 HLS 自适应码率、缩略图、剪辑、字幕与 DRM（付费档），并有按域名白名单的防盗链与播放分析。
Snippets（边缘改写）：用轻量 C++/Rust 模板在边缘改写响应（注入脚本、改 Header、加安全横幅），适用于不愿写完整 Worker 的「小手术」。

3.5 调试缓存：关注响应头

日常排查缓存是否生效，关键在于几个响应头：

cf-cache-status: HIT —— 命中边缘缓存，未回源。
cf-cache-status: MISS —— 未命中，已回源（第一次或刚被清除）。
cf-cache-status: EXPIRED —— 缓存过期，重新回源。
cf-cache-status: DYNAMIC —— 明确为动态内容，不缓存。
cf-ray: <ID> —— 本次请求在全网的唯一标识，报障或深挖链路时带上它，可精确定位请求经过的节点与版本。

3.6 实战：自建服务接入 Cloudflare 的正确姿势

结合个人运维的常见场景（很多人的自建服务因限制公网直连 80/443、或用反代+NPM 再加证书，绕过 CDN 直连暴露），一套稳妥的接入流程如下：

在 CF 控制台「添加站点」输入域名，抄录 CF 提供的两条 NS，到域名注册商处替换为 CF NS（权威 DNS 由 CF 托管）。
配置 DNS 记录：先全部用 DNS only（灰云）验证源站访问正常，再把需要保护的记录切换为 Proxied（橙云），开始加速与保护。
配置源站 SSL：选择 Full 或 Full（严格）——保证「CF → 源站」之间也是 HTTPS。源站证书可用 CF 自签的 Origin CA，或 Let’s Encrypt。
源站安全加固：让真实服务器只放行 Cloudflare 的回源 IP 段访问 80/443；更严格可在 CF 开启 Authenticated Origin Pulls（源站只接受由 CF 签发的证书建立的 TLS）。
若你的服务是「反代 + 端口映射，NPM 只监听非标端口、本机 Nginx 不监听 80/443」，务必理解：CF 回源走 80/443 标准端口。要么让源站监听 443，要么干脆改用 Cloudflare Tunnel（见第 10 章）从「出站隧道」打通，无需担心端口与证书问题。

（记忆中的实际约束：在部分自建环境下，内置 Nginx 不监听 80、通过反向代理加证书后才能访问，这类拓扑直接把 CF 与「80/443 回源 + NPM」强行组合会踩很多坑，此时优先考虑 Tunnel 反而是更干净的正解。）

第 4 章智能 DNS 托管

4.1 Cloudflare DNS 是什么

Cloudflare 提供权威 DNS（Authoritative DNS）托管：把域名的 NS 记录指向 Cloudflare，解析全部由它处理；同时用 Proxied（橙云）标记让流量再经过其代理。它不只是「快」，还附带一整层管理与安全能力：

超高可用：Anycast + 与根服务器/大型 ISP 的直连，解析命中率与延迟全球领先（通常 <10ms）。
DNSSEC 一键启用：为解析响应做数字签名，防伪造与缓存污染。
CNAME Flattening：允许在根域名使用 CNAME（一般 DNS 根域不能 CNAME），方便把根域指向 CDN / SaaS / 第三方页面。
负载均衡（Load Balancing）：把解析指向多个后端，按地域 / 权重 / 健康检查做全局负载与故障切换。
管理友好：全 API 化、Terraform 支持、一键导入 Zone、批量编辑，特别适合「代码化管理 DNS」。

4.2 记录类型详解

A / AAAA：IPv4 / IPv6 地址。
CNAME：别名（指向域名）。根域 CNAME 因 Flattening 而可用。
TXT：常用于 SPF、DKIM、DMARC、域名归属验证。
MX：邮件交换记录（与第 9 章 Email Routing 联动使用）。
SRV / CAA / NAPTR / DS：服务发现、证书签发授权、拨号导向、DNSSEC 委派签名等高级用途。
Proxied vs DNS only 的区别要牢记：橙云（Proxied）= 经过 CF 边缘，获得 CDN / WAF / 隐藏源站；灰云（DNS only）= 纯解析，直达源站——灰云记录不收保护，但也不受 CF 缓存影响（高频 API 常用灰云以防缓存污染）。

4.3 解析速度优化

智能就近：Anycast 保证用户解析到最近的节点。
无需逐级缓存失效：任一节点都能独立、正确地响应，全球一致。
TTL 设定建议：常规记录 120–300 秒；需要快速切换时可低至 60 秒；几乎不变的记录可设 3600 秒以减少查询、降低负载。

4.4 DNS 安全

DNSSEC：防篡改解析结果。开启后要把生成的 DS 记录同步到域名注册商；切换 NS 时若顺序错误可能造成瞬时 SERVFAIL，这是新手最常翻车的点——务必在变更窗口谨慎操作。
DDoS 防护：针对权威 DNS 的攻击由 Anycast 消化，普通站点几乎感知不到。
CNAME Round Robin / 加权：同一条记录多个目标，可做简单分流或故障兜底。

4.5 实战：域名邮箱与 DNS 联动

Cloudflare 的 Email Routing（免费）允许你：

在 DNS 中添加 MX 记录指向 route...cloudflare.com。
配置转发规则：contact@你的域名 → 任意真实邮箱。
支持逐地址转发与 catch-all 通配转发。

这样无需自建邮箱服务器就能拥有「能收信」的功能性域名邮箱。配合自建发信栈（Postfix/Dovecot/OpenDKIM）或第三方 SMTP 做发信，即形成「能收能发」的混合方案——恰好对应很多人「域名 + 邮箱要能收又要能发」的现实需求。

（记忆要点：Cloudflare Email Routing 只管入站收信，出站发信需另配 SMTP；纯 CF 免费无法发信。若追求发信投递成功率，还需正确配置 SPF/DKIM/DMARC。）

第 5 章网络安全体系（DDoS / WAF / Bot / 速率限制）

这是 Cloudflare 使用最重的领域，也是「为什么要套 CF」的核心理由。本章详细展开。

5.1 DDoS 防护（边缘清洗）

容量型 DDoS（带宽耗尽）：UDP flood、DNS amplification、SYN flood 等。靠 Anycast + 全网清洗消化——攻击被打散到全球数百节点，容量几乎用不完。
应用层 HTTP flood（俗称 CC）：Bot 用大量合法格式的 HTTP 请求打挂应用。靠速率限制 + Bot 管理 + WAF 规则自动识别「高频 / 低 JS 指纹 / 无来源规律」的行为。
传输层（L3/L4）防护：在网络层默认就对 IP / 端口 / TCP 做清洗，无需用户额外配置。
自治（Autonomous）防护：默认 DDoS 防护是「按需自动」的，异常流量达到阈值即触发；企业版可自定义指纹、清洗策略与响应动作。
给源站的配套铁律：因为攻击流量到边缘就被过滤，回源到源站的是「过滤后的干净流量」。但源站必须只放行 Cloudflare 回源 IP 段（官方提供 IP 列表，也可通过 api.cloudflare.com/client/v4/ips 程序化获取），否则攻击者可绕过边缘直达源站——即「源站裸奔」，CDN 白套。

5.2 Web 应用防火墙（WAF）

WAF 在边缘拦截恶意 Web 流量，基于规则库 + 托管规则集 + 自定义规则。

5.2.1 托管规则集（Managed Ruleset）

Cloudflare Managed Ruleset：开箱的通用安全规则，覆盖 OWASP 常见攻击向量（SQL 注入、XSS、命令注入、目录穿越、本地文件包含等），默认开启即获得基础防线。
OWASP CRS（Core Rule Set）：基于知名开源规则集的调制版，可在「攻击拦截」与「误伤率」之间调平衡；对中文站点常需微调豁免合法请求（避免把正常带中文参数的表单误伤）。
Sensitive Data Detection（企业版）：识别并保护泄露的身份证号、银行卡号等敏感数据。

5.2.2 自定义规则

基于以下字段做精细化处理（Block / Challenge / Skip / Log）：

IP / 国家 / 自治域 ASN / 数据中心；
URI 路径、Host、查询串；
User-Agent、Referer、Header、Cookie；
请求方法、协议、TLS 版本；
速率（每 5 分钟 / 每 10 秒的请求数）、Bot Score、设备类型、浏览器等。

5.2.3 WAF 动作（Actions）

Block：直接拒绝。
Managed Challenge：当威胁等级中等时发起「智能验证」，多数正常用户因行为与指纹可信而无感通过。
JS Challenge：要求执行一段 JavaScript 证明是真人浏览器。
Interactive Challenge：要求用户完成交互式验证（如点选）。
Skip / Log / 放行：用于白名单与审计。

（注意：不少自建个人站为了「降低误伤 + 提升体验」，会关闭或移除验证码类 challenge，只保留基于 IP / UA / 规则的硬拦截。这种取舍可行，但要接受失去一部分「人机校验」能力，需在体验与安全间自行权衡——这也是很多站点明明威胁分数不低却全程无验证的原因。）

5.2.4 WAF 的自动化建议

Cloudflare 会根据你的站点近期被攻击的模式，生成「建议添加的规则」，可一键应用。对没有专职安全人员的小团队，这能显著降低配置门槛。

5.3 速率限制（Rate Limiting）

经典速率限制（Free / Pro 基础）：基于 IP × URI 的计数，五分钟窗口，超限即触发动作。
进阶速率限制（更细粒度）：可按任意特征（IP、ASN、设备、路径、Header）+ 滑动窗口（10 秒 / 60 秒 / 5 分钟 / 60 分钟 / 24 小时）统计，支持 Burst 与平滑，动作可以是 Block / Challenge / 限速降速。
典型用途：防接口刷量、防暴力破解登录、防短信轰炸、防爬虫高频抓取、防 CC。
关键权衡：阈值设太低会误伤正常用户（尤其 NAT 后多个真实用户共享同一个 IP），需要设置合理的惩罚期、白名单，并对「登录/验证码」这类本应低频的端点单独设更低阈值。

5.4 Bot 管理（Bot Management）

Bot Score（0–99）：0 表示几乎确定是 Bot，99 表示几乎确定是真人；基于机器学习与行为指纹。
分类：Verified Bot（搜索引擎、监测器）、Known Good Bot、Blocked Bot、自然流量。
动作：对低分请求做 JS Challenge / Block / 限速 / 隔离 / 降低优先级。
用途：反爬、反 CC、防抢购脚本、防数据抓取、保护登录与支付。
注意：Bot Management 是 Enterprise 级昂贵能力；Free/Pro/Business 只能用较粗粒度的 Bot Fight Mode / Super Bot Fight Mode，可挡常见爬虫，但可能误伤部分工具。

5.5 其他安全增强

Page Shield：审计页面加载的前端脚本，检测充值脚本 / 恶意第三方 / 供应链前端攻击。
SSL/TLS 终止：免费提供边缘 TLS 证书，自动续期；支持多种「CF 到源站」的模式。
Universal SSL：默认给新接入域名签一张根域+通配证书。
Authenticated Origin Pulls：源站只接受由 Cloudflare 签名证书建立的 TLS 连接，传输层杜绝「绕过 CDN 直连源站」。
Prefetch：边缘对页面将要用到的资源做提前预取，提升首屏。
安全分级：按威胁分数决定是否对观光流量发起额外挑战。

5.6 个人站安全配置推荐起点

一套「够用」的 CF 安全基线（不追求把所有人都挡在外面，重点是挡住自动化攻击）：

源站防火墙只放行 CF 回源 IP 段访问 80/443。
开启 Universal SSL + 选择 Full（strict）模式。
开启 Cloudflare Managed Ruleset，把已知攻击挡在边缘。
给登录接口、验证码接口配速率限制（例如 5 分钟 50 次/IP 量级），兼顾体验。
若不想给人机校验，就把 Managed Challenge 动作改为仅对「高威胁分数 + 明确恶意 UA/IP」才触发。
定期看 Analytics 中 Security 标签的 Top 攻击来源，针对性加规则或封禁。

第 6 章零信任安全（Zero Trust）

Cloudflare 的零信任产品旨在解决「员工或设备如何安全访问公司内部应用」与「如何安全上网」两大问题，核心思想是永不信任、始终验证。

6.1 Cloudflare Access（应用访问控制）

替代传统 VPN：传统 VPN 需要把整个内部网络暴露给已认证设备，攻击面大。Access 把内部应用通过 CF 暴露，并在边缘做身份认证（集成 Google / Microsoft / Okta / GitHub / OpenID Connect 等 IdP）+ 细粒度策略。
策略示例：
- 只有公司域邮箱且所在国家符合条件的用户能访问管理后台。
- 只有安装了公司证书 / WARP 的设备能访问某些 API。
- 按会话时长、设备合规度（posture）做二次判断。
优势：源站无需公网 IP、认证在边缘、日志可审计、免 VPN 运维、兼容统一 SSO。
BSSO / IdP：用户用统一的单点登录即可进入，体验与内部系统一致。

6.2 Cloudflare Gateway（安全 Web 网关 / DNS 过滤）

在边缘对员工的 DNS 解析做过滤：拦截恶意域名、钓鱼、勒索软件 C2、成人内容（按策略分组）。
基于身份的访问控制：不同员工组策略不同。
DLP（数据防泄漏）：检测并拦截敏感数据外传（源代码、身份证号、卡号）。
远程浏览器隔离（RBI）：高风险网页在 CF 隔离的浏览器中渲染，只把安全结果传给用户，防止本地设备被攻击（企业版）。

6.3 Cloudflare Tunnel（内网穿透 / 出站连接）

值得单独强调的出站连接方案——

在服务器上运行 cloudflared 守护进程，主动向外与 CF 边缘建立加密隧道。
结果：服务器不需要公网入站端口，也不需要暴露 IP，公网通过隧道域名（*.trycloudflare.com 临时或自定义域名）访问。
典型用途：
- 内网 / 无公网 IP 的服务暴露到公网（配合自定义域名）。
- 把非标端口（如 9090、8888）映射为 80/443 出口，绕过对非标端口的限制。
- 保护源站（源站无入站，攻击者无从打）。
免费：免费套餐对个人并发足够。
Quick Tunnel（临时）：一条命令生成临时公网 URL 无需绑定域名，适合快速验证回调 / 演示。

6.4 WARP（Cloudflare WARP）

基础 WARP：把个人设备到网络的流量加密到 CF。
WARP + Zero Trust：作为企业零信任的设备 posture 来源（是否安装、是否合规）。
用途：改善连接质量、隐私保护、零信任基线。
注意：部分网络环境下 WARP 可能不可达，部署需评估实际可访问性。

6.5 零信任架构图

员工设备（WARP + 浏览器 / 客户端）
    │ 加密隧道
    ▼
Cloudflare 边缘（Access 认证 + Gateway 过滤 + Tunnel 会话策略）
    ▼ 只有通过策略的流量
源站 / 内部应用（可能在内网、无公网 IP）

6.6 常见误区

Tunnel ≠ VPN：Tunnel 是「源到边缘的出站隧道」，不是客户端 VPN；员工到公司用的是 WARP + Access。
Access 必须接 IdP：认证必须有身份提供方（邮箱密码 / SSO / OTP），否则无法做「人」的校验。
免费与付费：Zero Trust 对最多 50 个用户免费，超过需订阅；免费档包含一定的 Access / Gateway 配额。

第 7 章边缘计算平台（Workers / Pages / R2 / D1）

Cloudflare 不止是 CDN，更是一个全球无服务器边缘计算平台。这是近些年在开发者中最火的能力。

7.1 Cloudflare Workers（边缘函数）

核心概念：Workers 是部署在边缘节点上的 JavaScript / WASM 函数，一个 Worker 即一个「接收 HTTP 请求、返回响应」的无状态服务，在用户最近节点执行，天然低延迟。

运行时：基于 V8，使用标准 Fetch / Request / Response API。可用 JS/TS，也支持 Rust/WASM，部分支持 Python。
部署：workers.dev 子域即时上线，或绑定自定义域名。
触发方式：HTTP 请求、scheduled（Cron 定时）、队列消费者、R2 事件、Email 事件等。
典型用途：
- API 网关、鉴权、路由分流、请求改写。
- 在边缘聚合多个后端 API。
- 网站 A/B 测试、灰度发布、缓存策略。
- 轻业务逻辑、转发、数据清洗。
- Cron 定时任务（无服务器边缘 cron）。
免费额度：每天一定请求数与 CPU 时间，个人够用；超限按量计费。
生态：wrangler CLI 本地开发与部署、--dev 本地预览、tail 实时日志。

7.1.1 Worker 最小示例

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname === "/api/health") {
      return new Response("ok", { status: 200 });
    }
    const apiKey = request.headers.get("x-api-key");
    if (!apiKey) return new Response("unauthorized", { status: 401 });
    return new Response("Hello from the edge!", {
      headers: { "content-type": "text/plain" },
    });
  },
  async scheduled(event, env, ctx) {
    // 定时任务：每日推送 / 监控 / 汇总
    await fetch("https://example.com/cron-target", { method: "POST" });
  },
};

7.1.2 Workers 与 Cron 定时任务的高频用法

很多「每日推送 / 定时监控 / 汇总报告」脚本（日报、价格监控、健康检查、行情推送）都可以用 Workers 的 scheduled() 触发器做成边缘 Cron，免运维服务器上的 cron：

export default {
  async scheduled(controller, env, ctx) {
    ctx.waitUntil(doDailyJob());
  },
};

在控制台创建 Cron Trigger（如 0 9 * * * 表示每天 9 点 UTC），一个定时任务就在边缘完成——这正是个人运维者替代「VPS 上 cron + 常驻脚本」的高性价比方案。

7.2 Cloudflare Pages（静态站 + Functions）

JAMstack 托管：免费部署静态网站，来自 Git 仓库自动构建。
兼容主流框架：Next.js、Astro、Hugo、React/Vue/Svelte 静态导出等。
Pages Functions：给静态站提供动态后端（API / BFF），与 Workers 互为表里。
为什么个人爱用：绑定 GitHub、Push 即自动部署、自带 CDN + HTTPS + 免费 *.pages.dev 域名，零成本上线个人站 / 文档站 / 落地页 / 工具页。

7.3 边缘存储家族

Cloudflare 提供了完整的边缘存储家族，让开发者可以「全栈部署在边缘」而不必自建数据库服务器：

存储	类型	用途
KV（Workers KV）	全局键值（最终一致）	配置、会话、简单缓存、计数，适合低频写高频读
R2（对象存储）	S3 兼容对象存储	文件、备份、静态资源、图片视频源；出口流量免费
D1	SQLite 兼容关系数据库	小型关系数据、站点数据、轻应用后端
Durable Objects	有状态单实例对象	WebSocket 房间、协作、游戏状态、强一致单例
Queues	消息队列	异步任务、批量处理、解耦 Worker 间通信
Hyperdrive	数据库连接池加速	加速访问已有 Postgres / MySQL

7.4 Worker 生态的边界与适用判断

适合：请求量可预期、逻辑轻量、需要边缘极低延迟、无状态或简单状态、Cron 触发、表单处理。
不适合：长连接重计算、需要大量本地 CPU 密集、运行复杂 Python 依赖（受限）、绑定某机房的本地资源（写本地磁盘）。
与自建 VPS 的关系：很多人的策略是「简单 / 对外 / 轻量的事情用 Worker/Pages 边缘化；重逻辑 / 长连接 / 完整运行时留在 VPS」。二者互补而非替代。

7.5 参考文档

Workers：https://developers.cloudflare.com/workers/
Pages：https://developers.cloudflare.com/pages/
R2：https://developers.cloudflare.com/r2/
KV：https://developers.cloudflare.com/kv/
D1：https://developers.cloudflare.com/d1/
Durable Objects：https://developers.cloudflare.com/durable-objects/
Queues：https://developers.cloudflare.com/queues/

第 8 章图像与视频交付

8.1 Cloudflare Images

面向：需要图片托管、缩放、优化的站点与应用。
能力：上传处理、按需变体（尺寸 / 格式 / 质量）、URL 签名（防盗链）、边缘交付。
用法示例：https://<你的站点>/cdn-cgi/image/width=400,quality=80/https://原始图片URL 可在边缘按参数处理任意外部图片。
价值：减轻源站图片处理负担、控制流量、提升加载速度。

8.2 Cloudflare Stream

面向：视频上传、转码、托管、播放。
能力：自适应码率（HLS / MPEG-DASH）、缩略图、剪辑、字幕、DRM（付费档）、按域名白名单防盗链、播放分析。
价值：替代自建「ffmpeg 转码 + 存储 + 加载 + 播放器」的整套成本，特别适合内容平台。

8.3 Polish 与优化

Polish 可自动把图片转 WebP 并压缩（无损 / 有损档）。
可选更激进档以进一步省流量，但需评估画质损失。
与 Image Resizing 配合时注意叠加顺序与格式转换，避免双重压缩。

8.4 媒体方案取舍小结

简单图片：直接用 Polish + Image Resizing 即可，无需迁移存储。
成规模的图片管理：上 Cloudflare Images。
视频：几乎可以无脑用 Cloudflare Stream，成本远低于自建转码机群。

第 9 章邮件与通信保护

9.1 Email Routing（邮件转发 / 入站）

免费；把自定义域名邮箱转发到真实邮箱。
DNS 配置：MX 指向 Cloudflare，再建路由规则。
用途：打造「.你的域名」的形象邮箱而无需自建邮箱服务器，适合个人与团队。国内常与「域名 + 邮箱」的现实需求结合。

9.2 邮件安全（Area 1 / Email Security）

进站威胁检测：钓鱼、垃圾、商业邮件欺诈（BEC）、恶意附件 / 链接。
与企业邮箱（O365、Gmail）集成，作为网关或 API 前置过滤。
出站保护：DMARC 聚合报告（免费有基础 DMARC 报告，企业版增强）。

9.3 邮件基础设施中 CF 的角色（关键强调）

Cloudflare Email Routing 只处理「入站」（收信）。如果你需要出站发送（发信），Cloudflare 不提供免费 SMTP 发信服务。常见做法：

入站：CF Email Routing（免费）收信。
出站：自建 Postfix / Dovecot / OpenDKIM 发信，或第三方 SMTP（SendGrid / Mailgun 等）。
于是形成「能收能发」的混合方案——恰好对应很多人「自建邮箱能收不能发 / 自带域名要能发信」的实际需求。
邮件投递性（Deliverability）：自建发信必须配置 SPF / DKIM / DMARC，否则易进垃圾箱；Cloudflare 在 DNS 层帮你管理这些 TXT 记录，减少漏配。

9.4 参考文档

Email Routing：https://developers.cloudflare.com/email-routing/
Email Security：https://developers.cloudflare.com/email-security/

第 10 章网络与连接（Tunnel / WARP / Magic Transit / Load Balancing）

10.1 Cloudflare Tunnel（完整形态）

守护进程 cloudflared 从服务器出站建立到边缘的加密隧道（HTTP/2 / QUIC）。
优点：无需开放入站端口、隐藏源 IP、公网只能用你定义的域名访问、天然防直接攻击。
认证方式：隧道 token 或证书；临时隧道免登录用 *.trycloudflare.com。
与反向代理（NPM）的配合：若服务已是反代 + 端口映射（如 NPM 只监听 81、证书在 CF 层终结），用 Tunnel 直接把内网端口暴露即可，省去「公网 IP + 证书 + 端口」的痛苦；Tunnel 也支持按域名 / 路径把多个本地服务分发出去。
免费额度：免费套餐允许任意数量的隧道共享免费配额（并发有一定限制，个人服务足够）。

10.1.1 Tunnel 快速上手

# 安装
brew install cloudflared   # macOS
apt install cloudflared    # 部分发行版可直接安装
# 登录并创建
cloudflared tunnel login
cloudflared tunnel create my-tunnel
# 配置并路由 DNS
cloudflared tunnel route dns my-tunnel tunnel.example.com
# 运行
cloudflared tunnel run my-tunnel
# 临时隧道（免登录）
cloudflared tunnel --url http://localhost:8080

10.2 WARP

客户端传输层封装：把设备流量加密到 Cloudflare。
个人版：改善连接质量、隐私保护。
企业版（WARP + Zero Trust）：作为零信任的 device posture 来源。
注意部分网络环境下 WARP 可能受限，部署需评估实际可访问性。

10.3 Magic Transit / Magic WAN（企业级）

Magic Transit：把整个 IP 段 / 机房流量接入 Cloudflare 清洗后回源（不只是域名，而是网段），常用于被大规模 DDoS 攻击的企业 / 机房 / 游戏厂商。
Magic WAN / Magic Firewall：在 CF 网络上做分支机构组网（SD-WAN）与网络层防火墙策略。
一般个人用不上，但在企业网络架构里地位重要。

10.4 Load Balancing（负载均衡 / GSLB）

把同一域名解析到多个后端 / 机房，按健康检查 + 权重 / 地域做分发。
智能健康检查（HTTP / TCP / HTTPS）自动剔除故障后端。
应用场景：多机高可用、多地容灾、API 网关集群入口。

10.5 域名与网络层的一个实际提醒

如果你有「源站不监听 80/443、需要反代 + 证书 + 特定端口」这类拓扑，最干净的做法是：

首选 Cloudflare Tunnel，让 CF 终止公网入口，源站保持私网。
若坚持正规 CDN 反代，则必须让源站监听 80/443（或 8443 等 443 派生）并完成证书。
不要在「CDN 强制 80/443 回源」的前提下要求 CF 帮你访问非标端口——这不符 CDN 机制。

第 11 章开发与部署工具

11.1 Wrangler（Workers CLI）

npm i -g wrangler
常用命令：wrangler login、wrangler init、wrangler dev、wrangler deploy、wrangler tail（实时日志）、wrangler kv、wrangler d1、wrangler pages deploy。
支持本地构建与远程部署，是 Workers / Pages 开发的默认工具。

11.2 CICD 与版本控制

Pages 直接绑定 GitHub / GitLab 仓库自动构建部署。
Workers 可用 GitHub Actions 自动部署。
配合 wrangler 的 --env 可区分不同环境。

11.3 新一代 Cloudflare CLI

新一代 cloudflare 命令行（Go 实现）整合 DNS / Workers / Pages / Tunnel / Terraform 等，逐渐取代零散命令，管理离散资源更统一。

11.4 Terraform 与 IaC

Cloudflare 官方 Terraform Provider：可用代码管理 DNS 记录、规则、Worker 绑定等，适合需要「可重复、可审计」配置的企业与进阶开发者。

11.5 API 与 SDK

REST API：管理 DNS / WAF / Workers 等所有资源。
workers-sdk：Node 访问 Workers / Pages API。
Token 管理：推荐使用作用域受限的 API Token 而非全局 API Key（安全最佳实践，泄露影响面小）。

11.6 本地开发与调试

wrangler dev --local 本地运行。
wrangler dev --remote 使用真实边缘资源。
用 curl -v 查看 cf-ray 确认请求是否经过边缘。
wrangler tail 实时看日志，排查线上问题。

第 12 章可观测性与分析

12.1 内建 Analytics

Web Analytics / RUM：无需 JS 埋点也能取到访客 / 性能数据（免费、隐私友好，无需 cookie 同意横幅）。
Traffic Analytics：按请求数 / 带宽 / 攻击 / 缓存命中展示 Overview。
Security Analytics：被 WAF / Bot / 限速拦截的流量可视化，TOP 攻击来源。
Performance Analytics：缓存命中率、TTFB 拆解、延迟分布。

12.2 Logpush

将边缘请求日志实时推送到 R2 / S3 / Splunk / Datadog / 自建 HTTP 端点等。
支持按规则 / 字段过滤，降低存储成本。
免费套餐有一定 Logpush 额度，企业级更完整。

12.3 Workers Observability

wrangler tail 实时查看 Worker 日志。
Workers Logs、Traces、Metrics（企业版）。
ctx.waitUntil() 控制后台任务。

12.4 面向自建调度 / 报告的联动

很多个人把「CF 分析 + 自建 cron 脚本 + 推送」组合起来，实现：每天从 CF 拉取流量 / 攻击统计 → 生成日报 → 推送到 Telegram / 邮件。这也印证 Cloudflare 的 API 化能力——一切都是可编程、可调度的。

第 13 章行业与场景方案

13.1 个人站长 / 独立开发者

免费 DNS + CDN + HTTPS + DDoS + 基础 WAF。
Pages 免费托管个人网站 / 文档站。
Worker + Cron 做定时任务（日报、监控、推送）。
Tunnel 把 VPS 服务安全暴露到公网。
Email Routing 给域名邮箱收信。
典型组合：Cloudflare Tunnel + NPM（反代）+ 自建服务，公网入口由 CF 统一管理，源站安全、域名统一。

13.2 电商 / 企业官网

WAF + Bot 防抢购 + 速率限制防刷接口。
Images 图片压缩秒开。
Load Balancing 做可用性。
Argo 加速动态接口。

13.3 SaaS / API 平台

Workers 做网关 / 鉴权 / 限流。
R2 做对象存储，零出口费。
Zero Trust Access 保护管理后台。
Rate Limiting 保护开放 API。

13.4 金融 / 高合规行业

WAF + DLP + 数据防泄漏。
Magic Transit 扛超大 DDoS。
审计日志 + Logpush 留存。
DMARC / 邮件 BEC 防护。

13.5 游戏 / 泛娱乐

Magic Transit 防打。
Load Balancing 多区容灾。
Stream 视频流。
Bot 防脚本外挂。

13.6 部署与迁移注意（针对正在用 CF 的用户）

如果你已经在用 CF 反代个人服务，迁移 / 加固时注意：

不要改灰云而期望还有 CDN 保护——灰云纯解析，直接暴露源站。
源站防火墙只放行 CF 回源 IP 段——否则攻击者可绕过。
切换套餐 / 规则后等 1–5 分钟生效，用 curl -I 看响应头确认。
改动前备份 DNS 导出，回滚时快。

第 14 章成本模型与套餐选型

14.1 套餐一览

套餐	价位（约）	核心能力	适合
Free	$0	DNS、CDN、基础 DDoS、托管 WAF 规则、Universal SSL、Pages、有限 Workers、Email Routing、基础速率限制	个人站、试验、学习
Pro	约 $20/月	增强 WAF（更高配额）、Polish 图片优化、Argo、更多 Worker、页面规则更灵活	个人商业站、要求更高的个人
Business	约 $200/月	更多 WAF / Bot 控制、健康检查、SLA	成长型企业
Enterprise	定制	全功能：Bot Management、高级 DLP、专属支持、SLA、Magic Transit、定制	大企业、金融、游戏

14.2 按需计费 / 增值项

Argo Smart Routing：按带宽额外计价。
负载均衡：按原站数量 / 规则数 + 流量计价。
Workers：超过免费配额后按请求数 + CPU 时间计费（价格已变便宜）。
R2：按存储 + 操作计费，出口流量免费。
Images / Stream：按存储 / 流量计费。
Tunnel：免费（基于配额，支持付费增强）。

14.3 个人最划算的组合（性价比观点）

纯静态 / 个人站：Free + Pages + Tunnel + Email Routing，成本 ≈ 0。
有 API / 定时任务：Free Workers 配额或少量付费，比在 VPS 上再加一层成本划算。
推荐按需购买 Pro（尤其需要更强 WAF 速率限制上限与图片优化时）。

14.4 常见「省钱陷阱」

买了 Pro 却从不使用高级功能 → 浪费。
只想隐藏 IP → Tunnel（免费）比 Pro 更直接。
需要批量公网端口映射 → Tunnel 更省事，别为「端口映射」买高级套餐。
Workers 超量烧钱 → 先评估免费额度够不够，不够再买按量。

第 15 章最佳实践与常见误区

15.1 最佳实践清单

保持橙云（Proxied）为主域名，灰云仅用于确实要直连的 API。
源站隐藏 + 只信 CF 回源段：防火墙放行 Cloudflare IP ranges（官方 JSON）。
开启 Universal SSL + Full（strict），生产用 Authenticated Origin Pulls。
缓存策略明确：静态用 Cache Everything + 源站 Cache-Control；动态接口标 no-store。
速率限制保护登录 / 验证码接口，阈值留足余量防误伤。
用 Workers 做轻量业务与 Cron，减少 VPS 常驻进程。
定期看 Security Analytics 与 WAF 建议，动态优化。
改动 DNS / 规则先备份，回滚有退路。
API 化运维：用作用域受限的 token，避免全局 key 泄露。
合理使用 Tunnel 替代对源站暴露公网端口。

15.2 常见误区（务必避开）

误区	真相
以为灰云也有 CDN/WAF	灰云 = 纯 DNS，无保护
以为套了 CF 就一定能防所有攻击	WAF 需配置、源站要封段、规则要维护
认为 CF 会缓存所有内容	动态 / 带 Cookie 的接口默认不缓存
把 Worker 当 VPS 用跑长进程	Worker 无状态受限，不适合长连接 / 重 CPU
Tunnel 和 VPN 混为一谈	Tunnel 是源侧出站隧道；员工访问用 WARP + Access
CF Email Routing 能发信	它只管入站；发信需自建 SMTP 或第三方
修改源站为仅 443 且要求 CF 回访非标端口	CDN 回源用标准端口；非标用 Tunnel
以为 TTL 越长越好	需要快速切换时短 TTL 更灵活

15.3 调试速查

curl -sI https://你的域名 看 cf-cache-status / server: cloudflare / cf-ray。
nslookup 域名 看是否解析到 Cloudflare Anycast IP（104.16.x.x 等）。
curl -H "CF-Access-Client-Id:..." 测试 Access。
wrangler tail 看 Worker 实时日志。

第 16 章关键概念速查表

概念	含义
边缘（Edge）	全球各地的 CF 节点，位于用户与源站之间
Anycast	多节点共享 IP，用户路由到最近节点
Proxied（橙云）	流量经 CF 边缘，获得 CDN / WAF / 隐藏源站
DNS only（灰云）	纯解析，直接到源站
回源（Origin）	CF 边缘到真实服务器的请求
cf-cache-status	缓存状态（HIT / MISS / EXPIRED / DYNAMIC）
cf-ray	一次请求的全局唯一 ID，用于排查
WAF	边缘的 Web 应用防火墙
Bot Score	0（机器人）~99（真人）的信用分
Managed Challenge	智能验证，正常用户通常无感
CC / HTTP Flood	应用层频繁请求攻击
Tunnel	源侧出站加密隧道，暴露内网服务到公网
WARP	设备到 CF 的加密客户端连接
Zero Trust	永不信任，始终验证
Workers	边缘无服务器函数
KV / R2 / D1	键值 / 对象 / 关系数据库（边缘存储）
Durable Objects	有状态单实例对象
Logpush	边缘日志推送
Argo	智能回源路径优化
SSL/TLS 模式	边缘与源站之间证书校验力度

第 17 章官方文档索引

（均为 Cloudflare 官方开发者文档，按需跳转。）

开发者文档总入口：https://developers.cloudflare.com/
DNS 托管：https://developers.cloudflare.com/dns/
CDN / 缓存：https://developers.cloudflare.com/cache/
WAF：https://developers.cloudflare.com/waf/
DDoS 防护：https://developers.cloudflare.com/ddos-protection/
Bot 管理：https://developers.cloudflare.com/bots/
速率限制：https://developers.cloudflare.com/waf/rate-limiting-rules/
SSL/TLS：https://developers.cloudflare.com/ssl/
负载均衡：https://developers.cloudflare.com/load-balancing/
Cloudflare Tunnel：https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
零信任（Access / Gateway）：https://developers.cloudflare.com/cloudflare-one/
WARP：https://developers.cloudflare.com/warp-client/
Workers：https://developers.cloudflare.com/workers/
Pages：https://developers.cloudflare.com/pages/
KV / R2 / D1 / Durable Objects / Queues / Hyperdrive：相应路径 https://developers.cloudflare.com/<product>/
Images / Stream：https://developers.cloudflare.com/images/、/stream/
Email Routing / Email Security：https://developers.cloudflare.com/email-routing/、/email-security/
Analytics / Logs / Web Analytics / RUM：https://developers.cloudflare.com/analytics/、/logs/ 等
API 参考：https://developers.cloudflare.com/api/
Terraform Provider：https://developers.cloudflare.com/terraform/
Cloudflare IP 段：https://developers.cloudflare.com/cloudflare-ip-list 与 https://api.cloudflare.com/client/v4/ips
套餐与价格：https://www.cloudflare.com/plans/、https://www.cloudflare.com/pricing/
Cloudflare 博客（深度解析）：https://blog.cloudflare.com/
Learn Center：https://www.cloudflare.com/learning/

第 18 章深度专题：常见故障排查与 FAQ

18.1 缓存不生效 / 更新了看不到新内容

现象：改动了页面 / 脚本，但用户看到的还是旧内容。

原因与解法：

浏览器缓存：先 Ctrl+Shift+R 强刷，或加版本号参数（?v=2）改变 cache key。
CF 边缘缓存：确认 cf-cache-status 是 HIT 且过期时间太长 → 手动 Purge 或缩短 Edge Cache TTL。
源站 Cache-Control 太长：给动态内容加 Cache-Control: no-store，给静态内容加合适的 max-age。
使用了 Query String 版本化但 cache key 未区分：自定义 cache key 包含 ?v=。
多语言 / 多设备内容混用一条缓存：自定义 cache key 加入语言 / 设备头。

排查：curl -sI 页面URL | grep -i cf-cache，先看回来的是 HIT 还是 MISS。

18.2 源站被直接攻击 / 被爬虫扫描

现象：即使套了 CF，日志里仍出现大量直接打到源站 IP 的请求。

原因与解法：

域名为灰云（DNS only）或某条记录没点橙云 → 切橙云。
源站防火墙未限制只放行 CF 回源段 → 在防火墙放行 https://www.cloudflare.com/ips-v4 与 ips-v6 列表内的 IP 访问 80/443，其余一律 Drop。
更严格：开启 Authenticated Origin Pulls，让源站只接受 CF 签名的 TLS。
历史 IP 泄露：如果源站 IP 曾暴露并被公开工具收录，需更换源站 IP 或直接用 Tunnel（源站无入站，无从打）。

18.3 非标端口 / 反代 + 证书拓扑连不上

现象：服务在 9090 / 8080 等端口，套 CF 后访问 443 无响应或 521/522。

原因与解法：

理解：CF 回源只走标准 80/443（可配置回源端口为 8443 等 443 派生，但不能任意端口）。
若必须非标端口 → 用 Cloudflare Tunnel，把 localhost:9090 直接映射到域名，无需担心回源端口与证书。
若坚持反代 + CF：让反向代理统一监听 443 并完成证书，CF 开 Full（strict）。

18.4 发不了信 / 邮件进垃圾箱

现象：自建邮箱只能收不能发，或发出进垃圾箱。

解法：

出站需自建 SMTP 或第三方 SMTP；CF Email Routing 不收发信。
配置 SPF / DKIM / DMARC 三条 TXT 记录（在 CF DNS 里维护）。
出站 IP 信誉：自建 VPS 的 IP 可能信誉低，导致易被拒收；必要时用有偿 SMTP 或专用邮件主机。
反向 DNS（PTR）：部分邮件服务器要求出站 IP 有 PTR。

18.5 Worker 部署后不生效 / 404

解法：

wrangler tail 看是否有异常报错。
确认路由已正确绑定到域名（*.workers.dev 或自定义域名 + route）。
Worker 的 handler 是否正确导出 fetch。
本地 wrangler dev --local 先行复现。

18.6 DDoS / CC 被打但仍卡

解法：

确认边缘已触发清洗（Security Analytics 有记录）。
若仍是应用层攻击导致源站被打 → 开启速率限制 + WAF 托管规则 + 封禁攻击 UA/路径。
若源站是单机且弱，考虑用 CF Cache Everything 把静态全缓存，减少回源压力。
必要时用 Tunnel 隐藏源站，从根上消除「打你源站 IP」这条路。

18.7 切换 NS 后网站打不开

解法：

NS 生效需要时间（注册商 + 全球 DNS 传播），正常 24–48 小时内。
检查注册商处 NS 是否写对。
若开启了 DNSSEC，确认 DS 记录已同步到注册商，否则会 SERVFAIL。
用 dig +trace 域名 定位解析在哪一层出问题。

18.8 常见 FAQ

Q：CF 免费套餐够个人用吗？
A：绝大多数个人站点够用（DNS、CDN、HTTPS、基础 DDoS、限量的 Workers、Email Routing 均免费）。

Q：CF 会缓存我的登录态 / 购物车吗？
A：默认针对带 Cookie 的动态响应不缓存；只要源站正确给 Cache-Control，登录态不会被错误缓存。

Q：橙云和灰云可以混用吗？
A：可以。常见做法是：网页记录橙云（保护 + 加速），纯 API / 需要实时性的记录灰云（直连）。注意灰云记录不受 CF 保护。

Q：Workers 能代替服务器吗？
A：轻量 / 无状态 / 边缘场景能；长连接、重计算、复杂依赖不建议。常作为 VPS 的补充而非替代。

Q：Tunnel 免费吗？
A：对个人使用基本免费；有并发配额限制，超限需付费增强。

Q：CF 会看到我的数据吗？
A：CDN / WAF 场景 CF 作为网络的合法中间方处理经手流量；企业客户可用区域级数据驻留、TLS 终止位置等策略管理合规。是否信任取决于你的合规要求。

附录 A 术语表与缩写

CDN — Content Delivery Network，内容分发网络。
WAF — Web Application Firewall，Web 应用防火墙。
DDoS — Distributed Denial of Service，分布式拒绝服务。
Bot — 自动化程序（爬虫 / 脚本）；Bot Score 量化其「机器人程度」。
CC — Challenge Collapsar，应用层 HTTP 洪水攻击的俗称。
TLS / SSL — 传输层安全协议；CF 在边缘终止 TLS。
Anycast — 多节点同 IP 的路由方式，就近 + 抗 DDoS。
Origin — 源站，真实服务器。
Edge / PoP — 边缘节点 / Point of Presence。
JAMstack / SSG — 静态生成站点技术栈（配合 Pages）。
Zero Trust — 零信任网络安全模型。
IdP — Identity Provider，身份提供方。
SSO / BSSO — 单点登录。
DLP — Data Loss Prevention，数据防泄漏。
DMARC / SPF / DKIM — 邮件认证与防伪造的 DNS-TXT 记录族。
DNSSEC — DNS 域名系统安全扩展。
S3 Compatible — 与 AWS S3 API 兼容的对象存储接口。
IaC — Infrastructure as Code（Terraform 等）。
GSLB — 全局负载均衡。
Magic Transit — 整段 IP / 机房流量接入 CF 清洗。
SD-WAN — 软件定义广域网（Magic WAN）。

附录 B 快速决策树

场景 → 推荐方案

「我想让网站更快、更安全上线」→ DNS 接入 CF + 橙云 + Universal SSL。
「我不想暴露服务器 IP」→ 用 Tunnel 隐藏源站。
「有人打我的接口 / 刷登录」→ 速率限制 + WAF Managed Ruleset。
「我被爬虫抓数据」→ Bot 管理 / Super Bot Fight Mode + 限速。
「我要给内部系统做统一认证」→ Zero Trust Access。
「我不想买服务器但要跑定时任务」→ Workers Cron。
「我要免费托管一个静态文档站」→ Pages。
「我要放图片 / 视频」→ Images / Stream。
「我要给域名邮箱收信」→ Email Routing。
「我要隐藏服务但用非标端口」→ Tunnel 映射内网端口。
「我要多机容灾」→ Load Balancing。
「我被超大 DDoS 打机房」→ Magic Transit。

结语

Cloudflare 已经从「一个 CDN」进化成「一个横跨 CDN、DNS、安全、零信任、边缘计算、对象存储、视频、邮件的全球一体化网络平台」。对普通站长，它是「免费 + 省心」的上线利器；对开发者，它是「边缘即计算」的新型部署目标；对企业，它是「安全 + 加速 + 合规」的一站式防线。

理解 Cloudflare 的关键不是记住每个产品名，而是记住一句话：一切流量先经过 Cloudflare 的边缘，在边缘上同时完成加速、过滤、计算与验证，再把干净的流量送回你的源站。 抓住这个「位于中间」的架构心智，所有产品线都会自然串起来。

如果你正配置某个自建服务，遇到「源站暴露」「非标端口」「缓存不生效」「发不了邮件」这类问题，先回到这个心智模型推演——绝大多数卡点都能用「走 Tunnel 出站」「橙云对症」「标准端口回源」「入站 / 出站分离」这几个思维快速定位。

（全文完）

附录 C 深度专题：从零配置一个「安全且快」的网站（完整实操）

为了把前面各章串成一条可落地的路径，这里给出一个从零开始、把任意一个网站安全接上 Cloudflare 并加速的完整实操流程。假设你的网站运行在一台 Linux VPS 上，域名已经可以在某个注册商处管理。

C.1 第 0 步：确认当前网站架构

在动手之前，先画清楚当前拓扑：

你的网站监听哪个端口？如果是 80/443，说明可以直接套 CDN；如果监听的是 8080、9090 这类非标准端口，或者前面还有一个反向代理（比如 Nginx Proxy Manager 只监听 81），那么拓扑会比较复杂，优先考虑 Tunnel。
你当前有没有拿到合法证书？如果是自签证书，套 CDN 时记得选择「Full」模式（而非 Full 严格），因为自签证书默认不被 CF 信任；如果要用「Full 严格」，则要用 CF 的 Origin CA 签一张源站证书，或者使用 Let’s Encrypt。
你的源站有没有暴露在公网？如果反代和源站都在同一台机器或同一内网，Tunnel 会是更省心的选择。

把这些记下来，接下来的每一步就有清晰的判断依据。

C.2 第一步：把 DNS 交给 Cloudflare

在 Cloudflare 控制台点击「添加站点」，输入你的域名。
Cloudflare 会提示你两条 Name Server（形如 xxx.ns.cloudflare.com）。
回到域名注册商，找到「修改 DNS / 修改 NS」的位置，把这两条 NS 填进去，保存。
回到 CF，稍等片刻（通常几分钟到几十分钟）等待 NS 生效，然后在 CF 里「完成激活」。

注意：很多授权（例如国内某些注册商）刚切换 NS 时需要时间生效，全球 DNS 的解析变更一般需要最长 48 小时。期间如果开启过 DNSSEC，必须把 CF 生成的 DS 记录同步到注册商，否则可能出现解析不了（SERVFAIL）的情况。

C.3 第二步：先全部用灰云验证再点亮橙云

在 CF 的「DNS」页面：

先把你现有的 A/AAAA/CNAME 记录照抄进去，保持状态为「仅 DNS」（灰云）。
用灰云状态验证：curl -I http://你的域名 应该能正常返回你源站的内容，且响应里没有 server: cloudflare 字样（因为还没代理）。
确认灰云正常后，逐条把需要保护的记录切到「已代理」（橙云）。一般网页域名、API 域名都建议橙云；如果某条记录是给内部工具用的高频 API，也可以保留灰云，但要清楚灰云不享受 CDN 和 WAF 保护。

C.4 第三步：配置 SSL 模式

在 CF 的「SSL/TLS」页面：

选择「完整」或「完整（严格）」。多数自建站点选「完整」即可，前提是源站也开了 443 且有证书。
如果源站只有自签证书，选「完整」；若想让「完整（严格）」也能通过，去 CF 的「源站服务器」里签一张 Origin CA 证书装到源站。
开启「始终使用 HTTPS」，让访问 http 的用户自动跳到 https。

C.5 第四步：加固源站，只信任 Cloudflare

这一步很多人会忽略，但却是「套了 CF 还是被攻」的头号原因：

打开源站的防火墙（比如 iptables、firewalld、云安全组）。
仅放行 Cloudflare 回源 IP 段对 80/443 的访问。官方 IP 列表在 https://www.cloudflare.com/ips-v4 和 https://www.cloudflare.com/ips-v6。
更严格的做法：在 CF 开启「验证源站拉取（Authenticated Origin Pulls）」，让源站只在 TLS 握手时出示 CF 签发的客户端证书才放行。

做完这步之后，从外部直接访问你的源站 IP 应该无法得到内容，只有经过 CF 的回源流量能到达源站。

C.6 第五步：打开基础安全规则

在 CF 的「安全」页面：

打开「Cloudflare 托管规则集」（WAF），把常见攻击挡在边缘。
在「速率限制」给登录、验证码、注册这类敏感接口单独加规则（例如每 5 分钟最多 20 次，超过则质询或封禁 10 分钟）。
如果站点是公开内容，也不介意爬虫，可以只靠速率限制防刷；如果想要更强反爬，就需要了解 Bot 管理与免费版的 Bot Fight Mode。

C.7 第六步：确定缓存策略

静态资源（图片、CSS、JS、字体）让 CF 缓存，通常源站给出合理的 Cache-Control: max-age 就够了。
页面 HTML 如果要缓存，需要考虑是否包含登录态、个性化内容。如果含登录态，建议不缓存或按是否登录区分 cache key。
接口一定要即时性的话，源站给 Cache-Control: no-store。
如果想强制对某些 URL 全缓存，可以用缓存规则（Cache Rules）或页面规则（Page Rules）的「Cache Everything」。

C.8 第七步：验证与持续观察

用 curl -sI https://你的域名 看响应头，确认 server: cloudflare、有 cf-ray，cf-cache-status 符合预期。
打开 CF 的「分析」看流量与攻击分布。
定期查看「安全」—「事件」，根据被拦截的类型微调规则。
若接入后出现误伤（正常用户被拦截），检查挑战动作是否过严，必要时把 Managed Challenge 降为 Log 或放行白名单。

C.9 备选：用 Tunnel 替代「公网 IP + 证书 + 端口」的折腾

如果你嫌上面「开端口、装证书、配防火墙」太麻烦，或者源站根本在内网、没有公网 IP，可以直接走 Tunnel：

在 VPS 上装 cloudflared。
cloudflared tunnel login 登录你的 CF 账号。
cloudflared tunnel create my-tunnel 建隧道。
配置一条映射：把 https://app.你的域名 指向 http://localhost:8080。
cloudflared tunnel route dns my-tunnel app.你的域名 自动把 DNS 指向隧道。
运行 cloudflared tunnel run my-tunnel。

这样你的公网入口完全由 CF 接管，源站不出公网、不暴露任何端口，证书也由 CF 自动处理。对个人开发者做内网穿透、把本地服务临时对外演示，这是最省心的一条路。

附录 D 进阶：源码级边缘改造的几种模式

很多「高级玩法」本质是在边缘写一点逻辑。这里归纳几种常见模式以及对应的实现载体。

D.1 只在边缘加一个响应头或改动页脚

需求：不想改源站，但希望所有响应都带一个安全头（比如 Content-Security-Policy），或者在页面注入一段统计脚本。

载体：轻量的 Snippets 或一个 Worker 的 fetch handler 里 new Response(body, {headers})。
原理：Worker 拦截请求，请求源站拿到响应后，改写 header 或 body 再返回。
注意：改写 body 会增加 CPU 开销；对超大响应，尽量只在入口页做，避免全站都改。

D.2 边缘开关与灰度发布

需求：新版本想先给 10% 用户看，或者按国家 / 设备区别对待。

载体：Worker 根据 request.headers.get('CF-IPCountry')、User-Agent，或 cookie 里的 A/B 分组，路由到不同源站或返回不同版本。
与 Load Balancing 的权重配合，可做精细的灰度。

D.3 HTTP API 聚合与鉴权

需求：客户端一个请求，回源要拼好几个后端接口；或者要在边缘统一校验 token，别打到底层数据库。

载体：Worker 做 BFF（后端前置），在边缘聚合多个 fetch 的结果，做一个 Promise.all 后再返回。
鉴权：Worker 校验 Authorization / API Key / JWT，未通过直接 401，减轻源站与数据库压力。

D.4 定时任务与投递

需求：每天固定时间生成日报、检查服务健康、拉取数据并推送到指定频道（Telegram / 邮件 / webhook）。

载体：Worker 的 scheduled() + ctx.waitUntil()，绑定 Cron Trigger。
配合外部 API（如 Telegram Bot API、邮件 API）即可完成推送。
相比 VPS 上常驻脚本的优点是：无服务器、无常驻进程、天然抗单机宕机。

D.5 数据在边缘的暂存与计数

需求：需要一个简单的计数器、去重集合、或缓存一份跨节点共享的配置。

载体：Worker + KV（读多写少的键值）、或 D1（轻量关系数据）、或 Durable Objects（需要单实例状态）。
场景举例：点赞计数、访客去重、配置中心、短链存储。

D.6 防范暴力破解登录的统一前置

需求：给 N 个后端应用统一加一层登录防暴力破解，不必每个应用各自实现。

载体：CF 的速率限制 + 一个 Worker（在边缘对登录端点做 IP + 账号维度的计数与封禁）。
优点：改动全部在边缘，源站应用零改动。

附录 E 一些容易混淆的产品对比（避坑）

你想要的	别选	该选
隐藏源站 IP	（把源站 IP 公开在 DNS 灰云）	Tunnel / 橙云 + 源站封段
给内网服务开个公网口	反复改防火墙开放端口	Cloudflare Tunnel
免费给域名邮箱收信	自建整套邮箱	Email Routing（入站）+ 第三方 SMTP（出站）
免费托管静态网站	买 VPS 自建 Nginx	Cloudflare Pages
定时执行一段脚本	常驻 VPS cron 脚本	Workers Cron
给 API 加鉴权限流	每个后端写死	Worker + Rate Limiting
缓存已登录的个性化页面	Cache Everything 无脑缓存	按 cookie 区分 cache key / 不缓存登录态
防超大 DDoS 打机房	只靠单机 CDN	Magic Transit（企业）
想更懂网络层面	只看业务日志	看 Cloudflare 博客与 Learn Center

这类对比能帮助你在动手前就选对工具，少走弯路。

附录 F 小改怡情：把 Cloudflare 用到「妙」处的几个点子

**用 Email Routing 给自己域名造一个 hi@你的域名**，无论网站还是对外名片都能用它。
用 Tunnel 把本机正在开发的 Web 应用临时暴露给朋友预览，一条 cloudflared tunnel --url http://localhost:3000 就够。
用 Worker 做短链服务：/s/abc123 在边缘 302 到目标 URL，配合 KV 存储，不占服务器。
用 Worker + KV 做一个简易访客计数器，展示在个人博客首页。
用 Pages 托管个人文档 / 简历 / 落地页，绑定 GitHub 后 push 即更新。
用 Workers Cron 每天拉取服务器状态并推送到 Telegram，常驻监控不求人。
用 R2 做对象存储 + 自建备份上传，避免依赖某个云存储厂商被限流。
用 CF DNS 的批量编辑与 Terraform 让域名配置进 Git，团队协作更规范。
用 Web Analytics（无需 cookie 横幅）给个人站点做轻量访客统计，兼顾隐私。
用 Page Shield 盯住页面第三方脚本，防止被插恶意代码而不自知。

这些「小闭环」正好是个人开发者最容易即插即用的点，也是很多人持续使用 Cloudflare 的理由——不是因为它多强大，而是因为许多高频需求它都在免费层就给了答案。

附录 G 常见报文示例（速查）

以下是一些对接排错时常用的报文与命令，方便复制即用。

G.1 头部含义示例

HTTP/2 200
server: cloudflare
cf-ray: 1a2b3c4d5e6f7-PEK
cf-cache-status: HIT

server: cloudflare：请求确实经过了 CF 边缘。
cf-ray 末尾的区域码（如 PEK）表示命中的最近节点。
cf-cache-status: HIT：命中边缘缓存。

G.2 查看缓存状态

1	curl -sI https://example.com \| grep -i 'cf-cache-status'

G.3 测试是否经过 CF（看解析 IP）

1 2	dig +short example.com # 若返回 104.16.x.x / 104.17.x.x / 172.67.x.x 等 CF 段，说明走了 CF

G.4 查看 TLS 握手协议与证书

1	openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \| head

G.5 Worker 本地开发与 tail

1 2	wrangler dev --local wrangler tail

G.6 Tunnel 临时暴露

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

附录 H 接下来的学习路线

先把你手头的站点 / 自建服务安全、稳定地接入 CF（本文附录 C 就是完整探路）。
接着用免费能力把「个性化的小工具」搬到边缘：Pages 托管、Worker Cron、Tunnel 暴露。
需要动态后端时，尝试 Worker + KV / D1 / R2 的小项目。
有余力再看 Cloudflare 博客的深度文章，理解它背后是如何做到「又快又稳」的。
需要正规安全合规的企业，研究 Zero Trust、Magic Transit 与相关认证（如 FedRAMP / SOC 2 相关文档，在 Cloudflare Trust Hub 可查）。

本书到此，希望你对 Cloudflare 的「用途」有了成体系的认知。真正把知识变成能力的关键，是在自己的小项目上动手一遍——把域名接进来、点亮橙云、加一条速率限制、写一个 Worker 定时任务，你会比读过一百遍文档更快地理解这个平台。

（全书完）

附录 I 面向运维实战的常见问题速答

I.1 为什么有时候改了 DNS 但迟迟不生效

权威 DNS 由 Cloudflare 托管后，解析通常秒级生效，但用户侧递归服务器有自己的缓存。常见情况：

浏览器缓存：强刷或换无痕窗口。
系统 DNS 缓存：刷新本地 DNS 缓存。
运营商递归缓存：等待 TTL 过期（一般几分钟到几十分钟）。
如果切换过 NS，最长需要等待全球缓存自然过期，最长约 48 小时。

排查时用 dig @8.8.8.8 域名 A 与本地 dig 域名 A 对比，通常能定位是「还差在哪里」。

I.2 明明开了缓存，为什么首屏还是慢

缓存只解决静态资源与可缓存页面的重复请求。首屏第一次访问必然要经历 DNS → TCP → TLS → 回源全链路，原始延迟无法完全消除。

如果回源链路本身很慢（例如跨境、跨运营商），首屏优化要靠：图片压缩、资源合并、开启 HTTP/2/3、使用 Argo 优化回源、或把源站放到更靠近用户的区域。
如果源站响应很慢，CF 只能等到源站多久才能返回多久。先优化源站数据库查询、加缓存层等，再谈 CDN 收益。

I.3 Cloudflare 缓存与「登录态」的经典冲突

很多开发者遇到过「改了代码用户还看旧页」的困境，常见原因：

源站返回了 Cache-Control: public, max-age=3600 且 CF 开了 Cache Everything，导致登录态 / 个性化内容被缓存。
解法：对含登录态的页面，要么不开缓存，要么按 cookie（有没有登录）区分 cache key，要么响应头用 Cache-Control: private, no-store。

I.4 Worker 与 R2 的免费额度到底有多少

免费额度会随政策调整，应以官方定价页为准。大致的理解是：

Workers：每天有一定数量的免费请求与 CPU 时间，超过后按量计费。
R2：有免费的存储量与操作次数，超过后按量计费。
KV / D1 也有免费层与按量层。

个人小项目通常在免费层内运行；规模化后会产生少量费用，但仍比自建一套边缘基础设施便宜得多。选型时把「免费额度是否够」作为是否进付费的基础，再结合你的流量预期来评估。

I.5 为什么有时候被 Cloudflare 拦住却不认识是哪个规则

去「安全」—「事件」里按时间查看拦截记录，每次拦截都会标明命中的规则 ID。
如果是 Managed Challenge 拦了，会显示威胁分数来源。
如果规则太严想放行某类请求，用白名单或调整动作（从 Block 改为 Log）先观察。

I.6 Tunnel 与「公网暴露」的取舍是否安全

Tunnel 让源站没有公网入站端口，攻击者少了一条直达源站的路径。但这不是「绝对安全」：

只要定义了域名 + 认证（特别是 Access），才真正控制了谁能访问。
若只是裸跑一个 trycloudflare 临时隧道且不做访问控制，任何拿到 URL 的人都能访问，所以要给重要的 Tunnel 域名接上 Access 策略。
安全的组合是：Tunnel 暴露 + Access 认证 + Gateway 过滤，形成完整的零信任。

I.7 我的站点在国内能不能用 Cloudflare

这个问题需要分情况：

Cloudflare 的边缘节点在大陆地区没有广泛部署，多数用户会走海外节点，延迟和可用性可能波动；国内访问体验有时不如国内厂商。
如果你的主要用户在国内，需要权衡：Cloudflare 的免费中国路线（或与本地厂商合作）可能需要额外条件与备案；若主要用户在国外，CF 反而是极佳选择。
结合你业务的实际访客与合规需求，再决定是否用 CF 作为唯一入口，还是用 CF 做海外 / 境外加速，国内另配云接入。

I.8 遇到「源站 521 / 522 / 523」是什么意思

521：源站拒绝连接（源站没在监听，或端口不对，或防火墙挡了 CF 回源段）。
522：链接超时（源站响应太慢，TCP 握手没完成）。
523：源站 IP 无法解析（回源域名解析失败）。
524：源站响应超时（源站处理超过了 CF 回源超时时间）。

排查顺序：先确认源站实际健康（curl http://127.0.0.1:80），再看源站防火墙是否放行 CF 段，再看端口与域名指向是否正确，最后由慢到快逐层优化源站性能。

I.9 关于「Cloudflare 会限速或过检测」的一些理解

Cloudflare 对 CDN 流量并不会主动限制正常业务；但如果你的流量模式异常（如瞬间超高并发、疑似 Bot、或明显违反服务条款的内容），它可能触发挑战或流量限制。健康、合规、正常速率的站点基本不受影响。

如果你是个人站点，关键是把返回码、缓存、源站性能这些基础项做好，不必担心「CF 会无缘无故查我」。CF 的价值在于：多数风险在边缘就被挡掉了，而不是让你自己去直面攻击。

I.10 迁移走 / 不再用 CF 时怎么平滑退出

先把需要直连的 DNS 记录改成灰云（DNS only），让流量不再经过 CF。
或者直接把 NS 改回你自己的 DNS 或云厂商 DNS。改 NS 前先在自己的新 DNS 里把全部记录建好，避免解析真空。
若要彻底下线，记得清理第三方对 CF 的依赖（比如 Tunnel、Worker 路由、R2 绑定、Email Routing 的 MX）。
谨慎操作，逐步验证：先灰云，再改 NS，最后删除 CF 站点。

附录 J 术语里的常用「高频缩写」补充

TFO — Original IP 隐藏（源自 CDN 常用）。
PoP — Point of Presence，接入节点。
ASN — Autonomous System Number，自治域编号，用于按运营商/网络做地理或路径判断。
OWASP CRS — OWASP 核心规则集，Web 攻击检测规则库。
BFF — Backend For Frontend，面向前端聚合后端的一种架构，可放在边缘实现。
BGP — Border Gateway Protocol，边界网关协议，Anycast 依赖它。
RUM — Real User Monitoring，真实用户监控。
RBI — Remote Browser Isolation，远程浏览器隔离。
Fetch 标准 — Web 平台用于请求/响应的标准 API，Worker 与浏览器一致。
Cache Key — 决定一条缓存如何被区分的一组请求特征。
Origin CA — Cloudflare 签发的源站证书，用来在「完整（严格）」模式下认证源站。
Authenticated Origin Pulls — 验证源站拉取，源站验证 CF 连接的机制。

到这里，这份 Cloudflare 用途总结就完整了。愿你用它把网站、接口与自建服务打理得又快又稳、源站安全。如果你有任何具体的接入或排错需求，随时可以把现状发来，我们一起定位。

（全书完）

Cloudflare 完全指南：产品、用途、架构与最佳实践

目录

第 1 章 什么是 Cloudflare

1.1 一句话定义

1.2 为什么它如此特殊

1.3 发展历程与规模

1.4 它解决的核心问题（按痛点对应）

1.5 对读者的意义

第 2 章 核心价值与全局架构

2.1 一张图理解 Cloudflare 怎样「插进」你的系统

2.2 Anycast 技术

2.3 分层产品体系总览

2.4 免费与付费的统一底座

2.5 为什么个人开发者也应关注

第 3 章 CDN 与全球加速

3.1 CDN 基本原理与 Cloudflare 的实现

3.2 缓存层级：浏览器缓存 → 边缘缓存 → 源站

3.3 动态内容加速：Argo Smart Routing

3.4 图片与媒体交付优化

3.5 调试缓存：关注响应头

3.6 实战：自建服务接入 Cloudflare 的正确姿势

第 4 章 智能 DNS 托管

4.1 Cloudflare DNS 是什么

4.2 记录类型详解

4.3 解析速度优化

4.4 DNS 安全

4.5 实战：域名邮箱与 DNS 联动

第 5 章 网络安全体系（DDoS / WAF / Bot / 速率限制）

5.1 DDoS 防护（边缘清洗）

5.2 Web 应用防火墙（WAF）

5.2.1 托管规则集（Managed Ruleset）

5.2.2 自定义规则

5.2.3 WAF 动作（Actions）

5.2.4 WAF 的自动化建议

5.3 速率限制（Rate Limiting）

5.4 Bot 管理（Bot Management）

5.5 其他安全增强

5.6 个人站安全配置推荐起点

第 6 章 零信任安全（Zero Trust）

6.1 Cloudflare Access（应用访问控制）

6.2 Cloudflare Gateway（安全 Web 网关 / DNS 过滤）

6.3 Cloudflare Tunnel（内网穿透 / 出站连接）

6.4 WARP（Cloudflare WARP）

6.5 零信任架构图

6.6 常见误区

第 7 章 边缘计算平台（Workers / Pages / R2 / D1）

7.1 Cloudflare Workers（边缘函数）

7.1.1 Worker 最小示例

7.1.2 Workers 与 Cron 定时任务的高频用法

7.2 Cloudflare Pages（静态站 + Functions）

7.3 边缘存储家族

7.4 Worker 生态的边界与适用判断

7.5 参考文档

第 8 章 图像与视频交付

8.1 Cloudflare Images

8.2 Cloudflare Stream

8.3 Polish 与优化

8.4 媒体方案取舍小结

第 9 章 邮件与通信保护

9.1 Email Routing（邮件转发 / 入站）

9.2 邮件安全（Area 1 / Email Security）

9.3 邮件基础设施中 CF 的角色（关键强调）

9.4 参考文档

第 10 章 网络与连接（Tunnel / WARP / Magic Transit / Load Balancing）

10.1 Cloudflare Tunnel（完整形态）

10.1.1 Tunnel 快速上手

10.2 WARP

10.3 Magic Transit / Magic WAN（企业级）

10.4 Load Balancing（负载均衡 / GSLB）

10.5 域名与网络层的一个实际提醒

第 11 章 开发与部署工具

11.1 Wrangler（Workers CLI）

11.2 CICD 与版本控制

11.3 新一代 Cloudflare CLI

11.4 Terraform 与 IaC

11.5 API 与 SDK

11.6 本地开发与调试

第 12 章 可观测性与分析

12.1 内建 Analytics

12.2 Logpush

第 1 章什么是 Cloudflare

第 2 章核心价值与全局架构

第 4 章智能 DNS 托管

第 5 章网络安全体系（DDoS / WAF / Bot / 速率限制）

第 6 章零信任安全（Zero Trust）

第 7 章边缘计算平台（Workers / Pages / R2 / D1）

第 8 章图像与视频交付

第 9 章邮件与通信保护

第 10 章网络与连接（Tunnel / WARP / Magic Transit / Load Balancing）

第 11 章开发与部署工具

第 12 章可观测性与分析

第 13 章行业与场景方案

第 14 章成本模型与套餐选型

第 15 章最佳实践与常见误区

第 16 章关键概念速查表

第 17 章官方文档索引

第 18 章深度专题：常见故障排查与 FAQ