Game server tunnels: playit.gg, frp and VPS

A tunnel lets a game server at home accept players without a port forward: a small agent on your machine opens an outbound connection to a relay with a public address, and the relay sends player traffic back down that connection. That is how services like playit.gg, self-hosted tools like frp, and a WireGuard link to a cheap VPS get servers online from behind CGNAT. The cost is a detour - every packet goes via the relay, adding anything from a few milliseconds to over a hundred depending on where it is - and, unless you take care, the server sees every player as coming from the relay's address, which breaks IP bans and per-player limits. Use a tunnel when you cannot forward a port and want to keep the server at home. Do not use one to fix a problem that a port forward or a hosted server would solve more simply.

What a tunnel does#

A home server behind NAT cannot accept connections that start from outside. It can, however, start connections outward, and those are allowed everywhere. A tunnel turns that around.

1. An agent on the home machine connects out to a relay server on the public internet and keeps the connection open.
2. The relay listens on a public address and port for players.
3. When a player's packet arrives at the relay, the relay sends it down the open connection to the agent.
4. The agent hands it to the game server on the same machine, and replies travel back the same way.

Because the agent dials out, nothing has to be opened at home: not on the router, not through the ISP's carrier NAT. That is the whole appeal. NAT and CGNAT for game hosts explains why the direct route is closed in the first place.

The options#

The protocol column eliminates options quickly. Most games use UDP for gameplay - Valheim, Source games, Palworld, Project Zomboid, almost every survival game - so any tunnel that only carries TCP is useless for them. Minecraft Java and Terraria are TCP and work with anything. TCP vs UDP for game servers explains why games choose UDP and what that means for proxies.

playit.gg#

playit.gg is a hosted tunnel service aimed at game servers. You run its agent on the machine with the server, claim it to an account in the browser, and create a tunnel for the game: a protocol, a local port, and the service gives you a public address and port on its network. Players connect to that address instead of yours.

It handles both TCP and UDP, which is why it is the common answer for Valheim or other UDP games behind CGNAT. The free tier is enough for a group of friends; paid tiers add things such as more tunnels, choice of ports and regions. The exact limits change, so check the current ones before you plan around them.

Three things to know before relying on it:

• The address is theirs. If you leave the service, the address goes with it and players need a new one. Putting your own domain in front helps where the game supports a name.
• Your traffic passes through a third party. For a game server this is usually fine; know it anyway.
• The relay location sets your latency. Pick the region closest to the middle of your players, not to you.

frp on a VPS#

frp is an open-source reverse proxy for exactly this job. You run frps on a small VPS with a public address and frpc next to the game server at home. Recent versions use TOML configuration:

bindPort = 7000auth.token = "a-long-random-shared-secret"

serverAddr = "198.51.100.20"serverPort = 7000auth.token = "a-long-random-shared-secret"[[proxies]]name = "valheim-game"type = "udp"localIP = "127.0.0.1"localPort = 2456remotePort = 2456[[proxies]]name = "valheim-query"type = "udp"localIP = "127.0.0.1"localPort = 2457remotePort = 2457

Players then join 198.51.100.20:2456. Older frp releases used an INI format with different key names, so match the documentation to the version you download. Open 7000/tcp and the game ports on the VPS firewall, and nothing at home.

frp's advantage is control: your own relay, your own ports, as many services as you like, no third party in the path. The cost is that you now run and secure a VPS, and the relay's location and network quality are your problem.

WireGuard and port forwarding on a VPS#

The most transparent version is a plain WireGuard tunnel between the VPS and the home machine, with the VPS forwarding game ports into the tunnel at the IP level. Nothing is game-aware; packets are just routed.

# On the VPS: wg0 is the tunnel, 10.8.0.2 is the home server's tunnel address$ sudo sysctl -w net.ipv4.ip_forward=1$ sudo iptables -t nat -A PREROUTING -i eth0 -p udp --dport 2456:2457 \    -j DNAT --to-destination 10.8.0.2$ sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

The MASQUERADE line is the simple version: it rewrites players' source addresses to the VPS's tunnel address, so the home server's replies naturally go back through the tunnel. It also means the game server sees every player as 10.8.0.1. Keeping real addresses is possible - drop the masquerade and make the home machine route replies for that traffic back through the tunnel with policy routing - but it is fiddly and easy to break the rest of your home network in the process. Persist the rules and the sysctl, or they vanish on reboot.

This approach carries any protocol and any game unchanged. It is also the one that demands the most networking knowledge. Firewall rules that matter covers locking down the VPS around it.

What a tunnel costs#

Latency

Every packet takes a detour through the relay. The added latency is roughly the round trip from the home server to the relay, and the player's round trip changes from "player to your house" to "player to relay plus relay to your house".

The rule: put the relay close to the server or close to the players, ideally both. A relay in the wrong region turns a fine server into a laggy one. Game server ping by region has the distances. Free tiers sometimes put you on whatever relay is available; check the address you were given and test it.

Real player addresses

A relay that terminates connections - most tunnel services, frp, the masquerade setup - makes every player appear to come from the relay. The consequences:

