This was the smoking gun for me. Thanks for sharing.
In case someone is using Apache 2.4 (sudo apt info apache2
) as the reverse proxy:
Reverse proxy configuration Apache2 for Octoprint using a wildcard cert
Also can't edit the Wiki post, but if anyone is having issues with Traefik websockets:
It appears Octoprint isn't handling schema wss
provided by the X-Forwarded-Proto
header (which is being added by Traefik by default). This causes Octoprint to reject the Web Socket request with a 403, with Firefox considering this a NS_ERROR_WEBSOCKET_CONNECTION_REFUSED
error, aborting the web socket (which is slightly confusing, as it's obvious that a connection to Octoprint, through the reverse proxy, has been successfully made).
No specification disallows or allows for this schema, but wss
isn't exactly orthodox (so I wouldn't go as far as calling this a bug, on either side).
Ultimately the fix is something like this:
http:
middlewares:
https-redirect:
redirectScheme:
scheme: https
strip-camera-path:
stripPrefix:
prefixes:
- "/camera-1"
proto-headers:
headers:
customRequestHeaders:
X-Forwarded-Proto: "https"
routers:
octoprint:
rule: "Host(`octoprint.service.blah`)"
service: octoprint
middlewares:
- https-redirect
- proto-headers
octoprint-inline-camera:
rule: "Host(`octoprint.service.blah`) && Path(`/camera-1`)"
service: octoprint-camera
middlewares:
- https-redirect
- strip-camera-path
services:
octoprint:
loadBalancer:
servers:
- url: "http://127.0.0.1:8081"
octoprint-camera:
loadBalancer:
servers:
- url: "http://127.0.0.1:8080"
The important section is the proto-headers
middleware - used to override the wss
schema to https
.
http:
middlewares:
proto-headers:
headers:
customRequestHeaders:
X-Forwarded-Proto: "https"
...
routers:
octoprint:
middlewares:
- proto-headers
Basically, the /reverse_proxy_test/
test doesn't test web socket headers, so you'll silently have a really buggy UI when using Traefik with the default configuration.