try_files not always sending full $uri to proxy_pass and upstream

[bengalih@…]

So I'm dealing with an app that states it needs a configuration block like so (removed tuning settings I believe irrelevant to issue):

server {
    listen 80;
    server_name app1.mydomain.com;
}

location / {
        proxy_pass http://10.10.10.102:8096/;
    }

location /socket {
        proxy_pass http://10.10.102:8096/socket;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

When using this configuration, the app functions properly, or specifically in the console logs of the app I see no errors and the sockets that need to be created/accessed are apparently done so. However, my overall nginx config is a bit more complex and I try to standardize and modularize things in a certain way. I have a configuration which looks more like this, using proxy_pass and upstream blocks:

upstream app1_backend {
        server 10.10.10.102:8096;
}

server {
        listen 443 ssl http2;

        server_name app1.mydomain.com;

        location @proxy {
                proxy_pass http://app1_backend;
        }

        location / {
                try_files $uri @proxy;
        }

        location /api {
                try_files $uri @proxy;
        }

        location /socket {
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                try_files $uri @proxy;
        }
}

The above does not work. Namely the application complains that it can't access /socket. If however I change it to the below block, it works:

  location /socket {
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                try_files $uri @proxy/sockets;
        }

I don't believe I should have to append /sockets onto the @proxy statment.
I don't need to do this with the /api location for it to work properly.

Is there something undocumented here, perhaps with setting the http_version or any other explanation of why the entire /socket $uri is not being sent on through the proxy_pass and upstream?

[Maxim Dounin]

An obvious problem with your second configuration is that proxy_set_header and proxy_http_version directives are used in the wrong location (not in the location where proxying configured), hence they won't do anything. Most likely your application won't work without these directives used when proxying, so complaints from the application are expected.

No idea why the third configuration works for you, as it is expected to return 500 (Internal Server Error) error when requesting non-existent files within /socket, since there is no "@proxy/sockets" named location in your configuration.

Note well that your original configuration is actually expected to be much more robust and effective than your attempts to "modularize" things. Check out Igor Sysoev's talk ​Scaleable NGINX Configuration if you are interested.

If you have further questions on how to configure nginx, consider using ​support options available.

[bengalih@…]

Maxim,

Thanks for your comments. I will definitely watch the Scaleable video to see how I might improve my configurations.

I just wanted to add closure that I am not actually sure the third configuration was working, as I got the same feedback from the app logs as if I had an empty socket location like this:

 location /socket {
        }

When viewing the NGINX logs, I could still see 404 errors when hitting the empty location, but the app apparently didn't log/complain which is why I thought it was functioning properly.

Also thanks for pointing out the wrong location of the proxy commands, I had overlooked that when I did some refactoring.