• IP bans ban everyone, or nothing, since every player shares one address.
• Per-IP connection limits trip as soon as a few players join.
• Logs and anti-cheat lose the information they rely on.
• Geo-features and "same-IP alt account" detection stop working.

The fix for TCP games is the PROXY protocol: the relay prepends a small header with the real client address, and the server reads it. Paper supports this with proxies.proxy-protocol: true in config/paper-global.yml, and Velocity with haproxy-protocol = true in velocity.toml. frp and some tunnel services can send the header. Both ends must agree - a server expecting the header rejects connections without it, and the reverse produces garbled logins. Most UDP games have no equivalent, so for them, plan on identifying players by account ID rather than IP.

Bandwidth and reliability

The relay carries all your traffic twice - in from players, out to your house, and back. A free tier with a bandwidth cap or a small VPS with a monthly transfer limit needs to be sized for that; game server bandwidth per player has the per-game numbers. And the tunnel adds a component that can fail: if the agent crashes or the relay goes down, the server is unreachable while running perfectly. Run the agent as a service that restarts on failure.

Keeping the agent running#

A tunnel is only as reliable as the agent at home. If it stops - a crash, a reboot, a laptop lid closed - the server keeps running and nobody can reach it, and the console shows nothing wrong. On Linux, run the agent as a systemd service so it starts at boot and restarts on failure:

[Unit]Description=frp clientAfter=network-online.targetWants=network-online.target[Service]ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.tomlRestart=alwaysRestartSec=5[Install]WantedBy=multi-user.target

Enable it with sudo systemctl enable --now frpc. The same pattern works for other agents; playit.gg ships its own service setup for Linux and Windows. Systemd services for your apps explains the unit file in more depth. Then monitor the public side, not the home side: a query against the relay address every few minutes catches a dead agent, a dead relay and a dead game server with one check. Query ports and A2S has a check that fits in a cron job.

Overlay networks: the private alternative#

If everyone who plays is a friend, a public tunnel may be more than you need. Overlay networks such as Tailscale, ZeroTier or a hand-built WireGuard mesh put the server and every player on one private network. Players connect to the server's private address on that network, and nothing at all is reachable from the public internet.

That has real advantages: no relay detour in most cases, because overlay tools try hard to connect peers directly and only relay when NAT on both sides prevents it; no exposed port for scanners or floods; and real, distinct addresses for each player. The cost is that every player installs a client and joins your network, which rules it out for anything public and adds a support burden whenever someone gets a new PC. For a group of four to ten who all know each other, it is often the best answer on this page.

Proxies that are not tunnels#

Two other things get called proxies in game hosting and are worth separating.

Game-aware proxies such as Velocity and BungeeCord for Minecraft sit in front of one or more backend servers and move players between them. They solve network design, not reachability - the proxy itself still needs a public address. Minecraft Velocity proxy networks covers them.

Generic stream proxies such as nginx's stream module forward raw TCP or UDP from one address to another, which is useful for putting a game behind a different public address you already control:

stream {    server {        listen 2456 udp;        proxy_pass 10.8.0.2:2456;    }}

That is effectively the relay half of a tunnel, written by hand. An ordinary HTTP reverse proxy, or Cloudflare's orange cloud, cannot carry game traffic at all; Cloudflare for websites and game servers explains why.

When to use one, and when not#

Use a tunnel when you are behind CGNAT, cannot get a public IPv4 address from your ISP, want the server to stay on your own hardware, and the group is small enough that the relay's limits do not matter. Also when you want to keep your home address out of every player's server list - a tunnel hides it, which is a genuine benefit given how often home addresses leak.

Do not use one when a port forward would work. A direct path is always faster and simpler. And for a public or growing community, a tunnel is a halfway house: you are paying for a relay, adding latency, losing player addresses and still depending on your home connection and electricity. At that point the relay VPS could simply run the server, or a hosted server could. Hosting a game server at home vs renting one and port forwarding vs hosted servers cover that decision.

A RE:NODE VDS works as a relay endpoint for frp or WireGuard, since you get root and choose the ports - though a VDS in Germany with a public address can just as well run the game server itself, without the detour.

FAQ#

Is playit.gg safe to use?

It is a widely used service for exactly this purpose, and the agent only makes outbound connections. Your game traffic does pass through their relays, and your server is reachable by anyone who knows the tunnel address, so apply the same care as with any public server: passwords or whitelists, and no exposed admin ports.

Can I use ngrok for a Valheim or Palworld server?

No. ngrok's TCP tunnels do not carry UDP, and those games use UDP for gameplay. Use a service or tool that supports UDP, such as playit.gg, frp or WireGuard.

How much latency does a tunnel add?

Roughly the round trip between your server and the relay. With both in the same country it is a few milliseconds; with the relay on another continent it is 80 ms or more. Choose a relay near the server and the players.

Why do all players show the same IP address?

Because the relay forwards their traffic and the server sees the relay as the sender. For TCP games that support it, enable the PROXY protocol on both the relay and the server to pass real addresses through. For UDP games, rely on account IDs instead.

Do I still need to port forward with a tunnel?

No. The tunnel agent connects outward, which every home network allows. Nothing is opened on your router, which is why tunnels work behind CGNAT.