使用runserver_plus(--nothreading)的Django本地服务器请求挂起问题

核心原因推测 #

你遇到的问题本质是单线程服务器下的请求接收阻塞：当使用runserver_plus --nothreading时，服务器以单线程模式运行，一次只能处理一个TCP连接的请求。请求#1迟迟未启动处理，并非视图逻辑问题，而是服务器一直在等待请求#1的完整数据（请求头/请求体）到达，直到请求#2（新的TCP连接）发起后，服务器优先处理了这个完整的新请求，之后请求#1的完整数据才传输完成，服务器才开始处理它。

常见触发场景：

• 浏览器端因并发限制、页面资源加载阻塞等原因，未完整发送请求#1的数据
• Mac Docker虚拟机的端口转发延迟，导致请求数据包传输不完整
• Werkzeug（runserver_plus依赖的WSGI服务器）旧版本的单线程连接处理bug

解决方案 #

1. 移除--nothreading选项 #

直接使用多线程模式启动服务器，这是最直接的解决方法：

python manage.py runserver_plus

多线程模式下，服务器可以同时处理多个TCP连接，不会因单个连接的请求传输阻塞而卡住其他请求。

2. 排查请求传输完整性 #

• 在容器内使用tcpdump抓包，检查请求#1的数据包是否完整到达服务器：

  # 进入容器
  docker-compose exec <your-service-name> bash
  # 安装tcpdump（若未安装）
  apt-get update && apt-get install tcpdump
  # 抓包监听8000端口（假设Django端口是8000）
  tcpdump -i any port 8000 -A
  

  观察请求#1的GET/POST请求是否完整包含所有头信息和请求体。

3. 升级依赖版本 #

升级Django Extensions和Werkzeug到最新稳定版，修复可能存在的单线程处理bug：

pip install --upgrade django-extensions werkzeug

4. 调整Docker网络配置 #

• 尝试优化Docker资源分配：打开Docker Desktop设置，增加虚拟机的CPU、内存配额，避免性能瓶颈导致的传输延迟。
• 若使用默认桥接网络异常，可尝试自定义桥接网络替代默认配置。

5. 临时禁用Debug Toolbar #

Debug Toolbar的中间件可能在请求处理前引入额外的等待逻辑，暂时移除debug_toolbar在INSTALLED_APPS和MIDDLEWARE中的配置，验证问题是否消失。

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