从AWS备份恢复EC2实例后出现nginx 502 Bad Gateway错误

1. 先抓Nginx错误日志的核心信息 #

Nginx错误日志默认路径一般是/var/log/nginx/error.log，如果是站点单独配置了日志，就找对应文件。重点盯这几类报错：

• connect() failed (111: Connection refused)：Nginx连不上Gunicorn，要么Gunicorn没启动，要么监听的端口/socket和Nginx配置不匹配
• permission denied while connecting to upstream：Nginx进程没有权限访问Gunicorn的socket文件（比如socket文件属主是root，Nginx用www-data用户跑）
• upstream prematurely closed connection while reading response header from upstream：Gunicorn在处理登录请求时崩溃了，大概率是Django代码层面的问题
• no live upstreams while connecting to upstream：Nginx配置里的上游服务（Gunicorn）完全不可用

2. 确认Gunicorn的运行状态 #

• 先查Gunicorn是否在运行：ps aux | grep gunicorn，或者用systemd管理的话systemctl status gunicorn
• 如果没运行，尝试启动：systemctl start gunicorn，启动失败就去看Gunicorn的日志（通常在/var/log/gunicorn/或者项目自定义的日志目录），里面会有启动失败的具体原因（比如端口被占、配置文件错）
• 如果Gunicorn在运行，核对它的监听地址：比如Gunicorn启动时用了--bind 127.0.0.1:8000，那Nginx配置里的proxy_pass必须是http://127.0.0.1:8000；如果用unix socket，要确认socket文件路径和权限都匹配Nginx的配置

3. 绕过Nginx直接测试Gunicorn #

用curl直接访问Gunicorn的服务，比如：curl http://127.0.0.1:8000/login（替换成你的登录页面路径）

• 如果返回500 Internal Server Error，说明问题出在Django这边：去看Django的日志（查项目settings.py里的LOGGING配置找日志路径），重点看登录视图的报错——比如数据库连接失败（备份的数据库是否正常恢复？）、依赖包缺失（备份没包含新安装的包？）、缓存配置错误
• 如果Gunicorn能返回正常的登录页面HTML，那问题肯定在Nginx的配置：检查登录路径的location规则是否正确，反向代理的proxy_set_header是否配置了必要的头（比如Host、X-Real-IP），有没有重写规则导致请求异常

4. 检查备份后的权限与完整性 #

• 静态文件/媒体文件权限：Nginx需要读取静态文件，确保/static/目录的属主是www-data（或Nginx运行用户），权限至少是755
• 数据库完整性：进入Django shellpython manage.py shell，执行from django.contrib.auth.models import User; User.objects.first()，看是否能正常查询用户——如果报错，说明数据库恢复有问题，或者数据库连接配置错误（比如settings.py里的数据库密码、地址不对）
• 虚拟环境依赖：如果备份没包含虚拟环境，重新安装依赖：pip install -r requirements.txt，避免因缺失包导致Gunicorn处理请求崩溃

5. 用Nginx访问日志辅助定位 #

查看/var/log/nginx/access.log，找到登录请求的记录，确认请求的URL、HTTP方法、状态码，看是否有重定向（301/302）后触发的502，或者请求没匹配到正确的location规则

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