mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Very slow HTTPS (even to hosts in the same network) #369
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#369
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nguadagno on GitHub (Oct 9, 2021).
Is it a duplicate question?
Couldn't find anything
Describe the bug
HTTP(S) requests take a tremendous long time.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Pings in the same local network should not be over 500 ms, but they are.
Info
Uptime Kuma Version: 1.7.3
Using Docker?: Yes
Docker Version: Docker version 20.10.7, build 20.10.7-0ubuntu1~20.04.2
OS: Ubuntu server 20.04 LTS kernel 5.4.0-88-generic
Browser: Firefox 93.0
Docker logs:
Monitor #2 is going a public DNS record, but the host is on the same virtual machine and all my other machines in the same network take <1ms to get to it.
Monitor #1 is a remote host that normally has around ~50ms ping from my network.
Monitor #3 is also a public DNS record that points to my public IP and, again, its <1ms for all the other hosts, but a lot higher from Kuma.
It's not really a problem since it works fine, but I'd like them to be quicker, so that I can spot problems quicker. I'm guessing this is because Kuma doesn't use any DNS caching (or the local adguard server) but goes throught the NS every time. Is there any way to improve this?
@louislam commented on GitHub (Oct 9, 2021):
DNS cache was discussed before, I cannot find the thread.
I remember that, the conclusion is that Node.js do not provide dns cache function. It is not easy to add this on my own.
A workaround: specify --dns "your local server" in the
docker runcommand.@chengunm commented on GitHub (Oct 9, 2021):
I konwed it, thank you wery much.
------------------ 原始邮件 ------------------
发件人: "louislam/uptime-kuma" @.>;
发送时间: 2021年10月10日(星期天) 中午11:46
@.>;
@.***>;
主题: Re: [louislam/uptime-kuma] Very slow HTTPS (even to hosts in the same network) (#628)
DNS cache was discussed before, I cannot find the thread.
I remember that, the conclusion is that Node.js do not provide dns cache function. It is not easy to add this on my own.
A workaround: specify --dns "your local server" in the docker run command.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
@nguadagno commented on GitHub (Oct 10, 2021):
@louislam I've tried that but nothing seems to improve.
@gaby commented on GitHub (Oct 10, 2021):
@louislam Thoughts on this library: https://www.npmjs.com/package/cacheable-lookup
They have full dns lookup examples here: https://httptoolkit.tech/blog/configuring-nodejs-dns/
There's also an axios compatible one here: https://npmjs.com/package/axios-cached-dns-resolve
@nguadagno commented on GitHub (Oct 10, 2021):
Somehow it managed to get even worse...
For now I'll go back to some other uptime monitor, Kuma is not very usable in my case as it is right now. I'll keep checking in on it since I really love the idea and I'll try again in a few months. I'm very sorry :/
@chakflying commented on GitHub (Oct 10, 2021):
Wow this is exactly what we need! The axios one is in ESM tho, I'm not sure if we can use it.
@louislam commented on GitHub (Oct 10, 2021):
Is the TTL of that record too short?
I believe your local dns server should cache the record for you.
And also make sure you are not using the alpine tag.
@gaby commented on GitHub (Oct 10, 2021):
It seems like nodejs natively suffers from DNS caching issues. There's a huge discussion about it here: https://github.com/nodejs/node/issues/8436
Suggested solutions are:
@nguadagno commented on GitHub (Oct 10, 2021):
TTL is 300 for some of the records and 150 for others, it's longer than the interval of the monitors.
I'm using the
:1tag, as listed in the README.@CristianT commented on GitHub (Feb 23, 2022):
I think this should be moved back to a bug since there is something messed up with the name resolution.
I setup various monitors an name resolution seems to take 5s, or 10s to 12s
If I monitor https://google.com reponse times are regularly between 10400ms and 10600ms.
To discard SSL, response time in http://www.testingmcafeesites.com/ are from 10500ms to 10800ms.
My local router http site using ip address takes from 500ms to 700ms to check
My local grafana healthcheck endpoint https://grafana.mydomain.local/api/health consistently replies between 5010ms and 5015ms, but sometimes it takes 10100ms
One particularity of my system is that I'm running Adguard to filter ads and malicious site, but the response is very fast, plus I have rewritten mydomain.local and it returns a local IP within 0.02ms, and other sites are returned within 26ms, google is even faster.
Running version 1.11.4 in a docker container (louislam/uptime-kuma:1)
@CristianT commented on GitHub (Feb 23, 2022):
Here is an update:
I installed dnsutils in the uptime-kuma container and the manual name resolution works fine in time and value, but it states the following message:
;; reply from unexpected source: 172.17.0.1#53, expected 192.168.3.11#53
where 172.17.0.x is my docker network and 192.168.3.x is my home LAN. The problem is this adguard instance is running in a container in the same docker host.
I changed the host DNS to 1.1.1.1 and the times are as expected.
I changed it again to an adguard instance outside docker but in my network and times are also as expected.
Aparently I'm not only one with tha issue:
https://forums.docker.com/t/dns-issues-with-local-resolver-and-containers-on-the-same-host/102319/8
The thing is that all the containers I have running in this instance work correctly, the only one with issues that I know is uptime kuma. So in my opinion there are 2 issues, one is the 'unexpected source' message from the docker setup, and the other is that uptime kuma is maybe too strict in the dns queries origin (not sure if on purpose or by chance).
@Saibamen commented on GitHub (Oct 7, 2022):
Fixed in axios-cached-dns-resolve
https://github.com/tcollinsworth/axios-cached-dns-resolve/issues/27