If you set up a web server or NAS at home and typed your own domain into the browser from inside your network, only to get a timeout or your router's login page instead of your site, the culprit is almost always NAT loopback. NAT loopback (also called hairpin NAT or NAT reflection) is a router feature that lets devices inside your network reach your server using its public IP or domain name, instead of forcing them to use the internal LAN address. Many home routers ship with this feature missing or turned off, which is exactly why your server works from a phone on mobile data but not from your laptop at home.
Content Table
What Actually Happens When You Type Your Domain
Your domain name points to your home's public IP address, the one your ISP assigns to your router. When a device outside your network connects, the path is simple: it hits your public IP, your router's port forwarding rule catches the request, and it hands the traffic to your internal server (say 192.168.1.50).
From inside your network, the trip gets weird. Here is the sequence that breaks:
- Your laptop asks DNS for the domain and gets back your public IP, for example 203.0.113.10.
- Your laptop sends the request out toward that public IP, which means it goes to your router's WAN side.
- The router sees a request coming from the LAN, destined for its own public IP, that then needs to bounce right back into the LAN.
- Without loopback support, the router does not know how to "hairpin" that traffic back inside, so the packet dies or gets answered by the router's own admin page.
That U-turn (out to the WAN interface and immediately back into the LAN) is the whole problem, and it is where the name "hairpin NAT" comes from.
What Is NAT Loopback
NAT loopback is the router behavior that recognizes a LAN device trying to reach a service published on the router's own public IP, and quietly rewrites the connection so it stays internal. The device thinks it is talking to the public address, but the router loops the traffic straight back to the correct internal host.
The feature goes by several names depending on the vendor, which makes it confusing to search for in your router settings:
| Term | Where You'll See It |
|---|---|
| NAT loopback | Generic term, TP-Link, older firmware |
| Hairpin NAT | Networking docs, enterprise gear |
| NAT reflection | pfSense, OPNsense, Ubiquiti |
| Loopback / Internal port forwarding | Various consumer routers |
All four describe the same trick: reflecting a connection aimed at your public IP back into your local network so local network access to your own services actually works.
Why So Many Routers Skip It
Router NAT tables handle inbound and outbound traffic separately, and reflecting a packet requires the router to rewrite both the source and destination addresses on a single connection. That extra work is the reason many budget routers leave it off:
- Extra CPU cost: every reflected connection needs double address translation, which cheap routers avoid to keep throughput high.
- Security assumptions: some firmware treats LAN-to-WAN-to-LAN traffic as suspicious and blocks it by default.
- It's an edge case: vendors assume most users never host anything, so the feature is either buried or absent.
How to Confirm This Is Your Problem
Before changing settings, rule out the other common causes so you don't chase the wrong fix.
- Test from outside: load your domain on a phone with Wi-Fi off. If it works, your port forwarding and DNS are correct, and the issue is loopback.
- Try the internal IP: from your home laptop, browse to the server's LAN address directly (http://192.168.1.50). If that works but the domain doesn't, it's a reflection issue, not a server issue.
- Check what DNS returns: confirm your domain resolves to your public IP. You can look up the resolved address and verify the record is pointing where you expect. If you're unsure how to check, see our guide on how to find your DNS server address.
- Ping the domain from inside: use a ping tool or your terminal to confirm the domain resolves to the same public IP you expect and isn't stale from a recent change.
If you recently pointed the domain at a new IP and it still resolves to an old one from inside, the problem may be caching rather than loopback. Our explainer on how DNS propagation works covers why records take time to update everywhere.
How to Fix It
There are three practical routes, from easiest to most robust.
1. Turn on NAT loopback in your router
Log into your router admin panel and search the firewall, NAT, or port forwarding sections for any of the names in the table above. Enabling it is usually a single checkbox. On pfSense or OPNsense, set NAT Reflection mode to "Pure NAT" or "NAT + Proxy" on the relevant port forward rule. This is the cleanest fix because everything keeps using the real domain.
2. Use a split-DNS / local hosts override
If your router can't do loopback, make internal devices resolve the domain to the internal IP instead of the public one:
- Run a local DNS resolver (like a Pi-hole or your router's built-in DNS) with a record mapping your domain to 192.168.1.50.
- For a single machine, add a line to its hosts file.
# /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts
192.168.1.50 myserver.example.comThe downside: laptops that leave home will keep trying the internal IP until you remove the entry, so this suits fixed devices best.
3. Upgrade the router or firmware
If your hardware simply doesn't support reflection, flashing open firmware (OpenWrt) or moving to a router that supports hairpin NAT solves it permanently. This is worth it if you host multiple services and want them all reachable by name from anywhere.
Confirm your domain points where you think it does
Before blaming NAT loopback, use our free ping tool to check that your domain resolves to your real public IP and is actually reachable, so you know whether it's a reflection issue or a DNS one.
Ping your domain now →
Mobile data connects from outside your network, so it hits your public IP and port forwarding normally. On home Wi-Fi, the request has to loop back through your router to reach the same server. If NAT loopback is off, that U-turn fails, so the site loads externally but not internally.
No. NAT loopback only affects traffic that originates inside your own network and targets services you already published. It doesn't open new ports or expose anything extra to the internet. Your existing firewall and port forwarding rules still control all inbound access from outside.
Nothing functional. Hairpin NAT, NAT reflection, and NAT loopback all describe the same behavior: a router redirecting internal traffic aimed at its public IP back into the LAN. The name just depends on the vendor. pfSense and Ubiquiti say reflection, while consumer routers usually say loopback.
Yes, use a local hosts file entry or a local DNS resolver that maps your domain to the server's internal IP. Devices at home then reach it directly without needing the router to reflect traffic. The trade-off is that portable devices break when they leave home until you remove the override.
Browse to the server's internal IP directly from a home device. If that loads but the domain doesn't, it's a loopback issue. If neither works, or the domain resolves to the wrong address, it's more likely DNS or port forwarding. Testing from outside your network confirms which side is broken.