Pi-hole silent after VPN connects: an empty query log is the tell

Part of our guide on quick fixes for update issues

One filter applied to the query log splits this fault in two, and the two halves need opposite fixes.

Read the query log filtered to the affected client

Say you connect the VPN, the browser hangs on every page, and you start editing blocklists. Stop there. Open the Pi-hole admin page, go to Query Log, and use the client filter to show only the machine that just failed. Leave the VPN up while you do it.

Now watch the log for thirty seconds while you reload a page. Two outcomes matter, and nothing else does.

An empty log means the query never arrived. Your VPN client sent the lookup somewhere else, or the tunnel swallowed the route to the Pi-hole's 192.168.x.x address. Pi-hole cannot answer a question it never hears.

A logged query with no reply means the packet arrived and Pi-hole stayed silent, refused it, or answered from a blocked list. That is a settings problem on the Pi-hole itself, and routing is fine. There is more on how to know if slow internet is router or isp in a separate guide.

Pi-hole DNS stops working after VPN connects

Picture a tunnel that carries everything. A full-tunnel VPN, the default in most clients, routes all traffic including port 53 lookups through the encrypted link. Your device stops asking Pi-hole and asks whatever resolver the VPN provider pushes for the session.

Many VPN clients set their own DNS server for the session, and the operating system accepts it. Pi-hole's address is still configured, but it no longer wins.

The tunnel can also capture the whole 192.168.x.x subnet. If your VPN client routes all traffic, packets to a private LAN address can be sent down the tunnel instead of out to your own router. Pi-hole is then unreachable even though it is sitting on the same network. The other half of this decision is recovering from volume crashes.

Modern browsers add a third layer. Firefox enables DNS-over-HTTPS by default in some regions; Chrome and Edge ship a secure-DNS setting that is usually off but easy to switch on. That app-level resolver skips the operating system setting entirely, so even a working Pi-hole route gets bypassed.

Check the client's current DNS server before you change anything

Before you touch Pi-hole, confirm what DNS server your client is actually using. The VPN may have pushed its own resolver without telling you.

On Linux, run resolvectl status or cat /etc/resolv.conf and look for the nameserver line. On macOS, run scutil --dns | grep nameserver. On Windows, open a command prompt and run ipconfig /all, then find the DNS Servers entry under your active adapter. We go through windows license oem or retail step by step elsewhere on the site.

If the output lists anything other than your Pi-hole's address, the VPN client or your operating system switched resolvers when the tunnel came up. You can fix that in the VPN client's DNS setting, or by excluding the Pi-hole address with split tunneling.

Pi-hole's listen interface and permitted origins settings

Suppose the log shows the query but the status reads refused, or the client retries forever. Pi-hole is answering on the wrong interface or rejecting the source address. Both are one-page fixes in Settings, then DNS.

The listen interface controls which network card Pi-hole answers on. The common choices are a specific adapter (often eth0 on a Raspberry Pi, but check ip addr or ifconfig on your own host to find the name), or all. Localhost-only mode explains refused answers from LAN clients. Before you commit to anything, it is worth looking at how to improve email deliverability for campaigns.

Permitted origins decide which source addresses are allowed at all. Set to 'allow only local requests', Pi-hole accepts just its own subnet. A VPN exit address, or a device whose traffic appears from another interface, falls outside that range and gets dropped.

The setting that catches people is the restart requirement. Changing the listen interface does not take effect until the DNS resolver restarts. Use the restart button in Settings or run pihole restartdns in a terminal.

1. Open Settings, then DNS, and note your current listen interface value.
2. Set it to all, or to the specific LAN adapter (check ip addr or ifconfig for the name), not localhost-only.
3. Check permitted origins and widen it if your clients arrive from outside the Pi-hole's own subnet.
4. Save, then restart the resolver with pihole restartdns or the restart option in the interface.
5. Reload the client page and watch the log for a reply, not just an entry.

Check the firewall on the Pi-hole host

Say the log shows the query arrived but Pi-hole never answered. The listen interface is set to all, permitted origins allows the client, and blocking is off. Check the firewall next. Before you commit to anything, it is worth looking at choose an eSIM for your trip.

A firewall rule on the Pi-hole host can silently drop incoming DNS packets on port 53, or block replies from leaving. The query appears in the log because Pi-hole's logging happens before the kernel firewall runs, but the reply never makes it back to the client.

