# Exercise 2: Diagnose "Every Request Comes From the Same IP"

## Scenario

The API team at `northwind.dev` just shipped a per-user rate limiter and an abuse-detection system, both keyed on client IP address. Within an hour of deploying behind the company's new nginx reverse proxy, two things go wrong:

- **Incident A**: the rate limiter locks out the *entire API* for all external users simultaneously, far sooner than its configured "100 requests/minute per IP" limit should allow for any real traffic pattern. Debug logging shows every single incoming request, from every real-world user, is being logged with the exact same source IP: `10.0.0.1`.
- **Incident B**: the abuse-detection system flags a legitimate power-user's account for "impossible travel" — their requests appear to originate from `10.0.0.1` (an internal, private-range address) one minute and then a real public IP the next, even though the user insists they haven't changed networks or devices.

Investigating, you find:

- `10.0.0.1` is the internal IP of the nginx reverse proxy box itself.
- The proxy's config has a `location /api/` block that does `proxy_pass http://api_backend;` with no other `proxy_set_header` directives at all.
- One API endpoint, used only by the internal admin dashboard (which talks to the backend directly, bypassing the proxy entirely, over the private network), is the one occasionally producing a real public IP in Incident B's logs.

## Deliverables

Produce all of the following, in this file, below this line:

1. **A root-cause explanation for Incident A** — using theory section 3, explain exactly why every request's logged IP is `10.0.0.1`, and why this has nothing to do with the rate limiter's threshold being misconfigured.
2. **A root-cause explanation for Incident B** — explain why the admin dashboard's direct, proxy-bypassing traffic produces a *different* IP pattern than the proxied traffic, and why this is actually consistent behavior once Incident A's cause is understood, not a second unrelated bug.
3. **The exact fix**, as a diff-style description of what to add to the `/api/` `location` block (naming specific headers from theory section 4) and what the backend application code must be changed to read instead of the raw connection's source address.
4. **A one-paragraph note on the security implication of the fix** — once the backend starts trusting a forwarded-for header, what new risk does that introduce (referencing theory section 5), and what must the proxy itself guarantee for the fix to be safe rather than trading one bug for a spoofing vulnerability?

## Constraints

- Treat Incidents A and B as having the same underlying root cause, not two separate bugs — your answer to Deliverable 2 must derive it from Deliverable 1's explanation rather than inventing an unrelated cause.
- The fix in Deliverable 3 must not involve bypassing the proxy for regular API traffic (that would defeat TLS termination and load balancing) — the proxy must stay in the path.