这类问题我又碰上了一次。站点迁移到新机器后重启过一次服务，之后每次抓取响应头里的 Last-Modified 都是重启时刻，蜘蛛开始全站重抓。
第一反应是「文件系统挂载参数让所有文件的修改时间一致」，验证下来不成立。
排查方向其实有限，先把可能性排一排。响应头由静态服务的默认配置生成，取的是进程启动时间；动态页面没有单独输出 Last-Modified，交给了前置缓存；CDN 回源时覆盖了源站的这一个头部。
第一件事是对比两个页面的 Last-Modified 是否相同
curl -sI https://www.example.com/post/1 | grep -i last-modified; curl -sI https://www.example.com/post/2 | grep -i last-modified接着按内容真实修改时间输出头部
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $modified) . ' GMT');然后让 CDN 透传源站的缓存校验头
proxy_pass_header Last-Modified;等前面都确认过，再确认 If-Modified-Since 能返回 304
curl -sI -H 'If-Modified-Since: Wed, 11 Nov 2026 02:00:00 GMT' https://www.example.com/post/1 | head -1怎么算真的好了，看的是同一批现象。改成按内容时间输出后，同一时刻全站时间戳一致的现象消失，304 命中率回升到七成。
补一句。这个头部一旦失真，全站都会被当成刚更新，抓取预算会在一夜之间被消耗干净。报错文案容易误导，真正的原因往往在相邻那一层的日志里。