Publish a verified dedicated server without changing your router
A home game server can give your group control over the world, rules, updates, and access, but the server must first be reachable from outside your home network. This guide explains how NAT, CGNAT, game ports, and Localtonet relays fit together. It also provides an end-to-end Minecraft Java Edition example, including local verification, safe exposure, external testing, routine operation, and troubleshooting. The same Localtonet workflow can be adapted to another game only after you confirm that game's dedicated-server support, required ports, and transport protocols in its current official documentation.
📋 What's in this guide
How a home game server becomes publicly reachable
A dedicated game server is an application that listens for network traffic on one or more local ports. A player on the same computer or local network can often connect directly, but an internet player normally cannot use a private address such as 127.0.0.1, 192.168.x.x, or 10.x.x.x. Those addresses are not routed across the public internet.
Most home routers use Network Address Translation, or NAT, to let several local devices share an internet connection. Some internet providers also use Carrier-Grade NAT, commonly called CGNAT, which adds provider-managed address translation outside the home. Traditional hosting commonly requires an inbound router rule that maps a public port to the server's private address. That option may be unavailable when the host cannot administer the router, does not have a directly reachable public address, or is behind CGNAT.
With Localtonet, the client application on the hosting device establishes an outbound connection to one of our relay servers. The relay provides a public host and port. A friend connects to that public endpoint, and traffic is forwarded through the active tunnel to the configured local IP address and port.
An outbound tunnel does not bypass organizational security controls. Endpoint protection, a local firewall, parental controls, network policy, or egress filtering can block the Localtonet client or the game server. Use Localtonet only on systems and networks where you have permission to run both applications.
Tunnel creation and tunnel availability are different states
Creating a tunnel saves its configuration, but it does not make the game server publicly available. You must start the tunnel after creating it. The public endpoint remains usable only while the dedicated server is available, the selected Localtonet device is connected, and the tunnel is running.
If the game server stops, Localtonet has no active local service to forward traffic to. If the Localtonet client disconnects or the tunnel is stopped, the relay can no longer deliver traffic to the server. This lifecycle distinction is important when diagnosing a server that worked earlier but is no longer reachable.
Where latency comes from
A relayed connection adds a network path between the player, the selected Localtonet relay, and the host. Observed latency depends on physical distance, internet routing, congestion, packet loss, the host's connection, the player's connection, and the game server's own performance. TCP is not automatically unsuitable for games, and UDP is not automatically the fastest in every real-world situation. The application chooses a transport based on the behavior it needs.
When selecting a relay, consider the locations of both the host and the players. A relay that is geographically close may be a sensible starting point, but measured results matter more than assumptions based only on a city name. Available relay values can change, so select from the current dashboard rather than following a hardcoded server code from a tutorial.
Prerequisites for hosting safely
Confirm the complete server requirements before creating a tunnel. A tunnel can carry compatible network traffic, but it cannot add dedicated-server functionality to a game that does not provide it, correct an unsupported operating system, or compensate for missing runtime dependencies.
Do not estimate server capacity from a generic player-count formula. CPU load, memory use, world size, simulation complexity, plugins, mods, tick rate, save activity, and network behavior vary substantially by game and version. Use the game publisher's current requirements as the baseline, then monitor the actual host under realistic load.
Persistent worlds also require a backup plan. Identify the server's configuration, save, and world directories before inviting players. Test how to stop the server cleanly so backups are not taken while important data is only partially written.
Choose TCP, UDP, or combined UDP/TCP correctly
The required tunnel type must match the server application's listening protocol. Do not select a protocol based only on the game's genre. A real-time game might use TCP, UDP, or multiple sockets with different responsibilities. The authoritative answer is the current documentation for the exact dedicated-server version you are running, supplemented by the server's startup logs and listening-socket inspection on the host.
| Tunnel type | Use it when | Important limitation |
|---|---|---|
| TCP | The dedicated server listens for the required public connection on TCP. | A TCP tunnel cannot deliver UDP datagrams to the server. |
| UDP | The dedicated server listens for the required public connection on UDP. | A UDP tunnel cannot carry a separate TCP-only service. |
| Combined UDP/TCP | The application needs both transports on the same local port. | It does not combine several different local port numbers into one tunnel. |
Some servers use separate ports for gameplay, server discovery, status queries, voice, or administration. A combined UDP/TCP tunnel for one local port does not expose a query service or RCON listener running on another port. Review every required socket individually. Depending on the documented server design, additional public forwarding configurations may be required.
Build a port inventory before exposure
For each port listed by the game's official server documentation, record its purpose, local port number, transport, whether internet players actually need it, and whether it should ever be public. This prevents a common mistake where the gameplay port is forwarded correctly but the game's browser, query service, or connection handshake depends on another socket.
| Port role | Question to answer | Exposure decision |
|---|---|---|
| Gameplay | Which exact TCP or UDP socket accepts player sessions? | Expose only the documented player-facing socket or sockets. |
| Query or discovery | Does direct connect work without it, or does the server browser require it? | Expose it only when the game's documented connection model needs it. |
| RCON or administration | Can this interface change settings, issue commands, or control players? | Keep it private unless remote access is explicitly required and strongly protected. |
| Voice or auxiliary service | Is it integrated into the server, and does it listen on a separate port? | Configure it separately according to the publisher's documentation. |
Verify what the process is actually listening on
Server startup logs often report the listening address, port, and protocol. Operating-system network tools can also show active listeners, but their commands and output differ by platform. Compare the observed listener with the server configuration. If documentation says the server uses TCP but only a UDP listener appears, or the expected port does not appear at all, fix the local server before configuring the tunnel.
The listening address matters too. 127.0.0.1 is the loopback interface and is reachable only from the same machine. A LAN address is reachable from appropriate devices on the local network. An unspecified bind address, often represented as blank in an application setting, may allow the application to listen on available interfaces. The exact behavior belongs to the game server, not Localtonet, so follow that server's documentation rather than forcing an address without understanding it.
Minecraft Java Edition end-to-end example
Minecraft Java Edition provides an official dedicated-server download and is a useful single-port TCP example. The instructions below apply to the official Java server, not Minecraft Bedrock Edition, proxy networks, modded server distributions, or third-party server software. Those products can have different installation, runtime, port, and security requirements.
Minecraft Java server releases require a compatible Java runtime, and the required Java version can change between Minecraft releases. The supplied evidence does not establish one Java major version that is correct for every current server release. Use the requirement shown on the official Minecraft server download or release information for the exact server file you download, then verify the installed runtime before continuing.
Install and configure the official server
Create a dedicated server folder
Create a new folder owned by a non-administrative account used for the game server. Keep the server file, configuration, logs, and world data together so they can be backed up consistently. Do not run the server from a temporary download directory.
Download the official Minecraft Java server
Visit the official Minecraft website, open its Downloads area, and select the Java Edition server download for the release you intend to host. Place the downloaded server JAR in the dedicated folder. Avoid unofficial mirrors.
Verify Java before starting
Open a terminal or command prompt and check the active runtime. Confirm that its reported version satisfies the requirement for the downloaded Minecraft server release.
java -versionRun the server once to generate its files
From the server folder, start the downloaded JAR. If your file has a different name, use its exact filename instead of server.jar. The first run creates configuration files and stops because the EULA has not yet been accepted.
java -jar server.jar noguiRead and accept the EULA
Read eula.txt. If you agree to the terms, change eula=false to eula=true and save the file. Do not automate acceptance without first reviewing the agreement.
Review server.properties before public access
Open server.properties while the server is stopped. For the standard Java server example, confirm the intended server-port. The conventional default is 25565. Leave server-ip blank unless you have a specific, documented reason to bind the process to one local interface. An incorrect address here can prevent Localtonet from reaching the server.
Enable game-level access control
Keep online authentication enabled for an ordinary internet-connected server. Enable the Minecraft allowlist and add only the players who should join. Use operator permissions sparingly. Do not grant operator status merely because someone is on the allowlist.
Start and verify the server locally
Start the server again, wait for startup to complete, and connect from Minecraft Java Edition on the host using localhost:25565. If testing from another LAN computer, use the host's LAN address and ensure the local firewall permits the required connection. Do not create a public tunnel until this test works.
The Minecraft process listens on a local network interface. Localtonet's assigned hostname and public port belong to the relay side of the connection and should not be entered as the Minecraft server's local bind address.
Use a clean shutdown and backup routine
Use the Minecraft server console's stop command before closing the terminal, restarting the computer, updating the server, or taking an offline backup. Abrupt process termination can interrupt world saving. After the server has stopped, copy the world data, configuration files, allowlist, operator list, and other files needed for recovery to storage separate from the live server folder.
stopTest restoration before relying on a backup process. A backup is only useful if you know which files it contains and can restore them to a working server. When updating Minecraft or Java, stop the server, back it up, read the release requirements, update one component at a time, and verify locally before reopening the tunnel.
Configure the Localtonet tunnel
Complete the local Minecraft test first. For the conventional Minecraft Java configuration above, the target is TCP on local port 25565. If you changed server-port, use the configured value instead. For another game, substitute only values verified in that game's current official server documentation.
Install and run the Localtonet client
Download the appropriate client from the Localtonet download page. Current options include Windows, macOS, Linux, Android, Docker, Microsoft Store packages, and a zero-install SSH path. Use the installation path appropriate for the device that can reach the game server.
Authenticate the intended device
Select or enter that device's Localtonet authentication token in the client. The token is device-specific and must be kept secret. Do not paste it into screenshots, public chat, a server address field, source control, or a tutorial. Once authenticated, confirm that the intended device appears connected.
Select an available relay server
In the dashboard, choose from the currently available relay servers or regions. Do not reuse a server code copied from an old guide because availability can vary. Start with a location that makes sense for the host and player group, then verify performance through real tests.
Create the correct raw-port tunnel
Open the TCP/UDP tunnel area, select the authenticated device, choose TCP for this Minecraft Java example, and enter the local target IP and port. Use 127.0.0.1 only when the Localtonet client runs on the same machine as Minecraft and the server is reachable through loopback. If the client runs on another device, use the Minecraft host's reachable LAN address instead. Enter 25565 unless you deliberately configured another Minecraft server port, then create the tunnel.
Start the tunnel
Creation alone does not activate the configuration. Find the created tunnel and press Start. Confirm that it is running and note the assigned public host and port shown by the dashboard.
Test externally, then stop or delete when finished
Have an authorized player test the assigned public host and port from a genuinely external internet connection. When the session is over, stop the tunnel if you intend to keep its configuration, or delete it when it is no longer required.
The local IP must be reachable from the device running the Localtonet client. Loopback points back to that device itself. If the game server and Localtonet client are on different computers, 127.0.0.1 points to the wrong machine. Use the game server's reachable private address and verify that the host firewall allows the connection from the Localtonet device.
Optional automatic client startup
The current Localtonet download page documents service installation for supported desktop systems. On Windows, Localtonet can run as a Windows Service. On Linux with systemd, it can run as a system service. On macOS, the client supports a launchd service path. These options let the client start after reboot and continue after logout.
Automatic Localtonet startup does not automatically guarantee that the game server has started, that its world loaded successfully, or that a saved tunnel is running. Verify every component after a reboot. Protect the token used by a service, restrict administrative access to the host, and use only the documented service commands for the installed client version.
Verify the complete connection path
Test in layers. A successful external connection depends on several independent components, and skipping directly to an internet test makes failures harder to isolate.
Confirm server startup
Read the game server console and logs. Confirm that startup completed without a runtime, EULA, configuration, save-file, or port-binding error.
Test on the host
Connect using the local address and configured local port. For the Minecraft example on the same computer, test localhost:25565.
Test from the Localtonet client device
If Localtonet runs on a different machine, verify that machine can reach the server's private IP and port. This catches LAN routing and host-firewall problems before the relay is involved.
Confirm the Localtonet device and tunnel states
Verify that the intended token or device is connected and that the correct tunnel is running. Recheck its local target, protocol, relay selection, and assigned public endpoint.
Test from outside the home network
Ask an allowlisted friend to connect through their own internet connection using the exact public host and port currently displayed. Testing the public address from inside the same network may not reproduce an external player's route.
A successful local connection proves that the game process is available. A successful connection from the Localtonet device proves that the configured target is reachable. A successful external connection proves the full path through the selected relay. Record which layer fails before changing settings.
Secure and operate a public game server
Treat the assigned public host and port as discoverable. Keeping the endpoint out of public posts reduces casual sharing, but it is not an authentication mechanism. Protect the game server itself and minimize the number of exposed services.
Use IP restrictions carefully
Current Localtonet pricing lists IP whitelisting with pay-as-you-go tunnels. IP restrictions can reduce who reaches the endpoint, but they do not make it invisible and should complement game-level authentication rather than replace it. Friends with dynamic public addresses may lose access when their provider changes their address. Carrier networks, shared connections, and VPN use can also affect which source address the relay sees.
Keep local firewall rules narrow
Localtonet does not require an inbound router port-forwarding rule. The operating-system firewall may still need to permit the game server locally, especially if the Localtonet client is on another LAN device. Scope any rule to the required application, protocol, port, and trusted local source wherever the operating system permits. Do not disable the firewall globally to make a test pass.
Plan routine maintenance
- Warn players before stopping the server and allow pending saves to complete.
- Use the server's documented shutdown command instead of terminating the process abruptly.
- Back up the world and configuration before updates or major mod changes.
- Verify the game server locally after every update.
- Confirm that the Localtonet client and tunnel are active after a reboot.
- Recheck the assigned public endpoint before telling players to reconnect.
- Stop or delete tunnels that are no longer needed.
Troubleshooting connection failures and latency
The server does not work locally
Do not troubleshoot the relay yet. Check the game server console for missing runtime dependencies, an unaccepted EULA, malformed configuration, unavailable files, or a port already in use. Verify that the expected process is running and listening on the configured port. For Minecraft, confirm that the Java version is compatible with the downloaded server release and that server.properties contains the intended port.
Localhost works, but the Localtonet client is on another computer
The server may be bound only to loopback. Review the game's bind configuration. For Minecraft Java, an unnecessary value in server-ip can cause this problem, so leave it blank unless a specific bind is required. Confirm that the server host's firewall permits the Localtonet client device to reach the gameplay port over the LAN.
The tunnel exists, but nobody can connect
Check whether the tunnel was actually started. Then confirm that the associated Localtonet device is online. Creating a tunnel is not the same as running it, and a running tunnel cannot reach a disconnected client. Restart only the failed component and review its status again.
The protocol or port is wrong
Compare the tunnel with the game server's current official documentation and actual listening sockets. A TCP tunnel will not deliver UDP gameplay traffic, and a UDP tunnel will not deliver a TCP connection. Also confirm that the local port is the server's configured port rather than an unrelated client, query, or administrative port.
Direct connect works, but the server browser does not
The game may use a separate query or discovery port. Review its server-browser documentation and port inventory. Do not assume that a combined UDP/TCP tunnel on the gameplay port covers a query listener running on a different number. Decide whether the auxiliary service must be exposed and configure it separately only when the official workflow requires it.
The local firewall blocks the connection
Confirm that the game server application and required local port are allowed for the appropriate network profile. If Localtonet runs on another computer, test the private address from that computer. Avoid broad rules such as allowing all inbound traffic or disabling endpoint protection.
The server worked before a reboot
Verify three independent states: the dedicated server process, the Localtonet client device, and the tunnel. Automatic startup must be configured separately for the game server and the Localtonet client. A saved tunnel may also need to be started. Review startup logs instead of assuming each service launched successfully.
Friends are using an old endpoint
Compare the address they entered with the host and port currently displayed in the dashboard. If the endpoint changed, distribute the new value through a trusted channel. Current pay-as-you-go pricing lists custom ports, while exact availability and configuration should be checked in the current dashboard before relying on a persistent public port.
The connection is available but latency is high
Measure before changing configuration. Test another currently available relay, check the host and players for congestion or packet loss, and monitor whether the game server is falling behind because of CPU, memory, storage, plugins, mods, or world simulation. A wired host connection can remove Wi-Fi variability, but it cannot correct internet-route congestion or an overloaded server process.
Some players can connect and others cannot
Review game allowlists, passwords, bans, version compatibility, mod compatibility, and any Localtonet IP restrictions. If an allowed player's public address changed, an old IP rule may reject them. Ask affected players to provide error messages without sharing account credentials or your Localtonet device token.
Check the path in this order: server process, local listener, local connection, connection from the Localtonet device, authenticated Localtonet client, started tunnel, current public endpoint, external player. This sequence identifies the failed layer without introducing several unrelated configuration changes at once.
Current Localtonet pricing considerations
Self-hosting avoids renting a separate game-server machine, but it is not necessarily cost-free. The host still supplies the computer, electricity, internet connection, maintenance, and backups. Localtonet also has free and paid tunnel options.
| Option | Current published terms | Game-hosting consideration |
|---|---|---|
| Free | One HTTP, TCP, or UDP tunnel, 1 GB bandwidth per month, and a 30-minute tunnel timeout. | Useful for setup and short tests, but the timeout and monthly allowance do not represent persistent hosting. |
| Pay-as-you-go | $2 per tunnel per month, unlimited tunnels, unlimited bandwidth, and no tunnel timeout. | Each required tunnel contributes to the monthly total, which matters for games needing several separate ports. |
| Paid access and endpoint options | Current pricing lists custom domains and ports, IP whitelisting, SSO, and team management. | Check the current dashboard for the exact option and configuration available to your tunnel before depending on it. |
Pricing and included capabilities can change. Review the current Localtonet homepage and pricing information before building a long-running server plan. Do not calculate cost from a single gameplay port until you have confirmed whether the game also requires separate public query, discovery, or other player-facing ports.
Frequently asked questions
Can I host a game server without router port forwarding?
Yes, when the game provides a compatible direct-listening dedicated server. The Localtonet client establishes an outbound connection to our relay, which provides a public host and port. This removes the need for an inbound router port-forwarding rule, but outbound traffic can still be restricted by local or organizational policy.
Do my friends need to install Localtonet?
Not for the direct public tunnel workflow described here. The host runs the Localtonet client, and authorized players connect through the assigned public host and port using the game's supported direct-connect method.
Does a combined UDP/TCP tunnel expose every port a game needs?
No. It supports both transports for the configured local port. If gameplay, query, discovery, voice, or administration services use different port numbers, review each one separately and expose only those that authorized players genuinely need.
Why should I test the server locally before creating a tunnel?
A tunnel cannot repair a server that failed to start, listens on the wrong port, uses an incompatible runtime, or has invalid configuration. Local testing proves that the application is available before the relay is added to the connection path.
Should Minecraft server-ip be set to the public Localtonet address?
No. The public address belongs to the Localtonet relay. For the standard Minecraft Java setup, leave server-ip blank unless you have a specific reason to bind the server to a particular local interface. Configure Localtonet with a local address that its client can actually reach.
Is the public game-server endpoint private if I share it only with friends?
No. Treat a public host and port as discoverable. Use game-level authentication, passwords or allowlists where supported, least-privilege administrative permissions, current software, narrow firewall rules, and optional Localtonet IP whitelisting where available.
What happens when the host computer or Localtonet client goes offline?
Players cannot reach the server. Availability requires the dedicated server, the authenticated Localtonet device, and the selected tunnel to remain active. After a reboot, verify all three components before asking players to reconnect.
Is the Localtonet free tier suitable for an always-on game server?
The current free tier includes one tunnel, 1 GB of bandwidth per month, and a 30-minute tunnel timeout, so it should not be described as persistent hosting. Current pay-as-you-go pricing is $2 per tunnel per month with unlimited bandwidth and no tunnel timeout.
Publish your verified game server with Localtonet
Start by confirming that your dedicated server works locally and documenting every required port and protocol. Then install Localtonet on a device that can reach it, create the matching tunnel, start it, and test the assigned endpoint from an external connection.
Get Started Free →
