Direct answer

NAT loopback (hairpin NAT) determines whether players inside your home network can connect using your own public IP or domain. A loopback failure does not necessarily mean the server is unreachable from the Internet.

Recommended procedure

  1. First confirm the Minecraft server is reachable from another device on the LAN using its private address (for example 192.168.x.x:25565).
  2. Ask a friend on a different network or use a mobile connection to test the public host and port.
  3. If outside connections work but inside-to-public fails, check whether your router supports NAT hairpinning or loopback.
  4. Use the private LAN IP or split-horizon local DNS for devices inside the network; continue using the public hostname for external players.
  5. If outside connections also fail, troubleshoot port forwarding, host firewall, ISP CGNAT and server binding rather than blaming hairpin NAT.

Why this matters

Some routers do not route a connection back into the LAN when its destination is the router’s own public address. The result is specific to local testing and can mislead you about external reachability.

Practical example: Example: a home-hosted server may be reachable to your friend on mobile data while your own PC fails when connecting to play.example.com. That is classic hairpin NAT behavior. If the LAN IP works too, do not change Paper’s listening address; provide an internal address or local DNS resolution for home clients.

How to verify the result

  • Document three separate tests: localhost on server, LAN IP on another local device, and public address from an external network.
  • Confirm the outside test reaches the correct Java TCP port.
  • If using DNS, verify the public hostname resolves to the address you intended.

Version and compatibility notes

  • On Geyser/Bedrock, also test the distinct UDP port.
  • A home router reporting a public address different from an external IP check may indicate CGNAT or double NAT.

Official references

These sources were checked for the current MSH revision. Version-sensitive details should always be confirmed against the project documentation for the release you run.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000