Find the configuration file your Nginx instance uses

Start with the running master process, then run configuration checks with the same binary and options. A bare nginx -t tests that command's default configuration; it can point to a different installation from the one serving traffic.

Inspect the master process

ps aux | grep '[n]ginx: master'
systemctl cat nginx

A process might show:

nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf

-c selects a configuration file. Also preserve a custom -p prefix and relevant -g global directives from the service's startup command. Without -c, the binary uses its compiled configuration path; inspect it with:

/usr/sbin/nginx -V 2>&1

Look for --conf-path. Distribution packages, source builds, and containers can coexist with different defaults.

Test that configuration

For the example above:

sudo /usr/sbin/nginx -t -c /etc/nginx/nginx.conf

Successful output identifies the file tested:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

This checks syntax and attempts to open referenced files. It does not interrogate the running master's in-memory configuration.

Inspect the include chain

Use the same binary and startup-path options with -T:

sudo /usr/sbin/nginx -T -c /etc/nginx/nginx.conf | less
sudo /usr/sbin/nginx -T -c /etc/nginx/nginx.conf > full-nginx-config.txt

The output contains the main file and included files with identifying comments. Diagnostics go to standard error. Review the exported file before sharing it because configuration can contain credentials or internal addresses.

A common layout is:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Search the dump for the directive and its surrounding context, then edit the actual included file. A file outside the include chain has no effect.

Confirm the reload

For a service using the example configuration:

sudo /usr/sbin/nginx -t -c /etc/nginx/nginx.conf && sudo systemctl reload nginx
sudo journalctl -u nginx --since '5 minutes ago'

Also check Nginx's error log and make a request that exercises the changed behavior. If a reload fails, existing workers can continue serving the previous configuration. A later successful -T only proves that the current files can be read, not that the failed reload applied them.

FAQ

What if nginx is not on PATH?

Use the binary path from the service or process listing. For a container, run the check inside that container, such as docker exec web nginx -t, and account for its startup options.

Which of several nginx.conf files should I edit?

Use the path selected by the running instance's binary, prefix, and -c option. Do not choose by filename or modification time alone.

Can I recover the last successfully loaded configuration with -T?

No. Keep deployment artifacts or versioned configuration and correlate them with successful reload logs. -T parses the current files on disk.

References: Nginx command-line options, reload behavior.