Nginx reverse proxy stuck at "Loading OctoPrint's UI, please wait..."

Get Help Networking
#1

What is the problem?
Octoprint UI doesn't show up. It's stuct at "Loading OctoPrint's UI, please wait..."

What did you already try to solve it?
Can't fix it.

Logs (syslog, dmesg, ... no logs, no support )
octoprint.log https://pastebin.com/4NeEqTbV

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, ...)

Debian Buster. Octoprint 1.4.2
Nginx config file https://pastebin.com/GspsLDeq
Nginx works with letsencrypt and has a redirect from HTTP to HTTPS.

In firefox inspector doing GET /octoprint/ I see:

You don't seem to have JavaScript enabled
OctoPrint's UI requires JavaScript to work. Please enable JavaScript and reload.

Also having lots of simmilar JS errors in console:

Could not bind view model UiStateViewModel to target #page-container-main : parseBindingsString@https://ibox.netng.pl/octoprint/static/webassets/packed_libs.js?df208d52:3:6802
Could not bind view model AboutViewModel to target #footer_about : parseBindingsString@https://ibox.netng.pl/octoprint/static/webassets/packed_libs.js?df208d52:3:6802
Reverse proxy configuration examples
#2

Take a look at Can't access through NGinx proxy server, sounds similar.

#3

Enabling CORS didn't help.

#4

Reverting to 1.4.1 also didn't help.

#5

Hey @LucasAZ :slight_smile:

Would you mind trying some things ?

Test 1 : add the trailing slash in the « location » stanza
proxy_set_header X-Script-Name /octoprint
becomes
proxy_set_header X-Script-Name /octoprint/

Test 2 : verify the http_upgrade stanza
In your partial config file, we see the proxy_set_header Upgrade $http_upgrade
Is you map defined in the http block ?

It should read something like :

map $http_upgrade $connection_upgrade {
            default upgrade;
            '' close;
        }

Test 3 : try using http before enabling https
(hey, IT Sec engineer hat on : please never consider http for production :D)
It seems like your browser can't get the websocket / js working. It might be related to TLS restrictions in your browser.

Best of luck :slight_smile:
K.

1 Like
#6

Changing to

proxy_set_header X-Script-Name /octoprint/

Didn't help. I have same https working with nginx for other sites without any issues. I've enabled nginx to listen on non standard port with https which works. Issues seems to boil down to /octoprint

Non standard port on nginx:

server {
    listen 5050 ssl;
    listen [::]:5050 ssl;

    ssl_certificate /etc/letsencrypt/live/ibox.netng.pl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ibox.netng.pl/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/ibox.netng.pl/chain.pem;

    server_name ibox.netng.pl;

    location / {
      proxy_set_header X-Forwarded-Host $http_host;
      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;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_http_version 1.1;
      proxy_pass http://127.0.0.1:5000/;
      client_max_body_size 0;
    }
}
1 Like
#7

Also please see https://github.com/OctoPrint/OctoPrint/issues/3776#event-3886530947 for more logs.

1 Like
#8

To be sure : the nginx stanza you posted (the one without the "location /octopi/") is working, right ?

May I ask you an other test ? It would be about variations on the location definition.

location /octoprint
location = /octoprint/

My feeling gut, location /octoprint is better (cause it says "/octoprint" AND "/octoprint/"). I don't know how the websockets of Octoprint work exactly but it may be reached on /octoprint while ressources are located under /octoprint/*, hence the location /octoprint hypothesis.

K.

#9

with:

location = /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 https;
	proxy_set_header X-Script-Name /octoprint/;
	proxy_set_header X-Forwarded-Proto https;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Ssl on;
	client_max_body_size 0;
	proxy_http_version 1.1;
	proxy_pass http://127.0.0.1:5000/;
}

I get 404 errors in octoprint.log

2020-10-16 18:02:20,670 - tornado.access - WARNING - 404 GET //static/webassets/packed_libs.css?ec88168c (172.31.1.100) 2.89ms
2020-10-16 18:02:20,674 - tornado.access - WARNING - 404 GET //static/webassets/packed_core.css?24a56478 (172.31.1.100) 3.03ms

With:

location /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 https;
	proxy_set_header X-Script-Name /octoprint;
	proxy_set_header X-Forwarded-Proto https;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Ssl on;
	client_max_body_size 0;
	proxy_http_version 1.1;
	proxy_pass http://127.0.0.1:5000/;
}

I have same 404 errors.

#10

Okay. Sorry, I'm leading you through test :wink:

New one, if you're okay ? I feel like the non-standard port may have a impact on the websocket (though I'm not really sure …). What if you add (to your original config, you may throw our previous tests I guess)

proxy_set_header X-Forwarded-Port $server_port;

K.

#11 
location /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_set_header X-Forwarded-Proto https;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Ssl on;
	proxy_set_header X-Forwarded-Port $server_port;
	client_max_body_size 0;
	proxy_http_version 1.1;
	proxy_pass http://127.0.0.1:5000/;
}

Still stuck at "loading"

#12

So, let's continue !

What do you get requesting http://ibox.netng.pl:5050/sockjs/ ?

I start fearing that the sockjs implementation in Octopi doesn't use the non-standard port in your URL scheme. Maybe @foosel have an input on this ?

For me, sockjs fails at the initialization, for an unknow reason. Could be the port, could be something else, and as my knowledge on WebSockets reaches here its limits, I may have to let that sink for a while and see if anyone has a better view on that.

K.

#13 
curl http://ibox.netng.pl:5050/sockjs/
Welcome to SockJS!

curl  https://ibox.netng.pl/octoprint/sockjs/
Welcome to SockJS!

@koreth any idea ?

1 Like
#14

How did I missed this answer ?

@luqasz, how is it going ? Still stuck ?

#15

Yes. Still stuck.

#16

Okay.

I feel like we narrowed the bug down to the "location /" vs "location /octoprint" in your nginx file.

Question : Is the port 5000 closed on your server ?
Rationale : how possible is it (in your opinion) that your browser is going directly to :5000 where it actually should go through 5050 (nginx) ? Can you check that octoprint listening on localhost only ?

I would probably try both state:

  • octoprint closed (127.0.0.1 + port 5000 firewall'd)
  • octoprint opened (listen on 0.0.0.0 + port 5000 open too)

Just to see if there's a strange behavior from the UI trying to reach "/" instead of "/octopi" (or /whatever) when there's also a custom port :wink:

K.

#17

Still stuck. I had octoprint listen on 0.0.0.0:5000. Forced octoprint to listen only on localhost. Still same issue.

#18

Possibly daft question... have you changed config.yaml to include the relevant reverse proxy settings? Details are here: https://docs.octoprint.org/en/master/configuration/config_yaml.html#server