Cloudflare：实用教程（从入门到精通）

产品定位与准备

Cloudflare 既可以为现有网站提供 DNS、代理和防护，也提供运行代码、存放文件、保存业务数据及调用模型的服务。使用这些产品并不意味着要把现有网站全部搬家：先明确一个需求，再选择对应服务，通常比一次启用所有功能更容易维护。

例如，公开图片可以放入 R2，报名记录交给 D1，后台用 Worker 接收表单；域名来信通过 Email Routing 转发，注册验证码则需要发信通道。它们各自解决一部分问题，需要应用代码与配置配合，开通服务不会自动为网站增加完整业务功能。

开始前准备

1. 准备本人或团队有权管理的账户、域名与项目，确认账户恢复方式并启用多因素认证。
2. 记录现有网站托管位置、DNS 记录、邮箱服务和部署方式；操作生产域名前导出配置或保留可恢复记录。
3. 使用测试子域名、测试数据和独立开发资源练习。先确定谁承担账单，再决定是否开通付费产品。
4. 在控制台确认当前账户和域名，不要把同一团队的测试环境误当成生产环境。

本教程按功能说明入口，控制台名称可能随更新变化；找不到菜单时，使用控制台搜索并对照官方文档。每完成一项，都从访客或收件人的角度测试结果，而不只看控制台的绿色状态。

域名接入与 DNS 记录

注册商管理域名的注册和续费，权威 DNS 管理域名指向哪里，网站托管平台负责交付页面。三者可以不是同一家公司；把 DNS 接入 Cloudflare，不等于转移域名注册，也不等于上传了网站文件。

1. 在域名管理入口添加自己的域名，核对扫描或导入的记录，特别是现有网站、MX 和邮箱验证 TXT，不能只检查首页。
2. 按照所选接入方式完成配置。常见的完整接入需要到注册商修改权威名称服务器；如已有 DNSSEC，先依官方接入步骤协调原 DS 记录，避免解析验证失败。
3. 等待域名状态正常后，进入 DNS 记录页，按托管或邮件服务提供的类型、名称和目标添加记录。同名记录已存在时先比较，不直接覆盖。
4. 分别检查根域名、www、业务子域名和邮件收件是否正常，再结束变更窗口。

示例一律使用 example.com。验证失败时依次确认账户、权威名称服务器、记录名、目标和 TTL；不要为“加快生效”反复删除重建。传播、递归缓存和本机缓存都会影响看到结果的时间。

代理状态与 HTTPS

橙云表示支持代理的流量经过 Cloudflare，灰云表示只提供 DNS 解析。是否能开启代理取决于记录类型、协议和上游平台要求；邮件服务器及域名验证相关记录不能照着网站记录一并改成橙云。

1. 先按托管平台说明选择 DNS only 或 Proxied，确认网站在正确地址响应。
2. 检查浏览器到 Cloudflare 和 Cloudflare 到源站两段连接。自建源站应配置有效证书，在满足条件时采用 Full (strict)，而不是通过弱化证书验证掩盖源站错误。
3. 确认 HTTPS 页面、静态资源及 API 都能访问，检查是否出现证书错误、混合内容或反复跳转。
4. 发生故障时记录原模式，只回退本次明确的变更，不随意切换整个域名的安全设置。

Flexible 与源站强制 HTTPS 的组合可能形成重定向循环。遇到 521、522 或 525 等错误，应结合源站服务、连接、防火墙与证书逐项定位。Cloudflare 边缘可用不代表源站一定健康，HTTPS 正常也不代表网站内容可信。

Email Routing 收件转发

Email Routing 可以把 [email protected] 的来信转到现有收件邮箱。它不是一个带独立登录和收件箱的办公邮箱，也不自动让 Gmail 等邮箱用你的域名身份回复。

1. 在 Email Service 的路由功能中添加目标收件地址，到该邮箱完成验证。
2. 选择要启用路由的域名，核对向导要求的 DNS 记录。如果域名已经使用企业邮箱，先评估 MX 冲突和迁移方案，不直接替换现有收件链路。
3. 创建自定义地址与目标邮箱的转发规则，先从一个测试地址开始。
4. 用另一个邮箱发送测试邮件，检查正文、附件和垃圾邮件文件夹；确认正常后再把联系地址发布到网站。

