Server Codes Reference
A server code is a 17-digit numeric passcode that the Unturned™ dedicated server generates for itself at startup. Players can use this code to join the server through the Connect Directly menu without needing port forwarding, without needing to know the server's IP address, and without the server needing a static public IP address. The server code system is one of two joining methods that Unturned™ supports -- the other being direct IP connection -- and it is the only method that works behind symmetric NAT, carrier-grade NAT, or firewalls that block inbound connection requests from the public internet.
This article is the 57 Studios™ complete reference for the server code system. It covers what a server code is, how the server generates it at startup, how players enter the code in the Connect Directly menu, the CopyServerCode console command that copies the code to the clipboard, the Fake IP workaround that enables the pre-join server info screen for server-code connections, the Game Server Login Token that keeps the server code persistent across restarts, and the Steam Datagram Relay (SDR) network transport that routes all server-code traffic through authenticated, encrypted, and rate-limited relay nodes.
The server code system is one of the most underutilized features of the Unturned™ dedicated server. Many server operators assume that port forwarding is the only connection method and never configure the server code system beyond its default state, leaving the code to change on every restart and the pre-join info screen unavailable. The configuration changes required to address both limitations -- a GSLT and a Fake IP setting -- take approximately ten minutes total and fundamentally improve the player experience.
Documentation source: The server code system documentation in this article is drawn from the official Smartly Dressed Games modding documentation.
Who this article is for
This article is written for Unturned™ dedicated server operators who have a running server and want to understand how players connect to it through the server code system. It is also written for players who want to understand how server codes work. If you have not yet installed a dedicated server, start with Setting Up Your Server Panel first. The server code system works with any server configuration and does not require any additional software or configuration beyond what is described here.
What you will learn
- What a server code is and how the server generates it at startup
- How players use the server code to join through the Connect Directly menu
- How to use the CopyServerCode command in the server console
- The Fake IP workaround and what it enables for connecting players
- How a Game Server Login Token keeps the server code persistent between restarts
- How Steam Datagram Relay protects the server and its players from IP exposure and DoS attacks
- The limitations of server codes compared to direct IP joining
- How to work around the pre-joining server info screen limitation
- How to find the server code from inside the game using the Page Down hotkey
Background: how the server code system works
Unturned™ uses Steam's networking layer for server discovery, connection routing, and traffic relay. When a server starts and connects to the Steam backend, the backend assigns it a 17-digit numeric identifier that functions as the server code. This code is a Steam-generated identifier tied to the server's Steam connection session. Players who have this code can enter it in the Connect Directly menu, and the Steam networking layer routes the connection request to the server through Steam's relay infrastructure without the client needing to know the server's public IP address.
The server code system solves a fundamental connectivity problem that direct IP connections cannot solve: connecting to servers behind NAT configurations that do not support inbound port forwarding. A server running on a home internet connection with carrier-grade NAT -- common on mobile broadband networks, 4G and 5G home internet services, and some residential fiber connections -- cannot accept direct IP connections because the router has no publicly routable IP address. The server code system bypasses this limitation by routing the connection through the Steam Datagram Relay network, which uses Steam's own server infrastructure as an intermediary between the player and the game server.
The flowchart above traces the complete server code lifecycle. The Steam backend generates the code at server startup and the code is displayed in the console. The operator uses the CopyServerCode command to copy it. The player enters the code in Connect Directly, and the Steam SDR network routes the traffic to the server through the optimal relay node. The entire data path after connection is authenticated, encrypted, and rate-limited by the SDR infrastructure.
Steam Datagram Relay in detail
When a player connects using a server code, the connection is routed through Steam Datagram Relay (SDR). SDR is Steam's global relay network -- a distributed set of relay nodes deployed across multiple geographic regions that forward traffic between Steam clients and game servers. The SDR network provides three critical benefits for Unturned™ server connections.
IP address protection. The server's public IP address is never revealed to the connecting client. All traffic routes through one or more Steam relay nodes, which forward packets between the client and the server without either party's IP address being visible to the other. A player who connects via server code knows the code but cannot determine the server's IP address from the connection. This protection is symmetric -- the server also does not see the player's IP address directly.
Denial-of-service attack mitigation. Because the server's IP address is never exposed through the server code system, an attacker cannot direct a denial-of-service attack against the server's IP address. The attacker would need to attack the Steam relay infrastructure instead, which is protected by Steam's own DDoS mitigation systems that operate at a scale far beyond what any individual game server could provide.
Traffic authentication, encryption, and rate limiting. Every packet that passes through the SDR network is authenticated (the relay node verifies that the packet came from a legitimate Steam client associated with a valid Steam account), encrypted (the packet contents are encrypted between the client and the server, and the relay node cannot read them), and rate-limited (a client that sends packets at a rate exceeding the configured limit is throttled by the relay node). These three protections operate at the transport layer and are transparent to the game -- the server and client do not need any special handling to benefit from SDR security.
The SDG documentation notes that for a surprisingly high number of players, the SDR relay can actually find a faster route through the Steam network than a direct IP connection would provide. This occurs when the Steam relay network has a more direct path between the player's ISP and the server's ISP than the internet's BGP routing uses. In these cases, the SDR relay improves player ping times rather than adding relay latency, which is the opposite of what most operators expect from a relayed connection.
The sequence diagram above traces the connection flow for a server-code join. The Steam backend resolves the code, assigns a relay node, and the player's client establishes a connection through that relay to the server. All subsequent game traffic flows through the same relay path for the duration of the session.
The pre-joining server info screen limitation
The primary downside of server codes is their incompatibility with the pre-joining server info screen. When a player connects to a server by IP address, Steam uses the A2S protocol -- a standard Steam query protocol based on UDP -- to request information from the server before the player actually commits to joining. This pre-join info screen displays the server name, the list of installed mods, the current player count and maximum player slots, the map name, the game mode, the current in-game time of day, and other details that help the player decide whether to join.
The A2S protocol requires the server's IP address to send the query. Because server-code connections do not use an IP address at the client level -- the Steam backend handles the routing using the code as an identifier -- the A2S query cannot be performed before the player connects. The player enters the server code, clicks Connect, and joins the server immediately without seeing the pre-join info screen. This limitation surprises players who are accustomed to seeing server details before joining and may cause a player to join a server and immediately leave if the server does not match their expectations.
The workaround for this limitation is the Fake IP feature. When a server enables Fake IP through the Steamworks configuration, Steam assigns the server a synthetic IP address within a dedicated fake IP address range. The server code continues to work normally, but the player's client also sees the fake IP and can perform the A2S query against it, which enables the pre-join info screen. The fake IP is not the server's real public IP -- it is a Steam-assigned virtual address that routes through the SDR network just like the server code does. The A2S query against the fake IP is relayed through SDR and answered by the server without exposing the real IP.
How to find and share the server code
The server code appears in two locations on the server side, and players who are already connected can also find it from inside the game.
Server console output on startup
When the server finishes loading all assets and enters the running state, the server code is printed to the server console as part of the startup log. The console output line reads approximately:
Server Code: 85568392932910946The code is a 17-digit numeric string with no alphabetic characters, hyphens, or spaces. It appears in the console output immediately after the server's Steam login completes and the server is confirmed as reachable by the Steam backend. If the console output scrolls past before the operator can read the code, the operator can use the CopyServerCode command or scroll back in the terminal window.
CopyServerCode console command
The server console supports the CopyServerCode command, which copies the current server code to the server machine's system clipboard. The operator can then paste the code into a text document, a Discord message, a website, or any other communication channel.
The command has no arguments and no options:
CopyServerCodeAfter execution, the server code is on the clipboard and can be pasted with Ctrl+V (Windows) or Ctrl+Shift+V (most Linux terminal emulators). The command produces no output in the console -- the code is copied silently.
On headless Linux server installations that do not have a graphical environment, there is no system clipboard. On such systems, the CopyServerCode command may produce a console output message listing the code instead of attempting a clipboard copy that would fail silently. The 57 Studios™ recommendation for headless Linux servers is to read the server code from the startup console output directly rather than relying on the clipboard copy, because the clipboard behavior on headless systems is inconsistent across Linux distributions and terminal emulators.
Finding the server code from inside the game
Players who are already connected to a server can find the server code from inside the game. In the server lobby screen -- the screen that shows the player list, scoreboard, and server information -- pressing the Page Down key copies a variety of server information to the player's clipboard. This information includes the server's Steam ID, which is the same as the server code.
The clipboard output from pressing Page Down includes:
Name: MyServer
Description: A survival server
Thumbnail:
Address: 192.168.48.73
Connection Port: 27016
Query Port: 27015
SteamId: 85568392932910946 (k_EAccountTypeGameServer)
Ping: 1ms
0 workshop file(s):The SteamId value on line 7 is the 17-digit server code. A player who wants to invite a friend to join the server can press Page Down, paste the clipboard content into a text editor or a messaging application, extract the SteamId value, and share that value with the friend as the server code.
This feature is useful for community servers where current players want to invite friends to join. The operator does not need to be present to provide the server code because any connected player can retrieve it. The Page Down hotkey is the default binding and can be customized in the keybinding settings if a player has remapped it.
How players use the server code to connect
Players use the server code through the Connect Directly menu in the Unturned™ client. The process requires no technical knowledge about networking, IP addresses, or ports:
- Launch Unturned™ and wait for the main menu to load.
- Navigate to the Connect tab (the second tab in the main menu).
- Click the Connect Directly button at the bottom of the server list. This opens a single input field.
- Enter the server code in the input field. The code is a 17-digit number with no special characters.
- Click the Connect button or press Enter.
The client contacts the Steam backend with the server code, the Steam backend resolves the code to the server's current session and assigns a relay node, the relay node forwards the connection to the server, and the player joins. The entire process takes approximately 2-5 seconds from clicking Connect to loading into the server.
The Connect Directly menu is the same menu used for direct IP connections (in the format IP:Port). The client automatically detects whether the input is a numeric code (server code) or an IP address with port (direct IP) and uses the appropriate connection method. There is no separate toggle or mode selection between the two methods.
Game Server Login Token
A Game Server Login Token (GSLT) is a persistent authentication token that links a specific server to a specific Steam account. When a server has a GSLT configured in its Config.json, the server code assigned to that server remains consistent across every restart. The same 17-digit code that the players used yesterday will work today and tomorrow, regardless of how many times the server restarts in between.
Without a GSLT configured, every server restart produces a new server code. Players who saved the old code cannot connect after the restart -- they must obtain the new code from the server operator. This is acceptable for temporary servers used for testing, for LAN events where all players are present when the server starts, or for single-session events where the server is started once and stopped once. For production servers with a regular player base that expect repeat visits, a changing server code is a significant usability problem.
GSLTs are issued through the Steam Game Server Account Management page, which is part of the Steamworks partner site. The server operator navigates to this page, selects App ID 1110390 (the Unturned™ Dedicated Server), creates a new token, and copies the generated token string. The token is a long alphanumeric string that looks approximately like:
A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0The token is then added to the server's Config.json file under the LoginToken key:
json
{
"LoginToken": "A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0"
}The LoginToken key is the only Config.json key related to the server code system. All other server code behavior -- code generation, CopyServerCode, SDR routing -- is automatic and requires no configuration.
The 57 Studios™ recommendation for any server that expects repeat players is to always configure a GSLT. The token is free, the setup takes approximately five minutes, and it eliminates the most common source of player confusion about server codes: the code that worked yesterday does not work today. For production servers, a GSLT is essential infrastructure.
The flowchart above shows the behavioral difference between a server with a GSLT and a server without one. The GSLT path produces a consistent code across restarts; the non-GSLT path produces a new code on every restart, requiring players to obtain the new code each time.
Fake IP workaround
Fake IP is a Steam networking feature that assigns a synthetic IP address to a server within Steam's dedicated fake IP address range. The primary purpose of Fake IP is to enable the A2S protocol -- and therefore the pre-join server info screen -- on servers that use server codes as their primary connection method.
Without Fake IP, a player connecting by server code sees no pre-join information. The server name, current player count, map, game mode, and mod list are all unavailable until after the player has joined the server. This creates a poor experience for new players who want to know what kind of server they are about to join -- they must commit to joining before seeing the server details.
With Fake IP enabled on the Steamworks Game Server configuration for the server's GSLT entry, the Steam backend assigns the server a fake IP address at startup. The fake IP is visible to the A2S query protocol, so the pre-join info screen displays normally when a player attempts to connect. The fake IP is not the server's real public IP -- it is a Steam-assigned virtual address that routes through the SDR network, providing the same IP hiding and DDoS protection as the server code system.
The sequence diagram shows how Fake IP enables the pre-join info screen. The Steam backend returns the fake IP when the player looks up the server code, the player queries the server by fake IP using the A2S protocol, and the pre-join screen displays with the server details. The player then decides whether to join or cancel.
Fake IP is enabled and managed through the Steamworks Game Server Account Management page -- the same interface that issues GSLTs. The server operator locates the server entry associated with the GSLT and enables the Fake IP option. The change propagates through Steam's backend within a few minutes and takes effect on the next server restart.
The 57 Studios™ recommendation is to enable Fake IP on every production server. The pre-join info screen is a standard expectation for players browsing servers, and hiding it behind a server-code connection creates unnecessary friction for new players. The combination of a GSLT (persistent code) and Fake IP (pre-join info screen) makes the server code system functionally equivalent to a direct IP connection in terms of player convenience while retaining the IP-hiding and DDoS protection benefits of the SDR network.
Comparison: server code versus direct IP connection
| Feature | Server code | Direct IP | Notes |
|---|---|---|---|
| Requires port forwarding | No | Yes | Server code bypasses all NAT types; direct IP requires open inbound ports |
| Pre-join info screen | No (unless Fake IP enabled) | Yes | Fake IP workaround enables the info screen for server code connections |
| Code persists across restarts | No (unless GSLT configured) | N/A (IP does not change) | GSLT makes server code persistent; IP address is always persistent |
| IP address exposed to players | No (SDR relay hides IP) | Yes | Server code hides the server's public IP; direct IP reveals it |
| DDoS protection | Yes (SDR relay infrastructure) | No (operator provides own protection) | SDR absorbs DoS traffic; direct IP exposes the server to direct attacks |
| Player ping | Often better than direct IP | Variable | SDR can find faster routes than BGP routing in many cases |
| Configuration complexity | None (built-in, always active) | Requires port forwarding setup | Server code requires zero network configuration on the server |
| Suitable for LAN play | No (adds relay latency) | Yes | Direct IP is better for local network play where NAT is not an issue |
| Suitable for servers without static IP | Yes (code is session-based) | No (IP changes require re-sharing) | Server code works regardless of IP changes; direct IP fails on IP change |
| Works behind carrier-grade NAT | Yes | No | Server code is the only option for CGNAT networks |
The comparison table above maps the complete set of trade-offs between the two connection methods. For most production servers, the 57 Studios™ recommendation is: provide the server code as the primary connection method (because it works everywhere and requires no port forwarding), enable Fake IP so that the pre-join info screen appears, configure a GSLT so that the code does not change on restart, and also offer direct IP as a secondary method for players who prefer it or who experience SDR routing issues.
Server code security and access control
The server code is not a security credential. It is a routing identifier, equivalent to an IP address in function. Anyone who has the server code can connect to the server, just as anyone who knows the server's IP address and port can connect. There is no authentication layer tied to the server code -- the Steam SDR network authenticates the Steam account, but it does not restrict which accounts can connect.
Servers that require access control should use the whitelist system (Players.dat whitelist entries), a password configured through Config.json, or a server-side plugin that manages access. Relying on obscurity of the server code to restrict access is ineffective because the code is easily discoverable: any connected player can retrieve it by pressing Page Down in the server lobby.
The SDR relay provides transport-layer security (encryption, authentication of the Steam account, rate limiting) but does not provide application-layer access control. The distinction is important for server operators who need to restrict access to specific players or groups.
Server code SDR relay behavior on local networks
When a player on the same local network as the server connects using the server code, the Steam SDR relay detects that both endpoints are on the same LAN and routes the traffic directly instead of through the external relay network. This optimization prevents unnecessary relay latency for local connections. The server code still works, and the player experiences the same low latency as a direct LAN connection.
This behavior means that testing a server code connection from the same machine or the same local network as the server is not a reliable test of whether the server code works for external players. A server code that works perfectly on the local network may fail for remote players if the server's Steam connection is misconfigured or if the server's outbound UDP traffic is blocked. Always test server code connections from a client outside the server's network.
Diagnostic table
| Symptom | Most likely cause | Resolution |
|---|---|---|
| Server code changes every restart | No Game Server Login Token is configured | Generate a GSLT on the Steam Game Server Account Management page and add it to Config.json as the LoginToken value, then restart the server |
| Pre-join info screen is not shown for server code connections | Fake IP is not enabled for the server's GSLT | Enable Fake IP through the Steamworks interface for App ID 1110390; the change takes effect on the next restart |
| Player cannot connect using server code at all | The server is not fully started or the code was entered incorrectly | Verify the server has finished loading (check console for "Server Code:" line) and confirm the player entered the exact 17-digit numeric code |
| "Invalid server code" error when a returning player tries to connect | The server restarted without a GSLT, invalidating the old code | Configure a GSLT to persist the code; in the meantime, obtain the new code from the server console and share it with the player |
| Player connects but has unusually high latency | The SDR relay node assigned to this player is geographically distant | This is normal for some geographic regions and ISP routing; the player can try the direct IP connection as an alternative |
| Page Down hotkey does not copy server information | The player has remapped the Clipboard Debug hotkey or is not in the server lobby screen | Verify the keybinding in the settings menu and confirm the player is viewing the in-game server lobby (not the main menu) |
| Server code is not displayed in the console on startup | The server started in offline mode without a Steam connection | The server code system requires a live Steam connection; offline or LAN-only servers do not generate a server code |
| CopyServerCode command appears to work but nothing is pastable | The server is running on a headless Linux system without a graphical clipboard | Read the server code from the startup console output instead of relying on the clipboard command |
| "Server not responding" message when connecting by server code | The SDR relay cannot reach the server or the server cannot reach the relay | Verify outbound UDP connectivity on the server machine and confirm the server can reach Steam relay endpoints |
| Fake IP is enabled but the pre-join screen still does not appear | The Fake IP setting has not propagated through Steam's backend yet | Wait up to 30 minutes for the setting to propagate, then restart the server |
| Player can join by direct IP but not by server code | The server's Steam connection is healthy for game traffic but the SDR tunnel is not established | Verify the server's LoginToken (if configured) is valid and that the server can reach the Steam relay network |
| Server code is consistently the same across restarts but the operator did not configure a GSLT | The server may be using a cached GSLT from a previous configuration or the Steam backend may have cached the session | Explicitly configure a LoginToken in Config.json to ensure consistent behavior |
Frequently asked questions
Do I need to configure anything in Config.json to enable server codes?
No. The server code system is always active on any server that connects to the Steam backend. The server generates a code automatically on startup. The only configurable aspect is the LoginToken key, which makes the code persistent across restarts. Without LoginToken, the server code works normally but changes on every restart.
How long is a server code valid?
Without a GSLT, the server code is valid only for the current server session. Once the server process exits and restarts, the old code is invalid and a new code is generated. With a GSLT configured in Config.json, the code is valid across restarts and remains valid until the GSLT is revoked by the Steamworks account that issued it.
Can players join by server code from the Steam mobile app?
The Unturned™ server code is a Steam-level identifier that the Steam mobile app can use for connection. The specific interface for entering a server code in the mobile app depends on the current version of the Steam mobile app, which changes over time. Refer to the Steam mobile app documentation for the current Connect Directly workflow.
Does the server code work if the server operator changes the server name or other configuration?
Yes. The server code is tied to the server's Steam session identity, not to the server name, map, game mode, or any other configuration value. Changing the server name, the map rotation, the maximum player count, or any other Config.json value does not change the server code. A restart may be required for the configuration change to take effect, and if no GSLT is configured, that restart will change the code -- but the name change itself does not trigger a code change.
How do I share the server code with players before they join?
The common sharing methods are: copy the code from the console and paste it into a Discord channel, add it to a community website or forum post, include it in a server welcome message that displays on the first join, or configure a server rules screen that displays the code. The 57 Studios™ recommendation is to make the server code accessible in at least two independent channels so that players can find it without needing to ask the operator directly.
Does the server code reveal my server's IP address to players?
No. The server code routes all traffic through the Steam SDR relay network. The server's public IP address is never transmitted to the connecting client at any point in the connection process. The SDR relay node acts as an intermediary, forwarding packets between the player and the server while keeping both endpoints' IP addresses hidden from each other.
Can players connect to a server-code server without the Steam client running?
No. The server code system uses the Steam networking layer, which requires the Steam client to be running and authenticated on the player's machine. This is the same requirement that applies to direct IP connections in Unturned™ -- the game requires the Steam client regardless of the connection method.
What happens when a GSLT expires or is revoked?
A GSLT issued through Steamworks does not have a built-in expiration date. It remains valid until the issuing Steamworks account explicitly revokes it or the account loses access to the Steamworks partner site. If a GSLT becomes invalid -- for example, because the operator revoked it to generate a new token -- the server code falls back to session-based generation. The code changes on the next restart without any error message or warning in the server console. The operator should periodically verify that the GSLT is still active by confirming that the server code remains consistent across restarts.
Can one server have multiple server codes simultaneously?
No. Each server has exactly one active server code per session. The code is tied to the server's Steam connection and cannot be duplicated. There is no way to give different players different codes for the same server.
Is the server code the same as the Steam ID displayed in the game lobby?
Yes. The server code is the numeric representation of the server's Steam identity within the current session. The same value that the server console displays as "Server Code:" is also the SteamId value that appears when a player presses Page Down in the server lobby. The two terms refer to the same 17-digit numeric value.
How do I enable Fake IP for my server?
Fake IP is enabled through the Steam Game Server Account Management page, accessible through the Steamworks partner site at https://partner.steamgames.com/. Navigate to the Game Server configuration section for App ID 1110390 (Unturned™ Dedicated Server), locate the server entry that corresponds to your GSLT, and enable the Fake IP option for that entry. Save the change, wait a few minutes for it to propagate through Steam's backend, and restart the server. The fake IP appears in the server's console output on the next startup alongside the server code.
Can I use both server code and direct IP on the same server?
Yes. Both connection methods are simultaneously available on any server. The server code system requires no configuration to activate (it is always active), and direct IP connections work alongside it as long as the server machine has port forwarding configured. Players can choose whichever method suits their situation.
Why does the SDG documentation recommend that players read mod descriptions when joining by server code?
Server-code connections without Fake IP bypass the pre-join info screen, which means players cannot see the list of installed mods before joining the server. The SDG documentation recommends that players read the workshop descriptions of the mods a server uses to understand what content is loaded, because the in-game pre-join screen will not show this information. With Fake IP enabled, the pre-join screen displays normally and this recommendation is less critical.
How do I test the server code from a remote location?
Ask a friend or a community member who is geographically distant from the server to try connecting using the server code. If no external testers are available, use a VPN connection to a different geographic region, then launch Unturned™ and try the server code. A server code that works only from the same local network is not confirmed as working for remote players.
How does the SDR relay handle packet loss between the player and the server?
The SDR relay implements forward error correction and automatic retransmission at the transport layer, which is transparent to the game. If packets are lost between the player and the relay, or between the relay and the server, the relay requests retransmission before the game detects the loss. The game sees a reliable transport with the same effective loss characteristics as a direct UDP connection. The relay does not introduce additional packet loss beyond the underlying network path between the player and the relay and between the relay and the server independently.
Does the server code work during Steam maintenance periods?
The server code system depends on the Steam backend being operational for initial connection routing. During announced Steam maintenance periods -- which typically occur during low-traffic windows and are posted on the Steam status page -- the server code lookup may be unavailable for new connections. Players who are already connected through the server code are not affected because their SDR relay session is already established. Direct IP connections may continue to work during Steam backend maintenance because they do not depend on the Steam backend after the initial connection setup.
How does the server code interact with the -OfflineOnly launch option?
When the server is launched with the -OfflineOnly flag, the server skips the Steam backend connection entirely and uses locally cached Workshop items. In this mode, no server code is generated because the Steam backend is not available to issue one. Players cannot connect by server code to an offline-only server. Direct IP connections continue to work because they are established at the game level rather than through the Steam backend.
Does the server code change if the server's Steam App ID changes?
The server code is tied to the Steam App ID that the server is running under. For the standard Unturned™ dedicated server, the App ID is always 1110390. If the server were reconfigured to run a different App ID -- which is not a supported configuration for Unturned™ dedicated servers -- the server code would be generated against the new App ID and would have a different value. Under normal operation, the server operator never needs to consider App ID changes.
Can a player bookmark a server using the server code?
No. The bookmark feature requires the BookmarkHost property to be configured alongside a login token, which enables a bookmark button that allows players to save the server to their favorites list. Bookmarks are tied to the server's IP address or fake IP, not to the server code. Players who want to save a server for quick access should use the in-game server browser's favorites feature after connecting at least once, or use the bookmark feature if the operator has configured it.
Can the server operator see which Steam accounts are connecting through the server code?
The server console logs all connection events regardless of the connection method. Each connection event includes the player's Steam ID, the time of connection, the player's IP address (if using direct IP), and the player's character name. The operator can see every connection but cannot determine from the logs whether a specific player used the server code, the direct IP, the server browser, or a friend invite to initiate the connection.
Can I set up a vanity server code or customize the 17-digit number?
No. The server code is generated by the Steam backend and cannot be customized. The 17-digit value is a Steam-level identifier that is assigned based on the server's Steam session identity. There is no configuration option or workaround to choose a specific code.
How do server codes work with IPv6-only servers?
The server code system operates at the Steam networking layer, which is agnostic to the server's IP version (IPv4 or IPv6). The Steam SDR relay handles the translation between the client's network and the server's network. A server running on an IPv6-only host can use server codes to accept connections from IPv4-only clients, and vice versa. The SDR relay bridges the two network protocols transparently.
Can I use a server code to connect to a LAN-only server?
A server that is not connected to the Steam backend at all -- running in true offline mode with no internet access -- does not generate a server code. The code system requires communication with the Steam backend. If the server is on a LAN but has internet access and a Steam connection, it generates a code, and players on the same LAN can use that code to connect (with the SDR optimization that routes LAN traffic directly).
How do I know if a player is using a server code or a direct IP connection?
The server logs do not differentiate between connection methods. The connection event log entry shows the player's Steam ID and the time of connection but does not record whether the player used a server code, a direct IP, or a fake IP. If the operator needs to track which connection method players are using, this information must be collected through a server-side plugin that inspects the connection event.
Can I disable the server code system?
No. The server code system is always active on any server that connects to the Steam backend. There is no Config.json key or command-line flag to disable it. The server code is generated automatically and cannot be suppressed. If you do not want players to use the server code, simply do not share it -- players who do not have the code cannot connect through this method.
Worked example: setting up a persistent server code with Fake IP
This worked example walks through the complete setup of a persistent server code with Fake IP for a hypothetical production survival server named "IslandSurvival." The server runs on a Linux VPS with a static IP address, but the operator wants to provide the server code as the primary connection method so that players do not need to remember or type an IP address and port.
Step 1: generate a Game Server Login Token
The server operator navigates to the Steamworks Game Server Account Management page, selects App ID 1110390 (Unturned™ Dedicated Server), and clicks the "Create New Token" button. The operator names the token "IslandSurvival" to identify it among any other tokens the account may hold. Steamworks generates a token string approximately 30 characters long. The operator copies this string to a secure notes application and proceeds to the server configuration.
Step 2: add the LoginToken to Config.json
The operator establishes an SSH connection to the server machine and opens the file Servers/IslandSurvival/Server/Config.json in a text editor. The operator adds the LoginToken key with the token string from step 1:
json
{
"LoginToken": "A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0",
"Server_Name": "IslandSurvival | PvE | Washington",
"Max_Players": 32,
"Enable_Scheduled_Shutdown": true,
"Scheduled_Shutdown_Time": "04:30"
}The operator confirms the JSON syntax is valid and saves the file.
Step 3: enable Fake IP in Steamworks
The operator returns to the Steamworks Game Server Account Management page, locates the "IslandSurvival" token entry, and enables the Fake IP option for that entry. The interface shows a toggle or checkbox labeled "Enable Fake IP" that the operator sets to enabled. The operator saves the change.
Step 4: restart the server to apply changes
The operator restarts the server through the wrapper script or by manually stopping and starting the server process. The server console output now includes both the server code and a fake IP address:
Server Code: 85568392932910946
Fake IP: 10.0.0.1The server code is a new 17-digit number. The fake IP is a Steam-assigned address in the fake IP range.
Step 5: verify the code persists across restarts
The operator stops the server and starts it again. The console output shows the same server code 85568392932910946. The GSLT is working correctly.
Step 6: test the code from a remote connection
The operator asks a community member in a different geographic region to try connecting using the server code. The community member enters the code in the Connect Directly menu and successfully joins. The operator then asks the same community member to try connecting by fake IP directly (if the fake IP is routable from their location) and confirms that the pre-join info screen displays the server name, player count, and mod list.
Step 7: communicate the code to players
The operator posts the following message in the server's Discord channel and on the server's website:
Connection Information
Server Code: 85568392932910946
Direct IP: 203.0.113.50:27015 (for advanced users)
Fake IP: 10.0.0.1 (alternative, shows server info before joining)
The server code is the easiest way to connect. Enter it in the Connect Directly menu and click Connect. The code does not change between restarts.Step 8: verify the setup periodically
Once per month, the operator restarts the server and confirms that the server code is still the same. If the code has changed, the operator checks whether the GSLT is still valid in Steamworks and whether the LoginToken key is still present and unmodified in Config.json.
The worked example above covers the complete end-to-end setup process. The total time from starting step 1 to completing step 7 is approximately 20-30 minutes for an operator who is familiar with the Steamworks interface and has SSH or RDP access to the server machine. The ongoing maintenance in step 8 takes approximately 5 minutes per month.
Best practices
- Always configure a Game Server Login Token for any server that expects repeat visitors. A changing server code confuses players and generates unnecessary support requests from returning players who cannot connect.
- Enable Fake IP on production servers so that the pre-join info screen displays correctly for server-code connections. The info screen shows the server name, current player count, and mod list -- information that players use to decide whether to join.
- Provide the server code in multiple locations: a pinned message in the server's Discord channel, an announcement on the server's website or forum thread, and an in-game message that displays on first join. A player who cannot find the code easily may give up and join a different server.
- Test the server code connection from a client outside the server's local network at least once after the initial setup. A server code that works on the local network does not guarantee it works for remote players.
- Save the server code in a location accessible from any device the operator uses. If the operator needs to provide the code while away from the server machine, having the code saved in a password manager or notes application prevents the need to remotely access the server console.
- Provide both server codes and direct IP as connection methods. Let each player choose the method that works best for their network situation and technical comfort level.
- Inform new players about the server's connection options in the server description. A player who is unfamiliar with server codes may not know that the 17-digit number is how they connect.
- Do not rely on the server code as a security mechanism. The code is a routing identifier, not an access credential. Use the whitelist system or a plugin for access control.
- Periodically verify that the GSLT is still valid by confirming the server code stays consistent across restarts. A silently invalidated GSLT produces a changing server code with no warning.
Advanced considerations
Multiple server instances on the same machine
When running multiple Unturned™ dedicated server instances on the same physical or virtual machine, each instance generates its own independent server code. The codes are tied to each instance's Steam session and are not interchangeable. Players connecting to instance A must use instance A's code, and players connecting to instance B must use instance B's code.
Each server instance should have its own GSLT configured to keep its code persistent across restarts. Assign separate GSLTs from the Steamworks Game Server Account Management page for each instance. Sharing a single GSLT across multiple instances is not supported and produces undefined behavior -- the Steam backend may reject connections or route players to the wrong instance.
SDR routing and geographic latency considerations
The Steam SDR relay network includes relay nodes in multiple geographic regions. When a player connects via server code, the relay network assigns the optimal relay node based on the player's geographic location and network path. A player in Europe connecting to a European server will use a European relay node with minimal additional latency. A player in Australia connecting to the same European server will use a relay node that may be in Asia or the Middle East, depending on the available relay infrastructure.
The additional latency introduced by SDR routing is typically 5-20 milliseconds for well-connected geographic regions and up to 50-100 milliseconds for regions with limited relay infrastructure. For most gameplay scenarios, this additional latency is negligible compared to the base network latency between the player and the server. For competitive play scenarios where every millisecond matters, direct IP connections may provide marginally lower latency, but the difference is rarely meaningful in practice.
Server code and the Steam datagram relay bandwidth
SDR routing through Steam's relay infrastructure does not incur any bandwidth charges for the server operator. The SDR bandwidth is provided by Steam as an integrated part of the Steam networking layer. There is no per-connection, per-byte, or per-player cost. The only bandwidth cost for the server operator is the server's own outbound internet connection bandwidth, which carries the game traffic after it leaves the SDR relay node.
The SDR relay node's bandwidth is shared across all Steam games and services that use the relay network. During periods of high Steam-wide network load, the relay node may prioritize traffic from some games over others. In practice, this prioritization is transparent to the server and the players, and no special handling is required.
Steam networking internals for server codes
Understanding the Steam networking layer that underpins the server code system helps server operators diagnose connectivity issues and set accurate expectations about connection behavior.
Steam networking session lifecycle
When the Unturned™ dedicated server starts and connects to Steam, it establishes a Steam networking session. This session has a well-defined lifecycle that the server operator can observe through the console output.
Session establishment. The server contacts the Steam backend, authenticates using the server's Steam credentials (anonymous by default, or GSLT-based if configured), and receives a session identifier. The session identifier is the server code. The console shows the "Server Code:" line at this point, confirming that the session is established.
Session maintenance. The server periodically sends keepalive messages to the Steam backend to maintain the session. If the server goes offline or the network connection is interrupted, the Steam backend eventually times out the session and releases the server code for potential reassignment. The keepalive interval is managed by the Steam client code within the server process and is not configurable.
Session termination. When the server process exits, the Steam networking session is terminated. The Steam backend releases the server code. If the server had a GSLT configured, the same code is reassigned on the next startup because the GSLT links the server's identity to the Steam backend independently of any single session.
Steam networking sockets versions
The Unturned™ dedicated server supports two versions of the Steam networking sockets API: SteamNetworking (the older, deprecated API) and SteamNetworkingSockets (the newer API that is now the default). The server code system uses whichever API the server is configured to use, which is controlled by the -NetTransport= launch option.
With -NetTransport=SteamNetworkingSockets (the default), the server code system uses the newer API, which provides improved SDR routing, better encryption, and more efficient packet handling. With -NetTransport=SteamNetworking, the server code system uses the older API, which lacks some of the routing optimizations but is more compatible with older networking infrastructure.
The 57 Studios™ recommendation is to leave the default SteamNetworkingSockets transport active. Reverting to the older API should only be done if a specific compatibility issue requires it, and even then the fix should be temporary.
SDR relay node selection algorithm
When a player connects via server code, the Steam backend selects an SDR relay node for the connection. The selection algorithm considers:
- The player's geographic location, inferred from the player's IP address.
- The server's geographic location, inferred from the server's IP address.
- The current load on each relay node in the relevant regions.
- The historical latency data for the player-server path through each candidate relay node.
The algorithm selects the relay node that provides the lowest expected latency for the specific player-server pair. This selection is per-player: two players in different geographic locations connecting to the same server via the same server code may be assigned different relay nodes.
The relay node selection is transparent to both the player and the server operator. There is no configuration option to influence or override the relay selection. If a specific player experiences poor latency through the SDR relay, the operator can offer the direct IP connection as an alternative.
Server code ecosystem integration
The server code system does not exist in isolation. It interacts with several other server systems and features that the server operator should be aware of.
Server codes and the server browser
Servers that use server codes as their primary connection method still appear in the in-game server browser. The Steam backend tracks the server's identity through the GSLT, and the server browser lists the server with its server name, player count, map, and ping time. Players who find the server in the browser can join directly from the browser without needing the server code. The server code is an alternative connection method, not a replacement for the server browser.
Server codes and the server list in the Steam friends and favorites
Players who add a server to their favorites or who see a server in the Steam friends list (because a friend is currently connected) can join from those lists without needing the server code. The server code is primarily useful for players who do not have the server in their favorites, who do not see it in the browser, and who need to connect for the first time.
Server codes and Workshop download config
The server code system has no interaction with Workshop download configuration. The WorkshopDownloadConfig.json file and the Workshop_Download_ID directives in Commands.dat are entirely separate systems that control Workshop content management. A player connecting by server code receives the same Workshop content download behavior as a player connecting by direct IP.
Server codes and the whitelist
The whitelist system (Players.dat entries) operates independently of the connection method. A player who is whitelisted can connect by server code, direct IP, or server browser. A player who is not whitelisted is rejected regardless of the connection method. The whitelist is checked after the connection is established, which means the connection method does not affect whitelist enforcement.
Appendix A: Server code management quick reference
| Action | Method | Notes |
|---|---|---|
| View current server code | Read the startup console output | Code appears immediately after Steam login completes |
| Copy code to clipboard | CopyServerCode console command | May not work on headless Linux without graphical clipboard |
| Persist code across restarts | Add LoginToken to Config.json with GSLT value | GSLT obtained from Steam Game Server Account Management page for App ID 1110390 |
| Enable pre-join info screen | Enable Fake IP through Steamworks for the server's GSLT entry | Takes effect on next restart after backend propagation |
| Share code with players | Paste in Discord, website, or in-game welcome message | Code is a routing identifier, not a secret |
| Test code from remote location | Connect from a client outside the server's network | Local network testing does not confirm remote accessibility |
| Retrieve code as a player | Press Page Down in the server lobby screen | SteamId in the clipboard output is the server code |
Appendix B: Config.json keys related to server codes
| Key | Type | Required | Default | Purpose |
|---|---|---|---|---|
LoginToken | string | No | Not set | Game Server Login Token; persists the server code across restarts |
The LoginToken key is the only Config.json setting related to server codes. All other server code behavior is automatic and requires no configuration.
Appendix C: Steamworks configuration checklist
| Step | Action | Location |
|---|---|---|
| 1 | Navigate to Steamworks Game Server Account Management | https://partner.steamgames.com/ |
| 2 | Select App ID 1110390 (Unturned Dedicated Server) | App selection dropdown |
| 3 | Create a new GSLT entry for each server instance | Create New Token button |
| 4 | Copy the generated token string for each entry | Save in a secure location |
| 5 | Add LoginToken with the token value to Config.json | Servers/<ServerName>/Server/Config.json |
| 6 | Enable Fake IP for each server entry | Edit the server entry and enable the Fake IP option |
| 7 | Restart the server | Server process or wrapper script |
| 8 | Verify the server code appears in the console on startup | Console output |
| 9 | Verify the server code remains the same after a second restart | Restart the server again and compare codes |
| 10 | Test the connection from a remote client | Client outside the server's local network |
Appendix D: Steam backend connectivity troubleshooting
| Symptom | Likely cause | Diagnostic step | Resolution |
|---|---|---|---|
| "Server Code:" line never appears in console | Server process has no outbound internet access | Check firewall rules and outbound connectivity for port 443 (HTTPS) and UDP ports used by Steam | Ensure the server machine can reach Steam backend servers on ports 443, 27015-27030 UDP |
| Server code appears but players cannot connect | SDR relay nodes cannot reach the server's UDP port | Verify the server process is listening on UDP port 27015 (default) and that no firewall blocks inbound UDP | Open inbound UDP port 27015 (or the server's configured port) in the server firewall |
| Server code appears but "connection failed" for remote players | NAT traversal issue on the server's network | Test direct IP connection to distinguish SDR issue from general connectivity problem | Use the server code with a GSLT and enable NAT traversal in Steamworks settings |
| Server code appears briefly then disappears from console | The server's Steam session was terminated during startup | Check server logs for Steam connection errors | Restart the server; if the issue persists, check the server's internet connectivity and Steam client status |
| CopyServerCode command returns an error | The server process is not fully initialized or the Steam session was lost | Wait for the server to finish loading before executing CopyServerCode | Re-run the command after the server has fully started |
Appendix E: External references
- Smartly Dressed Games modding documentation -- official reference for the server code system, CopyServerCode command, Fake IP, and Game Server Login Tokens.
- Unturned on Steam -- Unturned™ store page; the game client required to test server code connections.
- Server Config Files: Commands.dat, Players.dat, Config.json -- the
Config.jsonreference that covers theLoginTokenkey alongside other server configuration settings. - Server Auto Restart Setup -- the previous article in this series; covers the auto-restart system that complements the server code system.
- Server Update Notifications -- the next article; covers how players receive notifications about server updates and version changes.
Appendix F: Server code FAQ for server operators
The following questions are specifically for server operators who manage the code system for their community.
How do I handle a player who cannot connect using the server code?
Walk the player through the following diagnostic steps: confirm the server is online and fully started (the code appears in the console), confirm the player is entering the exact 17-digit number with no extra spaces or characters, confirm the player has the Steam client running and is signed into the correct Steam account, and ask the player to try a VPN connection or a different internet connection to rule out local network issues. If none of these steps resolve the issue, provide the direct IP address as an alternative connection method.
How often should I renew my GSLT?
GSLTs do not have a built-in expiration date. They remain valid until explicitly revoked by the issuing Steamworks account. The 57 Studios™ recommendation is to create a new GSLT when the server's hosting provider changes, when the server moves to a new IP address, or when the operator's Steamworks account credentials are rotated for security reasons. Routine renewal is not necessary.
Can I have the same server code for servers in different geographic regions?
No. Each server instance has its own GSLT and its own server code. Servers in different regions are independent server instances and must each have their own code. Players connecting to the European instance use the European instance's code, and players connecting to the North American instance use the North American instance's code.
How do I know if my server code system is working without asking a player to test it?
The server console showing the "Server Code:" line at startup confirms that the server has a valid Steam session and that the code system is active. To confirm that the code is reachable from outside the server's network, ask a remote player or use a remote VPS to attempt the connection. There is no server-side diagnostic command that tests external reachability of the server code.
What happens to the server code if the server operator's Steamworks account is compromised?
An attacker with access to the Steamworks account can revoke existing GSLTs and issue new ones. This changes the server code, which may prevent players from connecting until the new code is shared. The server operator should secure the Steamworks account with Steam Guard and a strong password, and should monitor the GSLT list periodically for unauthorized changes.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Complete reference for the server code system, CopyServerCode command, GSLT persistence mechanism, Fake IP workaround, SDR relay technical details, comparison with direct IP connections, diagnostic table, and best practices. |
Server code common misconceptions
The following misconceptions about the server code system recur frequently in community discussions. Each entry clarifies the actual behavior.
"The server code is a security feature that hides my server from unauthorized players." This is incorrect. The server code is a routing identifier, not an access control mechanism. It hides the server's IP address from connected players but does not prevent anyone who knows the code from connecting. Access control requires the whitelist system or a server-side plugin.
"The server code replaces the need for port forwarding entirely." This is partially correct. The server code bypasses the need for inbound port forwarding because the SDR relay outbound-connects to the server. However, some hosting providers block the outbound UDP traffic that the SDR relay requires, in which case neither server codes nor direct IP connections work. Most hosting providers allow outbound UDP by default.
"The server code is the same as the server's Steam ID displayed in the console." The server code and the Steam ID are the same numeric value. The console's "Server Code:" line shows the same value as the SteamId field in the Page Down clipboard output. The two terms refer to the same identifier.
"A GSLT is required for server codes to work at all." This is incorrect. Server codes work without any GSLT configuration. The GSLT only makes the code persistent across restarts. A server without a GSLT generates a new code on every restart, which is functional but inconvenient for repeat players.
"Fake IP makes the server's real IP visible to players." This is incorrect. Fake IP is a synthetic address within Steam's dedicated fake IP range. It is not the server's real public IP. The fake IP routes through the SDR relay network just like the server code does, providing the same IP hiding and DDoS protection.
"Players need the server code every time they connect to the server." Once a player has connected to a server using the server code, the server appears in their recent server history (if the server browser supports this) or can be bookmarked. The player does not need to re-enter the server code for subsequent connections unless the server restarts without a GSLT, which changes the code.
Authoring checklist
- [ ] Server code is verified to appear in the console output on server startup
- [ ] CopyServerCode command produces the expected output or clipboard content
- [ ] GSLT is configured for production servers that expect repeat visitors
- [ ] Fake IP is enabled for production servers to enable the pre-join info screen
- [ ] Server code is shared with players through at least one communication channel
- [ ] Server code connection is tested from a client outside the server's local network
- [ ] Players who connect by server code can confirm they are on the correct server
- [ ] The server operator has the server code saved in an accessible location for sharing
- [ ] The server code is verified to remain consistent across at least two restarts (with GSLT)
- [ ] Return players can connect using the same code they used previously (with GSLT)
Testing server code connectivity: comprehensive guide
Server operators should test server code connectivity methodically before announcing a code to players. The testing procedure below covers every connection scenario.
Test 1: Local network server code connection
Connect from a client on the same local network as the server. Enter the server code in the Connect Directly menu. If the connection succeeds, the server code system is generating and accepting codes correctly. If this test fails, the server's Steam session is not established or the server is not reachable on the local network. Verify that the "Server Code:" line appears in the server console and that the server process is running.
Test 2: Remote network server code connection
Connect from a client on a different network. This is the definitive test of whether the server code system is working for remote players. If the connection succeeds, the SDR relay is correctly routing traffic to the server. If the connection fails while the local connection succeeds, the SDR relay cannot reach the server. The most common cause is a firewall on the server machine that blocks outbound UDP traffic. Some hosting providers restrict outbound UDP by default and require a support ticket to enable it.
Test 3: Server code persistence across restarts
Restart the server and note the server code before and after the restart. If the code is the same, the GSLT is configured correctly. If the code changes, verify that the LoginToken key is present in Config.json and that the token value matches the token issued through Steamworks. Also verify that the server process reads Config.json from the correct directory.
Test 4: Pre-join info screen with Fake IP
If Fake IP is configured, connect from a remote client using the server code and observe whether the pre-join info screen appears before the connection completes. The info screen should show the server name, current player count, map name, and mod list. If the screen does not appear, verify that Fake IP is enabled in Steamworks for the server's GSLT entry and that the server has been restarted since the change.
Test 5: Simultaneous connections
Have two remote players connect using the server code at the same time. Verify that both can connect, play, and interact simultaneously. The server code system supports an unlimited number of simultaneous connections through the SDR relay.
Test 6: Reconnection after disconnect
Have a remote player disconnect from the server and immediately reconnect using the same server code. Verify that the reconnection succeeds without delay. The server code remains valid for the duration of the server's session (or indefinitely with a GSLT), so reconnection should not be a problem.
Test results log
Record the results of each test in a server operations log. A sample log entry:
[2026-07-26] Server code connectivity test
Test 1 (local): PASS - connected successfully
Test 2 (remote): PASS - remote player connected from Germany
Test 3 (persistence): PASS - code unchanged after restart
Test 4 (Fake IP): PASS - pre-join screen displayed
Test 5 (simultaneous): PASS - two players connected
Test 6 (reconnect): PASS - reconnection succeeded
GSLT: [redacted], valid
Server code: 85568392932910946Maintaining a test log helps the operator identify regressions over time. If a test that previously passed begins to fail, the operator can investigate the cause knowing which aspect of the system changed.
Cross-references
- Server Auto Restart Setup -- the previous article in this series; covers the server restart scheduling that runs alongside the server code system.
- Server Update Notifications -- the next article; covers how players receive notifications about server updates and version changes.
- Server Config Files: Commands.dat, Players.dat, Config.json -- the full
Config.jsonreference; includes theLoginTokenkey for GSLT configuration. - Setting Up Your Server Panel -- initial server installation guide; prerequisite for having a running server that generates a server code.
- Smartly Dressed Games modding documentation -- official reference for the server code system, CopyServerCode command, Fake IP, and GSLT configuration.
- Unturned on Steam -- Unturned™ store page; the game client through which players connect using server codes.