Pi-hole, DNS service, Web UI, Logging, randomly hangs

Help Community Help
1

The issue I am facing: Pi-hole, DNS service, Web UI, Logging, randomly hangs

Details about my system:

At the time of adding this topic (2026-03-30).

Host:

Hardware: Beelink EQR6
OS: Debian 12.2.0-14 (Up-to date)
ProxMox: pve-manager/8.4.0/ec58e45e1bcdf2ac (running kernel: 6.8.12-9-pve)
CPU: 8C/16T
RAM: 24GB
Disk: 1TB (66% free)
Network: 1Gbps
NICs: 2 Eth + 1 WiFi (1 wired connected and in use)
Quick topology: ProxMox[Pi-hole CT] → Switch (8p managed, default settings) → Router (Virgin Media - router mode) → Internet

ProxMox Privileged CT:

OS: Debian 12.2.0-14 (Up-to-date)
Pi-hole:
Core version is v6.4 (Latest: v6.4)
Web version is v6.4.1 (Latest: v6.4.1)
FTL version is v6.5 (Latest: v6.5)
Cores: 2 (0,1% average use)
RAM: 512 MB (8,5% average use)
Disk: 8 GB (88% free)

DNS: enabled
Upstream DNS:
192.168.0.1
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4

DHCP: enabled (34 named static entries added, including itself and the router local eth - format: MAC, IP, Name)

What I have changed since installing Pi-hole:

  • configured it for DHCP (added static entries on Web UI)

  • restored it with privileged CT settings (initially created as unprivileged) - no other change during the restore process

Additional information:

  • hang happens randomly 2-5 times a day, for 3-8 minutes each
  • DNS resolution does not work at the time of hang and webpages are not accessible by name
  • no resource exhaustion at the time of issue
  • at the time of hang, Web UI is not accessible
  • at the time of hang, pihole.log has a gap (pihole.log.1 does not have)
  • at the time of hang, other servers are accessible on the network
  • no other CT/VM are affected or hang on the ProxMox node
  • the ProxMox host is not affected and does not hang
2

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

sudo pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

3

Thanks a lot for getting back this quick and taking the time!

I have generated the debug log, but it contains sensitive information what I don’t feel like sharing (e.g.: MAC, device names, PW hash, etc.).

I have hidden this information from the file while paying extra attention to the special characters and formatting of the file, in case you would process it programmatically.

Could you please let me know how could I upload and share this log with you?
I could also share the other logs I saved with the gaps when the hang happens.

Please advise!

4

Please note that when you upload debug logs, they are stored in a secure server and only around 8 or 9 people can access the logs. Actually, only 1 or 2 members will probably see your log while helping you. No one else can access the URL that shows the log.

Using the command suggested above is usually the safest way to upload a log.

5

I appreciate the clarification, but I still don’t feel like sharing this info - not specifically because of you, but in general. That is a lot of info of someone’s personal environment.
As I have removed the sensitive parts of this file, if you share the way the script uses to upload the log, I can do the same and upload it for you.

Please let me know!
We can discuss this in private as well and I can send the file to you, if you prefer that or not feeling to share the way you upload logs.

I would understand that.

6

In the meantime, I have increased the RAM and swap, both to 1 GB.
Also I put the entry of trying to assign itself a lease to “ignore” as it has a fix IP. (It was the same IP anyway.)

I am also planning on recreating it on a Ubuntu CT instead of Debian.

Any experience/differences with these two?

7

In the meantime I have moved the system to Ubuntu 24.04.
What I have noticed so far, that with the Ubuntu CT, the system feels more snappy and stable.

I have also increased the DHCP lease time from 1h to 1w, just to test.

(I keep sharing this info, in case I find a solution and someone wanders around here with the same issue - or if it is going to be useful for you, devs too.)

Will see how it goes.

8

You should be aware that we may not be able to properly analyse your issue from a redacted log.

You can upload your redacted log to our servers, where it would be treated the same as regular debug logs: Only trusted Pi-hole team members can access it, and it auto-deletes after 48 hours:
(substitute with your redacted file as appropriate)

cat </here/my/debug.log> | pihole tricorder

Then share the token here as shown after upload success.

9

I absolutely understand that. I have only removed the most necessary parts and I have left the formatting and special characters in the log untouched.
I appreciate your flexibility!

I have uploaded my debug log as instructed.
The token is:
Km0nhOi6

Thank you!

10