Catch-all 会接收未单独配置地址的来信，方便但也可能增加垃圾邮件。仅在确有用途时开启，并定期清理规则。若需要使用域名地址发信或回复，应另外配置经过认证的发信服务，不把转发成功当作发信授权完成。

Email Sending 发信接入

Email Sending 用于注册通知、找回密码、订单提醒等事务邮件，目前官方将其标为 Beta。向任意收件人发送邮件需要 Workers Paid；向账户中已验证的目标地址发送有不同规则。包含额度和超额费用应以官方价格页与当前账单周期为准，不把它理解成购买了独立办公邮箱。

1. 先确认账户资格和费用，再在发信功能中接入发件域名，按向导完成认证记录。
2. 核对发信状态与域名验证状态。不要为了发信删除正在工作的收件 MX，也不要用一条新 SPF 记录覆盖其他合法发件服务的需求。
3. 按现有应用选择已支持的 SMTP、REST API 或 Workers 绑定。SMTP 参数和凭据取自控制台，不使用 Cloudflare 登录密码代替发信凭据。
4. 把密钥放在后端 Secret 或部署环境安全配置中，设置最小权限；先发普通测试邮件，再接入验证码业务。

请为【项目】评估并接入 Cloudflare Email Sending，用于【事务邮件用途】。
先检查现有发信实现、域名认证、账户资格和费用，暂不改生产配置。
保留验证码生成、有效期、限流与校验，只替换发信通道。
按现有技术栈选择 SMTP、API 或 Workers 绑定并说明理由。
凭据只放后端秘密配置，不进入前端、仓库或日志；不要破坏现有收件 MX。
获我确认后，只向【本人测试邮箱】发送测试邮件，随后验证完整业务流程。
付费、创建凭据、修改生产 DNS 或上线前分别征求确认，并提供回退步骤。

接口返回接受请求不等于收件箱已经收到。应保留脱敏的请求标识和发送结果，检查退信、抑制名单及收件端过滤；不要用重复群发测试送达率。

验证码流程与邮件排查

邮件服务负责传递消息，验证码是否可用由网站决定。更换发信平台时，验证码生成、失效时间、使用次数及验证逻辑应保持明确，不能改成“只要发送成功就允许登录”。

1. 在测试环境检查正确、错误、过期和已使用的验证码；找回密码链接也要验证一次性和有效期。
2. 限制同一账号、邮箱及来源的请求频率。页面倒计时只是交互提示，后台仍需独立限流。
3. 验证码不要写入公开日志；响应内容避免泄露某邮箱是否已注册，结合业务设计统一提示。
4. 核查发件域名认证、发件地址、收件地址和抑制状态，再查看服务结果和收件端垃圾邮件。
5. 超时或发送失败时给用户可理解的重试提示；重试应有上限，避免一次点击发送多封。

上线前用本人测试账号完成从申请验证码到提交验证的闭环。若发信被接受但收件箱没有邮件，继续查投递状态；若收到了却无法登录，重点检查应用的存储、时钟、有效期和校验逻辑。

Workers、Pages 与绑定

Workers 适合承接表单、API、身份校验等请求处理，也能结合 Static Assets 交付静态文件。已有 Pages 项目可以按实际需求继续维护，不应只因看到新教程就迁移一个正常运行的网站。

1. 建立独立测试项目，先让一个最小页面或接口正常响应，再增加业务逻辑。
2. 需要数据库或存储时，先创建测试资源，再在 Worker 的 Bindings 配置中连接。
3. 给绑定起明确的名称，例如 D1 使用 DB；代码中的 env.DB 必须与配置一致。
4. 普通开关可以作为环境变量，API 密钥使用 Secret。开发、预览和生产环境分别配置，不让测试代码连接生产数据库。
5. 部署到测试地址后提交一次真实表单，检查状态码、保存结果和失败提示，再评估生产发布。

绑定提供资源访问能力，不会自动写出上传、查询或权限代码。发布前核对权限、数据库迁移和回退顺序；回退代码版本通常不会同时还原数据库中的业务数据。

R2 文件存储

R2 适合保存图片、附件和下载资料。文件可由后台读取，也可以按需要公开；“上传成功”和“访客有权下载”是两个独立结果。公开宣传图片与私人资料应使用不同的访问设计。

1. 在 R2 创建测试桶，先上传不含个人资料的图片。
2. 决定公开或私有：公开图片可按向导绑定自定义域名；私有资料通过经过身份校验的后台或适用的短期授权方式访问。
3. 公开地址准备好后，用未登录 Cloudflare 的浏览器测试图片。私有文件则分别测试有权限、无权限和过期请求。
4. 检查大小、文件类型、内容及清理策略，再把上传入口接到业务页面。

