核心是禁用Nginx默认ETag并改用构建期内容哈希：需配置etag off;，用SHA-256等预计算静态资源指纹注入ETag头；同步禁用Last-Modified、统一Cache-Control，确保多节点缓存一致性。
核心问题不是 ETag 本身，而是默认机制依赖文件系统元数据（修改时间、大小、inode），在多节点部署中极易不一致。解决的关键是切断运行时环境对 ETag 的干扰，改用构建期确定、内容驱动的唯一标识。
必须关闭默认 ETag 生成
Nginx 默认的 etag on; 行为不可控，它会自动读取文件的 mtime 和 size 计算值，只要文件被复制、解压或同步时间不同，各节点上生成的 ETag 就不同。即使内容完全一样，浏览器带一个节点返回的 ETag 去请求另一个节点，也会因不匹配而返回 200 而非 304。
- 在 http、server 或 location 块中明确写入
etag off; - 检查所有子配置（尤其是 location 块）是否意外覆盖了该设置
- 重载 Nginx 配置使其生效
统一使用构建时预计算的内容哈希
最稳定可靠的方式，是把 ETag 变成“静态指纹”：在 CI/CD 构建阶段，对每个静态资源（如 app.js、style.css）计算 SHA-256，并将结果注入响应头。这样无论部署多少台 Nginx，只要资源内容不变，ETag 就完全一致。
- 构建脚本中生成类似
ETag: "sha256-abc123..."的值 - 可存为同名文件（如
app.js.etag）或写入元数据文件 - Nginx 中用
add_header ETag $sent_http_x_static_hash;回填（需先由后端或构建工具设好X-Static-Hash） - 若纯静态托管且无后端支持，可用 OpenResty + Lua 在 Nginx 层轻量读取文件前几 MB 计算 CRC32，但不如构建期哈希稳妥
同步处理其他缓存关键头
只修 ETag 不够。Last-Modified 同样依赖 mtime，也会导致跨节点不一致；Cache-Control 若策略不同，还会让协商缓存逻辑混乱。
- 禁用默认 Last-Modified：
add_header Last-Modified "";或设为固定可信时间戳，如add_header Last-Modified "Wed, 01 Jan 2025 00:00:00 GMT"; - 确保所有节点返回完全一致的 Cache-Control，例如
public, max-age=31536000, immutable - 避免同时启用 ETag 和 Last-Modified 做双重校验，除非二者严格同步（实践中几乎无法保证）
适用于不可变静态资源的简化方案
如果资源版本化明确（如 /v1.2.3/app.js），且内容发布后永不变更，可跳过哈希计算，直接硬编码语义化 ETag：
add_header ETag "W/\"v1.2.3-20260410\"";- 配合长效缓存：
add_header Cache-Control "public, immutable"; - 每次内容更新时，必须同步更新该字符串，否则缓存将永远不刷新
- 此方式不适用于 API 响应或任何动态内容
