Cloudflare 安全见解排查与配置笔记

这篇记录一次 Cloudflare Security Insights 告警整理。最初列表里同时出现 HSTS、Security.txt、AI 爬虫、Bot Fight、邮箱 CNAME 和平台默认域名等问题，看起来数量很多，但逐项核对后会发现：真正需要修改的配置、第三方服务必须保留的结构，以及可以归档的平台提示混在了一起。

排查的重点不是把所有提示机械地“修成绿色”，而是先确认每个主机名实际承担什么职责，再决定修复、保留还是归档。

先按主机名分组

这次涉及的主机名可以分为四类：

如果不先分组，很容易把邮件协议地址当成普通网站代理，或者为了消除提示去修改 Cloudflare 无法代理的服务。

配置 Security.txt

Security Insights 首先提示正式域名没有配置 security.txt。这个文件用于告诉安全研究人员如何报告问题，标准路径是：

https://example.cn/.well-known/security.txt

站点在 public/.well-known/security.txt 中维护以下信息：

Contact: mailto:security@example.com
Expires: 2027-07-08T00:00:00.000Z
Preferred-Languages: zh, en
Canonical: https://example.cn/.well-known/security.txt

部署后分别检查自定义域名和 Pages 默认域名：

curl.exe -I https://example.cn/.well-known/security.txt
curl.exe -I https://example-site.pages.dev/.well-known/security.txt

两个地址都返回 HTTP 200，但后续扫描仍短暂显示“Security.txt 未配置”。这种情况下应以线上响应为准，将对应见解标记为误报，而不是重复新增文件。

给网站响应加上安全标头

Cloudflare Pages 可以通过 public/_headers 为静态响应增加标头：

/*
  Strict-Transport-Security: max-age=15552000
  X-Content-Type-Options: nosniff

max-age=15552000 对应约六个月。nosniff 用来阻止浏览器猜测与声明不一致的 MIME 类型。

仅修改 Pages _headers 后，example.cn 的页面响应已经带有 HSTS，但 www.example.cn 的 301 跳转由 Cloudflare 边缘层直接生成，最初仍然缺少该标头。因此还需要在控制台中启用区域级 HSTS：

example.cn
→ SSL/TLS
→ 边缘证书
→ HTTP 严格传输安全 (HSTS)

本次采用的设置：

启用 HSTS：开启
最长期限：6 个月
应用于子域：关闭
Preload：关闭
No-Sniff：开启

没有开启 includeSubDomains，因为 imap、pop3、smtp 等子域由阿里企业邮箱负责，不应该让主站的 HSTS 策略强制覆盖全部子域。Preload 也先保持关闭，避免未来迁移 HTTPS 或 DNS 时留下难以快速撤销的浏览器策略。

保存后再次检查：

curl.exe -I https://example.cn/
curl.exe -I https://www.example.cn/

最终主域的 200 和 www 的 301 都返回：

Strict-Transport-Security: max-age=15552000
X-Content-Type-Options: nosniff

新一轮扫描中，“没有 HSTS 的域”关于 www.example.cn 的提示随之消失。

邮箱记录为什么必须保持灰云

站点使用阿里企业邮箱，相关 DNS 结构包括 MX、SPF、DMARC，以及 IMAP、POP3、SMTP 的 CNAME。Cloudflare 会把未代理 CNAME 视为“暴露的基础结构”，但这里的灰云是正确配置。Cloudflare 的普通代理主要处理 HTTP/HTTPS 流量，并不能直接代理标准邮件客户端协议。以下记录必须保持“仅 DNS”：

imap.example.cn
pop3.example.cn
smtp.example.cn

MX、SPF、DKIM 和 DMARC 记录同样不能因为安全见解提示而随意删除。对于“未代理的 CNAME 记录”，正确做法是归档见解，并注明它们属于第三方企业邮箱协议记录。

曾经存在的 mail.example.cn 只用于网页入口，但域名没有完成网页访问所需的备案，而且实际并不需要通过它登录邮箱，因此可以单独删除该 CNAME。这个决定不影响邮件收发，因为客户端和 MX 记录仍然保留。

配置 AI 爬虫策略

Cloudflare 把 AI 自动程序分成搜索、代理和训练三类。对于个人博客，本次策略是：

搜索：允许
代理：允许
训练：阻止

搜索爬虫可以帮助内容出现在检索结果中，代理类机器人可以在回答用户问题时引用页面；训练类爬虫则不需要默认获取全文。Cloudflare 还保留旧版“阻止 AI 自动程序”范围设置。当前将 AI 训练爬虫设置为在所有页面阻止，并让新策略接管后续分类。

开启 AI 迷宫与 Bot Fight

AI 迷宫会给不遵守爬虫规则的 AI 自动程序提供只对机器人可见的干扰链接；Bot Fight 则对已知自动程序流量发起检测或质询。本次设置：

AI 迷宫：开启
Bot Fight 模式：开启
JavaScript 检测：开启

开启后需要观察安全事件和正常访问。如果搜索引擎、站点监控或第三方服务出现误拦截，应先查事件记录，再按路径或机器人身份调整规则，而不是直接关闭全部防护。

为什么修复后仍有很多见解

重新扫描后，正式域名的 HSTS、Bot Fight 和 AI 策略提示已经消失，但列表仍保留一些来自默认域名和 DNS-only 服务的项目。原因是 Security Insights 不只扫描 example.cn，还会检查：

• Cloudflare Pages 自动生成的 pages.dev 地址；
• 帐户的 workers.dev 默认地址；
• 返回 404 的 fallback 地址；
• 所有 DNS-only 主机名；
• Turnstile 等帐户级建议。

这几类提示的处理方式如下：

Turnstile 不是一个“看到提示就全站开启”的开关。它需要放在登录、注册、联系或投稿表单中，并在服务端验证令牌。当前站点没有这些公开表单，因此归档比添加一个没有服务端校验的装饰性组件更合理。

归档不是忽略风险

归档前应该保留判断依据：

• 已通过公网请求验证配置时，选择“误报”；
• 第三方邮件服务必须保持 DNS-only 时，选择“接受风险”；
• 平台默认域名或不适用功能，写明生产入口和实际用途。

归档说明可以写得简短，但需要让以后回看的人知道当时为什么这样判断。例如邮箱记录可以注明：

阿里企业邮箱协议记录，邮件协议不支持 Cloudflare HTTP 代理，必须保持 DNS Only。

最终检查清单

• security.txt 在正式域和 Pages 默认域返回 200；
• 主域页面响应包含 HSTS 和 nosniff；
• www 的 301 响应也包含 HSTS；
• HSTS 没有应用到全部子域，也没有加入 Preload；
• AI 搜索与代理允许，训练爬虫阻止；
• AI 迷宫、Bot Fight 和 JavaScript 检测已开启；
• 阿里企业邮箱 CNAME、MX 与 TXT 记录保持正确；
• 归档已验证的误报和不适用建议；

小结

这次最容易误判的地方，是把安全见解的数量直接等同于漏洞数量。Cloudflare 会从帐户、域名、DNS 和平台默认地址多个层面给出建议，扫描器也不知道每个子域背后的业务语义。

更可靠的处理顺序是：先按主机名确定职责，再从公网验证实际响应，然后修改正式入口的安全配置，最后才归档第三方服务和平台默认域名产生的提示。这样既能提高主站安全性，也不会为了清空列表而破坏企业邮箱或其他正常服务。