The Wi-Fi is connected, the router lights look fine — but no website opens anywhere in the house. When Pi-hole is your only DNS server, Pi-hole down means internet down. Here is the calm recovery order, and the honest menu of backup plans for next time.
DNS is the phone book of the internet. Devices reach servers by address, but they find addresses by asking DNS — and in your house, that means asking Pi-hole. If the Ubuntu machine is off, crashed, or has lost its own network connection, every device is left holding questions nobody answers. The good news: this failure has a short list of causes and most are fixed in minutes. Work through them in order, resist the urge to change settings randomly, and at the end, pick a redundancy plan with open eyes.
Thirty seconds of diagnosis saves an hour. If devices show Wi-Fi connected but nothing opens, and the outage began suddenly on all devices at once, think DNS first. A quick proof: on any computer, try opening a site by name — it fails. The router's own status page still opens by its address, because that needs no DNS. When the pattern matches, go to the Pi-hole machine, not the router settings.
The humble causes lead the list. Check the Ubuntu machine is powered (power cuts, a switched-off strip, a well-meaning family member), its network cable is seated or its Wi-Fi joined, and it still holds its static address — run ip addr show and compare with the address your router points to. An address mismatch after a router change or a DHCP accident is a classic silent outage: Pi-hole healthy, but at a house number nobody is asking anymore.
On the machine, run pihole status. If blocking shows disabled or the FTL service is down, restart it with sudo systemctl restart pihole-FTL and check status again. If FTL repeatedly dies, the usual suspects are a full disk (logs and the gravity database grow) or a damaged configuration — the dashboard and system logs will say so. A plain reboot of the whole machine is a legitimate early step here: it is a DNS appliance, and a clean restart resolves a surprising share of wedged states.
If the house needs internet now and Pi-hole needs real repair, bypass it consciously: change the router's DHCP DNS back to automatic (your provider's DNS) or a public resolver, and reconnect devices. Everything works again, unfiltered. Write down that you did this. The number of homes running unfiltered for months because an emergency bypass was never reverted is large — set the reminder before you make the change, not after.
Now prevent the sequel, knowing each option's true price. Second Pi-hole: a second machine listed as the other DNS server — real redundancy, but lists and settings must be kept in step on two boxes. Public DNS as secondary: effortless, but devices will use it freely, so blocking leaks randomly — this trades away consistent filtering. Accept and prepare: keep one Pi-hole, keep the bypass steps written down, and keep the machine on a small UPS so power blips stop being outages. For most homes the third option, done knowingly, is the honest sweet spot.
pihole status after each. Randomly reinstalling, re-pointing the router and editing lists in one panic session turns a five-minute service restart into an evening of archaeology.Machine phir se khadi karni ho to pura setup video me hai — installer se router setting tak.
▶️ Watch Full VideoBecause every device asks that machine for DNS — the address lookups behind every website and app. Wi-Fi and the internet connection are fine; the phone book is missing. Restore the Pi-hole service (or its power, or its address) and names start resolving again immediately.
It will keep names resolving, but at a price: devices freely use both servers, so a large share of queries bypass Pi-hole and ads return unpredictably. It converts a rare full outage into permanent partial filtering. A second Pi-hole is the redundancy that does not compromise blocking.
Start with pihole status and the FTL service state, and check the disk is not full — a completely full disk can stop FTL from running. Re-enable blocking from the dashboard once the service is healthy, and look in the logs for why it stopped so it does not repeat.