为【项目】增加图片上传，使用 Cloudflare R2。
先说明图片是公开还是私有，未经确认不要开放整个桶。
后台验证登录、文件类型、实际内容和大小，并使用不可冲突的对象名。
使用后端绑定或最小权限凭据，禁止把访问密钥放入浏览器。
验证允许上传、拒绝非法文件、未授权访问和刷新后图片仍可加载。
说明替换图片及删除旧对象的策略，发布和权限变更前等待确认。

r2.dev 是受限的开发访问入口，不应当作正式交付域名。使用 Access 等措施保护自定义域名时，还要检查是否留有未经保护的其他公开入口；CORS 不是身份认证，不能用于阻止任意非浏览器下载。

D1 数据库

D1 适合用表结构保存报名、留言或业务记录。选用数据库前先明确需要保存的字段、谁可以查询以及保存多久，不把所有表单字段无差别长期留存。

1. 创建单独的学习数据库，确认不是生产库，在控制台查询入口依次执行下面三条语句。
2. 看到查询结果后，将该数据库绑定到测试 Worker，名称与代码保持一致。
3. 表单提交先做校验，再使用参数化语句写入，保存成功后才显示成功提示。
4. 用一条测试记录验证写入、读取和错误处理；管理查询必须进行权限检查。

CREATE TABLE tutorial_notes (id INTEGER PRIMARY KEY, title TEXT NOT NULL);
INSERT INTO tutorial_notes (title) VALUES ('学习记录');
SELECT id, title FROM tutorial_notes;

只在新建测试库运行示例；已有同名表时先检查，不删除表来“重试”。正式项目使用受版本控制的迁移，变更前备份并验证恢复路径。Time Travel 的可恢复窗口取决于当前方案，不能替代长期备份或业务审计。

KV 配置与一致性

KV 用键读取值，适合公告、配置和读多写少的数据。它不是“没有表结构的 D1”，不同位置的读缓存和最终一致性会影响修改后的可见时间。

1. 创建测试 namespace，添加 notice 键和一条不含敏感资料的公告。
2. 把 namespace 绑定到测试 Worker，通过程序读取并显示公告，而不是把管理凭据放在网页里。
3. 修改公告并在不同客户端观察结果，容许缓存传播时间，不用快速重复写入来强迫同步。
4. 给配置设置默认值和读取失败提示；涉及权限的决定由可信后端完成。

余额、库存扣减或需要立即一致的授权状态，不适合直接依赖 KV 的普通读写保证。应根据事务、并发和一致性要求选择合适存储。迁移前先确认数据访问模式，不按“离用户近”就推断所有操作都更快。

缓存更新与地址跳转

缓存适合重复交付不因用户身份变化的内容。发布新文件却仍看到旧内容时，先区分浏览器缓存、应用或 Service Worker 缓存、Cloudflare 缓存及源站内容，不要直接把所有请求改成永不缓存。

1. 先确认发布产物正确，再检查响应头、资源 URL 和请求是否经过代理。
2. 优先为静态资源使用内容哈希或版本 URL。确需清理边缘缓存时，使用针对具体 URL 的清理，避免无必要的全站清空。
3. 登录、订单、个人资料和带授权响应的页面不得盲目使用 Cache Everything；检查缓存键、绕过条件和应用响应头。
4. 需要跳转时先使用测试路径和临时跳转验证范围，确认没有循环、查询参数丢失或误匹配，再决定是否永久化。

验证要覆盖普通访客、两个不同账号和未登录用户，确保不会出现用户 A 的内容被用户 B 读取。永久跳转可能被浏览器长期保存，修改前应保存旧规则并准备回退方案。

WAF、限流与机器人防护

DDoS 缓解、WAF、速率限制和机器人检测针对不同风险。它们不能替代应用身份认证、输入校验、及时更新和数据库权限，也不能保证源站永远不故障。

1. 从安全事件与访问日志确认异常路径、时间和请求特征，再制定范围较窄的规则。
2. 确认套餐允许的动作、表达式和统计窗口。可以预览或记录时先观察，再启用挑战或拦截。
3. 为验证码、登录与上传接口设置合理速率，同时在应用层按账号或邮箱限流。
4. 上线后测试正常浏览、表单、搜索引擎和合法 API；出现误拦时回退最近规则并检查匹配原因。

