starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

cloudflare + nginx + uptime-kuma = wss broken #75

New issue

Closed

opened 2026-02-28 01:33:58 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 01:33:58 -05:00

Owner

Originally created by @zaanposni on GitHub (Jul 31, 2021).

Hello there,
as the title states my setup looks like this:

Cloudflare as DNS and proxy
Nginx as reverse proxy on my machine
uptime-kuma as a docker container (on 127.0.0.1:3001)

Since cloudflare offers some kind of protection I want to ensure everyone that visits my website, connects through cloudflare:

allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 172.64.0.0/13;
allow 131.0.72.0/22;
allow 104.16.0.0/13;
allow 104.24.0.0/14;

allow 192.168.0.0/16;
allow 172.16.0.0/16;
allow 10.0.0.0/8;

deny all;

However if I proxy traffic through cloudflare and apply these rules I cannot use kuma.

I am not entirely sure if this is an issue with kuma. However, Cloudflare states that Websockets (with SSL) are 100% supported by them and I have had other applications running with Websockets before.

If I skip cloudflare and allow all connections, kuma works but my SSL certificate is broken, which is kinda ugly.

I am open for suggestions on how to improve my setup since I am not sure if this is an issue with kuma.

Errors I am getting with my configuration:

Response (no content):

nginx access.log

[31/Jul/2021:21:27:29 +0200] "GET /socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 45 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0"

my nginx config:

server {
    listen 443 ssl http2;

    ssl_certificate /etc/nginx/keys/origin.pem;
    ssl_certificate_key /etc/nginx/keys/private.key;

    server_name status.zaanposni.com;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://localhost:3001/;

        proxy_http_version 1.1;
        
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host "status.zaanposni.com";
        proxy_read_timeout 86400;
    }
}

Originally created by @zaanposni on GitHub (Jul 31, 2021). Hello there, as the title states my setup looks like this: - Cloudflare as DNS and proxy - Nginx as reverse proxy on my machine - uptime-kuma as a docker container (on 127.0.0.1:3001) Since cloudflare offers some kind of protection I want to ensure everyone that visits my website, connects through cloudflare: ``` allow 173.245.48.0/20; allow 103.21.244.0/22; allow 103.22.200.0/22; allow 103.31.4.0/22; allow 141.101.64.0/18; allow 108.162.192.0/18; allow 190.93.240.0/20; allow 188.114.96.0/20; allow 197.234.240.0/22; allow 198.41.128.0/17; allow 162.158.0.0/15; allow 172.64.0.0/13; allow 131.0.72.0/22; allow 104.16.0.0/13; allow 104.24.0.0/14; allow 192.168.0.0/16; allow 172.16.0.0/16; allow 10.0.0.0/8; deny all; ``` However if I proxy traffic through cloudflare and apply these rules I cannot use kuma. I am not entirely sure if this is an issue with kuma. However, [Cloudflare states](https://support.cloudflare.com/hc/en-us/articles/200169466-Using-Cloudflare-with-WebSockets#12345683) that Websockets (with SSL) are 100% supported by them and I have had other applications running with Websockets before. If I skip cloudflare and allow all connections, kuma works but my SSL certificate is broken, which is kinda ugly. **I am open for suggestions on how to improve my setup since I am not sure if this is an issue with kuma.** Errors I am getting with my configuration: ![grafik](https://user-images.githubusercontent.com/24491035/127751127-c7615b6e-62be-456f-8d92-e84c34240a3a.png) ![grafik](https://user-images.githubusercontent.com/24491035/127751167-7be3aee6-58ef-4a6f-9e43-1ce44314f95d.png) Response (no content): ![grafik](https://user-images.githubusercontent.com/24491035/127751184-6f206184-b20b-4a57-8bc0-1e7b38dd3022.png) nginx `access.log` ``` [31/Jul/2021:21:27:29 +0200] "GET /socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 45 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0" ``` my nginx config: ``` server { listen 443 ssl http2; ssl_certificate /etc/nginx/keys/origin.pem; ssl_certificate_key /etc/nginx/keys/private.key; server_name status.zaanposni.com; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://localhost:3001/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host "status.zaanposni.com"; proxy_read_timeout 86400; } } ```

deekerman

2026-02-28 01:33:58 -05:00

closed this issue
added the
help
label

deekerman commented

2026-02-28 01:34:01 -05:00

Author

Owner

@Spiritreader commented on GitHub (Jul 31, 2021):

Hmm that is indeed weird.
Your nginx proxy config looks alright.
I just reverse-proxied my uptime kuma instance using cloudflare, and websockets work fine on my end.
It definitely appears to be an issue with cloudflare, not with uptime kuma.

A few questions:
Can maybe your access rules cause that? Have you tried without them?
Also, which cloudflare settings are you using?
Is the subdomain a CNAME reference?
What's the exact SSl setting (dynamic / strict) etc?
Do you have any of the protection in cloudflare enabled that might block access for this instance?

@Spiritreader commented on GitHub (Jul 31, 2021): Hmm that is indeed weird. Your nginx proxy config looks alright. I just reverse-proxied my uptime kuma instance using cloudflare, and websockets work fine on my end. It definitely appears to be an issue with cloudflare, not with uptime kuma. A few questions: Can maybe your access rules cause that? Have you tried without them? Also, which cloudflare settings are you using? Is the subdomain a CNAME reference? What's the exact SSl setting (dynamic / strict) etc? Do you have any of the protection in cloudflare enabled that might block access for this instance?

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@louislam commented on GitHub (Aug 1, 2021):

It's OK for me.
https://test-status.louislam.net

Could you try flexible SSL and reverse proxy without self-signed cert?

@louislam commented on GitHub (Aug 1, 2021): It's OK for me. https://test-status.louislam.net Could you try flexible SSL and reverse proxy without self-signed cert?

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@zaanposni commented on GitHub (Aug 1, 2021):

Thanks for your suggestions.
I have tried the following things.
DNS:

Use a A record (A status.zaanposni.com -> my ip)
Use a CNAME record (CNAME status -> zaanposni.com and A zaanposni.com -> my ip)

SSL:

Use flexible SSL settings
Use full strict SSL (my default and desired setting)

Page rules:

disable cache
disable rocket launcher (compresses javascript which causes errors on firefox for me)

Firewall:

no specific firewall rules applied - default configuration

Cloudflares "Access":

not enabled

Certificate:
I am not sure what you want me to change here. I have a certificate signed by cloudflare which works completly fine. Do websockets handle SSL on a different way?

I have investigated a bit because I thought I had managed to get websockets working for another app already and looked into HedgeDoc.
This is note-taking app I have used for some time and also uses sockets.
HedgeDocs request looks like this

I do not know what the differences between sockets via http and sockets via ws are, but HedgeDoc works with the following nginx.conf. Maybe you can enable something similiar for kuma?

map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}

