304 Not Modified 用于响应条件 GET 或 HEAD 请求（即带有 If-None-Match 或 If-Modified-Since 的请求），表示根据条件判断，客户端存储的副本仍是最新的。服务器不再重新发送资源，而是返回 304，客户端使用自己缓存的副本。这样可以节省带宽和时间。
304 永远没有响应体，响应在响应头之后的空行处结束。对于 Cache-Control、Content-Location、Date、ETag、Expires 和 Vary 这几个响应头，只要 200 响应中会包含，服务器就必须在 304 中同样发送，以便缓存更新已存储的响应。
虽然 304 属于 3xx 范围，但它并不是重定向：没有 Location，客户端仍停留在同一个 URL 上。如果客户端没有发送条件请求却收到了 304，说明服务器有问题。
响应示例
HTTP
HTTP/1.1 304 Not Modified
Date: Fri, 06 Nov 2026 10:15:32 GMT
ETag: "5f2b-1a3c"
Last-Modified: Wed, 28 Oct 2026 08:02:11 GMT
Cache-Control: public, max-age=600
Vary: Accept-EncodingSEO 与重定向检测
304 对抓取有帮助。Google 的抓取工具支持条件请求，304 会告诉 Googlebot 内容自上次抓取以来没有变化。这样既节省了抓取容量和服务器负载，页面在索引中的位置也不受影响，因此值得提供可靠的 ETag 或 Last-Modified 响应头，对大型网站尤其如此。
TrueURL 默认不发送条件请求头，所以看到的会是 200 而不是 304。要测试重新验证，可以在“自定义请求头”中添加 If-None-Match 请求头，值为页面的 ETag。
常见原因与使用场景
- 浏览器使用
If-None-Match重新验证缓存的页面、图片或脚本，而ETag仍然匹配。 - 爬虫或订阅阅读器使用
If-Modified-Since再次获取，而内容没有任何变化。 - 部署之后访客看到的仍是旧内容，因为服务器一直返回 304：它的验证器没有变化，例如
ETag根据文件大小和修改时间生成，而部署过程保留了这两项属性。应确保内容变化时验证器也随之变化。