How to locate Nginx access and error log files

Locating Nginx access and error logs shortens outage triage, supports incident response, and provides a reliable request trail for security controls like rate limiting and allow/deny rules.

The access_log directive records request lines into a configured destination, while error_log captures runtime diagnostics such as upstream failures, TLS issues, and configuration warnings. Both directives can be set globally under http or overridden per server and location blocks, and included snippets (for example from /etc/nginx/conf.d or /etc/nginx/sites-enabled) become part of the effective configuration evaluated at runtime.

Some deployments disable access logging with access_log off, send logs to syslog (syslog:...), or run in containers where logs are written to /dev/stdout or /dev/stderr instead of regular files. Log content can include sensitive URLs, query strings, and client IP addresses, so permissions and log rotation policies should be confirmed before sharing excerpts or widening access.

1. Search the effective Nginx configuration for access_log and error_log directives across included files.

   $ sudo nginx -T 2>&1 | grep --line-number --extended-regexp '^[[:space:]]*(access_log|error_log)[[:space:]]' | head --lines 20
   8:error_log /var/log/nginx/error.log;
   237:access_log /var/log/nginx/access.log main_perf buffer=64k flush=1s if=$log_request;

   Nginx writes the configuration dump to stderr, so 2>&1 is required when piping; if no matches appear, run sudo nginx -T without filtering to confirm the dump succeeded.

2. Show nearby server_name and listen lines to map each log directive to the relevant virtual host.

   $ sudo nginx -T 2>&1 | grep --line-number --extended-regexp --context 2 '^[[:space:]]*(server_name|listen|access_log|error_log)[[:space:]]' | head --lines 60
   6-worker_rlimit_nofile 1048576;
   7-pid /run/nginx.pid;
   8:error_log /var/log/nginx/error.log;
   9-include /etc/nginx/modules-enabled/*.conf;
   10-
   --
   235-                     '$status $body_bytes_sent $request_time';
   236-
   237:access_log /var/log/nginx/access.log main_perf buffer=64k flush=1s if=$log_request;
   238-
   239-open_log_file_cache max=1000 inactive=20s valid=1m min_uses=2;
   --
   244-# configuration file /etc/nginx/conf.d/redirect-http.conf:
   245-server {
   246:    listen 80;
   247:    server_name example.com www.example.com;
   248-
   249-    return 301 https://$host$request_uri;
   --
   252-# configuration file /etc/nginx/conf.d/ssl-http2.conf:
   253-server {
   254:    listen 443 ssl http2;
   255:    server_name example.com;
   256-
   257-    root /var/www/html;
   --
   283-# configuration file /etc/nginx/sites-enabled/default:
   284-server {
   285:    listen 80 default_server;
   286:    listen [::]:80 default_server;
   287-
   288:    server_name _;
   289-
   290-    client_max_body_size 10m;

   Per-site directives override the global defaults, and the closest enclosing directive is typically the effective destination.

3. Extract the unique log destinations currently configured for Nginx.

   $ sudo nginx -T 2>&1 | awk '$1 == "access_log" || $1 == "error_log" { dest=$2; sub(/;$/, "", dest); if ($1 == "access_log" && dest == "off") next; print dest }' | sort --unique
   /var/log/nginx/access.log
   /var/log/nginx/error.log

   Destinations starting with / are on-disk paths, while syslog:... and stderr are not regular files.

4. Confirm the on-disk log files exist with expected ownership and permissions.

   $ sudo nginx -T 2>&1 | awk '$1 == "access_log" || $1 == "error_log" { dest=$2; sub(/;$/, "", dest); if ($1 == "access_log" && dest == "off") next; print dest }' | grep --extended-regexp '^/' | sort --unique | xargs --no-run-if-empty sudo ls -la
   -rw-r----- 1 www-data adm 750558025 Dec 30 00:32 /var/log/nginx/access.log
   -rw-r----- 1 www-data adm       484 Dec 30 00:29 /var/log/nginx/error.log

   Rotated logs are commonly present as access.log.1 or compressed as access.log.2.gz.

5. Generate a test request to create a fresh access-log entry.

   $ curl --silent --output /dev/null --write-out '%{http_code}\n' http://127.0.0.1/__log_test__
   404

   Replace the URL with the scheme/host/port routed to Nginx when 127.0.0.1 is not a valid listener.

6. Confirm the test request appears in the access log destination.

   $ sudo tail --lines 200 /var/log/nginx/access.log | grep --fixed-strings "__log_test__" | tail --lines 1
   127.0.0.1 - [30/Dec/2025:00:32:01 +0000] "GET /__log_test__ HTTP/1.1" 404 335 0.001

   Replace /var/log/nginx/access.log with the access_log path identified above when different.

7. Tail the error log destination to confirm where runtime failures are recorded.

   $ sudo tail --lines 50 /var/log/nginx/error.log
   2025/12/30 00:27:10 [error] 5922#5922: *10932 client intended to send too large body: 11534336 bytes, client: 127.0.0.1, server: _, request: "POST / HTTP/1.1", host: "127.0.0.1"
   2025/12/30 00:29:29 [error] 6074#6074: *10940 access forbidden by rule, client: 127.0.0.2, server: _, request: "GET /admin/ HTTP/1.1", host: "127.0.0.1"
   2025/12/30 00:29:38 [error] 6079#6079: *10941 access forbidden by rule, client: 127.0.0.2, server: _, request: "GET /admin/ HTTP/1.1", host: "127.0.0.1"

   Replace /var/log/nginx/error.log with the error_log destination when different.

8. Query the systemd journal when error_log points to stderr or syslog:....

   $ sudo journalctl --unit nginx --no-pager --lines 50
   Dec 30 00:20:18 host nginx[5139]: 2025/12/30 00:20:18 [notice] 5139#5139: signal process started
   Dec 30 00:20:18 host systemd[1]: Reloaded nginx.service - A high performance web server and a reverse proxy server.
   Dec 30 00:21:17 host systemd[1]: Reloading nginx.service - A high performance web server and a reverse proxy server...
   Dec 30 00:21:17 host nginx[5179]: 2025/12/30 00:21:17 [notice] 5179#5179: signal process started
   Dec 30 00:21:17 host systemd[1]: Reloaded nginx.service - A high performance web server and a reverse proxy server.