Docker部署Django+Vue+Gunicorn+Nginx出现502 Bad Gateway问题咨询

1. 单容器打包方案的合理性 #

这个方案完全匹配你的业务场景：面向客户独立部署、非多租户、每个客户版本独立，单容器的优势非常契合需求：

• 交付复杂度低：单个镜像即可完成交付，客户侧不需要掌握多容器编排、服务依赖管理的能力，后续部署到AWS ECS时，单容器的任务定义也更简洁，故障排查成本更低
• 版本一致性更强：前端、后端、反向代理的版本完全绑定，不会出现多容器场景下版本 mismatch 的问题
  如果你的业务没有单独扩缩容Nginx/后端、单独更新某一组件的需求，不需要拆分多容器。如果后续有单独更新的诉求，再拆分也完全来得及，当前阶段单容器是更优选择。

2. Gunicorn绑定端口后绕开Nginx的原因 #

核心原因是端口暴露规则和访问路径的问题：

• 如果你在docker run或者docker-compose.yml里把容器的8000端口映射到了宿主机，用户直接访问宿主机的8000端口时，请求会直接发送到容器内绑定0.0.0.0:8000的Gunicorn服务，自然不会经过Nginx
• 正常的访问链路应该是：容器仅对外暴露80/443端口，所有用户请求先到Nginx，Nginx根据规则转发静态资源请求到Vue产物目录，转发动态请求到Gunicorn的sock文件或者127.0.0.1:8000（注意Gunicorn不要绑定0.0.0.0，仅绑定127.0.0.1就可以避免外部直接访问）

3. 502错误排查方法与配置建议 #

502 Bad Gateway的本质是Nginx无法正常转发请求到上游的Gunicorn服务，按以下步骤排查即可定位问题：

常见故障原因 #

• sock文件权限不匹配：Gunicorn创建sock文件的运行用户，和Nginx的运行用户不一致，导致Nginx没有读写sock文件的权限
• sock文件路径不一致：Nginx配置中proxy_pass指向的sock路径，和Gunicorn启动参数中指定的sock路径不匹配
• 启动顺序错误：容器启动脚本中Nginx比Gunicorn先启动，Gunicorn还没完成sock文件创建，Nginx就已经完成启动，无法找到上游服务
• Gunicorn启动异常：Gunicorn看起来启动成功，实际因为依赖缺失、配置错误已经崩溃，没有实际运行

排查步骤 #

1. 进入运行中的容器：docker exec -it <你的容器ID> /bin/bash
2. 查看Nginx错误日志：cat /var/log/nginx/error.log，日志会明确标注是权限不足、文件不存在还是连接被拒绝，可以直接定位大部分问题
3. 验证Gunicorn可用性：执行curl --unix-socket <你的sock文件路径> http://localhost，如果返回正常响应，说明Gunicorn运行正常，问题出在Nginx配置；如果请求失败，说明Gunicorn本身运行异常，查看Gunicorn的运行日志排查问题
4. 检查sock文件属性：执行ls -l <你的sock文件路径>，确认文件存在，且Nginx运行用户有读写权限

本地部署优化建议 #

• 单容器场景下用supervisord管理Nginx和Gunicorn两个进程，避免启动顺序问题，同时可以配置进程异常自动重启
• Gunicorn不要绑定0.0.0.0，仅绑定127.0.0.1:8000或者sock文件，避免外部直接访问绕开Nginx
• 容器仅对外暴露80/443端口，不要映射Gunicorn的服务端口
• Nginx配置中单独配置静态资源规则，直接指向Vue构建后的dist目录，不需要转发到Gunicorn，提升访问性能

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