Nginx Reverse proxy: A slash makes all the difference.

I have been doing some work to build up some standard processes for Kubernetes. ArgoCD has become a big part of that, as it allows us to declaratively manage the state of our clusters.

After recovering from a small blow-up in the home lab (post coming), I wanted to migrate my cluster tools to utilize the label selector feature of the ApplicationSet’s Cluster Generator. Why? It allows me to selectively manage tools in the cluster. After all, not every cluster needs the nfs-external-provisioner to provide a StorageClass for pod file storage.

As part of this, I wanted to deploy to tools to the local Argo cluster. In order to do that, the local cluster needs a secret. I tried to follow the instructions, but when I clicked to view the cluster details, I got a 404 error. I dug around the logs, and my request wasn’t even getting to the Argo application server container.

When I looked at the Ingress controller logs, it showed the request looked something like this:

Obviously, that’s not correct. The call coming from the UI is this:

Notice the encoding: My Nginx reverse proxy (running on a Raspberry Pi outside my main server) was decoding the request before passing it along to the cluster.

The question was, why? A quick Google search lead right to their documentation:

  • If proxy_pass is specified with URI, when passing a request to the server, part of a normalized request URI matching the location is replaced by a URI specified in the directive
  • If proxy_pass is specified without URI, a request URI is passed to the server in the same form as sent by a client when processing an original request

What? Essentially, it means the slash at the end will dictate whether Nginx does anything with the request.

## With a slash at the end, the client request is normalized
location /name/ {

## Without a slash, the request is as-is
location /name/ {

Removing the slash, the Argo UI was able to load the cluster details correctly.



, ,