What I Wanted to Do
I wanted to verify that nginx was working correctly and find out why pages weren’t loading despite getting requests. Tracking down the log files helped me identify the root cause quickly.
Log File Locations
nginx logs are typically stored here:
/var/log/nginx/access.log # Access log
/var/log/nginx/error.log # Error log
You can also confirm the paths from the config file:
grep log /etc/nginx/nginx.conf
Checking the Access Log
Monitor in real time
tail -f /var/log/nginx/access.log
Show the last 100 lines
tail -n 100 /var/log/nginx/access.log
Filter by a specific IP address
grep "192.168.1.1" /var/log/nginx/access.log
Extract 404 errors only
grep " 404 " /var/log/nginx/access.log
Count the most-accessed URLs
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
Checking the Error Log
Monitor errors in real time
tail -f /var/log/nginx/error.log
Show only error-level entries
grep "\[error\]" /var/log/nginx/error.log
Log severity levels:
| Level | Meaning |
|---|---|
| notice | Normal operation notices |
| warn | Warnings (non-critical) |
| error | Errors (needs attention) |
| crit | Critical errors |
Reading the Access Log Format
The default access log looks like this:
192.168.1.1 - - [28/May/2026:10:00:00 +0900] "GET /index.html HTTP/1.1" 200 1234 "-" "Mozilla/5.0..."
Fields from left to right:
- Client IP address
- Remote user (usually
-) - Authenticated user (usually
-) - Request timestamp
- Request line
- HTTP status code
- Response size in bytes
- Referer
- User-Agent
Checking Log Rotation
ls -la /var/log/nginx/
Old logs are kept as access.log.1 or compressed as access.log.2.gz.
logrotate is usually configured by default with nginx.
Common Pitfalls
- If the log file is empty, nginx may not be running or the path may be wrong
- Always check
systemctl status nginxfirst — it saves time before digging into logs - Add
sudoif you get aPermission deniederror reading the log files - On high-traffic servers, always use
tail -nto limit output or the terminal can freeze connect() failedin the error log usually means the backend behind a reverse proxy is down
Related Articles
- nginx Basic Configuration File Guide
- nginx 502 Bad Gateway: Causes and How to Fix It
- nginx Reverse Proxy Setup: Expose a Node.js App on Port 80/443
- Monitor Linux Logs in Real Time with tail -f
- How to Search Files with grep and find on Linux
Recommended Cloud Hosting
Looking for reliable cloud infrastructure? Check out these developer-friendly services.
- Cherry Servers - High-performance VPS and dedicated servers
- Cloudways - Managed cloud hosting for developers