How to Analyze Nginx Access Logs (Step-by-Step)

This walkthrough uses standard command-line tools that come with any Linux box, so you can follow along over SSH without installing anything. At the end, when the file gets too big to eyeball, there is a faster option.

Step 1: find the log

On most installs the access log sits at /var/log/nginx/access.log. Older rotated logs are alongside it, gzipped, named access.log.1, access.log.2.gz, and so on. If you are not sure where yours is, the config will tell you:

grep -r access_log /etc/nginx/

To read a compressed rotated log without unpacking it first, use zcat in place of cat. And before you dig in, get a sense of scale: wc -l access.log tells you how many requests you are dealing with.

Step 2: know the fields

Every command below slices the line by position, so you need to know what sits where. The combined format puts the client IP first and the request, status, and byte count in fixed spots after that. If any of this is unfamiliar, read the log format guide first, it makes the awk commands obvious instead of magic.

Step 3: who is hitting you

Start with the top client IPs. This surfaces both your heaviest real users and any single source flooding you:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

The left column is request count, the right is the IP. One address with ten times the traffic of the next is worth a closer look. It could be a CDN, or it could be a scraper. The bad bot guide covers how to decide which.

Step 4: what are they asking for

Next, the most requested URLs. This is your real content popularity, and it also exposes probing:

awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -25

Field seven is the request path. If your top pages make sense, good. If /wp-login.php is in the top ten on a site that does not run WordPress, you are being scanned.

Step 5: what is breaking

Now the status codes. This is the health check:

awk '{print $9}' access.log | sort | uniq -c | sort -rn

Field nine is the status. You want mostly 200 and 304. To see exactly which URLs are throwing errors, filter to the 5xx range and count the paths:

awk '$9 ~ /^5/ {print $7}' access.log | sort | uniq -c | sort -rn | head

Swap /^5/ for /^404/ to hunt broken links and scanner targets. The status code reference explains what each number is telling you, including the nginx-specific 499 and 444.

Step 6: bandwidth and timing

If you are chasing a bandwidth bill or a slow site, the byte count and timing fields are where to look. Total bytes sent across the whole log:

awk '{sum += $10} END {printf "%.2f GB\n", sum/1024/1024/1024}' access.log

Field ten is the response body size in the combined format. If you added $request_time to a custom format, you can sort by it to find your slowest endpoints, which is usually more useful than raw byte counts when the site feels sluggish.

Step 7: narrow to a window

When something happened at a specific time, stop looking at the whole file. Pull just the minute or hour that matters with grep on the timestamp:

grep "12/Sep/2026:13:5" access.log | awk '{print $9}' | sort | uniq -c

That shows the status mix during a ten-minute stretch, which is how you confirm whether an outage lines up with a deploy or a traffic spike.

When the command line runs out

This approach works and costs nothing. It also gets tedious once the file passes a few hundred thousand lines, or when you want to cross-reference IPs against URLs against status codes against time, all at once, instead of one awk pipe at a time. That is where a real analyzer earns its keep.

The tool on the home page does every step above in one pass and connects them, so you can click from a suspicious IP to the exact requests it made. Your log stays on your machine the whole time, because the parsing happens in the browser and nothing gets uploaded.