同一Docker容器内Django调用DRF接口超时问题排查

1. 内部请求地址错误（最常见原因） #

如果你的Django视图里调用API时用了外部域名/宿主机IP（比如http://your-public-domain.com/api/或http://192.168.x.x/api/），会导致请求从web容器出发，绕到宿主机网络再回到Nginx，这个链路可能因为容器网络隔离、防火墙规则或端口映射缺失而超时。

解决方法：

• 直接使用Docker Compose服务名访问web容器：http://web:8000/api/your-endpoint（Docker Compose默认会为服务创建DNS解析，容器间可通过服务名互相访问）
• 避免在内部调用中经过Nginx，直接请求Gunicorn服务，减少中间环节

2. Gunicorn Worker阻塞或数量不足 #

如果Gunicorn的worker数量过少（比如默认的1个），当你的Django视图处理请求时，会占用唯一的worker；此时视图内部发起的API请求需要等待空闲worker，最终导致超时。

解决方法：

• 调整Gunicorn启动参数，增加worker数量：gunicorn your_project.wsgi:application --workers 4 --bind 0.0.0.0:8000（worker数建议设置为2*CPU核心数+1）
• 如果是CPU密集型任务，考虑使用异步worker（比如gevent），避免同步请求阻塞

3. 内部请求指向Nginx导致循环阻塞 #

如果视图内部调用的是Nginx的地址（比如http://nginx:80/api/），请求会走Nginx反向代理再回到web容器。这种情况下，若web容器的worker被当前请求占用，反向代理的请求会一直等待，最终超时。

解决方法：

• 跳过Nginx，直接请求web容器的Gunicorn服务（如http://web:8000/api/）
• 若必须经过Nginx，检查Nginx的proxy_connect_timeout、proxy_read_timeout配置，适当延长超时时间，但优先考虑直接调用web服务

4. 容器网络配置异常 #

虽然Nginx能正常访问web容器，但仍可能存在网络问题导致内部请求失败：

• 检查web容器是否真的监听0.0.0.0:8000：进入web容器执行netstat -tulpn | grep 8000，确认Gunicorn绑定的是0.0.0.0而非127.0.0.1
• 验证容器间网络连通性：在web容器内执行curl http://web:8000/api/your-endpoint，看是否能正常返回结果
• 检查Docker Compose的网络配置，确保两个容器在同一网络（默认情况下，Compose会为项目创建专属网络，所有服务自动加入）

5. 请求库超时设置过短 #

如果使用requests或其他HTTP库发起内部请求，若未设置合理的超时时间，可能因网络延迟触发超时。

解决方法：

• 在请求时明确设置超时参数，比如：requests.get('http://web:8000/api/xxx', timeout=10)

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