In nginx, inside `location /api/ { ... }`, what is the difference between `proxy_pass http://backend;` and `proxy_pass http://backend/;`, and what URI does the upstream receive in each case?

## What `proxy_pass` actually decides When nginx proxies a request it has to construct the request line it will send upstream. `proxy_pass` controls that, and its behaviour splits on one question: **does the value contain a URI component after the host, port, or upstream group name?** - **No URI** — `proxy_pass http://backend;` or `proxy_pass http://10.0.0.11:8080;`. Nginx sends the request URI as it stands, including the part that matched the location. - **A URI is present** — `proxy_pass http://backend/;`, `.../v2/`, `.../app`. Nginx takes the portion of the normalized request URI that matched the location prefix, removes it, and prepends the URI written in the directive. A lone `/` is a URI. That is the whole trick, and it is why the trailing slash is never cosmetic. ## Worked example ```nginx upstream backend { server 10.0.0.11:8080; } server { location /api/ { proxy_pass http://backend; # GET /api/users -> GET /api/users } location /app/ { proxy_pass http://backend/; # GET /app/users -> GET /users } location /old/ { proxy_pass http://backend/v2/; # GET /old/users -> GET /v2/users } } ``` The practical guidance is to keep the slashes symmetric: if the `location` ends in `/`, either give `proxy_pass` no URI at all or give it a URI that also ends in `/`. Mismatched slashes — `location /api` against `proxy_pass http://backend/` — produce URIs that look wrong at the upstream and are painful to reason about, so avoid the shape rather than memorising its output. ## Diagnosing it The failure is one-sided: the proxy is healthy, the upstream is healthy, and every response is a 404 or a redirect loop. Read the upstream's own access log, not nginx's — nginx logs `$request` (what the client sent), while the upstream logs what it actually received. `$uri` and `$request_uri` in an nginx log format make the difference visible from the proxy side too: `$request_uri` is the original, unmodified URI, `$uri` is the current normalized one after any rewrites. ## Where the URI form is forbidden Nginx can only do prefix replacement when it knows what matched. It does not in these cases, and refuses to start: - `location ~ ^/api/` — a regex location. - Named locations, `@fallback`. - Inside `if` or `limit_except`. In all of them `proxy_pass` must be written without a URI, and you shape the URI yourself with `rewrite`: ```nginx location ~ ^/old/(.*)$ { rewrite ^/old/(.*)$ /v2/$1 break; proxy_pass http://backend; } ``` The `break` flag stops rewrite processing and keeps the request in this location; the rewritten URI is then what `proxy_pass` sends. Adding a URI to `proxy_pass` here would be both illegal and redundant. ## The variable form is a third behaviour ```nginx proxy_pass http://$upstream_host:8080; ``` Once a variable appears in `proxy_pass`, nginx no longer resolves the name at configuration load time against an `upstream` group; it needs a `resolver` directive and looks the name up at request time, honouring the record's TTL. That is sometimes exactly what you want — it lets a backend's address change without a reload — but it is a different code path with different failure modes, and a `proxy_pass` that suddenly starts returning errors after someone parameterised the host is usually a missing `resolver`. ## Why interviewers ask It is the smallest possible illustration of the general point that a reverse proxy rewrites requests, and that the app behind it sees something different from what the client sent. A candidate who can state the rule crisply, name the two forms, and say what they check in the upstream's log has clearly configured a real proxy rather than copied a snippet.