我的博客响应头缺了什么：Cloudflare _headers 补课记

为什么静态站最容易漏掉这一环#

静态站很容易让人产生一种错觉：我只是一堆 HTML 和图片，没有数据库、没有登录、没有后端逻辑，能有什么安全问题？

问题在于，安全响应头管的从来不是服务器，而是浏览器。服务器已经正确返回了内容，浏览器接下来怎么解释这些内容、允不允许别人嵌套、要不要带着 Referer 跑去外站——这些决定权在响应头手里，而 Cloudflare 不会替你写。

三条常见路线，我对比过：

1. Cloudflare 控制台的 Transform Rules（Modify Response Header）。不用改代码，点点鼠标就行。但配置只活在控制台里，不进仓库、不能 review、换账号就没了；免费套餐的动态规则条数也紧张。
2. 在 Worker 里包一层 fetch，手动 headers.set()。最灵活，但对一个纯静态站来说，为了加几个响应头把整个静态资源链路接管一遍并不划算。
3. 在静态资源目录放一个 _headers 纯文本文件。跟仓库走、跟构建走、可 diff、可回滚，Workers 静态资源原生支持。

我选第 3 条，理由很简单：这个站的部署方式是「push 到 main → Cloudflare 构建 → wrangler deploy」，配置也应该在这个链路里，而不是散落在控制台。

实测：securityheaders.com 给了 F#

直接看结果：

报告时间是 05 Oct 2026 13:10:38 UTC，扫的是 https://blog.juluo.work/。六个红叉分别是：

报告底部还有一块 Upcoming Headers，列着 Cross-Origin-Embedder-Policy、Cross-Origin-Opener-Policy、Cross-Origin-Resource-Policy 三个头。它们目前不计入扣分，我也没打算上：COEP / COOP 一开严格模式，站外图片和第三方 iframe 很容易一起挂掉，收益（启用 SharedArrayBuffer 之类）个人博客用不上。

再用 curl 自己确认一遍，毕竟第三方工具的结论我得自己复现：

真实输出里跟安全相关的头命中数是 0。响应里确实有一堆头，但仔细看全是 Cloudflare 自己的东西：

• Server: cloudflare、CF-RAY: ...、CF-Cache-Status: HIT —— 这是「谁在处理请求」，不是安全策略。
• Nel / Report-To —— 网络错误上报（Network Error Logging），属于可观测性头。它们让浏览器把网络故障上报给 Cloudflare，跟「防不防 XSS / 点击劫持」没有半点关系。
• Cache-Control: public, max-age=0, must-revalidate —— 这是 Workers 静态资源的默认缓存策略，跟安全无关（后面还会用到它）。
• alt-svc: h3=":443" —— 告诉浏览器可以走 HTTP/3。

所以「响应头列表很长」这件事本身很有欺骗性。

另外我顺手测了一下明文 HTTP：

curl.exe -s -o NUL -w "final_code=%{http_code} redirects=%{num_redirects} url=%{url_effective}`n" -L --noproxy "*" http://blog.juluo.work/
# final_code=200 redirects=0 url=http://blog.juluo.work/

redirects=0，明文 HTTP 直接返回 200，站点没有强制跳转 HTTPS。这一条在后面的 HSTS 部分很关键。

逐个头过一遍：作用、副作用、我的取舍#

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=(), usb=()

方案：一个 public/_headers 文件#

最终要写进仓库的就是这个文件：

# public/_headers —— Cloudflare Workers 静态资源的自定义响应头
# Astro 构建时 public/ 会原样复制到 dist/，Workers 解析这个文件并改写响应头
# （文件本身不会被当作静态资源下发，站点里看不到它）

