starred/uptime-kuma

Fork 0

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

Some URL show down after updated to v1.23.4 #2792

New issue

Closed

opened 2026-02-28 03:07:25 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 03:07:25 -05:00

Owner

Originally created by @aciducen1995 on GitHub (Nov 14, 2023).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

After updating my uptime-kuma to the latest v1.23.4, some URLs are showing down. Refer to Error based on log. After i revert back to v1.23.3, the uptime are ok.

📝 Error Message(s) or Log

Error in Dashboard
write EPROTO C0577B433D7F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Error in container log
| Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0
2023-11-14T19:13:46+08:00 [MONITOR] WARN: Monitor #5 'https://xxxxxx.com.my': Failing: write EPROTO C0A7EDAA937F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Keep in mind i have changed the URL to xxxxx

🐻 Uptime-Kuma Version

1.23.4

💻 Operating System and Arch

Oracle Linux 8.5

🌐 Browser

Google Chrome

🐋 Docker Version

20.10.17

🟩 NodeJS Version

No response

Originally created by @aciducen1995 on GitHub (Nov 14, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem After updating my uptime-kuma to the latest v1.23.4, some URLs are showing down. Refer to Error based on log. After i revert back to v1.23.3, the uptime are ok. ### 📝 Error Message(s) or Log **Error in Dashboard** write EPROTO C0577B433D7F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922: **Error in container log** | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0 2023-11-14T19:13:46+08:00 [MONITOR] WARN: Monitor #5 'https://xxxxxx.com.my': Failing: write EPROTO C0A7EDAA937F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922: Keep in mind i have changed the URL to xxxxx ### 🐻 Uptime-Kuma Version 1.23.4 ### 💻 Operating System and Arch Oracle Linux 8.5 ### 🌐 Browser Google Chrome ### 🐋 Docker Version 20.10.17 ### 🟩 NodeJS Version _No response_

deekerman

2026-02-28 03:07:25 -05:00

closed this issue
added the
help
label

deekerman commented

2026-02-28 03:07:29 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 14, 2023):

This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall?