A gap in Pi-hole's query log would suggest that your network hasn't send any DNS queries to Pi-hole, typically because another DNS server has been used instead of Pi-hole.
That may also explain why you wouldn't be able to access Pi-hole's web UI via pi.hole, as only Pi-hole would know how to resolve that domain.

Your debug log is void of any DHCP/RA information:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
   Scanning all your interfaces for DHCP servers and IPv6 routers
   Timeout: 6 seconds
   
   No answer on eth0

That's likely due to running Pi-hole in a Proxmox VM environment which isolates network access (or perhaps due to your managed switch):
In your current configuration, we are unable to see whether your router would distribute alternative IPv4 DNS server addresses via DHCP or advertise IPv6 addresses via RDNSS RA messages.

The VM's own DNS configuration may hint at that happening:

*** [ DIAGNOSING ]: contents of /etc

-rw-r--r-- 1 root root 153 Mar 30 13:43 /etc/resolv.conf
   search Internal
   nameserver 192.168.0.1
   nameserver 1.1.1.1
   nameserver 1.0.0.1
   nameserver 8.8.8.8
   nameserver 8.8.4.4

If a client is aware of a set of DNS servers, it may pick any of those for its next DNS request at its own discretion, allowing it to by-pass Pi-hole - if your Pi-hole would even be among those.

Interestingly, that set of DNS servers is the same as you've configured as Pi-hole's upstreams:

   [dns]
     upstreams = [
       "192.168.0.1",
       "1.1.1.1",
       "1.0.0.1",
       "8.8.8.8",
       "8.8.4.4"
     ] ### CHANGED, default = []

So I can't be entirely sure if your Proxmox VM has acquired them via DHCP or you've set them manually.

Unrelated to your issue, but as far as Pi-hole is concerned, using that set of upstreams is flawed:
It means your network would be unable to reliably resolve local names that only your router at 192.168.0.1 would be aware of.
If would seem sensible to remove your router from upstreams and enable Pi-hole's Conditional Forwarding to your router instead.

In any case, you should verify that your router distributes Pi-hole's IPv4 as DNS server exclusively, and also that it does not advertise any IPv6 DNS server address at all, or at least only one of your Pi-hole machine's stable IPv6 addresses.

There's another irregularity in your debug log:
It shows an excessive amount of UI access during a very short time frame:

-rw-r----- 1 pihole pihole 21K Mar 30 13:43 /var/log/pihole/webserver.log
   -----head of webserver.log------
   [2026-03-30 03:00:52.145 IST 174] Authentication required, redirecting to /admin/login
   [2026-03-30 03:00:53.642 IST 174] Authentication required, redirecting to /admin/login
   (…20 more lines…)
   [2026-03-30 03:00:53.699 IST 174] Authentication required, redirecting to /admin/login

The webserver.log's tail also shows another burst of requests around 10:09.
If those were really logins, they may have exhausted Pi-hole's available sessions. While this may have contributed to your observation of inability to access Pi-hole's UI, it seems less likely, as it wouldn't explain your other symptoms.

But still:
Would you run any third-party software that would excessively try to access Pi-hole's UI? Some kind of monitoring software or sync tool perhaps?

If so, you should consider tuning its request frequency down and/or properly sign in and out of Pi-hole, so a terminated session can be returned to the session pool.

11

Thank you very much for the detailed analysis!

I will do my best to address all your points one by one:

Gap in log - another DNS

Currently there are no other DNS servers on the network.
There are no settings for this unfortunately on the ISP router and it is very limited (only settings are DHCP on/off, IPv4 pool, etc.), but as soon as I turn off DHCP on the ISP router and set Pi-hole to be the single DHCP server on the network, clients start to use Pi-hole as the default and only DNS.
If I turn off the DNS service on the Pi-hole machine, the name resolution does not work.
If the ISP router is set as DHCP, the clients start to use the ISP provided DNS servers.

Web UI access issue

I access the Pi-hole Web UI by IP only and it was not available by IP at the time of hang.
Other Web UIs were accessible at that time (by IP as well).

DHCP/RA

Interesting. I have set Pi-hole as DHCP and turned off this setting on the ISP router.
The clients seem to get IPs and DNSMASQ names as normal.

ProxMox network

Currently the ProxMox VMs/CTs are directly getting IPs from the LAN (from Pi-hole), and have their own virtual NICs communicating on the host's "eno1" (Eth0), bridged through "vmbr0".

Managed switch

Hmm, I would not think that the switch has anything to do with this, as there are no special rules or anything set on it currently.

ISP router and distributions

