WebSocket fails when running behind Authelia & Caddy

[danshat]

Apparently after (relatively) recent updates Metube fails to work correctly while running behind Authelia and a reverse proxy.

This is how the page looks, showing "Connection to server" message.

Network tab shows the following.

docker-compose.yml:

 metube:
        container_name: metube
        image: alexta69/metube:latest
        volumes:
            - *******:/downloads
        restart: unless-stopped

Authelia logs show this repeatedly:

time="2024-06-21T00:07:51Z" level=info msg="Access to https://metube.example.com/socket.io/?EIO=4&transport=polling&t=P0u7k_t (method GET) is not authorized to user <anonymous>, responding with status code 302 with location redirect to https://auth.example.com/?rd=https%3A%2F%2Fmetube.example.com%2Fsocket.io%2F%3FEIO%3D4%26transport%3Dpolling%26t%3DP0u7k_t&rm=GET" method=GET path=/api/authz/forward-auth remote_ip=192.168.0.1

Caddyfile configuration:

metube.example.com {
        forward_auth authelia:9091 {
                uri /api/authz/forward-auth
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
        }
        reverse_proxy metube:8081
}

I understand this is likely an issue with misconfigured Caddy instance. However if someone could possibly help me with this it would be great.

[PikuZheng]

can you try it without https to see if it's ssl's issue?

[PikuZheng]

After some google, I think this is a problem with Caddy proxying the wss protocol. Maybe changing the Authelia authentication method from http headers to cookies will help. Or open the wss protocol in Authelia (no authentication required)

[danshat]

can you try it without https to see if it's ssl's issue?

Authelia does not allow HTTP traffic: Target URL 'http://metube.example.com/' has an insecure scheme 'http', only the 'https' and 'wss' schemes are supported so session cookies can be transmitted securely.

After some google, I think this is a problem with Caddy proxying the wss protocol.

Caddy's official documentation states:

example.com {
    @websockets {
        header Connection *Upgrade*
        header Upgrade    websocket
    }
    reverse_proxy @websockets localhost:6001
    reverse_proxy localhost:8080
}

Meaning that WSS is supported by Caddy. This header configuration correlates with other reverse proxies configurations.

Weirdly enough, even without these directives and proper matchers in Caddyfile, the issue has been corrected after deleting browser cookies, but only temporarily:

In a couple minutes I restarted Authelia without changing anything else and once again requests to /socket.io are dropped. So relogging to Authelia solves this, but only for a short time.