Proxy_pass not working for HTTPS (UNRAID)

Projects NGINX
1

Please use this template for troubleshooting questions.

My issue: I have a network with my internet router feeding a server running Debian 13 and nginx 1.26.3. I have a separate server running Unraid and Immich. I have set up HTTPS reverse proxy access to Immich using a wildcard certificate for my domain and this works fine. I set up a similar configuration for Unraid which does not work for the folder access.

Unraid access works by accessing the root path (/) which returns a 302 record referring to /Main. Generally /Main determines that you are not logged in and refers you to /login. The issue is that access to both /Main and /login return 404 errors.

As I said, my Immich SSL setup works fine and if I set up an HTTP proxy for Unraid, it works fine.

If I CURL to https://unraid.mydomain.com I get the 302 response. If I CURL to https://unraid.mydomain.com/Main or https://unraid.mydomain.com/login I get a 404 response. If I CURL to Immich and its folders, everything is fine.

My setup is a follows. I have tried lots of variations based on other posts. This setup works fine for Immich which does have subfolders but does not use redirection.

server {
	listen 443 ssl;
	server_name unraid.mydomain.com;

	ssl_certificate /usr/certificates/mydomain.com.cer;
	ssl_certificate_key /usr/certificates/mydomain.com.key;

	ssl_session_cache shared:SSL:10m;
	access_log /var/log/nginx/access.log unraid;
	
	location = / {
		proxy_pass http://192.168.1.200:180/;

		proxy_set_header Host $http_host;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "Upgrade";
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
}

Version of NGINX or NGINX adjacent software (e.g. NGINX Gateway Fabric):

1.26.3

Deployment environment:

Debian 13 on a Dell 7010 server.

2

Hi @Percentage ,

I think the issue is with the = modifier it is used for exact matches

3

location = / { makes not difference.

After four days of searching and trying a whole bunch of different configurations I finally gave up. I reinstalled Debian from scratch and installed the Caddy server. I created the config below and it ran right away and even configured an SSL certificate.

unraid.mydomain.com {
	reverse_proxy http://192.168.1.200:180
}

immich.mydomain.com {
	reverse_proxy http://192.168.1.200:2283
}
4

= needs to be removed

I’m glad that Caddy helped you achieve the result faster. In fact, in my own pet projects I also sometimes use Caddy, but these products were designed at different times and with different philosophies. Caddy is a proxy focused on convenience out of the box, while nginx is a time-tested, high-perf server with a huge ecosystem and a configuration approach that demands more expertise.
In other words, nginx is a construction kit, it won’t do anything for you automagically. This allows you to control every nuance and behavior, but it also means you are responsible for the details and must understand how HTTP and other protocols work. Nginx also offers more config options and tuning knobs, which can be important in certain projects.

As you can see, Nginx documentation is pretty lean and aimed at experienced users. All directives are described, but figuring out how to assemble a working config can be challenging, even experienced engineers sometimes miss important details.

As a result, for home use, if you’re not interested in all these details and complexities, Caddy is a perfectly fine choice. However, convenience can sometimes hide configuration pitfalls that may affect security. When it comes to critical production services, though, trust and maturity play a much bigger role :slight_smile: