Running a homelab server sounds like a straightforward task on paper. I have been running my own homelab server on an old PC for over a year now. It often felt like solving one problem just to uncover another. One of the advantages of using a local server is that I can access the services instantly when on the same network. The moment I step outside, that advantage disappears. I have to rely on public domain names through Cloudflare Tunnel to access those services.

It means I had to bookmark all my 15+ services’ local addresses as well as public domain names and switch between them depending on which network I was on. The setup wasn’t broken, but it wasn't exactly elegant either. That was when I came across a simple networking concept, Split DNS. A straightforward DNS fix with everything I already had. Once set up, everything felt much more convenient; the right domain resolved automatically — no more switching, no more bookmarks.

The real issue was DNS, not my setup

Everything worked — just not from everywhere

At first, I believed something was wrong with my homelab setup. I set up the server and deployed a few services; everything worked fine when I accessed them via local IP on the same network. Jellyfin would instantly load on 192.168.0.115:8096, and so did Immich and Nextcloud. As soon as I moved to mobile data or moved outside my network, those local IPs were worth nothing. I then decided to implement port forwarding, but my ISP uses CGNAT, which made port forwarding a dead end.

That was where my Cloudflare Tunnel setup came in. On paper, it was a straightforward implementation. I deployed Cloudflared as a Docker container and connected it to the same Docker network as my other services. As soon as I mapped the services to a domain, everything was back to normal, even when I was outside my network.

Now this created another problem. I was effectively using two different methods to access the same service: a local IP when I was on the same network and Cloudflare Tunnel when I was outside the network. It didn’t break anything, but it disrupted the flow, and the experience felt fragmented. It would have been manageable with two or three services, but I self-hosted more than 15 services, so bookmarking all of them wasn’t a real solution.

I tried a few workarounds, such as editing the hosts file, using multiple browsers, and managing bookmarks, but they didn’t feel like a permanent fix. Every service was working as it was supposed to, but not in a unified way. That’s when I realized that the issue wasn’t with the server or the services themselves; it was the DNS and how it was resolved in the first place.

Split DNS — one small idea that fixes everything

Same domain, different answers, seamless experience

Accessing the same service but using two different methods was a pain. I then started thinking about whether I could access the same service but using only one domain, regardless of the network. After a couple of hours of internet scrolling, I came across split DNS. I could actually use two different IPs for the same domain, depending on which network the request is coming from. So, technically, if I were inside my local network, the domain would resolve to the local IP address, and if I were outside my network, it would route through Cloudflare Tunnel.

From a user's point of view, it was simple enough; it didn't matter which network I was on. I used the same domain. Nothing changed except that everything now felt seamless. Mobile data, home network, or public Wi-Fi — I would type the same address, and it would work. What made it even better was that I didn’t have to remove or replace my existing setup. The only real difference was that now local traffic no longer had to loop through the internet unnecessarily.

The system picks the most efficient path automatically — no input needed.

My setup + the small tweaks that made it reliable

Where most people get stuck — and how to avoid it

Setting up split DNS was easier than I thought. I actually had everything the setup needed. I was already using Pi-hole as my network-wide local DNS. Cloudflare was already working via Tunnel. All the services were containerized and under the same Docker network. So, it took a few minutes to add local DNS records to Pi-hole, and it was up and running.

I mapped each domain to my server's local IP address. Then the flow was simple: if I was on my local network, it resolved my local IP address, and as soon as I moved to another network, it returned the Cloudflare IP address. Nothing changed or needed to be done on the user’s end. The biggest advantage was that local traffic no longer depended on the external route.

There were a few small tweaks that made sure everything worked across all my devices. The first thing I needed to do was implement the Pi-hole DNS on all the devices. It was simple enough for me, as I was already using a dual-WAN gateway and Omada Controller with it, so I changed the DNS server to Pi-hole. I also stopped using localhost or local IP addresses for accessing any service, which eliminated the confusion.

During testing, I also faced IPv6 issues, as Cloudflare exposed both IPv4 and IPv6, and Pi-hole could only forward the domain to my server’s IPv4 address. Since I was using Cloudflare Tunnel, there was no way to disable IPv6 from that end. I then opted for a simple workaround; I stopped using IPv6 altogether on my Windows PC and Mac. But that is a temporary fix, something I’ll need to address properly down the line.

Once everything was in place, the process became completely transparent. Local traffic was landing on the local IP address, and outside traffic was using the Cloudflare IP addresses. Now I had to remember the subdomains of the services and use them only; the network stopped mattering.

The fix was already sitting right there

Split DNS, or split-horizon DNS, is a simple network configuration. What I didn’t realize was how elegantly it worked and the logic behind it, different DNS responses based on where the request is coming from. Looking back, the problem felt far more complicated than it actually was. I already had the solution with me; I just had to connect the dots.

Split DNS didn’t replace my existing setup; it just complemented it. Everything was working as expected; the services were running the same way. The only thing that changed was how I accessed it. If your homelab has the same structure as mine, Split DNS might be the one change that can tie everything together.