chagned too (in lower light corner window of my screenshot as foosel said) and nothing changed 
still the same.
@octojam - are you using nginx addon in home assistant too?
No I just have an nginx reverse proxy in front of octoprint (seperate container)
What versions of nginx do y'all have there?
I only know the version of addon for hassio
hassioaddons/nginxproxymanager-armv7:0.6.0
Just upgraded to the current nginx 1.19.1 to rule out it was a difference in behaviour between what I still had on this dev machine (1.13.something) and current versions.
Still no reproduction, it's behaving like it should with:
location / {
proxy_pass http://192.168.1.56;
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_http_version 1.1;
client_max_body_size 0;
}
and also with
location /vin/ {
proxy_pass http://127.0.0.1/;
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 /vin;
proxy_http_version 1.1;
client_max_body_size 0;
}
both on http and https, no issues at all 
That is against both 1.4.2 and the current maintenance branch.
My friend has exactly same experience.. he has standalone nginx on rpi2 and has no problem with 1.4.2 version ;-/
this is somewhere between earth, sky and nginx addon
It's not just the HA nginx add-on, @octojam also reported problems with regular nginx in a separate container.
I'm using docker nginx:1.19.0 on k8s, with an nginx ingress controller and octoprint downstream (separate server)
(worked fine with the above config until 1.4.2 update, then I'd get the 403 error on websockets until I made the change)
I’ve encountered this issue when upgrading to 1.4.2, also using Nginx Proxy Manager, but I can provide the Nginx config (with sensitive data removed).
# ------------------------------------------------------------
# octopi.########
# ------------------------------------------------------------
server {
set $forward_scheme http;
set $server "[####:####]";
set $port 80;
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443;
server_name octopi.########;
# Custom SSL
ssl_certificate /data/custom_ssl/npm-1/fullchain.pem;
ssl_certificate_key /data/custom_ssl/npm-1/privkey.pem;
access_log /config/log/proxy_host-12.log proxy;
location / {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
# Custom
include /data/nginx/custom/server_proxy[.]conf;
}
I don’t currently have any custom config so that last line isn’t importing anything.
proxy.conf contains
add_header X-Served-By $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass $forward_scheme://$server:$port;
Nginx version is 1.17.81.
Edit:
After further investigation I’ve managed to narrow it down to the missing X-Scheme header (as @foosel pointed out much earlier). Unfortunately there isn’t an easy way to add this to config managed by Nginx Proxy Manager, so we might need to try and get something merged into Nginx Proxy Manager upstream.
I assume then that the change in 1.4.2 is the enforcement of scheme matching on the Origin header.
Thank you @AvianLyric.
I just replicated this config in my local install:
location / {
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
add_header X-Served-By $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://127.0.0.1:5000;
}
Still no reproduction against https, everything works just as it should. It's a mystery 
Hmmm that’s strange, I’ll spend some time this evening digging through my setup and see if I can figure out what’s going wrong.
I'm pretty sure you are right in your assumption that it's the origin check that fails, as that's about the only place I can see a 403 being generated on websocket connection.
And that also saw a fix in 1.4.1/1.4.2:
I just debugged into this and I'm only seeing https as scheme there for both regular requests as well as secure websocket connections. I'm wondering if for SOME reason some of you are getting a wss scheme there, which would make this mismatch.
If it is the origin check, you could check if enabling CORS under Settings > API makes it work, as that will bypass the origin check on the web socket as well.
Edit: I've just pushed
which translates wss/ws into https/http for the origin check. If anyone of you currently being able to reproduce this problem (I still can't) would be able to test the maintenance branch and check if it's gone on that, that would help a lot.
1 Like
I'm willing to try this out as I have the same issue, but I seem to have issues with the steps to switch to the maintenance branch outlined here:
pi@octopi:~/OctoPrint $ source ~/oprint/bin/activate
(oprint) pi@octopi:~/OctoPrint $ git fetch
fatal: not a git repository (or any of the parent directories): .git
(oprint) pi@octopi:~/OctoPrint $
Have you run the add OctoPrint checkout script mentioned at the top of the FAQ post? OctoPi does not have the git repo by default, just the pip packages. Try running ~/scripts/add-octoprint-checkout, then the git repo should be there?
Geez, I completely gazed past that bit! 
I'll try this shortly and update in here.
1 Like
I've just tried the maintenance release and unfortunately I'm still getting the same error.
- OctoPrint 1.5.0.dev126+g641f27af3
- Python 2.7.16
- OctoPi 0.17.0
octoprint.log
2020-08-17 18:42:55,200 - octoprint.server.preemptive_cache - INFO - ... done in 0.20s
2020-08-17 18:42:56,675 - tornado.access - WARNING - 403 GET /sockjs/920/dqje4skz/websocket (::ffff:10.10.10.11) 2.39ms
2020-08-17 18:42:56,696 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:42:59,380 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.10.10.20
2020-08-17 18:42:59,436 - octoprint.server.util.flask - INFO - Passively logging in user username from ::ffff:10.10.10.20
2020-08-17 18:42:59,441 - octoprint.access.users - INFO - Logged in user: username
2020-08-17 18:43:04,356 - octoprint.server.util.sockjs - INFO - User username logged in on the socket from client ::ffff:10.10.10.20
2020-08-17 18:43:33,277 - tornado.access - WARNING - 403 GET /sockjs/128/o3rfoud1/websocket (::ffff:10.10.10.11) 2.36ms
2020-08-17 18:43:33,295 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:44:49,549 - tornado.access - WARNING - 403 GET /sockjs/888/ilbtquzy/websocket (::ffff:10.10.10.11) 2.25ms
2020-08-17 18:44:49,565 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:26,373 - tornado.access - WARNING - 403 GET /sockjs/701/nnaqx2ng/websocket (::ffff:10.10.10.11) 3.99ms
2020-08-17 18:46:27,285 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:40,740 - tornado.access - WARNING - 403 GET /sockjs/526/jw3rgbhk/websocket (::ffff:10.10.10.11) 3.97ms
2020-08-17 18:46:40,766 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
2020-08-17 18:46:43,937 - octoprint.access.users - INFO - Logged in user: username
2020-08-17 18:46:43,944 - octoprint.server.api - INFO - Actively logging in user username from 10.10.10.254
2020-08-17 18:46:45,352 - tornado.access - WARNING - 404 GET /favicon.ico (::ffff:10.10.10.11) 19.78ms
2020-08-17 18:46:45,384 - tornado.access - WARNING - 403 GET /sockjs/232/i5upyyhe/websocket (::ffff:10.10.10.11) 3.35ms
2020-08-17 18:46:45,469 - octoprint.server.util.sockjs - INFO - New connection from client: 10.10.10.254
Same error in both Chrome and Safari. I've also tried with the different proxy_set_header options in nginx but same issue. In 1.4.1 I was running my octopi proxy host with out of the box settings fine.
I've just enabled this as an additional test and this works fine. I'll revert to stable and try again.
Update: Back on stable 1.4.2 with API > CORS enabled and working fine.
Hi,
I'm back from holiday - made a click, enabled CORS, restart.. and my web is back through https!!
Thanks a lot!!
Hi there,
Just a quick "happend to me too" post.
I was running into the exact same issue (with a somewhat similar config):
- fairly recent nginx as a reverse proxy (in a docker container, behind a traefik "global" reverse proxy)
- stopped working after upgrading to 1.4.2
- the config was already including the "X-Scheme" line
- went back to normal after changing $scheme to https
Anyway, thank you for the great community (and help) 