If you are running ufw, check sudo ufw status and confirm port 53 is allowed. For firewalld, run sudo firewall-cmd --list-all and look for DNS in the services list. For plain iptables, run sudo iptables -L -n and scan for a rule that drops or rejects UDP port 53.

The fix is opening the port. For ufw, run sudo ufw allow 53/udp and sudo ufw allow 53/tcp. For firewalld, run sudo firewall-cmd --add-service=dns --permanent then sudo firewall-cmd --reload. Test again and watch the log for a reply.

Test from a second LAN device while the VPN is up

Say one laptop fails and you blame the Pi-hole. Before you rebuild anything, open a page on a second device on the same network that is not running the VPN. If that device resolves normally, the Pi-hole is healthy and only the first client is broken.

This one-minute test points the fix at the client, its VPN software or its DNS setting. It also protects you from the opposite error, rewriting a working Pi-hole configuration in response to a client problem.

If the second device also fails, the fault is upstream of any client. Check that the Pi-hole machine is powered, that its own internet works, and that your router still hands out its address as DNS. A router reboot can quietly reset the DHCP-assigned DNS server.

Run the test again right after the VPN connects and right after it disconnects. A fault that appears only while the tunnel is up confirms a routing or resolver conflict, not a broken Pi-hole.

Split tunneling the Pi-hole address or leaving the tunnel whole

Picture two ways to keep Pi-hole working with a VPN that has to stay on. Split tunneling sends some traffic outside the tunnel and the rest through it. Leaving the tunnel whole sends everything through, which is simpler but needs a different fix.

Split tunneling wins when you want local filtering to keep working. Add your Pi-hole's private address, 192.168.x.x, to the excluded list so lookups to it bypass the tunnel and stay on your LAN. Everything else still travels encrypted.

Most desktop VPN clients expose this as split tunneling; check your client's documentation for the exact term and menu location. The setting is a few clicks, and it directly targets the empty-log symptom where the tunnel was swallowing the route.

Leaving the tunnel whole is the honest choice when you cannot exclude addresses, or when you are on a locked-down work device. In that case your DNS filtering moves with you only if the VPN provider offers private DNS with custom resolvers, and many do not.

Mobile platforms and per-app DNS

Say your phone loses DNS on the VPN but your laptop does not. Mobile VPN apps often force their own DNS with no option to change it, and mobile operating systems handle DNS differently than desktops.

Android and iOS both support per-app DNS settings. A VPN app can push a resolver that only applies to traffic routed through the tunnel, while other apps still use the system-wide DNS. That split is invisible to Pi-hole, which only sees queries from apps not captured by the VPN.

System-wide DNS on mobile is harder to override. If you set Pi-hole as your DNS in Wi-Fi settings, a VPN can still replace it for the session. Some Android builds let you set a private DNS hostname that survives the VPN connection, but iOS offers no equivalent outside of a profile.

Mobile browsers add another layer. Safari on iOS respects the system resolver, but Chrome and Firefox on Android may enable secure DNS by default, which sends lookups directly to a public resolver over HTTPS and skips Pi-hole entirely. Check the browser's privacy settings and turn off secure DNS for one test.

Prove the query path before you look at blocklists

Say you disable blocking, the site loads, and you conclude the blocklist was at fault. That test proves nothing. Blocking off changes what Pi-hole does with a query, not whether the query arrives.

The order matters. Confirm the query reaches Pi-hole first. Then confirm Pi-hole replies. Only then look at whether the reply was a block.

A query that never arrives is invisible to every blocklist setting. Disabling blocking during an empty-log fault simply leaves the fault in place, and you have lost the log entries that would have shown you why.

Once the log shows a reply, blocking becomes a fair suspect. Search the domain in the log, find the blocked status, and check which list matched it. Whitelisting one domain is a smaller change than turning blocking off for everything.

1. Filter the log to the affected client and reload a page.
2. If nothing appears, fix routing or the client's DNS setting first.
3. If a query appears without a reply, fix the listen interface and origins, check the host firewall, then restart the resolver.
4. If a reply appears with a blocked status, whitelist the specific domain rather than disabling blocking.
5. Only after all three stages pass should you change blocklists wholesale.

Questions people still ask

I keep a cheap single-board computer as Pi-hole and a second laptop that never runs a VPN, purely so I always have a reference point when DNS breaks.