Chrome无法断点续传下载问题求助（已配置ETag与Accept-Ranges）

根据你提供的响应头，服务器已返回Accept-Ranges: bytes、ETag和Last-Modified这些断点续传必需的头信息，但Chrome仍无法触发Range请求，可从以下几个方面排查：

• 检查Nginx代理的Range请求传递配置
  Chrome发送Range请求时，Nginx需要将该请求头转发给后端服务器。如果你的Nginx配置未显式传递Range头，可能导致后端无法处理分段请求。在代理location块中添加：

  proxy_set_header Range $http_range;
  proxy_set_header If-Range $http_if_range;
  

  同时确认后端服务器支持Range请求（Firefox可正常续传，说明后端基础支持没问题，重点排查Nginx是否拦截了请求头）。

• 临时关闭Nginx的proxy_buffering测试
  当proxy_buffering开启时，Nginx会先缓存后端返回的完整文件再发送给客户端，这可能导致Chrome无法识别分段下载的可能性。在代理location中临时添加：

  proxy_buffering off;
  

  测试是否能解决问题，若有效再根据实际业务调整缓存策略（比如大文件关闭缓冲，小文件保留）。

• 排查Chrome的安全与缓存设置

  • 关闭Chrome的「下载后扫描病毒」功能：进入chrome://settings/privacy，找到「安全」板块，关闭「下载后扫描文件」选项，部分杀毒软件或内置安全扫描会干扰Range请求。
  • 清除Chrome的下载缓存：进入chrome://downloads/，右键点击对应下载任务选择「清除」，重新尝试下载和续传。

• 统一响应头的时区格式
  你的响应中Date使用GMT时区，而Last-Modified使用CEST时区，虽然时间逻辑自洽，但Chrome对时区解析可能存在兼容性问题。可以在Nginx中配置强制返回GMT格式的Last-Modified：

  add_header Last-Modified $date_gmt;
  

  或者调整后端服务器，使其返回GMT格式的Last-Modified头。

• 验证ETag的稳定性
  你的ETag为f9e73b20，属于强ETag，但如果后端服务器的ETag生成逻辑不稳定（比如每次请求生成不同值），Chrome会判定文件已更新，放弃续传从头下载。可以用cURL多次请求同一文件，确认ETag是否一致：

  curl -I http://your-download-url/xxx.zip
  

  若ETag变化，需调整后端或Nginx的ETag生成策略（比如基于文件内容和修改时间生成稳定的ETag）。

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