Self-hosted services often fail in a strangely specific way: they work from mobile data, they work from another network, and then they misbehave the moment you test them from inside your own house. That pattern is usually not random. It is often a sign that public DNS and local routing are pulling in different directions.
Split DNS sounds more complicated than it really is. In practice, it just means your home network gives a different answer for a name than the public internet does, because the best path inside the house is not always the same as the best path outside it.
What split DNS actually fixes
Imagine a service published behind a reverse proxy. Publicly, the domain points to your external address. From outside, that is correct. From inside, that same public route may force your request through hairpin NAT, firewall quirks, or an awkward extra hop that your network does not handle cleanly.
Split DNS solves that by returning the internal address to local devices instead. The domain stays the same, but the route becomes sensible. That single change often removes a lot of mystery from “works everywhere except at home.”
The simple version is usually enough
You do not need a huge enterprise-style DNS design to benefit from this. For many small setups, the practical version is straightforward: run a local resolver, create a local override for the service hostname, and point it at the internal reverse proxy or the internal service address you actually want local clients to hit.
The important part is consistency. If your certificate, reverse proxy rules, and app expectations all assume a specific hostname, keep the hostname stable and just change how it resolves inside the LAN.
Where people normally get stuck
The common failure points are not exotic. A local DNS server might not be the one clients are truly using. A router may still hand out public resolvers. A reverse proxy might listen on one address while the internal override points at another. Sometimes IPv6 enters the picture quietly and makes a carefully planned IPv4 override look broken.
That is why troubleshooting split DNS is usually less about cleverness and more about tracing the path. First check what address the client receives. Then check what is listening there. Then check whether the proxy and certificate chain match the hostname that the client requested.
When not to complicate it further
It is tempting to keep layering special cases onto a network once you get comfortable. Usually that is a trap. If one clean local override solves the problem, stop there. The best homelab fixes are often the ones you can still explain to yourself six months later without opening five browser tabs.
Split DNS earns its keep because it removes friction with very little ceremony. That is exactly the kind of solution a small self-hosted setup should prefer.