Practice: DNS, ports, HTTP, and access logs
Goal
Distinguish name resolution, connection establishment, and HTTP responses. Match client results to server evidence.
These exercises document the sessions already covered with your mentor. Repeat them with predictions before commands to check retention.
Run shell commands inside your Debian VM's SSH session unless instructed otherwise. Use your PC's browser for remote requests.
1. Address and port
Confirm the healthy nginx page works on port 80. Inspect listeners with ss -ltn.
If another service uses port 8080, ask your mentor to choose an unused port for the second request.
curl -v --connect-timeout 3 --max-time 5 http://127.0.0.1/
curl -v --connect-timeout 3 --max-time 5 http://127.0.0.1:8080/
ss -ltn
Before each request, predict the address, destination port, and result. Compare the error with the listening sockets.
Repeat from your PC's browser:
http://192.168.20.50/
http://192.168.20.50:8080/
Explain why the PC uses the VM's LAN address instead of loopback. A remote failure may differ from a local failure because filtering can apply.
Completion check: identify the unused port without restarting nginx or changing firewall rules. Explain which request succeeded and why.
2. Name resolution and HTTPS
On the VM, run:
dig +time=2 +tries=1 example.com A
curl -I --connect-timeout 3 --max-time 10 https://example.com
dig +time=2 +tries=1 training.invalid A
curl -I --connect-timeout 3 --max-time 10 https://training.invalid
Identify dig's status, answer addresses, and SERVER line. Explain that the resolver contacted can be a local stub.
The .invalid domain is reserved for invalid names. Normally, its DNS result is NXDOMAIN and curl cannot resolve the destination.
If results differ, investigate the actual output with your mentor. A configured proxy or modified resolver can change the observed behavior.
Completion check: distinguish failure to resolve a name from failure to connect to an address. State HTTPS's usual destination port.
3. HTTP responses
Use -i to include headers with a normal GET response. Uppercase -I instead sends a HEAD request.
curl -i --connect-timeout 3 --max-time 5 http://127.0.0.1/
curl -i --connect-timeout 3 --max-time 5 http://127.0.0.1/this-page-does-not-exist
The default site normally returns 200 for the first request and 404 for the second. Interpret actual results if the site differs.
| Status class | Meaning | Example |
|---|---|---|
| 1xx | Informational response | 100 Continue |
| 2xx | Successful request | 200 OK |
| 3xx | Redirection or related cache handling | 301 Moved Permanently; 304 Not Modified |
| 4xx | Client error response | 403 Forbidden; 404 Not Found |
| 5xx | Server error response | 500 Internal Server Error; 502 Bad Gateway; 503 Service Unavailable |
A 4xx response does not prove the human user caused the problem. Server configuration can also cause these responses.
A 404 is an HTTP response, so an HTTP-speaking endpoint received the request. A connection failure is not an HTTP status.
Plain curl can exit successfully after receiving HTTP 404. Use --fail when a script should treat HTTP error responses as failures.
Completion check: explain why restarting nginx does not create a missing page. Identify what changed between the two URLs.
4. Find your requests in the log
On the VM, inspect the default nginx access log:
sudo tail -n 10 /var/log/nginx/access.log
Find the two request paths and status codes. The access log records requests; the error log contains diagnostic messages.
Follow new entries interactively:
sudo tail -f /var/log/nginx/access.log
From the PC's browser, request http://192.168.20.50/find-my-request. Identify the client address, timestamp, method, path, and status.
The recorded address is the peer visible to nginx. NAT or a proxy can make it differ from your PC's own address.
Request a different path and predict which fields change. Browsers may make extra requests, such as for a favicon.
Repeat the unused-port request. Explain whether nginx on port 80 could have received it. Press Ctrl+C to stop following the log.
No entry alone does not prove a network fault. Logging can be disabled, buffered, or directed to another file.
Completion check: correlate a specific browser request with its log entry. Explain why a 404 is logged but an unused-port connection is not.
Review without hints
For each result, identify the failed or successful stage and propose one useful next check:
- Could not resolve host.
- Connection refused.
- Connection timed out.
- HTTP 404.
- HTTP 200 with an unexpected page.
Record the command, observed result, meaning, and remaining uncertainty. Use your notes before asking for a hint.