Read the right logs

Debug one request through the layers instead of dumping every log on the server.

Start with a request that records timing and connection details:

curl --verbose https://notes.example.com/health

The output tells you whether DNS resolved, TLS completed, and HTTP returned a status. Note the exact time and status before moving to the server.

Nginx access and error logs normally live under /var/log/nginx. Application output managed by systemd appears in the journal. Reproduce the request while watching focused sources:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log
sudo journalctl -u notes-app --since "10 minutes ago" -f

Use separate terminals so the events remain readable. A request in the access log proves it reached Nginx. An Nginx error such as connect() failed points toward the local upstream. An application journal entry proves the request reached the service.

If nothing appears, work outward:

dig +short notes.example.com
sudo ufw status
systemctl is-active nginx notes-app
sudo ss -lntp | grep -E ':80|:443|:3000'

This separates DNS, firewall, service, and listening-port failures.

A common mistake is reading old messages from a previous failure. Filter by the reproduction time and current boot:

sudo journalctl -u notes-app -b --since "2026-07-30 12:00"

Replace the time with the real event. Another mistake is restarting before collecting evidence. A restart can remove the failing state and make the cause harder to find.

Logs are sensitive data. Do not record passwords, authorization headers, session cookies, complete request bodies, or environment variables. Redact secrets before sharing a useful excerpt.

Your action is to request a missing path such as /does-not-exist and trace the resulting status through curl, the Nginx access log, and the application journal. Write down the last layer that observed it.