Networking and Ports

Your server needs to listen on one or more ports for player connections. The decisions you make about port usage, binding, and protocol support directly affect whether your server works on hosting platforms, behind firewalls, and in shared hosting environments.

Binding to the Right Interface

In most game server hosting environments, the game server must bind to 0.0.0.0 (or a specified IP/interface), not 127.0.0.1 or localhost.

• 0.0.0.0 accepts connections from any network interface, including connections from outside the machine (or container).
• 127.0.0.1 only accepts connections from the same machine. No player will ever connect.

This is the single most common networking issue with new game servers. If your server “works on my machine” but nobody can connect when it’s hosted, check this first.

0.0.0.0 is a good default for most servers, but you can also allow admins to specify a particular IP/interface if needed, and can be helpful in some shared hosting environments (e.g., -ip 192.0.2.0).

Minimum Number of Ports

The fewer ports your server requires, the simpler it is for everyone: players forwarding ports at home, admins configuring firewalls, and Hosting Providers assigning port ranges.

Typical port usage:

Port	Protocol	Purpose
Game port	UDP (usually)	Player connections and game traffic
Query port	UDP	Server browser queries (A2S, custom)
RCON port	TCP	Remote admin commands

Ideally, your server needs one port that handles everything. If you need a query port, such as is recommended for Steam’s server browser, make it an offset from the game port (e.g., game port + 1) so admins only need to configure one value.

RCON is optional but useful. If you support it, make it disabled by default and configurable.

Configurable Ports

Your server must accept port numbers via startup arguments or config files. Hardcoded ports are a deployment blocker.

Hosting platforms run multiple game servers on the same machine. Each server gets assigned a different port or port range. If your server only listens on port 27015 with no way to change it, only one instance can run per machine.

At minimum, support:

./server -port 27015

If you use multiple ports, let the admin configure each one:

./server -port 27015 -queryport 27016 -rconport 27017

Or calculate secondary ports as offsets from the primary:

./server -port 27015    # query = 27016, rcon = 27017

Shared Hosting vs. Dedicated IP

Most game server hosting platforms use shared IPs. Multiple game servers share the same public IP address, each on different ports.

This means:

• Players connect to shared.ip.address:assigned_port, not the default port
• Your game client must support connecting to arbitrary ports, not just the default
• Your server must work correctly on non-default ports

Some hosting platforms offer dedicated IPs where each server gets its own address. Your server should work in both models.

UDP vs. TCP

Most real-time game traffic uses UDP because it’s faster and doesn’t suffer from TCP’s head-of-line blocking. However:

• Game traffic: UDP is standard. Use it.
• Query protocol: UDP is standard (Steam’s A2S protocol uses UDP).
• RCON / admin: TCP is fine. Reliability matters more than speed for admin commands.
• HTTP callbacks: If your server makes outbound API calls (e.g., to Nodecraft’s API), those use TCP/HTTPS over the server’s outbound network, which is not player-facing.

Do not use TCP for real-time game traffic unless your game’s design specifically requires it (turn-based, very low frequency updates). The performance implications multiply across dozens of players.

Query Protocol

If your game launches on Steam, you should implement the A2S query protocol. This is what powers the Steam server browser and allows players to see server info (name, map, player count, ping) before connecting.

See Steam Server Browser for implementation details.

If you’re not on Steam, we’d recommend not using a separate query port to keep things simple. But if you do want a custom query protocol, use a simple UDP request/response format that returns server metadata. Keep the response small (under 1400 bytes to avoid fragmentation).

Environment Variables for Sensitive Data

When possible, use environment variables instead of config files for data that should not be stored on disk:

• API keys and authentication tokens
• Database connection strings
• Secret keys for encryption or signing

For everything else, config files are more user-friendly and easier to inspect. See Server Configuration for config file guidance.

Note that many smaller Hosting Providers don’t have robust ENV variable support in their control panels. For these environments, a config file with appropriate file permissions is a practical alternative. Document both approaches so server admins can use whichever their environment supports.

Common Mistakes

• Binding to 127.0.0.1: Server works locally, nobody can connect remotely.
• Hardcoded ports: Only one server instance per machine. Hosting platforms cannot deploy.
• Requiring port 0: Some code uses port 0 to mean “pick any available port.” This is fine for outbound connections but makes inbound connections impossible to configure.
• Not documenting ports: Hosting Providers and server admins don’t know which ports to open. List every port your server uses, its protocol (TCP/UDP), and its purpose in your documentation.
• Separate ports for features that could share one: Every additional port is another entry in the firewall rules and another port the hosting platform needs to allocate.
• Not supporting non-default ports in the game client: If your client’s “Connect” dialog only accepts an IP address with no port field, players cannot connect to servers running on non-standard ports.

Support for DNS

We recommend reading the Discovery: Direct Connect using DNS to include additional network options.