Django+uWSGI+Nginx部署应用浏览器请求未完成问题排查求助

• uWSGI到Nginx的响应传输阻塞：uWSGI日志明确显示请求已生成完整响应，但浏览器无法完成请求，核心大概率出在响应从uWSGI到Nginx的传输环节。比如Nginx的uWSGI缓冲区配置不足，无法承接457KB的响应内容；或者uWSGI的响应缓冲设置不合理，导致分段传输时卡住。
• 连接池复用异常或容量不足：ss工具仅显示3个到源站的连接，说明Nginx与uWSGI之间的连接池可能存在复用故障，或者配置的连接数上限过低，新请求无法建立连接，只能在队列中等待，最终导致浏览器请求超时。
• 系统层资源限制或TCP参数异常：虽然uWSGI内存占用正常，但系统的文件描述符限制、TCP连接回收参数（如TIME_WAIT超时）可能出现异常，导致连接无法及时释放，进而阻塞新请求的处理。此外，突发的磁盘IO瓶颈也可能导致响应写入缓冲区时停滞。
• 大响应的传输配置缺陷：本次请求生成了457KB的响应，若Nginx的uwsgi_buffers、uwsgi_buffer_size或uWSGI的post-buffering参数设置过小，会导致大响应无法一次性完成传输，出现断流或阻塞。

• 检查并调整Nginx与uWSGI的连接及缓冲配置

  1. 查看Nginx的uWSGI配置块，调整缓冲参数以适配大响应：

     uwsgi_buffer_size 64k;
     uwsgi_buffers 4 64k;
     uwsgi_read_timeout 60s; # 延长读取超时时间，避免大响应传输时被中断
     

  2. 确认uWSGI的listen队列大小（建议设为1024及以上）、processes和threads数量是否匹配当前请求量，避免worker资源耗尽。

• 排查系统层面的资源瓶颈

  1. 用ss -t state TIME_WAIT '( sport = :8000 )'查看uWSGI端口的TIME_WAIT连接数量，若过多，调整系统TCP参数加速连接回收：

     echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
     echo "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf
     sysctl -p
     

  2. 检查Nginx和uWSGI进程的文件描述符限制，用cat /proc/$(pidof nginx)/limits查看，确保Max open files不低于65535，若不足可在启动脚本中添加ulimit -n 65535。

• 验证响应传输链路

  1. 绕过Nginx直接访问uWSGI：curl http://127.0.0.1:8000/report/TASKS/BatchDashboard/，若能正常获取响应，说明问题在Nginx；若不能，聚焦uWSGI或Django的响应处理逻辑。
  2. 开启Nginx的uWSGI debug日志，在server块中添加：

     uwsgi_log /var/log/nginx/uwsgi_interact.log debug;
     

     查看日志中是否有响应传输中断、超时等异常信息。

• 优化uWSGI的响应处理

  1. 开启uWSGI的post-buffering参数，设置为post-buffering 8192，让uWSGI先将响应缓冲到内存再整体发送，避免分段传输的问题。
  2. 重启Nginx和uWSGI，用uwsgi stats监控worker的请求处理状态，观察连接数、响应时间等指标是否恢复正常。

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