Star Rupture LAN Multiplayer and EOS Routing
A server can be healthy while a same-network join fails. EOS session routing and a home router's hairpin behavior can make local and external tests follow different paths. Treat this as a routing symptom, not proof that the world or port is broken.
Compare routes
| Test | What it tells you |
|---|---|
| Two clients on the same LAN | Whether local discovery/hairpin routing works. |
| Client outside the LAN | Whether public endpoint, provider mapping, and firewall work. |
| Different ISP/VPN | Whether the failure follows a particular route. |
Safe test order
- Start the current official EOS executable and chosen port.
- Allow the port in the host firewall on the correct network profile.
- Test the local address only if the current client workflow supports it.
- Test the public address from outside the LAN.
- Disable VPNs and split-tunnel rules.
- Record which route worked before changing the router or server.
Public route works, LAN does not
Use the public route for the crew if it is reliable, or ask the router/ISP about NAT loopback/hairpin support. A tunnel or relay can be evaluated separately, but it is a community workaround—not a setting documented by the official server article.
Neither route works
- Check client/server build compatibility.
- Check process logs and the actual listening endpoint.
- Confirm router/provider mapping matches the launch port.
- Try a clean world so save selection is not masking a network issue.
See connection troubleshooting and setup. Managed Star Rupture hosting removes home-router hairpin behavior from the setup.