How to Analyze nginx Access Logs for Security Threats

What’s in a combined access log line

A standard nginx/Apache combined log line packs the client IP, timestamp, HTTP method and path, status code, response size, referer, and user-agent into one line:

203.0.113.7 - - [16/Jun/2026:03:00:00 +0000] "POST /api/v1/login HTTP/1.1" 401 287 "-" "python-requests/2.31"

Every field matters for security analysis, but none of them are dangerous in isolation — 401 happens constantly for legitimate reasons, and python-requests is a completely normal user-agent for a developer’s integration test. The signal is in the combination and the volume, not any single field.

What to look at first

1. Status code distribution per IP. A normal user produces a healthy mix of 200s with occasional 404s. A scanner produces almost all 404s with the rare 200 standing out. A credential-stuffing bot produces a wall of 401s, sometimes ending in a 200.
2. Request rate and timing variance. Humans are irregular. Scripts are suspiciously regular, or suspiciously fast.
3. User-agent strings. Not as a blocklist — context is everything. curl hitting your public status page is nothing; curl hitting /api/v1/admin/users is a different story entirely.
4. Path sensitivity. Know which of your endpoints are sensitive (auth, admin, data export) before you start reading logs, so you’re not treating every 404 on a typo’d marketing URL with the same urgency as a probe against /api/v1/admin.
5. Referer and origin consistency. Legitimate browser traffic almost always carries a referer for non-entry-point pages; most scripted attack traffic doesn’t bother.

Common patterns and what they mean

Pattern	Likely meaning
Many 401s, one 200, same path	Credential stuffing / brute force
Many distinct paths, mostly 404, one 200	Reconnaissance — they found something
UNION SELECT / ' OR 1=1 in query string	SQL injection attempt
Very high request rate, narrow path set	API scraping
200 responses with abnormally large size	Possible data exfiltration in progress

Where manual log review breaks down

Reading nginx logs line by line works for one suspicious request. It does not work for correlating thousands of lines across multiple IPs, cross-referencing source IPs against current threat intelligence, or scoring which of fifty simultaneous anomalies is actually the one worth an analyst’s attention first. That correlation step — not the log format itself — is the actual bottleneck in most manual log review processes.

LogTriage parses nginx logs automatically, enriches every IP against live threat intelligence (AbuseIPDB, OTX, GreyNoise, ThreatFox), classifies user-agents and path sensitivity in context, and produces a single risk-ranked report instead of a wall of raw lines.