How do I configure buffered NGINX access logs for analysis?

Definition: Buffered NGINX access logging holds request records in memory before writing them to a configured file. The access_log directive sets the destination, format, buffer size and optional flush interval, which controls when aged buffered data is written.

Key facts

• As of 17 October 2026, NGINX's request logging documentation states that either buffer or gzip enables buffering and limits buffer size to the platform's atomic disk-file write size.
• NGINX's rotation instructions specify renaming log files before sending the master process a USR1 signal to reopen them.
• The command-line reference documents nginx -t for checking configuration syntax and opening referenced files.

Which access_log settings enable buffering?

NGINX's access_log reference accepts a fixed file path, a format name, buffer and flush. This illustrative directive combines the buffer size and flush interval shown in its examples, using the predefined combined format:

access_log /spool/logs/nginx-access.log combined buffer=32k flush=5m;

The destination and values are example settings. The combined format includes the request, response status, referrer and user agent. A path containing variables has different constraints: buffered writes do not work, and workers need permission to create files in the log directory. The open_log_file_cache directive caches file descriptors for variable-based paths; its valid setting can allow writes to an old file to continue until the next validity check.

When do buffered records reach the file?

The logging reference lists three write triggers: the next log line does not fit in the buffer, buffered data exceeds the configured flush age, or a worker reopens logs or shuts down. In the example, flush=5m supplies an age-based trigger even when the buffer has room. A buffer-only setting leaves the other documented triggers in control.

For analysis, this means a request record can remain buffered before appearing in the file. The flush interval governs buffered-data age; it is separate from the rotation operation that changes which file receives subsequent records.

How does rotation hand files over for analysis?

NGINX's Controlling nginx describes rotation as renaming the current files and then signaling the master process to reopen logs. After successful reopening, the master asks workers to reopen their files. Workers open the new files and close the old ones immediately, making the old files available for processing such as compression.

The command-line reference provides this reopening command, used after renaming:

nginx -s reopen

The same reference documents reload separately: it reloads configuration, starts workers with the new configuration and gracefully shuts down old workers.

How is the configuration checked before use?

The command-line reference defines these checks:

nginx -t
nginx -T

The first checks syntax and attempts to open referenced files. The second performs the same check and prints configuration files to standard output. NGINX's logging documentation also states that access_log off cancels access logs at the current configuration level, and requests use the location where processing ends, including after an internal redirect.

Related terms

• Server log analysis
• How do I add user agent and response fields to NGINX logs?
• How do I write a separate NGINX access log for selected requests?

FAQ

Can I compress access logs while NGINX writes them?

NGINX's logging reference documents the gzip parameter, which compresses buffered data before writing and requires a build with zlib. The resulting atomic blocks can be read with zcat at any time.

Should I restart NGINX after renaming a log file?

The command-line reference provides nginx -s reopen specifically to reopen log files. The rotation procedure uses reopening after renaming.

Sources

1. NGINX, "Module ngx_http_log_module", undated
2. NGINX, "Controlling nginx", undated
3. NGINX, "Command-line parameters", undated

---

Check how a page reads to answer engines. Open the GEO score analyzer