Django+Nginx+Gunicorn架构下大文件下载中途重置问题问询

• 核心误区：你以为Nginx在独立处理文件下载，实际上下载请求根本没匹配到Nginx的静态文件规则，全程由Gunicorn的worker进程扛传输。看你Nginx配置，只有/data/开头的路径配了静态直出，而你的Django下载接口走的是根路径/的反代规则，Nginx只做字节转发，完全没参与文件读取、发送的逻辑。
• Gunicorn默认超时是30秒，判断逻辑是：如果某个worker在超时窗口内没有完成请求处理、返回响应，主进程会直接杀掉这个worker重启。大文件下载时，worker要持续把文件流推送给客户端，9GB文件哪怕按10MB/s的普通带宽算也要15分钟以上，用户带宽更低的话传输耗时可达数小时，远超过默认超时，甚至你之前给Nginx设的300秒（5分钟）超时也不够用——Gunicorn先把worker杀了，连接直接中断，客户端自然会从头开始重新下载。
• 你之前试的两个方案无效的原因很明确：Django侧分块读文件只是改了应用层读取文件的粒度，没解决worker被Gunicorn超时杀掉的核心问题；只改Nginx的超时参数只是调整了Nginx侧的等待阈值，Gunicorn自己的超时机制没适配，先一步杀进程，Nginx配置再高也没用。
• 你现在设--timeout 0确实能绕过问题，但这是典型的野路子解法：等于完全关闭Gunicorn的异常worker回收机制，后续要是有worker遇到死循环、卡死、第三方接口挂住等问题，会一直占着内存和CPU不释放，迟早把整个服务拖垮。

• 架构逻辑错误：把大文件长连接传输的压力全丢给了应用层的Gunicorn和Django。Gunicorn和Django的设计目标是处理动态业务逻辑，根本不适合扛大文件传输场景，不仅传输效率低，还会长期占用worker资源，并发量稍微上来，正常的业务接口就会因为没有可用worker全部报502。
• 路由规则错配：本来已经给/data/路径配了Nginx高性能静态传输，却没把下载请求导到这个路径上，配置完全没生效。
• 代码存在安全漏洞：Django下载函数直接把用户传入的field_name参数拼接到文件路径里，没有做任何路径穿越校验，攻击者只要传入../../etc/passwd这类构造值，就能下载服务器上的任意敏感文件。
• 超时配置不合理：用timeout=0关闭Gunicorn的worker保护机制，只是临时掩盖问题，反而引入了更大的服务稳定性风险。

• 优先调整架构，让Nginx处理大文件传输，完全绕开Gunicorn，这是生产环境大文件下载的标准做法，两种实现选一个即可：
  • 简单场景（下载不需要权限校验）：把所有待下载的tar.gz文件移动到/web/frontend/data/目录下，Django侧不用写读文件、返回流的逻辑，下载接口直接返回302重定向到对应的/data/xxx.tar.gz静态地址即可。Nginx的sendfile机制走内核态直接传输文件，性能比应用层读文件高一个数量级，完全不占用Gunicorn资源，也不存在超时问题。
  • 有权限校验场景（比如仅登录用户可下载）：用Nginx的X-Accel-Redirect特性实现。Django接口只做权限校验，校验通过后不需要读文件，只要在响应头里加X-Accel-Redirect: /internal/xxx.tar.gz，同时在Nginx里配一个内部访问的location指向文件存储目录，Nginx收到这个响应头后会自行读取文件返回给用户，Gunicorn的worker处理完校验逻辑就立即释放，整个接口响应时间只有几毫秒，根本不会触发超时。
• 修复路径穿越漏洞：不管用哪种方案，都要对传入的文件名参数做校验，至少要用os.path.basename()过滤掉参数里的路径分隔符，禁止用户传入带../的路径值，避免任意文件下载风险。
• 把Gunicorn的--timeout 0改回合理值，比如60秒即可。这个参数的本来作用是回收异常卡住的worker，正常动态接口不可能超过1分钟还没返回，不能直接关闭。
• 如果暂时不想调整架构，非要让Gunicorn扛传输，也不要设0超时，按最大30GB文件、最低预期用户带宽（比如1MB/s）计算最长传输时间，把超时设为略大于这个值即可，但非常不推荐这种做法——4个Gunicorn worker只要被4个大文件下载占满，其他所有业务接口都会无法响应。

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