多人可能共用校园或公司出口 IP，不能只按 IP 设置极低阈值。机器人挑战也可能影响自动化客户端。自建源站还需评估绕过代理直连的风险，不能只隐藏网页上的 IP 就当作隔离完成。

Turnstile 表单校验

Turnstile 可用于注册、登录或留言的人机校验。Site Key 是前端标识，Secret Key 只放后端。组件显示出来只代表前端已接入，后台必须通过 Siteverify 校验本次凭证，之后才处理业务。

1. 创建测试 widget，设置受允许的主机名，按页面要求配置前端组件。
2. 提交表单时把 token 传给后台；后台校验成功、主机名及适用的 action 匹配后，才继续原业务。
3. 测试 token 缺失、校验失败、过期、重复使用和请求超时，不把异常当作默认通过。
4. 结合应用限流与错误提示，确认普通用户能重试，不因脚本加载失败无限等待。

为【表单】接入 Turnstile，保留现有业务校验。
Site Key 可以放前端，Secret Key 仅放后端秘密配置。
后台通过 Siteverify 校验 success、预期 hostname 及配置的 action 后才继续。
覆盖缺失、失败、过期、重复 token 和网络超时，不能只检查 token 非空。
先用官方测试配置在测试环境验证，再人工确认生产配置和发布。

当前官方规定 token 有效期为 300 秒且只能验证一次；表单长时间停留或校验后业务失败时，应按接入文档刷新凭证。不要将验证组件误认为用户身份认证或权限证明。

Tunnel 与 Access

Tunnel 由运行服务的设备主动建立连接，把请求转到指定内网服务；Access 根据身份与策略决定谁可以进入。隧道连通不等于私人后台获得了访问保护。

1. 列出确实需要远程访问的单个服务和允许人员，备份原连接方式。不要把整个内网当作一个公开目标。
2. 先配置 Access 应用及明确的允许策略，避免使用宽泛的 Bypass；再按官方流程在可信设备安装连接器。
3. 保管控制台生成的连接凭据，选择精确的本地服务地址和域名，再启用路由。
4. 分别用允许身份、禁止身份和未登录窗口验证；同时检查源站直连、备用主机名和其他端口是否绕过保护。
5. 停止使用时撤销连接凭据、停用路由，并清理不再需要的访问授权。

临时公开地址只适合无敏感内容的测试，不是管理后台的保护措施。本教程不提供将私人服务直接公开的快捷命令；NAS、开发工具和数据库面板应保留自身认证及必要的网络限制。

Cron 定时任务

Cron Triggers 为 Worker 提供定时触发，适合统计、同步或生成日报。只有时间表没有任务处理代码，程序不会自动知道要生成什么；应先实现并手动验证 scheduled 处理逻辑。

1. 先用测试数据执行一次任务，确认写入范围、输出位置和失败日志。
2. 在 Worker 的触发配置中添加时间表，按 UTC 解释 Cron 表达式。
3. 例如北京时间每天上午 9 点，对应 UTC 01:00，使用下面表达式；保存前核对控制台显示的运行时间。
4. 等待配置生效与实际触发后，再检查日志和最终产物，不仅检查“已保存”。

0 1 * * *

定时任务应设计成重复执行也不会重复收费、重复发信或写出冲突数据，使用日期或任务标识防重。给失败和超时设置可见告警，清理任务先预览目标，不能用未经核对的条件批量删除生产数据。

Workers AI

Workers AI 提供托管模型推理，适合在应用中实现摘要、分类等能力；它不是为所有个人聊天需求准备的替代界面。接入前确定输入类型、模型能力、数据边界和每次调用的成本。

1. 从当前模型目录选择与任务相符的模型，阅读其输入输出、限制、许可证与计费说明。
2. 在测试 Worker 中配置 AI 绑定或适用的服务端调用方式，使用公开测试文本跑通最小请求。
3. 为用户身份、输入大小、频率、输出长度和超时设置边界，不能把有成本的接口无保护开放。
4. 准备正常、超长、空输入及不适合任务的样本，人工比较结果，再逐步启用。

