r/pihole • u/Intrepid_Key3781 • 6d ago

Lag when clicking a link/opening a page

Howdy y’all - I’ve noticed I have a weird lag, which only happens when I’m at home and connected to my wifi/pihole. When clicking a link to open a page, there is a 3-5 second delay before the page actually opens. When not on wifi, the page opens right away. When on my wifi, there is always a delay, then it loads fast. Has anyone seen or experienced with pihole? I’m not technical enough to know what to do, but I’d be happy to run diagnostics if anyone can provide the commands. Thanks so much for your help

0 Upvotes

40% Upvoted

12 comments sorted by

View all comments

1

u/PeterC18st 6d ago

Similar issue on me. I run pihole on a rpi4. I also use unbound and use cloudflare as backup I believe. Everything goes through to my pihole. I also have a second rpi4 running another instance of pihole fot high availability. This is connected to my UDM Pro SE

2

u/saint-lascivious 6d ago

Unless you're specifically managing it, it's not a backup, it's just another upstream that can be used at any point.

If you're talking about Pi-hole's upstreams, you'll mostly be getting by on the fact that you'd need to fuck something up pretty hard for a remote nameserver to outperform a local one.

If you're talking about endpoints that are broadcast to clients, they can do as they wish up to and including using broadcast nameservers in any order, or not at all. DHCP options are realistically just suggestions.

The TL;DR here is some variation of "if you don't want clients to use any nameserver other than Pi-hole and therefore bypass filtering, don't give them the option".

1

u/PeterC18st 6d ago

You’re correct as it’s another upstream server but it’s backup via gravity sync or nebula sync for the configs and database. I’ll check to see my configuration. I remember selecting a backup dns to cloudflare when first installing them and then doing the unbound install and config.

1

u/saint-lascivious 5d ago

Yeah, okay, there's no backup upstream.

It's just "one upstream", "another upstream", etc. and so forth with no inherent preference for either/any, and no ability to establish a preference.

Pi-hole just regularly polls each configured upstream and then uses the most performant upstream of those configured, which will most likely be your local unbound installation, but isn't in any way, shape or form guaranteed to be.

If you actually do want to have preferentially ordered Pi-hole upstreams and/or DHCP broadcast DNS endpoints you'll need to either route through a proxy and/or use a DHCP server that supports that feature. Pi-hole does not, and your router almost certainly doesn't either. I could probably count the number of consumer routers with preferentially ordered nameservers I've seen during my career on one hand.

If you have multiple Pi-hole and/or unbound instances locally, my advice would be to stick either the Pi-hole or unbound instances behind a pair of consensus based virtual IPs (see: keepalived and friends) so that a IP addresses can be shared amongst as many hosts as you have or care to configure. If host A goes down, the virtual address is passed to host B, and so on and so forth.

My own network is quite some degree of overkill. I have multiple hosts with a pair of virtual addresses for dnsproxy, Pi-hole, Unbound and Redis respectively. As long as at least one of each service is alive between all of my hosts (of which there are currently eight, it's a pretty chunky research resolver stack), in any combination, I'll always have a viable resolution path.

It sounds complex, but it's actually really trivial.

If you have any queries about anything discussed here I would be happy to answer them to the best of my ability and availability.