Django容器拒绝Nginx容器流量,出现502错误求助
问题排查与解决方案
一、当前连接重置问题的核心原因与修复
你遇到的recv() failed (104: Connection reset by peer)错误,最可能的原因是Django服务仅绑定了容器内部的127.0.0.1地址,导致Nginx所在的其他Pod无法访问。
1. 修改Django容器的启动绑定地址
Django默认的runserver命令会绑定127.0.0.1:8000,这个地址只能在容器内部访问,Kubernetes集群内的其他Pod无法连接。需要修改启动命令,让Django监听容器的所有网卡:
# 在Django Deployment的containers段添加command和args containers: - name: web image: localhost:5000/kubernetes/web ports: - name: http containerPort: 8000 imagePullPolicy: Always command: ["python3"] args: ["manage.py", "runserver", "0.0.0.0:8000"]
2. 修正ALLOWED_HOSTS配置
你当前添加的127.0.0.1和localhost仅适用于容器内部或直接访问Django服务的场景。Nginx转发请求时,会将客户端的Host头(比如你浏览器访问的localhost)传递给Django,所以需要将这个Host添加到ALLOWED_HOSTS中:
# settings.py ALLOWED_HOSTS = ['localhost', 'your-domain.com'] # 替换为实际访问的域名/IP # 测试阶段可临时用通配符(生产环境禁止):ALLOWED_HOSTS = ['*']
3. 验证连通性
- 进入Nginx Pod执行
curl http://my-django-svc:8000,如果能返回Django默认页面,说明网络和服务已正常。 - 如果仍有问题,查看Django Pod的日志,确认服务是否正常启动,是否有访问被拒绝的报错。
二、关于WSGI服务器的必要性
Django自带的runserver是开发专用服务器,绝对不能用于生产环境:
- 性能极差:仅支持单请求处理,并发能力几乎为0;
- 无安全防护:没有生产级别的请求过滤、超时控制等机制;
- 稳定性不足:长时间运行容易崩溃,不适合高负载场景。
生产环境必须使用WSGI服务器(如Gunicorn、uWSGI)来运行Django,标准架构为:Nginx(反向代理、SSL、静态文件处理) → WSGI服务器(运行Django应用)
示例:用Gunicorn启动Django
- 在Django镜像的Dockerfile中添加Gunicorn安装:
RUN pip install gunicorn
- 修改容器启动命令:
command: ["gunicorn"] args: ["--bind", "0.0.0.0:8000", "your_project_name.wsgi:application"]
替换your_project_name为你的Django项目名称(即wsgi.py所在的目录名)。
三、Nginx配置优化建议(生产环境)
为了更好适配Django的请求转发,建议补充以下配置:
server { listen 80; server_name your-domain.com; location / { proxy_pass http://my-django-svc:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 用于识别HTTPS请求 } # 静态文件直接由Nginx处理(生产环境建议挂载PVC或使用CDN) location /static/ { alias /path/to/your/static/files/; } location /media/ { alias /path/to/your/media/files/; } }
内容的提问来源于stack exchange,提问作者Johnny Pastrami
相关产品推荐
相关产品推荐

