Find logs for a Django application behind Nginx

Look at three separate sources: Nginx's proxy errors, the application server's process output, and Django's configured application logs. Their destinations depend on configuration; a missing file does not mean the layer produced no error.

FastCGI is a legacy Django deployment pattern. Django removed its built-in runfcgi support in 1.9. For current applications, identify the actual WSGI or ASGI server and use the protocol it serves rather than copying an old FastCGI block.

Start at Nginx

Many packages use /var/log/nginx/error.log and /var/log/nginx/access.log, but inspect error_log and access_log in the correct instance's configuration. Per-site logging can be useful:

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;
        proxy_set_header Host $host;
    }
}

This example assumes an HTTP-speaking backend such as a suitably configured Gunicorn service. A real FastCGI backend needs fastcgi_pass and its required parameters; a uwsgi-protocol socket needs uwsgi_pass. A socket path alone does not identify the protocol.

A 502 can indicate connection failure, premature closure, or an invalid upstream response. A 504 indicates a gateway timeout. Read the detailed error and upstream address before deciding whether Django handled the request.

Configure an explicit Django logging destination

For process-managed or containerized applications, a console handler gives the supervisor a clear stream to collect:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "console": {"class": "logging.StreamHandler"},
    },
    "root": {"handlers": ["console"], "level": "WARNING"},
    "loggers": {
        "django": {
            "handlers": ["console"],
            "level": "INFO",
            "propagate": False,
        },
    },
}

This deliberately replaces the django logger's handlers. If you need administrator error email, configure that handler explicitly as well. Django's defaults depend on DEBUG, logger configuration, and email settings; “unconfigured logs always go to stderr” and “all errors only go to email” are both too broad.

If you choose a file handler, ensure the application user can write its directory. Standard rotating file handlers are not a general safe shared rotation mechanism for multiple worker processes; prefer centralized process output or a rotation design suitable for the deployment.

Inspect the application-server process

For systemd, use journalctl -u django-app; with Supervisor, inspect the configured stdout/stderr log destinations; in containers, inspect the retained container logs. Gunicorn and uWSGI have different logging options—do not assume a shared --error-logfile flag. In a legacy FastCGI deployment, inspect the launcher and FastCGI server's own settings.

Collect Nginx and application logs as separate sources with service and instance identifiers. DataKit file-log collection can centralize file destinations; correlate timestamps and request IDs rather than treating 502 as a Django exception.

FAQ

Why does a 500 have no Django log entry?

Verify the request reached Django, the relevant logger is enabled, handler levels and filters allow it, and the destination works. A framework error, startup failure, and application-generated 500 can take different logging paths.

What should I check for connect() failed?

Check the backend process, listener, socket permissions, protocol, and address from Nginx's network context. A service listening only on another container's loopback is not reachable through your own loopback.

Can timing fields separate application and network latency?

Add $request_time and $upstream_response_time to the format, but do not interpret their difference as a precise network measurement. Uploads, buffering, retries, and response delivery also contribute.

References: Django logging, FastCGI removal in Django 1.9.