DevOps Foundations · Module 2: Networking, DNS, HTTP and TLS · Lab
Find the 502/503 Cause on a Proxy to Upstream Link
45 min hands-on · Core
Local Linux shell; any two-process setup where one HTTP server proxies to another (nginx, caddy, or a second python server acting as proxy).
Two ways to do this lab: in your browser on Killercoda (free, no install), or on your own machine as a local guide. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.
Objectives
- Produce a 502 and a 503 on demand and tell them apart from logs
- Read both the proxy log and the upstream log with matched timestamps
- Fix the upstream condition without touching the proxy
Step 1
Build the pair
Run an upstream app on 127.0.0.1:18081 and a proxy in front on :18080 forwarding to it. Confirm 200s end to end, and note both log locations.
Step 2
Break it twice, read both sides
First stop the upstream and record the proxy status and time-to-answer (expect fast 502). Then restart it in a mode that answers 503 or hangs past the proxy timeout (expect 503 or slow 504). Quote one proxy log line and one upstream log line per case with timestamps.
Step 3
Fix upstream only
Restore the healthy upstream, confirm 200s, and show with ss -tlnp that exactly one listener holds each port. The proxy configuration stays untouched throughout.
How to confirm it worked
- The 502 case shows a fast proxy answer with no matching upstream work
- The 503/slow case shows matched timestamps on both sides
- Exactly one listener per port is shown after the fix
- No proxy configuration was changed at any point