为【项目】增加 Workers AI 摘要功能。
先确认适合当前任务的模型、输入限制、许可与费用，不擅自开通付费。
只用公开测试文本；限制身份、输入长度、调用频率与输出长度。
摘要只根据输入，不补造事实；遇到材料不足时明确说明。
验证错误输入、超时和服务不可用，提供可理解的失败提示。
说明数据会发到哪里、哪些内容进入日志，人工确认后再上线。

模型输出不能替代事实核查。涉及用户上传内容时，先确认处理授权、保留策略和访问范围；不默认把客户资料、凭据或私人通信交给模型。

AI Gateway 与 AI Search

AI Gateway 偏向模型调用的观测与管理，AI Search 偏向资料检索和基于资料回答。两者可以组合，但启用网关不等于已经建立知识库，上传资料也不等于访客页面自动出现问答框。

先把问题分开

• 需要分析调用失败、延迟或用量：评估 AI Gateway 的日志、缓存及支持的提供商，逐项核对当前配置与费用。
• 需要根据网站或文件回答：评估 AI Search 的数据来源、索引状态、检索模式及权限过滤。

1. 从一份可公开的常见问题资料开始，创建测试实例，按需要使用默认 namespace 或独立分组。
2. 连接支持的数据来源，等索引完成，在测试界面检查检索与回答。
3. 同时准备“资料里有答案”和“资料里没有答案”的问题；核对引用与原始资料是否对应。
4. 由后台把问答界面接到实例，保留身份与资料权限，设置请求额度并清理不必要的日志。

不同租户、团队或用户的资料不能混合公开检索。调用日志和缓存可能包含问题及回答，需明确存储位置、可见范围和保留时长；模型供应商的费用与条款也需单独确认。

统计、日志与告警

网站访问统计回答“有没有人在用”，Worker 日志帮助定位“哪一步失败”，告警用来通知需要人工处理的异常。三者各有范围，不应把一张访问趋势图当成全部系统健康证明。

1. 按 Web Analytics 当前接入方式配置站点；需要脚本时加入公共页面模板，避免在同页重复加载。
2. 访问几个测试页面，核对统计能否出现；同时检查浏览器内容拦截或隐私设置可能造成的统计差异。
3. 为业务请求设置脱敏请求标识，记录阶段、状态和错误类别，不记录密码、验证码、token 或完整表单。
4. 从控制台的观测入口检查对应 Worker 的日志、错误与用量，按出错时间缩小范围。
5. 根据当前方案配置异常通知，确认收件人和通知通道，再通过安全的测试事件验证可达性。

采样、日志留存和告警能力随方案不同。数据看不到时先查配置、时间范围与权限，别立即把整个日志级别改成包含全部用户输入；账单通知也不必然等同于硬性消费上限。

实战选择、费用与上线检查

先选择一个能验收的目标：收到一封域名邮件、保存一条报名，或让一张公开图片稳定加载。不要为了“全套接入”同时变更 DNS、数据库和登录系统，否则故障发生时难以定位和回退。

费用不只来自一个订阅按钮。请求、存储、读写、邮件、日志和模型可能分别计量；在控制台核对当前免费额度、超额单价、账单周期和停用方式，再做最坏情况估算。不要认为“小网站”就不会产生费用。

先检查【项目】当前使用的 Cloudflare 服务，暂不修改。
目标是【一个可验证的需求】，请给出最小改动方案、费用来源和回退步骤。
先在本地或隔离测试环境验证，使用脱敏数据及最小权限。
不把密钥提交到仓库、前端或日志，不覆盖现有生产 DNS 和邮箱配置。
付费、权限扩大、删除数据和发布生产前，分别说明影响并等待确认。
交付实际验证结果及未完成项，不把“配置已保存”视为业务已可用。

上线前检查

• 账户、环境、域名和账单归属正确，密钥未进入前端或版本库。
• 成功、失败、未登录、无权限和重复操作都有明确结果。
• 生产发布经过确认，数据有备份，恢复步骤在测试中可执行。
• 日志已脱敏，费用可观察，维护者知道如何停用新功能。

官方入口

功能名称、资格、限制和费用可能调整。操作前从下列官方入口核对与当前账户相符的说明，不依据第三方截图猜测认证记录、密钥或账单条件。

使用声明

本文由 MENTUKEJI 根据项目官网、官方文档及公开资料整理。工具功能、价格、授权方式及服务条款可能随时调整，请以官方最新信息为准。

引用本文内容请注明来源并保留原文链接；如需全文转载，或发现内容错误、版权及授权问题，请联系：[email protected]。