Troubleshooting

Nothing here binds it, so the usual systemd-resolved fight was settled when you installed Pi-hole. If Pi-hole itself stops answering on port 53, that is a Pi-hole problem and this dashboard will simply report growing lag while it lasts.

Worth knowing which one is actually listening when something is odd:

sudo ss -lntup | grep ':53'

Check the three things in that order, because they fail differently. Authentication on v6 is a session rather than a header, so step 2 is a POST that hands back a session id:

# 1. Is the API up?
curl -sv http://192.168.1.10/api/info/version

# 2. Does the password work? Returns a session id.
curl -s -X POST http://192.168.1.10/api/auth \
  -H 'Content-Type: application/json' \
  -d '{"password":"your-app-password"}'

# 3. Can the container reach it?
sudo docker exec elele-dns wget -qO- http://192.168.1.10/api/info/version

If 1 and 2 work from the host but 3 fails, it is Docker networking: 127.0.0.1 inside a container is the container, not the host. Use the host’s LAN address in PIHOLE_URL, not localhost.

A 404 on /api/info/version almost always means v5. There is no fallback: v6 replaced those endpoints outright, and only the new ones are implemented.

Pi-hole has a small fixed number of session seats, and a 401 here usually means they are all taken rather than that the password is wrong — the client already retried with a fresh login before surfacing the error. Log out idle sessions under Settings, or generate an application password so this dashboard holds a seat of its own.

A password with 2FA attached will also fail. Use an application password instead, which bypasses the TOTP prompt by design and can be revoked without changing the password you type.

On Pi-hole the names come from FTL’s own reverse lookup, attached to each query. If they are missing there, the devices have no reverse DNS on your network — giving them static DHCP reservations with hostnames on your router fixes it at the source, for every tool rather than just this one.

You can still name them on the Devices page. Unlike the AdGuard path it does not write back, so the name lives here and Pi-hole carries on showing what it resolved.

Correct, and permanent rather than a configuration problem. The map is built from the IP addresses inside each DNS answer. FTL’s query API reports what kind of reply it sent — an address, a CNAME, NXDOMAIN — but never the addresses the reply contained, so there is nothing to place on a map.

The section is hidden rather than shown empty on purpose: an empty map reads as “your network went nowhere”, which is false. Country, city and ASN columns are blank on Pi-hole for the same reason. Everything not derived from answer addresses — devices, domains, companies, friction, anomalies, the explorer — is unaffected.

Vendor labels come from a device’s MAC address, matched against the IEEE OUI registry. AdGuard Home exposes MACs through its client and DHCP APIs; the equivalent Pi-hole endpoints are not read yet, so devices are named but not labelled “Apple” or “Sonos”. Unlike the map, this one is a gap rather than an impossibility.