Can't access through NGinx proxy server

I'm using Home assistant NGinx proxy addon. After upgrade to 1.4.2 this setup stop working. I have let's encrypt certificates created through that addon. Version 1.4.1 works perfectly. In the log is this interesting line (I think):

tornado.access - WARNING - 403 GET /sockjs/781/o1lfejn1/websocket

Connecting through local network is fine..
THX for help

Please upload a full octoprint.log log

There is nothing more in log, only succesfull login from local network, send message to printoid etc.. Maybe I can try to switch to trace. Will post some more details in couple of minutes. thx

Don't know ho to switch to trace in Octoprint. Did it in NGinx, but there is no some relevant info, only about "send request to address", nothing more. I backuped octoprint.log and restart whole octoprint system.

octoprint.log (27.1 KB)


Also share your nginx config please

This addon has no classic config file, it's stored somewhere in database, you can change it through web page. I didn't make any changes after upgrade Octoprint to 1.4.2.

It would sure help if you could somehow get the generated nginx config out of that in order to compare it to

As things are, I have NO idea what "websockets support" does and if the custom configuration down there actually gets injected at the correct place.

Yes, you are right, it should be better to have this config, but I think that there is no such file. In my opinion is generated dynamically from database. I found that examples before I started this thread, tried much combinations, there is a option to open "Advanced" tab and write here some specific config, but without success. But something in Octoprint had to changed, because this configuration was correct and I used it always :frowning:

Well, "something" certainly changed, but I can't currently tell you what of all of that might have caused your current issue. It's probably one of the updates surrounding the server dependencies, but without being able to reproduce or access to the config it's a bit hard to pinpoint. All I can tell you is that using the config example as linked above still works just fine over here.

1 Like

:slight_smile: yeah.. something..
I know, I have specific setup. I can try to run "full" nginx, but I'm not much friend with linux and nginx configurations. I have more websites behind and in past I had nginx on Centos and was unable to config all that sites as I needed :frowning: So this addon was best for me.. Bad situation for me, thanks for help!

I've reached out to the author of the add-on in the hopes he has a pointer how to get the generated config out of it. Let's hope for the best :slight_smile:

:astonished: :astonished: :flushed: :heart_eyes: :innocent:
thanks a lot, we will see :slight_smile:

Have you tried asking in the community addon discord channel ?

Hi, no, haven't tried this.. Firstly I went here.

Ok I have the exact the same issue. I've suggested giving the add-on dev full access to my instance. if that might help

I wonder if this issue is similar to Azelphur's issue in Discord support-octoprint channel? He seemed to be having problems with websocket through nginx and his fix was...

you can adjust your proxy settings to send X-Scheme https to work around the problem. That solution is annoying in nginx proxy manager though since you need to override the whole / location block so I will end up digging into the code to solve it. Octoprint should be taking X-Forwarded-Proto into account.

add proxy_set_header X-Scheme https; to your location / { block.

X-Scheme is a non standard alias for X-Forwarded-Proto I think, so in theory both should work, but in practice, seems octoprint supports X-Forwarded-Proto (which your reverse proxy should pass) but, Tornado seems to be unhappy with it. Not sure why.

If that is indeed the case I can't help but point out this:

from the official reverse proxy configuration examples as linked above :no_mouth:

I found, that it's working correctly if I remove SSL and certificate and go through simple http. So the problem could be something there.

Yes. An unset scheme header.

Try adding

proxy_set_header X-Scheme $scheme;

as highlighted in the example linked above.

I tried everything from that example, much combinations, etc.. everything is the same