Nginx + FastCGI + Django 架构下错误日志在哪里找？

排查顺序：这套架构的错误分布在三层——Nginx 层默认在 /var/log/nginx/error.log（配置与反代问题）；Django 应用层位置由 settings.py 的 LOGGING 配置决定，默认输出受 DEBUG、logger 和 Django 默认配置影响，不能假定都写到 stderr；数据库慢查询另有自己的日志。先看 Nginx 日志判断请求是否到达上游，再看应用日志。

第一层：Nginx 日志

Ubuntu/Debian 与 CentOS 默认位置一致：

• 错误日志：/var/log/nginx/error.log
• 访问日志：/var/log/nginx/access.log

实际路径以配置为准，查 /etc/nginx/nginx.conf 与 /etc/nginx/sites-enabled/ 下的站点配置：

server {
    listen 80;
    server_name example.com;

    error_log /var/log/nginx/example-error.log warn;
    access_log /var/log/nginx/example-access.log;

    location / {
        proxy_pass http://127.0.0.1:8000; # 此处假设后端为 Gunicorn HTTP
        proxy_set_header Host $host;
    }
}

上例是现代 HTTP 上游示意；遗留 FastCGI 必须使用 fastcgi_pass 并补齐应用所需参数，uWSGI 协议则使用 uwsgi_pass。502 可由上游连接失败、提前关闭或无效响应引起；504 是上游超时——这两类问题在 Nginx 日志里定界，再到应用层定位。

第二层：Django 应用日志

Django 默认日志路由随 DEBUG、logger 和邮件设置变化；并非所有错误都只发邮件。可在 settings.py 显式配置输出：

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'class': 'logging.StreamHandler',
            'stream': 'ext://sys.stderr',
        },
    },
    'root': {'handlers': ['file'], 'level': 'WARNING'},
    'loggers': {
        'django': {'handlers': ['file'], 'level': 'INFO', 'propagate': False},
    },
}

上例显式替换 django logger 的处理器；需要管理员邮件时应另行配置。若已按上例输出到 stderr，supervisor 托管看在 supervisord.conf 配的 stderr_logfile；systemd 托管用 journalctl -u django-app；Gunicorn 可用 --error-logfile，uWSGI 则需核对其 logto 等参数，不能混用。标准 RotatingFileHandler 不适合多 worker 直接写同一个轮转文件。

第三层：FastCGI 进程日志

manage.py runfcgi 已从现代 Django 移除；遗留 flup 部署应按实际进程配置排查。现代 Gunicorn/uWSGI 部署要让 Nginx 指令匹配后端协议，Unix socket 只是传输方式，不等于 FastCGI。

多台机器上的错误难以对齐时，可以把 Nginx 与 Django 日志分别通过日志采集器送入观测云，设置来源和服务名。先按同一时间窗查 Nginx 错误中的上游地址，再核对对应 Django 进程的异常堆栈，避免只凭 502 判断应用出错。

常见问题（FAQ）

Q：页面 500 但 Django 日志什么都没有？
A：检查 Django logger、handler、过滤器与实际输出目的地；DEBUG=False 不意味着所有错误都只发邮件。如写文件还需核对目录权限。

Q：fastcgi_pass 报 connect() failed 怎么查？
A：先确认 FastCGI 进程在跑（ss -ltnp | grep 8000），再看 Nginx error.log 的具体报错，多半是进程挂了或端口/socket 不匹配。

Q：能在 Nginx 日志里看到请求耗时吗？
A：在 log_format 里加 $request_time 与 $upstream_response_time，可辅助定位阶段，但两者相减不能直接得到纯网络耗时或确定根因。