(Related: nodejs/node#45378, blog post)

@chakflying commented on GitHub (Nov 14, 2023): This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall? (Related: nodejs/node#45378, [blog post](https://johnnyreilly.com/node-18-axios-and-unsafe-legacy-renegotiation-disabled))

deekerman commented

2026-02-28 03:07:29 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 14, 2023):

@aciducen1995

I think this is a duplicate of #4027
If you agree, could you please close this Issue, as duplicates only create immortal zombies and are really hard to issue-manage?
If not, what makes this issue unique enough to require an additional issue? (Could this be integrated into the issue linked above?) ^^

Note that our contribution guide can be found here and that we are open to contributions if you adhere to this

@CommanderStorm commented on GitHub (Nov 14, 2023): @aciducen1995 I think this is a duplicate of #4027 If you agree, could you please close this Issue, as duplicates only create immortal zombies and are really hard to issue-manage? If not, what makes this issue unique enough to require an additional issue? (Could this be integrated into the issue linked above?) ^^ Note that [our contribution guide can be found here](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) and that we are open to contributions if you adhere to this

deekerman commented

2026-02-28 03:07:29 -05:00

Author

Owner

@aciducen1995 commented on GitHub (Nov 14, 2023):

This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall?

(Related: nodejs/node#45378, blog post)

yes its behind corporate firewall.

@aciducen1995 commented on GitHub (Nov 14, 2023): > This is a security fix in node.js v17+. Is the server running behind a corporate VPN/firewall? > > (Related: [nodejs/node#45378](https://github.com/nodejs/node/issues/45378), [blog post](https://johnnyreilly.com/node-18-axios-and-unsafe-legacy-renegotiation-disabled)) yes its behind corporate firewall.

deekerman commented

2026-02-28 03:07:29 -05:00

Author

Owner

@desquinn commented on GitHub (Nov 17, 2023):

Wea re having the same issue following the upgrade. The commonality between two checks are that they are testing Lets Encrypt Certificates on Draytek routers using DDNS supplied by Draytek. The two urls are in the form https://xxxhostxxxx.drayddns.com:9443/ and the URLs work in firefox etc without any issue. These are the external firewalls for a couple of Small businesses.

@desquinn commented on GitHub (Nov 17, 2023): Wea re having the same issue following the upgrade. The commonality between two checks are that they are testing Lets Encrypt Certificates on Draytek routers using DDNS supplied by Draytek. The two urls are in the form https://xxxhostxxxx.drayddns.com:9443/ and the URLs work in firefox etc without any issue. These are the external firewalls for a couple of Small businesses.

deekerman commented

2026-02-28 03:07:30 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 17, 2023):

So you have other HTTP monitors, but they are working fine, except these 2?
What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally?
The timeout parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor?

1.23.5-beta.0 is also out so you may try it to see if it improves the situation.

@chakflying commented on GitHub (Nov 17, 2023): - So you have other HTTP monitors, but they are working fine, except these 2? - What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally? - The `timeout` parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor? `1.23.5-beta.0` is also out so you may try it to see if it improves the situation.

deekerman commented

2026-02-28 03:07:30 -05:00

Author

Owner

@desquinn commented on GitHub (Nov 17, 2023):

Have reverted to previous version but other https checks with https / Letsencrypt were behaving okay. Just checked and we have another equivalent router with a draytek ddns record that did not fail.
When it fails it goes to retry generating fails and same error messages. Did not see it ever come back with a positive result
Also tried to pause the two failing checks and it seemed to reactivate them and "pull down" the parent.
I did not vary the timeout but will upgrade a bit later and retry with varying the timeout.

I may try the beta as well.

@desquinn commented on GitHub (Nov 17, 2023): - Have reverted to previous version but other https checks with https / Letsencrypt were behaving okay. Just checked and we have another equivalent router with a draytek ddns record that did not fail. - When it fails it goes to retry generating fails and same error messages. Did not see it ever come back with a positive result - Also tried to pause the two failing checks and it seemed to reactivate them and "pull down" the parent. - I did not vary the timeout but will upgrade a bit later and retry with varying the timeout. I may try the beta as well.

deekerman commented

2026-02-28 03:07:30 -05:00

Author

Owner

@louislam commented on GitHub (Nov 17, 2023):

So you have other HTTP monitors, but they are working fine, except these 2?

What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally?

The timeout parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor?

1.23.5-beta.0 is also out so you may try it to see if it improves the situation.

1.23.5-beta.0 do not include https://github.com/louislam/uptime-kuma/pull/4044 yet.

@louislam commented on GitHub (Nov 17, 2023): > * So you have other HTTP monitors, but they are working fine, except these 2? > > * What is the behavior of the monitor? Does it go into retry (pending)? Does it change status to up occasionally? > > * The `timeout` parameter for a monitor was recently introduced. Does changing its value result in different behavior for the monitor? > > > `1.23.5-beta.0` is also out so you may try it to see if it improves the situation. `1.23.5-beta.0` do not include https://github.com/louislam/uptime-kuma/pull/4044 yet.

deekerman commented

2026-02-28 03:07:30 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 1, 2023):

@desquinn
github.com/louislam/uptime-kuma@b383392e8f was merged and is avaliable since the v1.23.5 release.
=> I am assuming this issue is fixed.

If it is not, could you please comment, so we can debug this further? ^^

@CommanderStorm commented on GitHub (Dec 1, 2023): @desquinn https://github.com/louislam/uptime-kuma/commit/b383392e8f962009ed68a5a086889c2ffab660c1 was merged and is avaliable since the `v1.23.5` release. => I am assuming this issue is fixed. If it is not, could you please comment, so we can debug this further? ^^