starred/uptime-kuma

Fork 0

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

axios parsed IPv6 as hostname (through proxy) #2463

New issue

Open

opened 2026-02-28 02:55:42 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 02:55:42 -05:00

Owner

Originally created by @SkwalExe on GitHub (Aug 11, 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

Description

I have an HTTP monitor that must use IPv6 only, to do that, I set the URL directly to the IPv6 address, disable redirects, and configure the hostname manually inside the custom HTTP Headers field.

I configured a proxy. The requests are failing, due to a bug in Uptime Kuma.

I know that there is a bug by looking at the proxy's logs.

...
1691789385.312      0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- -
1691789389.945      0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- -
...

We can see the request going to 2a01:443, which is incorrect.

The correct output should be [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443

I took a quick look at the code and the problem seems to come from the axios lib, I may be wrong.

👟 Reproduction steps

create a "ipv6 only" (as explained above) HTTP monitor, passing through a proxy.

👀 Expected behavior

The request is sent normally

to [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443

😓 Actual Behavior

the request is sent to an incorrect address : 2a01:443

🐻 Uptime-Kuma Version

latest beta.1

💻 Operating System and Arch

Ubuntu 22.04

🌐 Browser

Doesn't matter.

🐋 Docker Version

Not running in docker

🟩 NodeJS Version

📝 Relevant log output

1691789626.164      0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- -
1691789630.759      0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- -

Originally created by @SkwalExe on GitHub (Aug 11, 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) ### Description I have an HTTP monitor that must use IPv6 only, to do that, I set the URL directly to the IPv6 address, disable redirects, and configure the hostname manually inside the custom HTTP Headers field. ![image](https://github.com/louislam/uptime-kuma/assets/69600456/83946db4-cf24-4faa-b105-5a5c1a2d60a0) ![image](https://github.com/louislam/uptime-kuma/assets/69600456/e15494c8-1c04-45c2-930a-a897cc96eb5d) I configured a proxy. The requests are failing, due to a bug in Uptime Kuma. ![image](https://github.com/louislam/uptime-kuma/assets/69600456/655dbb0f-a560-44bb-a90b-9118ef265724) I know that there is a bug by looking at the proxy's logs. ```bash ... 1691789385.312 0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- - 1691789389.945 0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- - ... ``` We can see the request going to `2a01:443`, which is incorrect. The correct output should be `[2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443` I took a quick look at the code and the problem seems to come from the axios lib, I may be wrong. ### 👟 Reproduction steps create a "ipv6 only" (as explained above) HTTP monitor, passing through a proxy. ### 👀 Expected behavior The request is sent normally to `[2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443` ### 😓 Actual Behavior the request is sent to an incorrect address : `2a01:443` ### 🐻 Uptime-Kuma Version latest beta.1 ### 💻 Operating System and Arch Ubuntu 22.04 ### 🌐 Browser Doesn't matter. ### 🐋 Docker Version Not running in docker ### 🟩 NodeJS Version 16 ### 📝 Relevant log output ```shell 1691789626.164 0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- - 1691789630.759 0 82.66.235.227 NONE_NONE/500 0 CONNECT 2a01:443 skwid HIER_NONE/- - ```

deekerman added the

bug

A:monitor

type:enhance-existing

blocked-upstream

labels

2026-02-28 02:55:42 -05:00

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 11, 2023):

First of all: Thank you for taking the time to write such a detailed issue.

I think this is a bug upstream, see https://github.com/axios/axios/issues/5333
⇒ I don't see us being able to solve this
⇒ leaving this issue open despite us not being able to do anything about this issue is reasonable

create a "ipv6 only" (as explained above) HTTP monitor

I don't think this needs to be a distinct monitor.
⇒ tracked in https://github.com/louislam/uptime-kuma/issues/1242

@CommanderStorm commented on GitHub (Aug 11, 2023): First of all: Thank you for taking the time to write such a detailed issue. I think this is a bug upstream, see https://github.com/axios/axios/issues/5333 ⇒ I don't see us being able to solve this ⇒ leaving this issue open despite us not being able to do anything about this issue is reasonable > create a "ipv6 only" (as explained above) HTTP monitor I don't think this needs to be a distinct monitor. ⇒ tracked in https://github.com/louislam/uptime-kuma/issues/1242

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@SkwalExe commented on GitHub (Aug 12, 2023):

I bumped the axios version to 1.0.0 locally and uptime kuma started without any error. This fixed the issue

1691829367.068    145 82.66.235.227 TCP_TUNNEL/200 4562 CONNECT [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443 skwid HIER_DIRECT/2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b -
1691829370.735    143 82.66.235.227 TCP_TUNNEL/200 4562 CONNECT [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443 skwid HIER_DIRECT/2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b -

But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason.

WARN: Monitor #1 'test': Failing: Hostname/IP does not match certificate's altnames: Host: [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]. is not in the cert's altnames: DNS:mail.skwal.net, DNS:skwal.net | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0

I think we should use axios 1.0.0 since it is the only solution, and fix the ssl certificate valitation.

Also in the axios releases page there aren't any breaking changes from 0.27.0 (current version) to 1.0.0.

I read CONTRIBUTING.md and I know that the library shouldn't' be updated but it is the only solutions.

Update Dependencies
Since previously updating Vite 2.5.10 to 2.6.0 broke the application completely, from now on, it should update patch release version only.
Patch release = the third digit (Semantic Versioning)
If for maybe security reasons, a library must be updated. Then you must need to check if there are any breaking changes.

@SkwalExe commented on GitHub (Aug 12, 2023): I bumped the axios version to 1.0.0 locally and uptime kuma started without any error. This fixed the issue ``` 1691829367.068 145 82.66.235.227 TCP_TUNNEL/200 4562 CONNECT [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443 skwid HIER_DIRECT/2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b - 1691829370.735 143 82.66.235.227 TCP_TUNNEL/200 4562 CONNECT [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]:443 skwid HIER_DIRECT/2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b - ``` But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason. ``` WARN: Monitor #1 'test': Failing: Hostname/IP does not match certificate's altnames: Host: [2a01:e0a:c99:6170:907b:a8ff:fe6c:4f3b]. is not in the cert's altnames: DNS:mail.skwal.net, DNS:skwal.net | Interval: 60 seconds | Type: http | Down Count: 0 | Resend Interval: 0 ``` I think we should use axios 1.0.0 since it is the only solution, and fix the ssl certificate valitation. Also in the [axios releases page](https://github.com/axios/axios/releases?page=3) there aren't any breaking changes from 0.27.0 (current version) to 1.0.0. I read CONTRIBUTING.md and I know that the library shouldn't' be updated but it is the only solutions. > Update Dependencies > Since previously updating Vite 2.5.10 to 2.6.0 broke the application completely, from now on, it should update patch release version only. > Patch release = the third digit ([Semantic Versioning](https://semver.org/)) > If for maybe security reasons, a library must be updated. Then you must need to check if there are any breaking changes.

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 12, 2023):

Changes to dependency are also possible in case this solves bugs and does not introduce significant breaking changes.
We are currently at the start of the v2.0 Merge-window => even if this is breaking, we could merge this.

Could you test if the following is a breaking change and propose a PR?

But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason

@CommanderStorm commented on GitHub (Aug 12, 2023): Changes to dependency are also possible in case this solves bugs and does not introduce significant breaking changes. We are currently at the start of the `v2.0` Merge-window => even if this is breaking, we could merge this. Could you test if the following is a breaking change and propose a PR? > But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@chakflying commented on GitHub (Aug 12, 2023):

Please be aware that axios#5333 is a post 1.0 issue according to their report. I'm not sure how you got it working, but we should be careful to not break other things while fixing this.

@chakflying commented on GitHub (Aug 12, 2023): Please be aware that [axios#5333](https://github.com/axios/axios/issues/5333) is a **post 1.0** issue according to their report. I'm not sure how you got it working, but we should be careful to not break other things while fixing this.

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@SkwalExe commented on GitHub (Aug 12, 2023):

@CommanderStorm,

But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason

When creating a monitor with the IP directly in the URL, and setting the Host header manually, I don't really know if the SSL certificate hosts are supposed to be compared to the Host header. So this behavior may not be a bug, someone should clarify that.

Validating the SSL cert with the Host header is useful because it allows the cert to be valid when creating a monitor with the IP directly in the URL field. If a feature allowing to enter the IP address to which send the requests without making any DNS requests is added than it is not a problem.

Also, what do you mean by

I don't think this needs to be a distinct monitor.
⇒ tracked in https://github.com/louislam/uptime-kuma/issues/1242

I need a monitor to only make requests to my servers using their IPv6 address because they are behind a reverse proxy, and there are two different configurations for IPv4 and IPv6 on the server that I am monitoring. I didn't see any solutions in #1242.

@SkwalExe commented on GitHub (Aug 12, 2023): @CommanderStorm, > But now, the custom "Host" header doesn't validate the ssl certificate anymore for some reason When creating a monitor with the IP directly in the URL, and setting the Host header manually, I don't really know if the SSL certificate hosts are supposed to be compared to the Host header. So this behavior may not be a bug, someone should clarify that. Validating the SSL cert with the Host header is useful because it allows the cert to be valid when creating a monitor with the IP directly in the URL field. If a feature allowing to enter the IP address to which send the requests without making any DNS requests is added than it is not a problem. Also, what do you mean by > I don't think this needs to be a distinct monitor. > ⇒ tracked in https://github.com/louislam/uptime-kuma/issues/1242 I need a monitor to only make requests to my servers using their IPv6 address because they are behind a reverse proxy, and there are two different configurations for IPv4 and IPv6 on the server that I am monitoring. I didn't see any solutions in #1242.

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@SkwalExe commented on GitHub (Aug 12, 2023):

@chakflying, you're right. I think I know why it was working but it doesn't matter. Its a post 1.0.0 bug that was apparently fixed in axios#573.

The pr was created a week ago and has not been merged yet. So we will have to wait for the pr to be merged and for the next release to come out. Going from 0.27.0 to 1.4.0 doesn't include any (documented) breaking changes, you can check on the axios' release page.

@SkwalExe commented on GitHub (Aug 12, 2023): @chakflying, you're right. I think I know why it was working but it doesn't matter. Its a post 1.0.0 bug that was apparently fixed in [axios#573](https://github.com/axios/axios/pull/5731). The pr was created a week ago and has not been merged yet. So we will have to wait for the pr to be merged and for the next release to come out. Going from 0.27.0 to 1.4.0 doesn't include any (documented) breaking changes, you can check on the axios' release page.

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 12, 2023):

Going from 0.27.0 to 1.4.0 doesn't include any (documented) breaking changes, you can check on the axios' release page.

Yea, but that is because 1.x includes undocumented deprecations (at least I was unable to find the full notes the following statement is refering to) going from 0.x to 1.x:

There are multiple deprecations, refactors and fixes provided in this release. Please read through the full release notes to see how this may impact your project and use case.

There really is no way to know what changed, given that

there is no migration guide between 0.x and 1.x (https://github.com/axios/axios/discussions/4996)
- https://github.com/axios/axios/blob/main/UPGRADE_GUIDE.md does not includes a mention of said version or
- https://github.com/axios/axios/blob/v1.x/MIGRATION_GUIDE.md includes any content
the release log is also not helpful, as it is basically just a list of merged PRs

⇒ What changes would need to be made is unclear to me.
⇒ This seems quite risky (but with a payoff and enough testing likely something we could include in the v2.0 release)
Am I missing something?

@CommanderStorm commented on GitHub (Aug 12, 2023): > Going from 0.27.0 to 1.4.0 doesn't include any (documented) breaking changes, you can check on the axios' release page. Yea, but that is because 1.x includes undocumented deprecations (at least I was unable to find the full notes the following statement is refering to) going from 0.x to 1.x: > There are multiple deprecations, refactors and fixes provided in this release. Please read through the full release notes to see how this may impact your project and use case. There really is no way to know what changed, given that - there is no migration guide between 0.x and 1.x (https://github.com/axios/axios/discussions/4996) - https://github.com/axios/axios/blob/main/UPGRADE_GUIDE.md does not includes a mention of said version or - https://github.com/axios/axios/blob/v1.x/MIGRATION_GUIDE.md includes any content - the release log is also not helpful, as it is basically just a list of merged PRs ⇒ What changes would need to be made is unclear to me. ⇒ This seems quite risky (but with a payoff and enough testing likely something we could include in the `v2.0` release) Am I missing something?

deekerman commented

2026-02-28 02:55:47 -05:00

Author

Owner

@SkwalExe commented on GitHub (Aug 12, 2023):

Updating Axios may not be the solution. I took a look at the "fix pr" mentioned in 5731, and it doesn't seem to fix the error. I confirmed it by replicating the pr changes locally.

Also, I think I solved the axios bug locally, but found other bugs preventing me from configuring the proxy as I described in the issue description. This issue will be very hard to fix...

if you want to reproduce, here is how to fix the bug :

after npm install... etc, I edited the axios sources manually from the node_modules directory

/lib/adapters/http.js line 402

the [] were not present in the ipv6 address and thus the first : was treated a the separation between the IP and the port

parsed.hostname doesn't contain the brackets, but parsed.host does. So I just replaced parsed.hostname to parsed.host

@SkwalExe commented on GitHub (Aug 12, 2023): Updating Axios may not be the solution. I took a look at the "fix pr" mentioned in [5731](https://github.com/axios/axios/pull/5731), and it doesn't seem to fix the error. I confirmed it by replicating the pr changes locally. Also, I think I solved the axios bug locally, but found other bugs preventing me from configuring the proxy as I described in the issue description. This issue will be very hard to fix... if you want to reproduce, here is how to fix the bug : after npm install... etc, I edited the axios sources manually from the node_modules directory > /lib/adapters/http.js line 402 the [] were not present in the ipv6 address and thus the first `:` was treated a the separation between the IP and the port `parsed.hostname` doesn't contain the brackets, but `parsed.host` does. So I just replaced `parsed.hostname` to `parsed.host`