You know how sometimes you copy an nginx config snippet and it just... doesn't work? You stare at it, reload, check the logs, and nothing seems wrong. Then you spot it: a missing or extra slash at the end of the proxy_pass line. It’s one of those tiny details that silently breaks your setup.
Let’s look at two examples.
First, with a trailing slash:
location /app/ {
proxy_pass http://backend/;
}
Here, nginx replaces the matched part (/app/) with the URI in proxy_pass (http://backend/). So a request to /app/index.html goes to http://backend/index.html.
Now, without the trailing slash:
location /app/ {
proxy_pass http://backend;
}
In this case, nginx passes the entire request URI unchanged. So /app/index.html becomes http://backend/app/index.html.
The difference is subtle but important. If your backend expects requests at the root (like /index.html), the first form is what you want. If it expects the path to be preserved (like /app/index.html), the second form works.
I’ve seen this trip up people when they move from a location block that matches a prefix to one that’s more specific. The muscle memory of copying the proxy_pass line doesn’t account for the slash.
It’s not a bug. It’s documented behavior. But it’s easy to overlook when you’re in a hurry. Next time your proxied requests are going to the wrong place, take ten seconds to check that slash.
