Reverse Proxy & Login Access Issue

What is the problem?

I am using a LinuxServer/swag (previously LetsEncrypt) container on a raspberry pi to create a reverse proxy that points to a seperate pi that runs octoprint. I have it set up using DuckDNS validation.

Octoprint.[MyURL] --> I can log into Octoprint just fine using this, but only if I ignore the cert.
[MyURL] --> This shows the login page, but I cannot log in at all (it just redirects me back to login page).

The reason I'm posting is because firefox just started complaining about the certificate and the option to allow it is no longer available. (If I log in via MS Edge, I can ignore the cert, get to the login page, and log in)

What I'm hoping to resolve is either get the cert functional for this subdomain, or (maybe preferably) get the subfolder style url working properly.

What did you already try to solve it?

I tried refreshing the cert the container uses. My local network is set up so that Swag points to quite a few services on my network, all using the 'subfolder' style url. DuckDNS validation does not allow for both subfolder and subdomain validation. (you can either have .[mydomain] OR [mydomain] )

Octoprint is the only service that causes issues with using the subfolder method. I feel like there was a setting somewhere that allows you to change the access url to allow access like this, but I can't find any info on it currently.

Logs (syslog, dmesg, ... no logs, no support)

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)

All proxy settings match the configurations for LetsEncrypt noted on this url:

-- In my original reply, apparently the subfolder setup had been working at one point. But now it just refreshes, no changes made to my proxy setup.

Symptoms are identical to this issue:

For OctoPrint to work from a reverse proxy setup like this you need a few things configured, but also it could be the mess of https vs login cookies not working properly - I guess we are about to go through some fun debugging...

First, make sure you have the 'X-Script-Name' header set to '/OctoPrint' in your reverse proxy config for '[yourURL]'. That is needed so OctoPrint knows how to generate links & API requests properly.

Now you will probably have to open the browser's developer tools, to find the console. When you press the login button, are there any errors reported? If yes, let me know what they are!

If there's no error generated, I would next look at the network request itself. In the developer tools, there's the 'Network' tab, click the login button and see if you can find the login request content, like this:

The cookie header should exist, if it is invalid then the browser should complain about it there. Let me know if you find any errors or if you can find the Set-Cookie header. Probably advisable not to post the session cookie header content since it could allow someone access to your OctoPrint install.

Concerning the certificate, there's something in the container documentation about DuckDNS:

Seems like you are trying to use both at the time: Octoprint.[MyURL] is a subdomain of [MyURL] So to avoid certificates errors, I suggest you switch to the 'wildcard' certificate. Thus it will cover any *.[MyURL] you can encouter. But then again, it won't work for [MyURL] To get both, you'd have to rely on Certbot, or any other LetsEncrypt client that would let you pick the domains you wish to validate. I'm not that knowledgeable about containers offering that kind of service, but then again there might be one. Otherwise, there's always the solution of using the Pi's nginx package...

@SwHawk -- Yea, I was thinking about running a second container to handle the subdomains. But figured that would overcomplicating things.

@Charlie_Powell -- Thanks for the reply. No more debugging needed!
I already had the X-Script-Name set up properly in my configuration, but you posing the question caused me to double check.

I had a typo on this line:
rewrite /octoprint(.*) $1 break;
that I hadn't caught on my various inspections of that file. Once I corrected the typo, it worked first shot.

For record-keeping purposes, below is the new setup I'm using with linuxserver/swag docker container:


location /octoprint {
    return 301 $scheme://octoprint.$host/octoprint/;

location ^~ /octoprint/ {
	set $upstream_octoprint;
	proxy_pass http://$upstream_octoprint;
	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-Scheme $scheme;
	proxy_set_header X-Script-Name /octoprint;
	proxy_http_version 1.1;
	client_max_body_size 0;
	rewrite /octoprint(.*) $1 break;
1 Like

I get errors in the console.

Please help.

I have OctoPrint linked to a reverse proxy in dms 7 synology. However when i access https i cant connect both in Cura and in OctoPod. The webbrowser works.

Cura says: OctoPrint not available.
OctoPod says: bad ssl or other ssl problem.
OctoPod sometimes says: WSError 1