server {
    listen 443 ssl;

    ssl_certificate /etc/nginx/keys/origin.pem;
    ssl_certificate_key /etc/nginx/keys/private.key;

    server_name notes.zaanposni.com;

    location / {
        proxy_set_header Host notes.zaanposni.com;
        proxy_set_header X-Real-IP $remote_addr; 
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://localhost:3000;
    }

    location /socket.io/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host notes.zaanposni.com; 
        proxy_set_header X-Real-IP $remote_addr; 
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

@zaanposni commented on GitHub (Aug 1, 2021): Thanks for your suggestions. I have tried the following things. **DNS**: - Use a A record (`A status.zaanposni.com -> my ip`) - Use a CNAME record (`CNAME status -> zaanposni.com` and `A zaanposni.com -> my ip`) **SSL**: - Use flexible SSL settings - Use full strict SSL (my default and desired setting) **Page rules**: - disable cache - disable rocket launcher (compresses javascript which causes errors on firefox for me) **Firewall**: - no specific firewall rules applied - default configuration **Cloudflares "Access"**: - not enabled **Certificate**: I am not sure what you want me to change here. I have a certificate signed by cloudflare which works completly fine. Do websockets handle SSL on a different way? I have investigated a bit because I thought I had managed to get websockets working for another app already and looked into HedgeDoc. This is note-taking app I have used for some time and also uses sockets. HedgeDocs request looks like this ![grafik](https://user-images.githubusercontent.com/24491035/127762298-3aefebd7-184e-4083-a54c-54bfc44d551f.png) I do not know what the differences between sockets via http and sockets via ws are, but HedgeDoc works with the following `nginx.conf`. Maybe you can enable something similiar for kuma? ``` map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 443 ssl; ssl_certificate /etc/nginx/keys/origin.pem; ssl_certificate_key /etc/nginx/keys/private.key; server_name notes.zaanposni.com; location / { proxy_set_header Host notes.zaanposni.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:3000; } location /socket.io/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host notes.zaanposni.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } ```

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@zaanposni commented on GitHub (Aug 1, 2021):

Ok guys I found the problem. Kinda stupid 😄

Cloudflare Dashboard -> Network -> Enable WebSockets.

I thought they were enabled by default, sorry to waste your time..

For anyone reading in the future: My initial posted config works, no additional stuff required, just be sure to enable WS in Cloudflare 😵.

@zaanposni commented on GitHub (Aug 1, 2021): Ok guys I found the problem. Kinda stupid 😄 ## Cloudflare Dashboard -> Network -> Enable WebSockets. I thought they were enabled by default, sorry to waste your time.. ![grafik](https://user-images.githubusercontent.com/24491035/127766120-78b2646a-7a22-4b60-ab13-d5ae199be308.png) ![grafik](https://user-images.githubusercontent.com/24491035/127766129-b9dcf11b-c01e-4941-8dde-079fa683b3ac.png) For anyone reading in the future: My initial posted config works, no additional stuff required, just be sure to enable WS in Cloudflare 😵.

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@louislam commented on GitHub (Aug 1, 2021):

Ok guys I found the problem. Kinda stupid 😄

Cloudflare Dashboard -> Network -> Enable WebSockets.

I thought they were enabled by default, sorry to waste your time..

For anyone reading in the future: My initial posted config works, no additional stuff required, just be sure to enable WS in Cloudflare 😵.

Lol, glad you found the solution. I did not know that too. Will mention it in the wiki too

@louislam commented on GitHub (Aug 1, 2021): > Ok guys I found the problem. Kinda stupid 😄 > > ## Cloudflare Dashboard -> Network -> Enable WebSockets. > I thought they were enabled by default, sorry to waste your time.. > ![grafik](https://user-images.githubusercontent.com/24491035/127766120-78b2646a-7a22-4b60-ab13-d5ae199be308.png) > ![grafik](https://user-images.githubusercontent.com/24491035/127766129-b9dcf11b-c01e-4941-8dde-079fa683b3ac.png) > > For anyone reading in the future: My initial posted config works, no additional stuff required, just be sure to enable WS in Cloudflare 😵. Lol, glad you found the solution. I did not know that too. Will mention it in the wiki too

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@Nuckerr commented on GitHub (Sep 20, 2021):

Hi, I'm having this exact same issue, wss is enabled in cloudflare, same error:

I'm using cloudflare ssl certificates & proxying through cloudflare. I'm reverse proxying in nginx, here is my nginx config:

server {
    server_name status.nucker.me;
    listen 443 ssl;

    location / {
            proxy_pass    http://0.0.0.0:3001;
            proxy_set_header    X-Real-IP $remote_addr;
            proxy_set_header    Host      $http_host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

    ssl_certificate     /root/certs/cert.pem;
    ssl_certificate_key /root/certs/key.pem;
    ssl on;
}

@Nuckerr commented on GitHub (Sep 20, 2021): Hi, I'm having this exact same issue, wss is enabled in cloudflare, same error: ![image](https://user-images.githubusercontent.com/62883418/134051846-7110be1f-e963-4a29-b6cd-ba3185379c3b.png) ![image](https://user-images.githubusercontent.com/62883418/134051862-bb594529-ac8f-428c-a468-a3d45fec7f55.png) I'm using cloudflare ssl certificates & proxying through cloudflare. I'm reverse proxying in nginx, here is my nginx config: ```nginx server { server_name status.nucker.me; listen 443 ssl; location / { proxy_pass http://0.0.0.0:3001; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } ssl_certificate /root/certs/cert.pem; ssl_certificate_key /root/certs/key.pem; ssl on; } ```

deekerman commented

2026-02-28 01:34:05 -05:00

Author

Owner

@louislam commented on GitHub (Sep 20, 2021):

server {
    server_name status.nucker.me;
    listen 443 ssl;

    location / {
            proxy_pass    http://0.0.0.0:3001;
            proxy_set_header    X-Real-IP $remote_addr;
            proxy_set_header    Host      $http_host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

    ssl_certificate     /root/certs/cert.pem;
    ssl_certificate_key /root/certs/key.pem;
    ssl on;
}

Please read wiki, you are missing some headers.

https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy

@louislam commented on GitHub (Sep 20, 2021): > Hi, I'm having this exact same issue, wss is enabled in cloudflare, same error: > ![image](https://user-images.githubusercontent.com/62883418/134051846-7110be1f-e963-4a29-b6cd-ba3185379c3b.png) > ![image](https://user-images.githubusercontent.com/62883418/134051862-bb594529-ac8f-428c-a468-a3d45fec7f55.png) > I'm using cloudflare ssl certificates & proxying through cloudflare. I'm reverse proxying in nginx, here is my nginx config: > > ```nginx > server { > server_name status.nucker.me; > listen 443 ssl; > > location / { > proxy_pass http://0.0.0.0:3001; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $http_host; > proxy_set_header X-Forwarded-Proto https; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > } > > ssl_certificate /root/certs/cert.pem; > ssl_certificate_key /root/certs/key.pem; > ssl on; > } > ``` Please read wiki, you are missing some headers. https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy

deekerman referenced this issue

2026-02-28 03:01:34 -05:00

Looping Crash After Deleting Monitor #2627