Bottom Line: Do Not Solve Pi-hole and LanCache Port Conflicts by Inventing Nonstandard Client Ports
Pi-hole needs DNS on TCP/UDP 53. LanCache monolithic expects client traffic on ports 80 and 443. Its optional lancache-dns also wants DNS port 53. If all of that is forced onto one host IP, port collisions are expected.
Why Mapping DNS 53 to Host Port 54 Does Not Solve Normal LAN DNS
Clients and routers send ordinary DNS queries to port 53. They do not automatically discover that your DNS container lives on port 54. The current Pi-hole Docker documentation keeps DNS on TCP/UDP 53.
Why LanCache Still Wants 80 and 443
The LanCache monolithic guide publishes 80 and 443. HTTP content is cached on 80, while HTTPS traffic on 443 is passed through rather than cached. Mapping those services to 8081/8082 may make the container start, but intercepted clients still connect to the standard CDN ports.
Cleanest Design: One DNS Authority and a Separate Cache IP
If Pi-hole is already your LAN DNS, keep it on port 53 and make it the single DNS path for clients. Then point the relevant cache-domain overrides at a LanCache IP that can own 80/443. A second NIC, VLAN/macvlan or VM can provide that separate IP if your network design supports it.
LanCache itself notes that NAS platforms often already use ports 80/443 and recommends a VM when the appliance networking becomes awkward. See its NAS/port-conflict FAQ.
What to Verify Before Changing DNS
- Pi-hole remains reachable on TCP/UDP 53 at a stable LAN IP.
- LanCache has a stable IP where ports 80/443 are actually reachable.
- Gaming clients receive only the intended DNS server.
- Cache-domain overrides resolve supported CDN names to the LanCache IP.
- Normal unrelated DNS still resolves through your upstream resolver.
The Pi-hole hardware and DNS guide covers the current ZimaOS Pi-hole baseline, while the ZimaOS VM hardware guide is useful when a separate VM is the cleanest network boundary.
