Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx, apache2 or another reverse proxy, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
Web UI/admin interface on port 8089 (HTTP) available.
Operating System (Family and Version): Linux VincePi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux (trixie 0)
Hardware: RPi 4 Model B (aarch64)
Docker compose file or Docker run command: N/A
Docker engine version: N/A
Actual Behaviour:
pihole-FTLonly exposes port 53
Debug Token:
Not sure what went wrong:
[✓] ** FINISHED DEBUGGING! **
* The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (22) The requested URL returned error: 400
[✗] There was an error uploading your debug log.
* Please try again or contact the Pi-hole team for assistance.
* A local copy of the debug log can be found at: /var/log/pihole/pihole_debug.log
-rw-r----- 1 pihole pihole 300 Aug 14 02:23 /var/log/pihole/webserver.log
-----head of webserver.log------
[2026-08-14 02:19:09.511 CEST 2694] Initializing HTTP server on ports "8089,8489s"
[2026-08-14 02:19:09.518 CEST 2694] Error initializing SSL context
[2026-08-14 02:23:16.397 CEST 3000] Initializing HTTP server on ports "8089,8489s"
[2026-08-14 02:23:16.401 CEST 3000] Error initializing SSL context
-----tail of webserver.log------
[2026-08-14 02:19:09.511 CEST 2694] Initializing HTTP server on ports "8089,8489s"
[2026-08-14 02:19:09.518 CEST 2694] Error initializing SSL context
[2026-08-14 02:23:16.397 CEST 3000] Initializing HTTP server on ports "8089,8489s"
[2026-08-14 02:23:16.401 CEST 3000] Error initializing SSL context
Run from your Pi-hole machine, please share the output of:
Not at home currently, will try this evening.
Do you actually intend to access your Pi-hole web UI via ports 8089/HTTP and 8489/HTTPS?
Indeed; those are the recommended ports for v6 when installed by DietPi.
Your debug log also shows that you haven't configured any upstream DNS servers for Pi-hole, rendering public DNS resolution unavailable:
Not sure exactly how that happened, either a side-effect of the DietPi upgrade (from 9.x to 10.x) or a pre-existing error with Unbound … But until starting the DietPi upgrade it was working fine.
The upgrade initially failed with Unbound complaining about a missing key (file size turned out to be 0) and not being able to restart. Got help from the DietPi forum and was able to recover the key. Then I was able to complete the upgrade.
How did you install Pi-hole - via its DietPi-Software utililty or via Pi-hole's installation script?
Originally installed Pi-hole via DietPi-Software. But I have done some updates through sudo pihole update, shouldn’t I do that?
The default ports, so that it can be installed alongside dedicated webservers. So "recommended" is the wrong word .
DietPi updates do not touch Pi-hole configs. The only exception is if a prior Pi-hole v5 installation via dietpi-software is detected to have been upgraded to Pi-hole v6, in which case some cleanup of obsolete webserver configs is done, and the ports changed to 8089,8489s along with an informational prompt.
You can run sudo pihole -up without issues. Especially since Pi-hole v6, there are no conflicts between dietpi-software setups and the Pi-hole installer (== updater) anymore.
Pi-hole won't touch its configured upstreams.
While it would not actively use a dysfunctional upstream, it would continue to include and retry that during its regular upstream elections.
I am currently at a loss at explaining what could have caused those apparent upstream configuration changes (apart from user interaction).
Hence two unexpectedly empty files. Maybe /etc/pihole/pihole.toml was also empty, so FTL restored the default, which is an empty upstream list. ... ah no wait, then the web UI ports and password would have been reverted as well.
tls.pem (+certs) is as well regenerated automatically by FTL, if missing, right? (EDIT: Yes, they are.)
EDIT: Check dates first as deHakkelaar suggested below!
In that way, the issue is very similar to what happened with Unbound: Both failing to start because of some empty key, and both not generating it automatically, because the file does exist already .
Also keep an eye out for "under voltage" messages in the kernel ring buffer/logs:
sudo dmesg -T | grep -i voltage
Power brownouts can corrupt files:
On all models of Raspberry Pi since the Raspberry Pi B+ (2014) except the Zero range, there is low-voltage detection circuitry that will detect if the supply voltage drops below 4.63V (±5%). This will result in an entry being added to the kernel log.
If you see warnings, switch to a higher quality power supply and cable. Low quality power supplies can corrupt storage or cause unpredictable behaviour within the Raspberry Pi.
Makes sense! mdate of the key itself above Jun 5 14:23, which suggests it happened a longer time ago .
We checked for kernel errors on our GitHub: none in this boot session, and no lost inodes in /lost+found either.
Another (RPi-only) check:
vcgencmd get_throttled
should return 0x0, otherwise there is or was an undervoltage, temperature limit, thermal throttling, and/or frequency capping event. But at last undervoltage should be logged in dmesg as well.
If above returns anything other than "throttled=0x0", you can look it up on the man page:
$ man vcgencmd
[..]
get_throttled
Returns the throttled state of the system. This is a bit
pattern - a bit being set indicates the following meanings:
Bit Meaning
──── ────────────────────────────────────
0 Under-voltage detected
1 Arm frequency capped
2 Currently throttled
3 Soft temperature limit active
16 Under-voltage has occurred
17 Arm frequency capping has occurred
18 Throttling has occurred
19 Soft temperature limit has occurred
A value of zero indicates that none of the above conditions
is true.
To find if one of these bits has been set, convert the
value returned to binary, then number each bit along the
top. You can then see which bits are set. For example:
0x50000 = 0101 0000 0000 0000 0000
Adding the bit numbers along the top we get:
19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
From this we can see that bits 18 and 16 are set, indicat‐
ing that the Pi has previously been throttled due to under-
voltage, but is not currently throttled for any reason.
Can you recall if anything changed/happened on that modify date?
You would know better than us.
Apart from a remote break-in or a power brown out (the latter not probable, because I have an old fashioned alarm clock that would have gone in 00:00 blink mode), I can’t think of a logical explanation, because I was away from home for quite a while around that date. Well … a software bug or a hardware problem is always a possibility of course.
BTW, I actually performed the Diet-Pi upgrade because I didn’t manage to reach Pi-hole’s web UI and therefore ssh’ed into the Pi, got greeted by the upgrade invitation and … (I blamed my recent browser switch or a DHCP mishap then, but now I realize Pi-hole [the web UI, because ad filtering still worked] must have already been broken before the Diet-Pi upgrade).
Yes, I have and that brings back the web UI Only a tiny problem remains and causes a warning about the TLS cert: the name pi.hole doesn’t resolve. Should Pi-hole itself take care of that (it used to work before). Or do I need to add it into /etc/hosts?
.
.
.
Only a tiny problem remains and causes a warning about the TLS cert: the name