Written 6 Sep 2026. This is a how-to, not a product card.
When browsing feels slow after Pi-hole
Pages hang a few seconds, then load. Ads may still be blocked. Time a DNS lookup, check Pi-hole and its upstream, then prove it with a bypass. You don't need a faster plan tonight.
Haven't installed Pi-hole yet? Start with the first useful thing. One site broken while the rest of the house is fine? That is when a site won't load after Pi-hole. Ads back everywhere? That is when ads come back. This note is the other mess: names still resolve and ads stay blocked, but every new tab sits blank for a beat before it paints. That lag is often DNS, not your ISP plan.
Skip until the house asks Pi-hole
If the router never pointed DNS at the computer, this page will not help. Point it first: point the house at the ad block, or brand menus in point common home routers at Pi-hole. If Pi-hole is down or the admin page is blank, start with when the Pi-hole admin page won't open or when ads come back. You need SSH on the computer, or the admin page on the house network.
What this is
Browsers ask a name server before they fetch a page. When that answer is slow, every new host feels sticky even though a speed test to a number still looks fine. Pi-hole sits in that path. A slow upstream, a overloaded box, or a huge block list can add seconds. You time a lookup, check the computer, then prove it by pointing one laptop past Pi-hole for a minute. You don't buy a mesh kit for this.
Step 1: prove it is DNS, not the WAN
On a laptop on house Wi-Fi, open a site you have not visited today (a fresh name). Feel the hang. Then from the computer over SSH, time a lookup you care about (swap the name):
time dig +short example.com @127.0.0.1
Or, if dig is missing:
time resolvectl query example.com
Under about half a second is usually fine on a quiet house. Multi-second waits, or timeouts, mean the name path is the suspect. Then ping a number past the router (not a name):
ping -c 3 1.1.1.1
Three quick replies mean the WAN path is alive. Slow names with a fine ping to a number is DNS. If even 1.1.1.1 crawls or fails, fix the internet path first: check that the computer can reach the internet.
Step 2: confirm who phones ask
On the computer, confirm Pi-hole is the house answerer people should hit. Status in one line:
pihole status
You want FTL running and blocking on. Then see whether the computer itself is asking a sane name server: see which name server the computer is using. On a phone or laptop, a temporary look at Wi-Fi DNS should show the computer's house address (or the router only if the router forwards to Pi-hole). If devices still ask the ISP directly, point the router again: point common home routers at Pi-hole. One device with Private DNS or a VPN can feel “slow and weird” while others are fine — that walk is closer to when one phone still shows ads or when one laptop still shows ads.
Step 3: check Pi-hole and the box
Open http://pi.hole/admin (or the computer's address plus /admin). On the dashboard, look at recent query rate and whether the page itself loads slowly. From SSH, status is enough:
pihole status
If the computer itself is thrashing (fan loud, load sky high), DNS will feel sticky for the whole house. Free memory and a busy process are separate looks: see if the computer still has free memory, see what is keeping the computer busy. Heat under a pile of clothes is don't cook the computer. Disk packed so logs and gravity updates crawl: when the computer's disk is full.
A quick name lookup from the computer still helps: look up a site name from the computer. Prefer a site you use, not an ad tracker (blocked names can return 0.0.0.0 on purpose).
Step 4: check the upstream DNS
Pi-hole asks an upstream server for names it has not cached and has not blocked. A bad or far upstream makes every cold name wait. In the admin page open Settings → DNS (wording varies by version) and note which upstreams are checked. Prefer one or two reliable public resolvers close to you (Cloudflare 1.1.1.1, Google 8.8.8.8, or your ISP’s documented DNS). Don't enable every box on the list. Don't turn on DNSSEC troubleshooting rabbit holes on day one.
From SSH you can ask Pi-hole’s own listener, then ask an upstream directly and compare wall time:
time dig +short example.com @127.0.0.1
time dig +short example.com @1.1.1.1
If @1.1.1.1 is fast and @127.0.0.1 is slow, the hang is on the computer or in Pi-hole’s path to its configured upstream. If both are slow, the WAN or the upstream is the problem. Official upstream notes live in the Pi-hole upstream DNS guide.
Step 5: prove it with a one-device bypass
On one laptop only, set Wi-Fi DNS to 1.1.1.1 (and maybe 1.0.0.1) instead of Automatic / router. Renew the lease or toggle Wi-Fi. Browse a few fresh sites. If the hang vanishes on that laptop while the rest of the house still feels sticky, Pi-hole (or the path to it) was the cause. Put that laptop back on Automatic when you are done so ads stay blocked.
Same idea without leaving Pi-hole: pause blocking for five minutes and retry. Blocking off does not always fix a slow upstream, but it rules out a pathological list path:
pihole disable 5m
Turn it back on when the test is done:
pihole enable
If one bank or login is broken rather than slow, stop here and use when a site won't load after Pi-hole or allow a site in Pi-hole on purpose.
Step 6: lists and updates without a shopping trip
A fresh gravity update or a giant extra block list can make the first lookups after a change feel heavy. Update on purpose when you mean to, then re-time a dig:
pihole -up
Weekly OS updates stay on their own note: keep the computer updated. Pi-hole’s own refresh is keep Pi-hole updated. Before you wipe lists or reinstall, save a Pi-hole backup. Don't subscribe to every block list on the internet for a first house.
What this is not
This is not a reason to buy a faster ISP plan, a mesh kit, or a new mini PC on day one. It is not “ads came back.” That checklist is when ads come back. It is not one broken domain that needs an allow. That is when a site won't load after Pi-hole. It is not Unbound, recursive DNS, or DNSSEC homework this weekend. Stay on timing, upstream, and a one-device bypass.
What next
When lookups are quick again, leave the upstream alone for a week. For a calm allow when one site is broken, see allow a site in Pi-hole on purpose. For the query log, see see what Pi-hole blocked. Router pointing still shaky? Point common home routers at Pi-hole. IPv6 still sneaking past? When ads sneak past on IPv6. Share copies crawling while names are fine is a different walk: when the house share is slow.
Optional: jot that house DNS feels fine again in Lab plan — username + passkey, no email. Skip if you just want to keep reading.
Skip
- Skip a faster ISP plan because tabs hang before they paint.
- Skip a mesh kit or a new router for slow DNS.
- Skip Unbound and recursive DNS on day one.
- Skip adding every block list you find on a forum.
- Skip leaving one laptop on
1.1.1.1forever if you still want ads blocked on it. - Skip this if ads are back on every device. That is a different walk.
Sources
Pi-hole docs. Pi-hole: upstream DNS. Pi-hole command (status, disable, enable, -up, -c). Debian: dig. Debian: resolvectl. Official pages only. For install, see the first useful thing. For ads returning house-wide, see when ads come back. For one broken site, see when a site won't load after Pi-hole. For which name server the computer asks, see see which name server the computer is using.