This is something I am not sure of, as the router is very limited. However I believe it is in IPv4 mode only.
Currently, and at the time of creating this debug log, the DHCP is turned off on the ISP router and there are no IPv6 settings accessible.
The "Enable additional IPv6 support (SLAAC + RA)" option is currently turned off on the Pi-hole.
(As the router does not have IPv6 settings and this option above is turned off, I am not sure where the devices get IPv6 addresses from.)

VM (CT) and upstream DNS

I currently have the DNS set manually to these values on both Pi-hole and in the ProxMox Pi-hole CT as well. The physical host has different (manual) DNS settings.

Clarification:

ProxMox physical host (manual) DNS settings:
192.168.0.222 (Pi-hole CT)
192.168.0.1 (ISP router)
1.1.1.1 (Cloudflare)

ProxMox Pi-hole CT (manual) DNS settings:
192.168.0.1
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4

Pi-hole (manual) upstream DNS settings:
192.168.0.1
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4

My way of thinking with this was that if Pi-hole gets a DNS query then:
A. it is a local query and can resolve it -> (OK)
B. it is a local query, but can't resolve it -> 192.168.0.1 (OK)
C.a. it is an external query -> 192.168.0.1 (OK)
C.b. it is an external query -> 192.168.0.1 (X) -> 1.1.1.1 (OK)

As the Pi-hole runs on the CT, I have provided the same DNSs for the CT as well, similarly to the Pi-hole upstreams.

Also:
The other VMs/CTs on the same ProxMox host get the host's DNSs for themselves.
So the ProxMox host needs to have the Pi-hole set as primary DNS (for the other VMs/CTs), plus if the Pi-hole is not available for some reason, then the other 2 DNS (ISP router and Cloudflare) should be sufficient.

Upstreams

The DHCP server is turned off on the ISP router and Pi-hole deals with the DHCP leases, as well as with the DNSMASQ names.
This resolution currently works.
Also there are no IPv6 settings on the ISP router at all.

If would seem sensible to remove your router from upstreams and enable Pi-hole's Conditional Forwarding to your router instead.

In any case, you should verify that your router distributes Pi-hole's IPv4 as DNS server exclusively, and also that it does not advertise any IPv6 DNS server address at all, or at least only one of your Pi-hole machine's stable IPv6 addresses.

Could you please clarify if in this case these would still be needed?

UI access

This is an interesting phenomenon.
So I noticed that when I leave the Web UI open in my browser for some time (>=15-30 mins?), let it sit/go browsing on other pages, and when getting back to it and trying to click on the interface items, the page freezes for a few seconds then starts rapidly flashing (~10 flashes/sec) for around 2-4 seconds (probably the session has expired and it is trying to refresh) and then it drops me back to the login page (to log back in again).
I did not think of this too much so far, but it was a bit weird. I am not sure what would be the root cause of this.

Additional info to this:

  • the browser is Brave, up-to-date
  • I have other Web UIs open to the ProxMox host and VMs/CTs, but they don't produce this phenomenon
  • there are no plugins added to the browser other than ABP

3rd party software

Currently I am not running anything like that and I am not querying Pi-hole in any ways.

I hope all this helps some.
Once again, I appreciate your time and effort!

12

That's correct, the switch has no impact on your observation,
I mentioned it as an explanation for the absence of DHCP/RA information from your debug log.

A simple switch operates at layer 2/data link layer, but a managed switch may also do layer 3 switching (there's no exact definition of managed switches, it's more of a marketing concept).
If yours would do so, it may split your network into separate links. Since DHCP broadcasts are strictly same-link, Pi-hole's diagnostic DHCPDISCOVER message may never have reached your router.

But since your debug log does not even show Pi-hole's own DHCPOFFERs, it's more likely that your Proxmox environment has been causing this, e.g. by blocking port 67 broadcasts.

What matters is if clients would be aware of other DNS servers.
They don't have to be part of your network - 1.1.1.1 and 8.8.8.8 are public DNS servers, and if your clients are told to use them, they would.

As for IPv6: Even if you switched off your router's DHCP, it may still advertise IPv6 DNS server addresses, public ones or its own.

Pi-hole can check for that via pihole-FTL dhcp-discover, but only if it's connected to the same link, which it expectedly isn't when caged into a virtualised environment.

You may consider to run passive radvdump or active rdisc6 on your host machines to verify if your router would issue RDNSS RAs.

It's rather:
A. it is a local query and can resolve it -> (OK)
B. forward any other allowed request to the fastest responding upstream, as elected in regular intervals (see also DNS resolver - Pi-hole documentation).