# 第 1 阶段：先上 5 个基本没有副作用的安全头
/*
  Strict-Transport-Security: max-age=300; includeSubDomains
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=(), usb=()
  X-Frame-Options: SAMEORIGIN

# 第 2 阶段：CSP 先用 Report-Only 跑一周，确认没有误伤再转正
/*
  Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

# 顺手的收益：_astro/ 下的产物文件名带内容哈希，可以放心 immutable
/_astro/*
  Cache-Control: public, max-age=31536000, immutable

几个设计说明：

为什么放 public/。 wrangler.jsonc 里是 assets.directory = ./dist，而 Astro 会把 public/ 下的文件原样复制进 dist/，所以 dist/_headers 正好落在静态资源根目录。部署链路一个字都不用改，npx wrangler deploy 会把它一起带上去。

HSTS 先写 300 秒。 这就是上面说的分级爬坡，验证没问题再改成 31536000。

/_astro/* 那条不是安全头，是顺手捡的收益。 现在我的资源全是 Cache-Control: public, max-age=0, must-revalidate，虽然带 ETag 不会重复下载内容，但每次导航仍要走一次条件请求。实测 MainGridLayout.BQV2WkRb.css 有 288727 字节（约 282 KB），文件名里带内容哈希（BQV2WkRb）意味着内容一变文件名就变，可以放心 immutable。

别把这条件加到 HTML 上。 HTML 保持默认的 max-age=0, must-revalidate，否则发新文章读者看不到。

警告

_headers 只对静态资源响应生效，对 Worker 代码生成的响应无效。我另外两个服务——t.juluo.work（自建统计 Worker + D1）和 icon.juluo.work（链接卡片 Worker）——都是脚本模式，响应是代码里 new Response() 出来的，_headers 管不到它们，只能在 Worker 里手动 headers.set()。这一点官方文档写得很明确，别以为放个文件就全站生效了。

规则本身的几个细节（我对着官方文档核过）：

• 一个块 = 第一行是路径模式（/、/path/*，也支持写完整 URL），下面缩进的行是 名字: 值。
• 一个文件最多 100 条规则，每行含空格在内上限 2000 字符。
• 多个块命中同一个请求时，头会合并；同一个头被写了两次，值用逗号拼接。
• 想删掉某个头（默认头或者更宽规则加上的），用 ! 头名 的写法。
• 匹配支持 * 通配（整个模式只能有一个）和 :placeholder，匹配到的值可以在头值里用 :splat / :placeholder 引用。

怎么验证#

下面几步我没法替你跑（文件还没提交上去），只能给出 after 的验证方法：

# 1. 看完整响应头，预期多出 5 个新头
curl -sI https://blog.juluo.work/

# 2. 只筛安全头，预期有输出（现在是空）
curl -sI https://blog.juluo.work/ \
  | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy'

# 3. 确认 HTTP 是否跳转（先在 Cloudflare 开 Always Use HTTPS）
curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://blog.juluo.work/

# 4. 复检评分
#    https://securityheaders.com/?q=https%3A%2F%2Fblog.juluo.work&followRedirects=on

第 2 步在我本地现在是空输出，第 3 步现在返回 200（redirects=0）。做完之后这两步应该分别变成「有输出」和 301。Windows 上没有 grep，我是用 PowerShell 的 Select-String 做的等价统计（就是前面第二张截图里那条命令，结果是 0）。

踩坑与注意事项#

• 坑 1：以为上了 Cloudflare 就有安全头。 Cloudflare 免费套餐默认只加 Nel、Report-To、Server、CF-RAY、alt-svc 这些它自己的头，六个安全头一个都不加。这些是「可观测性头」和「传输协商头」，不是「安全头」，别被响应头列表的长度骗了。
• 坑 2：securityheaders.com 到底扫的是 HTTP 还是 HTTPS。 我第一次直接在输入框填了域名，它按 http://blog.juluo.work/ 扫的（报告里 Site 那一行会写出来）。后面加上 followRedirects=on、并且显式写 https://，报告才是你真正想要的那份。两次结果的评级都是 F，但缺的头数量不一样（HTTP 那份是 5 个，HTTPS 那份是 6 个，多了 HSTS），很容易看错。
• 坑 3（差点踩）：includeSubDomains 之前先数一遍子域。 我在 blog.juluo.work 上写是安全的；但如果图省事直接给裸域 juluo.work 写 includeSubDomains，而某个子域还跑在 HTTP 上，那就是浏览器缓存级别的打死，改回来也进不去。
• 坑 4：CSP 不能直接上强制模式。 静态站的页面是构建期生成的一大坨内联脚本，script-src 'self' 下去评论区和统计会立刻全灭。必须 Report-Only 先跑，看 Console 报错清单。
• 坑 5：immutable 别加错地方。 只给带内容哈希的 /_astro/*，HTML 保持默认。加错到 HTML 上读者会一直看到旧页面，而且因为自己浏览器强刷而不复现，特别难排查。

小结#

• 现状（实测）：六个安全头全缺，securityheaders.com 给 F，http://blog.juluo.work/ 明文返回 200 不跳转，juluo.work 不在 HSTS 预加载列表里。
• 值得马上补的四个：X-Content-Type-Options、Referrer-Policy、X-Frame-Options、Permissions-Policy。几乎是纯收益，副作用可以忽略。
• HSTS 要配合强制跳转一起上，max-age 从 300 秒分级爬，preload 现阶段别碰。
• CSP 是唯一需要认真做功课的：先用 Report-Only + 结构性指令，等内联脚本清理干净了再收紧。
• Cloudflare Workers 静态资源站，public/_headers 是成本最低、最可回滚的做法：跟仓库走、跟构建走、能 diff 能 review。但它只管静态资源，Worker 生成的响应还得在代码里加。

本文发布时站点还没有应用这些头，after 数据都是方案说明而不是实测结果。照上面四条命令复检即可。

配合 HTTPS 配置的 SSL Labs 评分一起看，安全审计的两块就齐了。