使用NGINX负载均衡器时JS文件尾部出现HTTP/1.1 304 Not Modified导致加载失败

这种问题我之前帮不少开发者排查过，大概率是NGINX在处理304响应的时候搞砸了——把响应头的内容错误拼到了响应体里，尤其是在负载均衡+缓存配置的组合下更容易触发。服务器上的JS文件本身没问题，但浏览器拿到的响应多了HTTP/1.1 304 Not Modified这串内容，直接导致JS解析失败。

下面是具体的排查和解决步骤，你可以一步步来：

1. 先查NGINX的缓存配置（重点） #

如果你在负载均衡节点或者后端节点用了proxy_cache相关指令，先盯紧这几个点：

• 检查proxy_cache_bypass或者proxy_no_cache的逻辑是不是写错了，比如条件判断错误，导致NGINX在该返回304的时候，把之前缓存的响应头和当前响应体乱拼在了一起。
• 确保If-Modified-Since和If-None-Match这两个缓存相关的请求头能正确传递给后端，别乱改或者删掉。可以在对应的location块里加上这两行：

  proxy_set_header If-Modified-Since $http_if_modified_since;
  proxy_set_header If-None-Match $http_if_none_match;
  

2. 验证后端服务器的304响应是否合规 #

HTTP规范里明确说了，304响应是不能带响应体的，只需要返回响应头就行。如果后端服务器（比如Apache、Tomcat这些）错误地在304响应里塞了空内容或者多余字节，经过NGINX转发后就容易出现拼接问题。

• 你可以直接用curl测试后端的304响应：

  curl -I -H "If-Modified-Since: [把JS文件的上次修改时间填这里]" http://你的后端服务器地址/path/to/问题JS文件.js
  

  看返回的结果是不是只有响应头，没有任何响应体内容。

3. 调整NGINX的响应传输配置 #

有些情况下，HTTP版本或者分块编码的设置会导致响应头和响应体混淆。可以在对应的location块里加上这几行试试：

proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding off;

强制用HTTP/1.1协议，关闭分块编码，避免NGINX在拼接响应时出错。

4. 临时关闭会话保持测试 #

如果你的负载均衡配置了会话保持（比如ip_hash），可以先关掉试试。有时候某一台后端服务器的304响应处理有问题，会话保持会让请求一直落到这台机器上，把问题放大。关掉后如果问题消失，那就是某台后端的锅，针对性排查就行。

5. 考虑升级NGINX版本 #

旧版本的NGINX在处理304响应+缓存的场景下确实存在bug，比如某些1.1x版本会出现响应头泄漏到响应体的情况。如果你的NGINX版本比较老（比如低于1.20），建议升级到最新的稳定版（比如1.24+），很多这类bug已经被官方修复了。

最后给你个小技巧：你可以用curl直接请求负载均衡节点的JS文件，加上If-Modified-Since头模拟浏览器的缓存请求，看看返回的内容里是不是真的有那串304字符串，这样能快速定位是负载均衡节点的问题还是后端的问题。

内容的提问来源于stack exchange，提问作者Sathya