Consequently:

If you'd instead want your B to happen, remove your router from upstreams and enable Pi-hole's *Conditional Forwarding *.

In general, you can't count on DNS servers being queried for specific domains or even in a particular order: As mentioned, if a client is aware of a set of DNS server, it may pick any of them for any given DNS request at its own discretion.
That doesn't mean that there isn't some logic on the client handling DNS selection - rather that logic often isn't well documented and even more frequently cannot be controlled.

For Pi-hole to reliably filter DNS requests for your network, it has to be the sole DNS server known by your clients.

From my explanations, it should be obvious that this applies regardless whether DNS server are learned from your router or manually applied.
Your Proxmox hosts current settings would allow it to by-pass Pi-hole via your router or 1.1.1.1.

This can be tolerated for the machine hosting Pi-hole, as it would allow it to run critical stuff like OS updates or Pi-hole's repair scripts if Pi-hole's DNS portion would be inoperational.
But your typical client has to use Pi-hole and Pi-hole only for reliable filtering.

Then my previous explanations of UI inaccessibility would not apply.
Would the times of excessive login attempts coincide with your observed hangs?

13

Managed Switches that are currently on the market for more or less normal prices are not Layer 3 Switches that also do Routing/NAT/DHCP/etc. so I think we can safely avoid those for now.

However things like DHCP Snooping and IGMPv1/2/3 Snooping are available on a lot of Managed Switches being sold so that could cause issues.
(We are not talking about Multicast DNS issues, but thought it might be useful to mention it anyway…)

Something I would also definitely check is the Firewall that Proxmox has for both the Host and it’s VM’s and LXC’s and Disable it if needed !!

14

(Apologies for the slow reply guys, Easter was hectic. :sweat_smile:)

Bucking_Horn:

Managed Switch

I can do a capture to see if the DHCPDISCOVER messages show up between the router and the switch.
But at the moment, I would think that is low priority in this case.
(The switch is a Netgear GS308E.)

ProxMox blocking broadcasts

Thank you for pointing that out, I am going to check this.

Gap in log - another DNS

I am not sure about what the router advertises, but when checking the clients, the only DNS they obtain automatically is the Pi-hole, probably due to it being the DHCP server and configuring DNS for them.

Going to look into radvdump and rdisc6 later on.

DNS order

With the A-B-C points I was just trying to depict different scenarios and cases (did not want to convey anything like Pi-hole would know if the query is external or not beforehand etc.)

I was not aware of how Pi-hole manages specified upstream DNS servers, so that's on me. Thanks for the heads up. will give it a good read.
(I was going by the usual, primary/secondary [and any subsequent ones on the list] DNS server order.)

In general, you can't count on DNS servers being queried for specific domains or even in a particular order: As mentioned, if a client is aware of a set of DNS server, it may pick any of them for any given DNS request at its own discretion.

So far I have the understanding that apart from a few implementations like with Pi-hole, in general the client tries to query the specified DNS servers in listed order and moves onto the next one only if the server is not responsive/accessible.
ProxMox follows this as well.

Pi-hole as sole DNS server

Currently I can confirm that the clients are automatically set up like that.
As mentioned, the clients (other than the ProxMox host and the Pi-hole CT) automatically get the Pi-hole IP as DNS and nothing else.
This is visible in their configurations as well.

Excessive login attempts, UI flashing and hang relation

No, I haven't noticed that it would happen at the same time.
If anything, it would be the other way around.

E.g.:
I notice that there is no DNS resolution -> Go and check Pi-hole -> Web UI fails to load -> Web UI flashes

Additional information

So far it seems that moving to Ubuntu was a good idea, the system feels much more stable.
I have also set the DHCP lease time to 1w. Since the 1w has passed today, we had one client (a phone) having resolution issues, but nothing else. (I would not even consider it repro in this case.)

Topic resolution

No other differences in settings and it seems that it is running fine for now. But will keep an eye on it.

In case you have other ideas, please share, but even so far I appreciate all your efforts and help with this!
We can leave this topic open for some time, in case anything else comes in, and I can let you know if all is good, let's say in an additional week.

nero355:

Thanks for joining in!

Switch

The switch is a Netgear GS308E, if this helps any.

Firewall

The firewall is disabled on the Datacenter level in ProxMox.

1 Like
15

That’s something that doesn’t make any sense to me :

  • Proxmox = Basically Debian with some additional KVM related conveniences.
  • You are using a LXC for Pi-Hole if I understood you correctly ?

