这是一份面向新站的 Cloudflare 上线检查清单，适合包含独立前后端、API、登录、支付回调或管理后台的网站。核心原则不是把所有开关一次性打开，而是先确认 DNS 与 TLS 链路正确，再逐步添加缓存和安全策略，每次变更后都验证实际业务。

原帖发布于 2026 年 8 月 11 日。以下内容保留原帖的八项配置、操作顺序、验证方法和作者明确提醒，并结合 Cloudflare 官方文档补充必要前提。

1. 先核对 DNS 记录

进入 DNS → 记录，逐条确认 Cloudflare 自动扫描的结果，而不是默认全部正确。典型网站可以这样组织：

  • 根域名 @：使用 A/AAAA 记录指向源站。
  • www：使用 CNAME 指向根域名。
  • 需要通过 Cloudflare 提供服务的网站记录开启代理，即橙色云朵。
  • 邮件、域名所有权验证和其他不支持代理的记录保持“仅 DNS”，不要因为想隐藏 IP 而全部开启代理。

原图：DNS 记录检查

修改后分别访问根域名和 www，确认两者均能建立 HTTPS 连接。随后选定唯一主域名，将另一个地址使用重定向规则做 301 跳转，避免同一内容出现两个规范网址。

原图：主域名重定向

2. SSL/TLS 使用“完全（严格）”

进入 SSL/TLS → 概述，在源站证书已经就绪后选择 完全（严格）。该模式会加密“浏览器到 Cloudflare”和“Cloudflare 到源站”两段连接，并验证源站证书。

源站需要满足三个前提：

  1. 443 端口可建立 HTTPS 连接；
  2. 证书未过期，且域名位于 CN 或 SAN 中；
  3. 证书由受信任 CA（例如 Let’s Encrypt）或 Cloudflare Origin CA 签发。

原图：完全（严格）模式

如果使用 Origin CA，需要明确它主要服务于 Cloudflare 到源站的连接。暂停代理、让浏览器直接访问源站时，浏览器通常不会把 Origin CA 当作公共受信证书。若证书不满足严格模式要求，访客可能遇到 526 错误。可参考 Cloudflare Full (strict) 官方说明。

原图：Origin CA 配置

3. 强制 HTTPS 并设置 TLS 下限

进入 SSL/TLS → 边缘证书，按业务兼容性检查：

  • 始终使用 HTTPS：开启，把 HTTP 请求重定向到 HTTPS。
  • 自动 HTTPS 重写：可开启，用于减少页面中仍引用 HTTP 资源造成的 Mixed Content；启用后仍需检查脚本、图片和第三方组件。
  • 最低 TLS 版本：设为 TLS 1.2。
  • TLS 1.3：开启。

完成后用开发者工具确认页面没有 Mixed Content，并检查源站自身是否又做了一层互相冲突的重定向，避免循环。

4. 开启并验证 DNSSEC

进入 DNS → 设置 → DNSSEC 启用签名。DNSSEC 的作用是验证 DNS 响应来自正确的权威服务器且没有被篡改，并不会直接提高网页速度。

原图：DNSSEC 设置

如果域名注册商不是 Cloudflare，还需要按界面提示将 DS 记录提交到注册商，并等待状态确认。迁移已有 DNSSEC 的域名时，旧 DS 记录和新的 Cloudflare 密钥不匹配会导致解析返回 SERVFAIL；应按 Cloudflare DNSSEC 官方迁移流程处理，不能只改 NS 后立即打开新签名。

5. 启用压缩与新协议

进入 速度 → 设置，检查内容优化与协议选项，包括压缩、HTTP/2 和 HTTP/3。不要仅以控制台显示“已开启”作为完成依据，应分别观察浏览器 Network 面板中的 content-encoding、协议版本和静态资源体积。

原图：速度和协议设置

图片优化和脚本相关开关可能改变资源格式或执行方式；包含旧浏览器、第三方 SDK 或严格 CSP 的站点应逐项开启并回归测试。

6. 静态资源可缓存，动态内容必须绕过

Cloudflare 默认适合缓存图片、CSS、JavaScript 和字体等静态资源。新站不要直接对所有 HTML 使用“Cache Everything”，因为登录状态、购物车、用户中心、后台和 API 可能包含用户专属数据。错误缓存动态页面可能把内容发给不该看到它的人。

在 缓存 → Cache Rules 中明确让动态路径绕过缓存，例如：

/api/*
/admin/*
/login/*
/checkout/*

实际规则还应考虑认证 Cookie、查询参数和不同主机名，不能只照抄路径。可结合 Cloudflare Cache Rules 字段与设置检查匹配条件，并用响应头验证 CF-Cache-Status 是否符合预期。

7. 基础安全防护从高风险接口开始

进入 安全性 → 设置，重点检查：

  • Bot Fight Mode：普通内容站可以试用；存在公开 API、监控或 App 客户端时应先小范围观察。
  • 速率限制：优先保护登录、注册、验证码和计算成本高的生成接口。
  • 安全级别：先保持可控的默认值，出现明确攻击证据后再调整。

原图：安全性设置

适合优先限速的请求示例：

POST /api/login
POST /api/register
POST /api/send-code
POST /api/generate

不要一开始就给全站设置同一阈值。上线后查看 安全性 → 分析 → 事件，关注搜索引擎、可用性监控和正常 API 客户端是否被误伤，再根据真实请求频率调整。

8. 隐藏源站，并保留安全的管理入口

Cloudflare 代理只有在攻击者不能绕过它直接访问源站时，才能完整发挥作用。原帖建议：

  • 删除不需要公开的源站 DNS 记录。
  • 检查历史 DNS、邮件记录和其他子域名是否泄露源站 IP。
  • 在源站防火墙中，仅允许 Cloudflare 官方 IP 段访问 80/443。
  • 应用需要真实客户端 IP 时，只信任来自 Cloudflare 入口的转发头。
  • 开启证书、流量与安全事件告警。

限制 80/443 前必须保留并测试 SSH 或其他独立管理入口；否则规则写错会把管理员一起挡在服务器外。Cloudflare 地址范围可能调整，应使用 官方 IP 范围页面作为唯一维护来源。不要无条件信任来自公网的 CF-Connecting-IP 或 X-Forwarded-For，应先保证请求确实经过可信的 Cloudflare 地址。

上线后的验收清单

配置完成后，至少用普通窗口和无痕窗口覆盖以下流程：

  1. 根域名与 www 的 301 跳转；
  2. 首页、静态资源和缓存响应头；
  3. 登录、退出、用户中心与管理后台；
  4. API、文件上传和 WebSocket；
  5. 支付或第三方回调；
  6. 源站证书续期与严格模式；
  7. DNSSEC 的 DS 状态和外部解析；
  8. 安全事件中是否存在正常流量误伤。

这套清单不是“开得越多越安全”。CDN 只是架构的一层，应用鉴权、数据库权限、备份、日志和源站补丁仍需独立维护。每次只改变一到两项，并记录变更前后结果，出现问题时才容易回滚和定位。

原作者：jonssonyan
原帖：https://linux.do/t/topic/2738924