starred/uptime-kuma

Fork 0

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

DNS monitor not working when running on same host as Adguard Home DNS Server #1740

New issue

Closed

opened 2026-02-28 02:31:03 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 02:31:03 -05:00

Owner

Originally created by @jschwalbe on GitHub (Jan 5, 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

2023-01-05T23:18:30-05:00 [MONITOR] WARN: Monitor #3 'DNS': Failing: queryA ETIMEOUT google.com | Interval: 20 seconds | Type: dns | Down Count: 0 | Resend Interval: 0

My home setup is as follows: the main IP of the server running my AdGuard DNS server & Uptime-Kuma is 192.168.1.81. If I add a DNS monitor with that same IP address, I get the error above. Changing the server to 1.1.1.1 or 8.8.8.8 works correctly, immediately. I also have a cloned AdGuard server on a different machine. Switching the IP to that machine, 192.168.1.100, works fine.

When I run a shell from the docker, I am able to ping the above IP. (The shell doesn't seem to have nslookup or dig, so I cannot try connecting to the server as far as I can tell.)

Is it a docker thing that I've set up incorrectly? I'm not great with networking within docker, so I wouldn't be too surprised.

👟 Reproduction steps

Set up Uptime-Kuma within docker.
Set up an AdGuard server on the same host, within docker.
Set up w/ a DNS monitor to monitor google.com, with server as the same IP that the server is running both AdGuard & Uptime-Kuma (in my case 192.168.1.81).
Load AdGuard and watch the requests coming in appropriately.

👀 Expected behavior

It should show me when DNS resolves and when it doesn't.
(My goal is to know if AdGuard fails for some reason.)

😓 Actual Behavior

It does not work.

🐻 Uptime-Kuma Version

1.19.2

💻 Operating System and Arch

Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux

🌐 Browser

Edge

🐋 Docker Version

No response

🟩 NodeJS Version

No response

📝 Relevant log output

2023-01-05T23:18:30-05:00 [MONITOR] WARN: Monitor #3 'DNS': Failing: queryA ETIMEOUT google.com | Interval: 20 seconds | Type: dns | Down Count: 0 | Resend Interval: 0

Originally created by @jschwalbe on GitHub (Jan 5, 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 ``` 2023-01-05T23:18:30-05:00 [MONITOR] WARN: Monitor #3 'DNS': Failing: queryA ETIMEOUT google.com | Interval: 20 seconds | Type: dns | Down Count: 0 | Resend Interval: 0 ``` My home setup is as follows: the main IP of the server running my AdGuard DNS server & Uptime-Kuma is 192.168.1.81. If I add a DNS monitor with that same IP address, I get the error above. Changing the server to 1.1.1.1 or 8.8.8.8 works correctly, immediately. I also have a cloned AdGuard server on a different machine. Switching the IP to that machine, 192.168.1.100, works fine. When I run a shell from the docker, I am able to ping the above IP. (The shell doesn't seem to have nslookup or dig, so I cannot try connecting to the server as far as I can tell.) Is it a docker thing that I've set up incorrectly? I'm not great with networking within docker, so I wouldn't be too surprised. ### 👟 Reproduction steps Set up Uptime-Kuma within docker. Set up an AdGuard server on the same host, within docker. Set up w/ a DNS monitor to monitor google.com, with server as the same IP that the server is running both AdGuard & Uptime-Kuma (in my case 192.168.1.81). Load AdGuard and watch the requests coming in appropriately. ### 👀 Expected behavior It should show me when DNS resolves and when it doesn't. (My goal is to know if AdGuard fails for some reason.) ### 😓 Actual Behavior It does not work. ### 🐻 Uptime-Kuma Version 1.19.2 ### 💻 Operating System and Arch Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux ### 🌐 Browser Edge ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output ```shell 2023-01-05T23:18:30-05:00 [MONITOR] WARN: Monitor #3 'DNS': Failing: queryA ETIMEOUT google.com | Interval: 20 seconds | Type: dns | Down Count: 0 | Resend Interval: 0 ```

deekerman

2026-02-28 02:31:03 -05:00

closed this issue
added the
help
label

deekerman commented

2026-02-28 02:31:08 -05:00

Author

Owner

@louislam commented on GitHub (Jan 6, 2023):

As 1.1.1.1 is working, I believe it is a network issue on your side. Please see wiki > troubleshooting.

@louislam commented on GitHub (Jan 6, 2023): As 1.1.1.1 is working, I believe it is a network issue on your side. Please see wiki > troubleshooting.

deekerman commented

2026-02-28 02:31:08 -05:00

Author

Owner

@jschwalbe commented on GitHub (Jan 7, 2023):

Thanks for the ideas. Ended up having to remove the 192.168.* address and instead put in 172.100.0.2. Also put them both on the bridge network. Not sure why I couldn't use 192.168.* though. Appreciate the help!

@jschwalbe commented on GitHub (Jan 7, 2023): Thanks for the ideas. Ended up having to remove the 192.168.* address and instead put in 172.100.0.2. Also put them both on the `bridge` network. Not sure why I couldn't use 192.168.* though. Appreciate the help!

deekerman commented

2026-02-28 02:31:08 -05:00

Author

Owner

@Danie10 commented on GitHub (Aug 25, 2024):

@jschwalbe think I solved the IP address issue for 192.168.*. I specified AdGuardHome to join the host network, and that made the DNS test work to the host IP address. Added the following in the docker-compose for the AdGuardHome service:

network_mode: host

@Danie10 commented on GitHub (Aug 25, 2024): @jschwalbe think I solved the IP address issue for 192.168.*. I specified AdGuardHome to join the host network, and that made the DNS test work to the host IP address. Added the following in the docker-compose for the AdGuardHome service: ``` network_mode: host ```

deekerman referenced this issue

2026-02-28 02:49:14 -05:00

Query often without taking up tons of database space #2280

deekerman referenced this issue

2026-02-28 04:08:31 -05:00

Unable to reduce minimum interval below 20 seconds #4590