So the best combination you could ever have is to simply make sure that :

  • Proxmox is completely up-to-date.
  • Then the LXC is also up-to-date and using the same version of Debian that Proxmox is using.

Suddenly using Ubuntu (Which is also Debian based, but can be a bit different from time to time) instead and having better performance is not what I would be expecting…

My DHCP Lease Time on 3 different Routers over all of the years that I have been using Pi-Hole has always been 86400 or better said 24 hours and I have never had any issues with that.

Routers used :

  • DrayTek 2860
  • Ubiquiti USG 3P
  • TopTon “NUC” with OPNsense 24.x/25.x/26.x

So it’s weird that you would have to raise the DHCP Lease Time value to have stable DNS Resolving at all times ?!

You are welcome! :slight_smile:

I try to help where I think I can/could/might…

16

LXC and updates

Yes, correct, I am using Pi-hole in a ProxMox LXC.
This is strange to me as well, as I am aware of the Debian base of ProxMox.

But the situation distinctly got better when I rebuilt the container with Ubuntu.
Back then with Debian, I made sure that everything was up-to date.

DHCP lease time

This was just an attempt from me to rule out any issues with that.
I don't think that this in particular helped much and probably I will set it back to 1d.

Appreciated! :grin:

17

There is no definite RFC establishing a specific client behaviour.
There are two things to consider when trying to predict which DNS server will be used for the next request.

a. OSs will determine the order of DNS servers themselves, e.g. by considering DNS server configuration for each network interface, potentially factoring in user defined preferences as well.
The take-away here is that the list of DNS servers as offered by your router may not be the same list in the same order that a given OS is actually using.

b. From that list, OSs may well try each resolver in order of appearance, switching to the next resolver only if the previous fails, or they may try other strategies like query all to use the first response, use the fastest responding one, evenly distribute DNS requests,...

But when would a resolver be rated as failed: If it doesn't reply in 50ms, or 500ms, or 2 seconds? Once or repeatedly?
And how would a failed DNS server be treated? Would it be permanently removed from the list? Does it get re-added when once it becomes available again? How often is it reassessed? What triggers a reassessment?
Could those parameters be controlled programatically, by user interaction or software definitions?

To be able to predict what DNS server would be used for any given DNS request, you'd have to know the answers of all of above as well as the current state of the machine issuing the request.

Hence:

In addition, you should be aware that NXDOMAIN is not a failure - it is a valid, successful DNS reply.
Take this configuration, e.g.:

Let's assume that only your router holds an A record for router.lan.
If an A type DNS request for router.lan would go to Pi-hole or Cloudflare, their answer would be NXDOMAIN, and that's where DNS resolution would stop. The DNS client would not continue to ask other DNS servers for router.lan, as it already has been told that such a record doesn't exist within public DNS.

If you would rely on local domains to be resolved by 192.168.0.1, that's what Pi-hole's Conditional Forwarding would be for.

18

DNS queries

I see, thanks for the heads up and explanation! That changes a few things and I should adjust my settings.

Hanging and inaccessibility

But for now let’s get back to discussing the root issue of Pi-hole/Web UI getting inaccessible and hanging at times, as I am certain that is why DNS resolution stops.

The DNS query resolution order should not affect Pi-hole/Web UI stability and accessibility by IP. If so, please refresh the connection between these two.

(I haven’t experienced these btw since moving to Ubuntu, so probably later on it can be closed with noting this as [a very weak and arbitrary] solution, unless you guys find something better. Still testing on my side.)

Unrelated

The forum here is constantly showing me popups that my draft is being edited from somewhere else.

And then I can either reload the page or ignore.

Later, it keeps blocking me with a “429 - Too many requests” error.

(Just mentioning this in case you want to look into it.)

19

This is usually caused by a second window opened on the same discourse topic. If you don't have another window opened, try closing the browser and opening again.

This is a server issue.

Maybe there is someone, or something (like search bots, AI bots), making too many requests to the server. Maybe it was just a network issue causing disconnections and re-connections.

Recently I saw the same happening on Github. This is usually a temporary issue.

1 Like
20

Unrelated

Thanks a lot for looking into it!

I think I have found the cause for the first part.

I was opening the topic, adding a draft from Gmail, and then switched to “open in browser”.

Probably the session from/via Gmail was causing issues.

For the second part, I have no oversight, but hopefully it is indeed temporary.

(Happened 2-3 times in the past 2 days.)

Thanks again!