Websockets and Reverse Proxy not working

[firedrow]

I have your hamclock-docker up and running on my local network, but when I try to put it online using Caddy Server and the reverse-proxy setup, the Websocket won't connect. Have you seen this behavior?

[ChrisRomp]

I haven't used Caddy, but I have it behind nginx (using Linuxserver.io's SWAG container) on my local network for HTTPS (because I embed it in my Home Assistant also using HTTPS). I think maybe I had some websocket issues initially and it was probably a header issue at the proxy (see the proxy.conf spec below).

Here's my nginx default.conf, in case it's helpful.

# redirect all traffic to https
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

# main server block
server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name _;

    include /config/nginx/ssl.conf;
    client_max_body_size 0;

    location /live.html {
        return 301 https://$host/;
    }

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app hamclock;
        set $upstream_port 8081;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port/live.html;
    }
}

# API Server
server {
    listen 8080 ssl http2 default_server;
    server_name _;

    include /config/nginx/ssl.conf;
    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app hamclock;
        set $upstream_port 8080;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

And proxy.conf:

# Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Proxy Connection Settings
proxy_buffers 32 4k;
proxy_connect_timeout 240;
proxy_headers_hash_bucket_size 128;
proxy_headers_hash_max_size 1024;
proxy_http_version 1.1;
proxy_read_timeout 240;
proxy_redirect http:// $scheme://;
proxy_send_timeout 240;

# Proxy Cache and Cookie Settings
proxy_cache_bypass $cookie_session;
#proxy_cookie_path / "/; Secure"; # enable at your own risk, may break certain apps
proxy_no_cache $cookie_session;

# Proxy Header Settings
proxy_set_header Connection $connection_upgrade;
proxy_set_header Early-Data $ssl_early_data;
proxy_set_header Host $host;
proxy_set_header Proxy "";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Method $request_method;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Original-Method $request_method;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_set_header X-Real-IP $remote_addr;

resolver.conf is just:

resolver  127.0.0.11 valid=30s;

[firedrow]

Instead of using Caddy, I switched to Cloudflare's ZeroTrust (how I have most of my Docker containers mapped to DNS). When I look at the container logs, I keep seeing:

LIVE: unknown GET live-ws

If I access it across the LAN, the log shows:

LIVE: client 172.27.0.10: new websocket request

[ChrisRomp]

Take a look at your browser developer tools on the network tab to see what WS requests are going out. Compare the working environment to the non working environment. That might clue you into what the difference is to change your Cloudflare configuration. CF may also have some docs/recommendations for websockets.