502错误是Nginx无法从上游WSGI服务器（如gunicorn）获取响应，需优先检查Nginx错误日志、上游进程状态、端口/socket监听、权限配置及超时设置，而非直接排查Django代码。
确认502是Nginx转发失败，不是Django崩溃
502 Bad Gateway本质是Nginx无法从上游（比如 gunicorn 或 uWSGI）收到有效响应。它不等于Django报错，而是Nginx“喊不到人”。先别急着翻Django日志，先看Nginx错误日志：/var/log/nginx/error.log，重点搜 connect() failed、Connection refused、timeout 这几类关键词。
常见现象包括：
- Nginx日志里反复出现
connect() failed (111: Connection refused)→ 上游进程根本没在监听 - 出现
upstream timed out (110: Connection timed out)→ Django或WSGI服务器卡住/启动慢/处理太耗时 - 没有Django访问日志，但Nginx access日志里有502 → 请求压根没进Django
检查gunicorn/uWSGI是否真在运行且监听正确地址
Django本身不直接响应HTTP请求，必须靠WSGI服务器中转。如果用的是 gunicorn，执行：ps aux | grep gunicorn 看进程是否存在；再用 netstat -tuln | grep :8000（假设你配的是 127.0.0.1:8000）确认端口是否被监听。
容易踩的坑：
立即学习“Python免费学习笔记（深入）”；
-
gunicorn启动命令里用了--bind 0.0.0.0:8000，但Nginx配置里却连127.0.0.1:8000→ 没问题；但如果绑的是--bind /tmp/gunicorn.sock，Nginx就必须用unix:/tmp/gunicorn.sock，不能写成127.0.0.1:8000 - 用户权限问题：Nginx worker进程（通常是
www-data）无法读取.sock文件 → 检查文件属主和权限，加chmod 664 /tmp/gunicorn.sock和chown www-data:www-data /tmp/gunicorn.sock - gunicorn启动后立刻退出 → 查
gunicorn的stdout/stderr输出（比如重定向到文件），常见原因是Djangosettings.py导入失败、SECRET_KEY未设置、数据库连接参数错误
核对Nginx upstream配置与Django服务的实际通信方式
Nginx配置里 upstream 块必须和WSGI服务器实际暴露的地址完全一致。例如：
upstream django_app {
server 127.0.0.1:8000; # 对应 gunicorn --bind 127.0.0.1:8000
# 或
# server unix:/tmp/gunicorn.sock; # 对应 gunicorn --bind unix:/tmp/gunicorn.sock
}
关键点：
- 不要混用：TCP端口和Unix socket不能交叉配置
- 如果用socket，Nginx配置里
proxy_pass必须写完整路径，且确保Nginx能访问该路径（SELinux或AppArmor可能拦截） -
proxy_read_timeout默认60秒，如果Django视图要执行长任务（如导出大Excel），必须调大，否则Nginx会在超时后主动断开并返回502 - 加
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;，否则Django的request.get_host()可能拿不到真实域名
验证Django能否独立响应，绕过Nginx直连WSGI服务器
这是最直接的隔离手段：停掉Nginx，用 curl http://127.0.0.1:8000/health/（假设有健康检查接口）或 curl -v http://127.0.0.1:8000 直连gunicorn。如果返回200，说明Django+WSGI工作正常，问题100%出在Nginx配置或网络链路；如果也失败，说明WSGI服务本身异常，此时看gunicorn日志或用 python manage.py runserver 临时验证Django基础功能。
注意：
-
runserver是开发服务器，不能替代gunicorn/uWSGI做生产测试，但它能快速验证Django设置、路由、数据库连接是否OK - 如果直连gunicorn成功，但Nginx仍502，优先怀疑防火墙（
ufw）、SELinux、或Nginx用户无权访问socket文件——这些比代码逻辑更常导致502
真正麻烦的502往往卡在权限、路径、超时这三个地方，而不是Python代码写错了。
