Many DNS queries & slower loading when using URL

[brodieferguson]

Description

1. Initially, I had Homepage set up successfully using docker labels on Server 1. It was fast loading, and widgets loaded API information instantly.
2. I had a second server (Server 2) running additional Docker containers, port forwarded.
3. I then configured Homepage (Server 1) with Widgets/APIs from Server 1 (docker labels) + Server 2 (services.yaml with ip:port), which worked fast as well.

Transition to Caddy + AdGuard

1. Switched to using Caddy + AdGuard local DNS rewrite.
2. Updated the services.yaml to use http://server2.lan instead of http://ip.address:port, which started slowing down the load time of API information.
3. Implemented Docker proxy on Server 2, updated docker.yaml and switched from services.yaml to docker labels. Now everything is autoconfigured, but the API information takes a few seconds to populate compared to being instant with the IP method.

Observation

• AdGuard Log: Homepage is the top requester, with up to 10s of requests per second for dockerproxy.server2.lan and quite a few per servicename.server2.lan.
• Having Homepage open for just minutes at a time has generated tens of thousands of DNS requests in the last 24 hours.
• Tried NGINX as well as Caddy, and also started a fresh homepage install in a devcontainer with just one service listed. AdGuard still showed many DNS requests for that service within seconds.
• Accessing local domain names and services work fine and quickly from other projects.
• Curling the APIs also gives an instant response.

I'm quite puzzled as there doesn't seem to be any latency related to DNS/Proxy if I was to manually curl, etc. Homepage worked fine with an IP based setup. I'm wondering if adding so many DNS lookups that don't seem to be temporarily grouped/cached could be hitting some sort of bottleneck.

homepage version

v0.8.13 (986a181, May 5, 2024)

Installation method

Docker

Configuration

No response

Container Logs

No response

Browser Logs

No response

Troubleshooting

No errors on curl, container logs, or browser.

[glime-ai[bot]]

Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer below is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course!

Thanks for using Homepage! ❤️

---

Based on the information provided, it seems that the issue you're experiencing with slow API information load times after transitioning to using Caddy + AdGuard with local DNS rewrites might be related to DNS resolution performance. Here are a few steps you can take to troubleshoot and potentially resolve the issue:

1. DNS Caching: Ensure that AdGuard or your network setup has DNS caching enabled. This will help reduce the number of DNS queries by caching the responses for a certain period.

2. Homepage DNS Configuration: Check if Homepage has any DNS configuration settings that can be adjusted to reduce the frequency of DNS lookups or to enable DNS caching.

3. Network Analysis: Use network analysis tools to monitor the DNS traffic and see if there are any patterns or issues with the DNS queries being made by Homepage.

4. Caddy/NGINX Configuration: Review the configuration of Caddy or NGINX to ensure that they are not causing any unnecessary DNS lookups. Look for any settings related to DNS resolution and caching.

5. Homepage Source Code: Since you mentioned that Homepage worked fine with an IP-based setup, consider looking at the Homepage source code to see if there are any hardcoded expectations for IP addresses or if there's a way to optimize DNS lookups.

6. Homepage Community and Support: Reach out to the Homepage community or support channels, such as the GitHub discussions or the Discord channel mentioned in the context, to see if others have experienced similar issues and if there are any known solutions.

7. AdGuard Settings: Review AdGuard settings to ensure that it's not logging or processing DNS requests in a way that could introduce latency.

8. Performance Monitoring: Use performance monitoring tools to analyze the Homepage application's behavior and identify any bottlenecks or performance issues related to DNS resolution.

9. Alternative DNS: Temporarily switch to a different DNS server to see if the issue persists. This can help determine if the problem is specific to AdGuard.

10. Incremental Changes: Revert to the previous working configuration and make incremental changes, monitoring the impact on performance after each change to isolate the cause.

Remember to document each step you take and any changes made, so you can revert them if necessary. If the issue persists, consider filing a detailed bug report with the Homepage developers, including all the troubleshooting steps you've taken.

This comment was generated by Glime.

[brodieferguson]

A combination of switching to HTTPS for all services and ip:port for docker proxy seems to have fixed the speed issue.
I'm still unsure exactly what was the problem as http services plus [no docker proxy & services.yaml for the second server] was slow.

My best guess is something related to the HTTP dns rewrite as that's the only constant over all non-working scenarios. (I'm doing the exact same local DNS rewrite for HTTPS in adguard, but had to use a real domain.)

[marcingrabda]

It seems I am experiencing the same issues. If I specify ip:port in widget configuration (e.g. http://192.168.1.2:9000), then everything works fine. If I go with FQDN (e.g. https://homebridge.mydomain.tld), then Homepage's widget queries start taking seconds per round-trip. Most of the time it is this slowness issue as I described, but on a couple occasions I saw "ENOTFOUND" (DNS resolution error) in homepage.log. Any nslookup, dig, or curl queries executed from the container take milliseconds.

I am using NPM (Nginx Proxy Manager) as the reverse proxy and Adguard Home as the DNS server. I am running the latest version of Homepage (v0.8.13) on Docker CE (26.1.3) deployed using Portainer if that matters.

[shamoon]

Using a fqdn will usually mean your queries go out over the internet before returning back to your server. So yes, slow.

You guys should look into how docker lets you use container names as DNS aliases

[marcingrabda]

These FQDNs are resolved by AdGuard DNS locally to 192.168.1.x, and even if it went over the internet, it would not explain a delay of a few seconds compared to double digit milliseconds when I use IP directly.

I think your idea to use container names still means I would have to specify ports, which is what I am trying to avoid. I want these queries to go through a reverse proxy like everything else in my network.

[brodieferguson]

Is the domain you're using real?

Using Adguard redirects on an http domain name I made up/ didn't own with .lan didn't make homepage happy. Also I had to specify more information in adguard for the fake dns info to get homepage to work with it at all. Other computers and services loaded the domain with a simple rewrite rule.

Then I bought a real .dev domain, used caddy and switched to using real HTTPS. I still obviously do the rewrite part because it's on the local network, but homepage loads instantly again. Given the initial http setup required more fine tuning than most, and the real https domain works, I wonder if it's something to do with how homepage is verifying or querying DNS.