After installing Pi-hole, one thing breaks — a bank login loops, a shopping app refuses to load offers, a link from an email goes nowhere. The fix is almost never 'turn Pi-hole off'. It is finding the one blocked domain that page needed, and whitelisting exactly that.
Blocking works by domain, and some sites quietly depend on a domain that also appears on blocklists — a login helper, a payment service, a 'click tracker' that an email link must pass through before reaching the real page. When Pi-hole blanks that one domain, the visible symptom is a broken site, not an ad. This guide shows the calm method: reproduce the problem, watch the query log at that moment, and whitelist the single domain responsible — never the whole list, never the whole site blindly.
Do not guess. Prove it in thirty seconds: in the dashboard, use Disable Blocking for a short timed period (for example 5 minutes) and repeat the exact action that failed. If it now works, Pi-hole's blocking is involved and you proceed. If it still fails, the problem is elsewhere — a site outage, an app bug — and whitelisting would only poke holes for no benefit. Re-enable blocking straight away either way; the timed disable turns itself back on, which is why it is the safe way to test.
Open the dashboard's Query Log, then perform the failing action once more on the affected device — click the email link, press the login button, open the app feature. Refresh the log and look at entries from that device at that second, marked Blocked. Usually one blocked domain stands out, requested at the exact moment of failure. That domain is your suspect. This live-log method is the difference between fixing a site in two minutes and guessing for an evening.
In the query log you can whitelist the blocked domain directly from its row, or add it under the dashboard's whitelist (Domains section). From the terminal the same job is pihole -w the-domain.example. Whitelist the exact domain shown — not its parent, not a wildcard — and then test the site again. If it works, you are done, and your blocking is weakened by precisely one domain.
Occasionally a service needs two or three related domains (a login domain plus a payment domain, for example). Repeat the same loop: act, watch the log, whitelist the next blocked domain that appears at the failure moment. Stop as soon as the site works. Also check from the terminal with pihole -q the-domain.example — it shows which blocklist contains a domain, which is useful if a domain you trust is being blocked for the whole house.
Every whitelist entry is a small permanent hole in your blocking, so treat the list like a guest list: small and reviewable. Add a comment in the dashboard noting why each domain was whitelisted ('bank login', 'school app'). Once in a while, scan the list — entries for services you no longer use can come back out. A tidy whitelist keeps both promises of Pi-hole at once: sites work, and blocking stays strong.
Dashboard ki pehchan aur setup ki buniyaad video me live hai — whitelist wala kaam usi dashboard se hota hai.
▶️ Watch Full VideoReproduce the failure while watching the dashboard Query Log. The blocked entry from your device, at the exact second of the failed click, is almost always the culprit. Whitelist that single domain and test again before adding anything else.
It re-allows everything from that one domain, on the whole network. That is why the rule is exact domains only, added one at a time, each with a reason noted. A handful of considered entries is normal maintenance; dozens of broad entries means something else is wrong.
Often, yes. Marketing and notification emails route clicks through tracking domains that blocklists legitimately contain; the tracker is supposed to forward you to the real page, but Pi-hole blanks it. Find the blocked domain in the query log from your click and whitelist it if you want those links to work — or copy the real destination address from the email instead.