I have grown used to dirty power at this point. The grid fails, you wait fifteen minutes for it to stabilize, and then you power the server back on just for the power to go off again. Usually, if the grid stays stable, the homelab returns to normal in under five minutes. But this last time was fundamentally different.
My server hosts the DNS instance for the entire house. When the server is down, the internet is functionally dead and the Wi-Fi is essentially unusable. Because of a nasty race condition I battled in the past, my Pi-hole container is strictly configured to come alive first so the rest of the services can resolve internal traffic.
After this latest outage, I kept the server off for a long stretch just to ensure the grid was actually stable. Meanwhile, the router stayed powered on, quietly queuing up every desperate network request from offline devices across the house.
When I finally booted the Proxmox server, the internet remained completely paralyzed well past the five-minute mark. Browsers spun endlessly with agonizing DNS timeouts.
Looking at the Pi-hole web interface, I saw a massive spike: over 5,000 queries registered in a single 30-minute block.
At first glance, jumping from my sleepy baseline to that kind of volume looked like a localized DDoS attack. But doing the math, that volume is a breeze for Pi-hole. It wasn’t crashing from the raw load, but the network was still suffocating.
I needed to bypass the web UI and drop directly into the terminal. By querying the pihole-FTL.db SQLite database and utilizing a sliding window SQL query, I pinpointed the exact second the chaos started. In a single sixty-second window, there were 1,369 requests.
Filtering by the offending IP revealed a friendly-fire culprit in my Docker Compose stack. Running a quick docker inspect, I mapped the IP directly to Homarr.
Waking up isolated, the dashboard was frantically hammering the local DNS to resolve API endpoints for its weather and GitHub widgets. To be fair, this wasn’t entirely a Homarr problem. Homarr definitely had the bigger piece of the pie, no pun intended, but you could clearly see that background requests for Google, Facebook, and Instagram from the disconnected phones and devices across the house did not hold up either. Everything was firing at once.
Yet, the true smoking gun was sitting in the Pi-hole diagnosis logs. The container had not stalled under resource exhaustion; its built-in defense systems had fired.
Because the router acts as the upstream forwarder for local clients, all that queued Wi-Fi traffic hit Pi-hole from a single IP address (192.168.1.1). The instant the surge crossed the threshold, Pi-hole’s default rate-limiter tripped, enforcing a strict ceiling of 1,000 queries per 60 seconds. Compounding the issue, the pending lookups immediately hit dnsmasq’s hard cap of 150 concurrent DNS queries.
Pi-hole was doing exactly what it was engineered to do: stopping what it perceived as a runaway rogue client. But in doing so, it deliberately severed the entire household’s connection to protect itself.
Instead of intervening or rebooting the router, I simply waited it out. It was late, and it was time to sleep. Watching the dashboard, I could see Pi-hole slowly but surely dealing with the requests, and the massive number in the queue began to steadily decline. I decided an immediate configuration fix wasn’t urgent, especially since I was already dealing with another bottleneck. Because of the ongoing dirty power, the physical connection between the router and the server had negotiated itself down. The usual 1Gbps link had dropped to a 100Mbps lifeline just to maintain signal integrity.
The only real solution was to let the hardware rest and wait for the grid to fully stabilize. As Homarr eventually reconnected and the rate-limit penalties expired, the queued requests cleared, and the bruised DNS container finally caught its breath. Ultimately, the container never crashed. It just followed its own safety rules perfectly while the physical hardware limped along underneath it. It proves that a service working exactly as designed can still take down your entire network.