遇到 502 错误，最先要做的不是改 Nginx 配置，而是确认后端服务（如 Gunicorn 或 uWSGI）是否正常运行且能被 Nginx 访问。

命令速用版

systemctl status gunicorn
systemctl status nginx
tail -f /var/log/nginx/error.log
curl -I http://127.0.0.1:8000

为什么会这样

Nginx 在这里扮演反向代理的角色，它负责接收用户请求并转发给后端的 Django 应用服务。502 Bad Gateway 意味着 Nginx 本身是好的，但它试图联系后端服务时，对方没有响应、拒绝连接或提前断开了。

这种情况多半不是 Django 代码逻辑错误，而是部署层面的通信问题。比如后端进程挂了、监听端口不对、防火墙拦截、或者 Socket 文件权限不足。

分步处理

1. 检查后端服务状态

确认 Gunicorn 或 uWSGI 是否在运行。如果使用 systemd 管理，执行 status 命令。如果进程不存在，尝试手动启动看是否有报错。

systemctl status gunicorn
journalctl -u gunicorn -n 50
# 手动启动示例（测试用）
gunicorn `--bind` unix:/run/gunicorn.sock myproject.wsgi:application

2. 查看 Nginx 错误日志

这是最直接的线索。日志通常会写明是 connect() failed 还是 upstream timed out。

tail -n 50 /var/log/nginx/error.log

3. 检查 Nginx 配置

确保 proxy_pass 指向正确的 socket 或端口，并设置合理的超时时间。修改配置后务必重载 Nginx。

server {
    listen 80;
    location / {
        proxy_pass http://unix:/run/gunicorn.sock;
        proxy_read_timeout 60s;
        proxy_connect_timeout 60s;
    }
}

systemctl reload nginx

4. 检查 Socket 或端口配置及权限

如果 Nginx 配置的是 unix socket，确保 socket 文件存在且 Nginx 用户有读写权限。避免使用 chmod 777，应指定用户组。

# 假设 Nginx 运行用户为 www-data
chown www-data:www-data /run/gunicorn.sock
chmod 660 /run/gunicorn.sock

如果配置的是 TCP 端口，确保后端监听的是 127.0.0.1 而不是仅限 localhost 或其他 IP。

5. 检查 Django 配置

检查 settings.py 中的 ALLOWED_HOSTS，确保包含当前请求的域名或 IP，否则 Django 会拒绝请求导致 502 或 400。

ALLOWED_HOSTS = ['your_domain.com', '127.0.0.1', 'localhost']

怎么验证是否生效

重启 Nginx 和后端服务后，使用 curl 命令测试。如果返回 200 OK 或 Django 正常页面，说明链路打通。

curl -I http://你的域名或 IP

同时观察 Nginx 访问日志，确认状态码不再是 502。

tail -f /var/log/nginx/access.log

常见坑

1. 虚拟环境未激活

后端服务启动时如果没有激活正确的 Python 虚拟环境，可能找不到 Django 模块导致进程启动失败。

2. 权限问题

使用 socket 文件时，Nginx 运行用户（通常是 www-data）必须对该 socket 文件有读写权限，否则会被拒绝连接。

3. SELinux 或防火墙

在 CentOS 等系统上，SELinux 可能阻止 Nginx 访问网络或 socket。防火墙如果拦截了本地回环端口也可能导致问题。

4. 绑定地址错误

后端服务如果只监听了 IPv6 或特定 IP，而 Nginx 配置的是 127.0.0.1，会导致连接失败。