The article explains how to locate the default Nginx access and error log files, which live in /var/log/nginx by default but may be elsewhere if configured differently. It then walks through real‑time monitoring with sudo tail -f, shows how to stop it, and why catching a 503 or traffic spike early can prevent bigger problems. For targeted investigation the guide demonstrates using grep to pull out specific IPs, URLs, or error patterns, piping results into less for easier reading, and explains how archived logs can be read on the fly with zcat after rotation. Finally it cautions against installing heavy tools like multitail or lnav when simple utilities are sufficient, ending with a real‑world anecdote that illustrates how a single log line uncovered a 500 error loop.

How to View Nginx Logs in the Linux Command Terminal

If you’ve ever had a weird 404 pop up on your site and the only clue you have is the log file, this guide will get you into the logs fast and keep you from chasing ghosts.

Where Are the Log Files?

Nginx keeps two main files by default:

• /var/log/nginx/access.log – every request that hits a server block
• /var/log/nginx/error.log – anything that goes wrong during processing

You can confirm their location with ls -l /var/log/nginx/. If your setup is custom, look for the access_log and error_log directives in your nginx.conf or any file under /etc/nginx/sites-available.

Watch a Log Stream In Real Time

The most common way to keep an eye on traffic or errors as they happen is:

sudo tail -f /var/log/nginx/access.log

Adding the -f flag tells tail to “follow” the file, printing new lines as they’re written. Why bother with this? Because you’ll see a 503 or a suspicious burst of traffic before anyone notices in your dashboard.

If you want to stop watching, press Ctrl‑C.

Search for Something Specific

Got an IP that keeps spamming your site? Use grep:

sudo grep "192.168.1.42" /var/log/nginx/access.log

The pattern can be a full URL path or even a regex like /api/v[0-9]+. If you’re hunting for errors, swap the file and add |less to scroll:

sudo grep "error" /var/log/nginx/error.log | less

Why run grep? Because logs are noisy. Filtering gives you context without scrolling through 10 K lines.

Look at Archived Logs

Nginx rotates logs with logrotate, often compressing older files into names like access.log.1.gz. To read them:

zcat /var/log/nginx/access.log.1.gz | grep "GET" | less

zcat decompresses on the fly, and you can pipe it to any tool you want. This is handy when you need a historical view of traffic spikes that happened last month.

Avoid Over‑Verbose Tools

Some folks install multitail or lnav because they look cool. They’re fine if you’re monitoring dozens of services simultaneously, but for the occasional Nginx check, plain tail, grep, and less are lighter and less distracting. No point in installing a full‑blown log viewer just to read a handful of lines.

A Real‑World Scenario

I once had a client whose site was throwing 500s after a minor config change. The error file was silent, but the access log showed an endless loop of GET /favicon.ico requests from a single IP. That single line in the log led to disabling that user’s account and restoring stability in minutes.

That’s it—no fancy GUI, just the terminal you know. Open your logs, filter what matters, and keep those servers humming.