Unturned Config.json Browser Settings Reference

Intermediate30-40 minutesCross-platformText EditorFTP ClientConfig.json

The Browser section of an Unturned dedicated server's Config.json is the block of configuration that determines how your server appears in the in-game server list, what players see when they inspect your server in the lobby, and how the server protects itself from problematic connections. If you have ever wondered why a server shows a custom icon, a description, or a website link in the server browser, the answers are here. If you have ever been kicked from a server for "bad packets" or "input spam" without understanding why, the explanation is in the filtering keys at the end of this article. This article documents all 36 keys in the Browser section, explains what each one does, and shows how they work together.

The Browser section sits alongside other major sections in Config.json -- Server, UnityEvents, Easy, and Workshop among them -- and every key covered here exists inside the Browser object in that file. The Browser section is one of roughly a dozen top-level objects in Config.json, each governing a distinct subsystem of the server. The Browser section specifically controls the public-facing surface: how the server is listed, described, and protected at the connection boundary.

If you are editing Config.json for the first time, make a backup before changing anything. A single misplaced comma or unquoted string can prevent the server from starting. The file uses standard JSON syntax: keys and string values are double-quoted, booleans are true or false unquoted, and numbers are written as plain digits with an optional decimal point. Trailing commas after the last element in an object or array are not valid JSON and will cause a parse error. The game expects the Browser object to contain the keys listed in this article; extra keys you add will be ignored, but missing keys will use the game's built-in defaults (which for most keys is the zero or empty value).

The keys documented here come from the game's own BrowserConfigData class, defined in PlayConfigData.cs in the Unturned SDK. Every key name, type, and default value is taken directly from that class. This article does not invent keys, rename fields, or guess at defaults. Where the game provides no built-in default for a key, the table shows a dash, and the explanation notes what that means in practice.

Each key is addressed in one of the four grouped explanation sections below, and some keys appear in multiple groups where their function spans categories. A key like Icon is both an identity signal (it tells players who you are) and a thumbnail asset (it is literally an image file); it is explained in both contexts.

Key table

The table below lists every key in the Browser section with its type and default value. Types use C# naming conventions (string, bool, int, uint, float) as they appear in the game's own configuration class. The EServerMonetizationTag type is an enum defined by the game and is not a standard C# primitive; the valid values for it are enumerated by the game, not chosen freely. The Link[] type is an array of Link objects, each containing a Message string and a URL string.

A dash (-) in the Default column means the game does not supply a built-in default for that key. In JSON terms, an unset string is an empty string "", an unset bool behaves as false, and an unset numeric type behaves as zero. Some keys have explicit defaults -- Max_Clients_With_Same_IP_Address defaults to 64, Scheduled_Shutdown_Time defaults to "1:30 am", Reset_Vehicles_Outside_Horizontal_Distance defaults to 40000.0f, and Update_Steam_Beta_Name defaults to "public". Only these five keys have non-empty defaults. Every other key starts empty, false, or zero unless you set it.

Key	Type	Default
Icon	string	-
Thumbnail	string	-
Desc_Hint	string	-
Desc_Full	string	-
Desc_Server_List	string	-
Login_Token	string	-
BookmarkHost	string	-
Is_Using_Anycast_Proxy	bool	-
Monetization	EServerMonetizationTag	-
Message	string	-
Url	string	-
Links	Link[]	-
VAC_Secure	bool	-
Max_Ping_Milliseconds	uint	-
Timeout_Queue_Seconds	float	-
Timeout_Game_Seconds	float	-
Max_Packets_Per_Second	float	-
Join_Rate_Limit_Window_Seconds	float	-
Bad_Packet_Rate_Limit_Window_Seconds	float	-
Bad_Packet_Rate_Limit_Threshold	int	-
Rate_Limit_Kick_Threshold	int	-
Max_Clients_With_Same_IP_Address	int	64
Max_Clients_With_Same_IP_Address_Log_Warnings	bool	true
Fake_Lag_Threshold_Seconds	float	-
Fake_Lag_Log_Warnings	bool	-
Fake_Lag_Damage_Penalty_Multiplier	float	-
Enable_Kick_Input_Spam	bool	-
Enable_Kick_Input_Timeout	bool	-
Enable_Scheduled_Shutdown	bool	-
Scheduled_Shutdown_Time	string	"1:30 am"
Enable_Update_Shutdown	bool	-
Update_Steam_Beta_Name	string	"public"
Chat_Always_Use_Rich_Text	bool	-
Validate_EconInfo_Hash	bool	-
Use_FakeIP	bool	-
Reset_Vehicles_Outside_Horizontal_Distance	float	40000.0f

Every key in this table is a genuine field from the game's BrowserConfigData class. No additional keys, no renamed fields, no guesses. The type and default columns are taken directly from the source and are not rounded or reinterpreted.

Grouped explanations

The 36 keys break naturally into four groups based on what they influence on your server:

• Identity and naming -- how your server identifies itself to the server list and to players who inspect it. This is the "who we are" group.
• Description and formatting -- the text players read before and after joining. This is the "what we say" group.
• Thumbnail and links -- visual assets and external clickable links. This is the "what they see and where they go" group.
• Server list visibility and filtering -- who can connect, who gets blocked, and how the server protects itself. This is the largest group and the "who gets in" group.

A handful of keys bridge categories. Icon and Thumbnail appear in both Identity and Thumbnail groups because they serve dual roles: they identify the server visually and they are the literal image assets. Desc_Hint, Desc_Full, and Desc_Server_List appear in both Identity and Description groups because the text that identifies your server is also the text that describes it. Where a key belongs to more than one group, it is explained in each, with the fuller explanation in the group closest to its primary function.

Identity and naming

Your server's identity is the first thing a potential player sees in the server list. Getting these fields right is the difference between a server that looks abandoned and one that looks intentional. An empty icon slot, a blank description, or a missing login token all signal to players that the server owner is not paying attention. The identity keys are not just cosmetic; several of them are functional requirements for the server to appear in the list at all.

Icon

A URL pointing to a 64-by-64 pixel image. Unturned downloads this image and displays it in the upper-left corner of the server lobby menu -- the detailed view a player sees after clicking on your server in the list, but before they click "Join." This is the larger of the two visual identity keys.

The image must be hosted at a publicly reachable URL. Unturned fetches it when a player inspects your server, so the hosting must be reliable. If the URL is unreachable or the image takes too long to load, the game will display a fallback or an empty space. Image hosting services that go down or throttle bandwidth will leave your server looking broken.

Because the icon appears prominently in the lobby menu, it is the main visual branding surface for your server. Choose an image that reads clearly at 64x64 pixels. Highly detailed photographs tend to blur and become unrecognisable at that size; simple shapes and high-contrast designs work better. If you are not a designer, a solid-colour square with your server initials in a contrasting colour is serviceable and reads clearly at 64 pixels.

A note on hosting: the image URL must return an image file with appropriate content-type headers. Some file hosting services return HTML pages for direct image links when accessed without a referrer or with an unexpected user agent. The game fetches these images as a simple HTTP client, not as a web browser. If your image host blocks non-browser user agents, the image will not load. Test your icon URL by opening it in an incognito browser window or by fetching it with a tool like curl. If you see an HTML login page or a "hotlinking not allowed" error instead of the image, the URL will not work in the game.

The image format matters less than the resolution. PNG is generally preferred for its lossless compression and support for transparency (useful if your icon is not a solid rectangle), but JPEG works too. The game does not enforce a file type at the config level; it fetches whatever the URL returns and renders it if it can decode it as an image.

Thumbnail

A URL pointing to a 32-by-32 pixel image. This one displays directly in the server list view, before a player clicks through to the lobby menu. It is the tiny icon that sits next to your server name in the list.

At 32x32 pixels, the thumbnail has very little room for detail. It is best treated as a recognisable symbol or colour swatch rather than a full image. Players scanning a long server list will notice it as a shape and colour before they read your server name. A thumbnail that looks like a blurry dot at 32 pixels is not doing its job.

Because the thumbnail and icon serve different contexts, you can use different images for them. A common pattern is to use a simplified, high-contrast version of your server logo for the thumbnail (just the shape, no text) and the full logo for the icon. This way the thumbnail is scannable in a list and the icon carries the detail when a player is already looking at your server.

Desc_Hint

A short string displayed directly underneath the server name in the server lobby menu. This is the line a player sees after they have clicked your server in the list but before they join. Think of it as a tagline or elevator pitch -- one line that captures what your server is about.

Keep it brief. The lobby menu has limited horizontal space, and a long hint will truncate with an ellipsis or get cut off mid-word. Aim for something a player can read in a glance: five to ten words is a good range. "Vanilla survival, active admins, weekly events" is more effective than "Welcome to our server we hope you enjoy your stay please read the rules."

The hint is not a substitute for the full description. It is a preview. A player who reads the hint and wants to know more will scroll to Desc_Full. A player who reads the hint and is not interested was never going to read the full description anyway. Write the hint for the second group: catch their attention, then let the full description do the convincing.

Desc_Full

A longer string shown in the lower-right area of the server lobby menu. This is where you explain what your server offers: rules, features, community links, schedule, mod list -- anything a player needs to know before deciding to join.

There is more room here than in Desc_Hint, but it is not unlimited. The lobby menu renders the description in a fixed-size text area. Text that exceeds the visible area requires scrolling, and players who do not scroll will only see the top portion. Structure your description so the most important information comes first: server rules and expectations, then features, then community links and credits. A player who reads the first paragraph and scrolls on should already know whether this server matches what they are looking for.

Line breaks in the JSON string will render as line breaks in the lobby menu. You can use this to create section headers, bullet-like lists with hyphens, or separated paragraphs. The game does not support Markdown or HTML formatting in this field; it is plain text.

Desc_Server_List

A short string displayed underneath the server name in the server list itself. This is separate from Desc_Hint: Desc_Server_List appears in the list view before a player clicks, while Desc_Hint appears in the lobby menu after they click.

The distinction matters because the two fields address different moments in the player's decision pipeline. When a player is scanning the server list, they see a grid of server names, thumbnails, player counts, and pings. Desc_Server_List is the one-line text field in that grid that tells them what kind of server this is before they commit to clicking it.

Because the player has not invested any time in your server yet at this point, the bar for them to click is low -- but so is the bar for them to scroll past. Desc_Server_List must be distinct and informative. A generic string like "Unturned server" or "Come play" tells the player nothing and wastes the field. "PVE survival, kits, /home" tells them exactly what to expect.

Login_Token

A Steam Game Server Login Token. This is not optional if you want your server to appear in the public server list. The token is generated through the Steam Game Server Account Management page at https://steamcommunity.com/dev/managegameservers. Without a valid token, the server browser cannot authenticate your server, and it will not list publicly.

The process for obtaining a token is: log into Steam in a web browser, navigate to the Game Server Account Management page, create a new game server account associated with Unturned (App ID 304930), and copy the generated login token. Paste that token into Config.json as the value of Login_Token. The token is a long hexadecimal or alphanumeric string and should be treated as a secret. Do not share it, post it in screenshots, or commit it to a public repository.

The official documentation at https://docs.smartlydressedgames.com/en/stable/servers/game-server-login-tokens.html covers the token lifecycle in detail, including how to revoke a compromised token and how to manage multiple tokens for multiple servers. In short: generate a token, paste it here, and keep it private. A server without a valid token can still run and accept direct connections, but it will be invisible in the server browser. Players will need to connect by IP or through Steam's friend-join system.

BookmarkHost

An address string that the server advertises to clients so they can find it again later, even if the underlying IP address changes. When a player bookmarks your server or adds it to their favourites in Steam, the game stores this address and uses it to reconnect in future sessions.

This field accepts three distinct forms, each suited to a different hosting setup:

• A DNS name, such as myunturnedserver.example.com. For servers not using Fake IP, this is the simplest approach. Create an A record on your domain pointing to your game server's public IP address, set that hostname here, and clients will resolve it through normal DNS. This is the recommended option for most self-hosted or VPS-hosted servers because it decouples the server's identity from its IP address. If you move the server to a different machine or your ISP changes your IP, you update the DNS record and bookmarked clients find the new address automatically the next time DNS propagates.

• A raw IP address. This works but is fragile. If your IP changes, every bookmarked client loses the server until they find it again in the browser list. There is no recovery path short of getting the new IP into the config and waiting for the server list to refresh.

• A web URL starting with http:// or https://, such as https://myunturnedserver.example.com/api/getaddress. This is designed for servers using Fake IP. Since Fake IP assigns random ports at startup, the server cannot advertise a fixed port number. Instead, you implement a web API endpoint that returns the current IP and port as a plain-text response body. Clients perform a GET request against this URL, and the response text can be a bare IP address, a DNS name, or an IP with a port override formatted as 127.0.0.1:27015.

The official documentation at https://docs.smartlydressedgames.com/en/stable/servers/bookmark-host.html has additional detail on the web endpoint format and on troubleshooting bookmark resolution.

If you do not set BookmarkHost, players can still join your server through the browser list, but they cannot bookmark it for direct reconnection. A server that changes IP and has no bookmark host set will silently lose its regular players.

Is_Using_Anycast_Proxy

A boolean flag. When set to true, the server lobby displays a warning to players that the ping shown in the server list may be higher than the actual in-game latency.

Anycast is a network routing technique where a single IP address is advertised from multiple physical locations, and traffic is routed to the nearest instance. When a server uses an Anycast proxy, the player's ping measurement in the server list reflects the round-trip time to the proxy endpoint, not to the game server behind it. The proxy might be physically closer to the player than the actual server, making the listed ping look better than it really is. Or the proxy might add overhead, making the listed ping look worse. The warning exists to set accurate expectations.

If you are not using an Anycast proxy, leave this as the default (effectively false). Setting it to true when it does not apply will display an incorrect warning label next to your server name, which may discourage players who interpret it as a sign of an unstable connection. Most small and medium servers do not use Anycast and should leave this flag off.

Use_FakeIP

A boolean controlling Steam's Fake IP system. When enabled, the server's real IP address is hidden from clients behind a Steam relay. Steam assigns random ports at startup, which changes with every server restart.

The primary benefit of Fake IP is that your server's IP is not directly exposed to every player who connects. This reduces the risk of DDoS attacks and other IP-based harassment, since the attacker only sees a Steam relay address. The trade-off is operational complexity: because the port changes, you cannot give players a fixed IP:port to connect to. You need to pair Fake IP with a web-based BookmarkHost endpoint that tells clients where to find the server at its current address.

Official documentation: https://docs.smartlydressedgames.com/en/stable/servers/fake-ip.html

Fake IP is a Steam networking feature, not something Unturned invented. It is the same system that other Steam games use for relayed connections. The decision to enable it is a trade-off between privacy and simplicity. If your server is on a residential connection or a small VPS with no DDoS protection, Fake IP adds a meaningful layer of protection. If your server is behind a robust firewall on a hosting provider that handles DDoS mitigation, the added complexity may not be worth it.

Monetization

An enum value of type EServerMonetizationTag that declares how your server is monetized, if at all. This appears as a tag in the server list so players can understand whether the server is free, donation-supported, or commercial before they join.

The exact set of valid enum values is defined by the game and is not a free-text field. You cannot write Monetization: "my custom tag" and expect it to work. The game will only recognise the specific values mapped in the EServerMonetizationTag enum. Check the Unturned SDK or the official server documentation for the current list of valid tags.

Setting this honestly helps players self-select. A player looking for a completely free experience can filter past monetized servers; a player willing to support a server through donations or purchases can seek them out. Misrepresenting your monetization status -- for example, claiming to be non-monetized while running a donation shop -- damages trust with your player base and may violate Steam's server listing rules.

Description and formatting

Once a player is looking at your server, the text fields you set determine what they read. This group covers the four description keys, the broadcast message field, and the rich text formatting toggle. The description keys overlap with the Identity group because the text that describes your server is also the text that establishes its identity. This section focuses on how to write and format those fields effectively.

Desc_Hint

Covered in detail in Identity above. To summarise: this is the short tagline under the server name in the lobby menu, the first text a player reads after clicking on your server. Write it as a hook -- one sentence that summarises why someone should join -- and keep it short enough to fit without truncation.

The hint sits in a prominent position directly below your server name and above the player count and ping display. It is the text equivalent of the icon: small, scannable, and representing the server's identity in a few characters. A well-written hint answers the question "what kind of server is this?" before the player has scrolled to the full description.

Desc_Full

Covered in detail in Identity above. To summarise: this is the long description in the lower-right of the lobby menu. You have more space here, but players who do not scroll will only see the top. Put rules and expectations first, features second, and community links last. Use line breaks in the JSON string to create visual structure in the plain-text output.

A common mistake is to fill the full description with ASCII art or decorative separators. These render inconsistently across different screen resolutions and font sizes and take up space that could be used for information. A clean, plain-text description with short paragraphs and clear section breaks is more readable than a wall of decorative characters.

Desc_Server_List

Covered in detail in Identity above. To summarise: this is the one-line field in the server list grid, visible before a player clicks. It must be distinct and informative enough to earn a click among dozens of competing servers.

Because this field is displayed in the list alongside every other server's Desc_Server_List, players will naturally compare them. A server whose list description is empty or generic will be scrolled past in favour of a server whose description signals active management and a clear server type.

Message

A string field. Based on its placement in the Browser section, this key sets a short message that the server displays in the server list, functioning as a status indicator or broadcast line visible alongside the server name. The field is a plain string with no default value. An unset Message produces no visible text in the server list beyond what the description keys already show.

This key is separate from the three permanent description keys, which makes it useful for temporary announcements. If your server is undergoing maintenance, hosting a special event, or changing its rules, you can update Message without rewriting Desc_Hint or Desc_Full. Players who check the server list before joining will see the current broadcast, and you can change it as often as you need without touching the permanent identity text.

Because the message appears in the server list alongside the name and Desc_Server_List, keep it brief. A long message in a narrow list column will truncate or wrap in ways that make the list harder to scan for other servers. Think of it as a status line, not a second description. "Scheduled maintenance at 3am UTC" is appropriate. A paragraph about your server rules belongs in Desc_Full.

The game's internal documentation does not provide a detailed description of this field's rendering behaviour. The guidance above is based on the key's name, type, and location within the Browser config class, which places it among the server-presentation keys.

Chat_Always_Use_Rich_Text

A boolean controlling whether vanilla text chat messages always use rich text formatting. The game's internal documentation states that this field no longer does anything. It is kept in the config class because server plugins may still reference it directly, but the game itself ignores it at runtime.

The historical context: IMGUI, the immediate-mode GUI library that Unturned uses for its user interface, handles rich text differently from plain text when fading chat messages off the screen. Plain text chat messages fade out after a few seconds to keep the screen clear during gameplay. Rich text messages do not fade in the same way. On plugin-heavy servers where chat messages carry formatted colours, clickable links, or embedded icons, the fade behaviour could cut off information that players needed to read. Setting this flag to true forced all vanilla chat messages to render as rich text, which bypassed the fade and kept messages visible longer.

However, the game's internal note is explicit: this key is vestigial. It no longer has any effect on chat rendering. It remains in the config class only for backward compatibility with plugins that may read it. If you do not use a plugin that documents a dependency on this key, leave it at its default (effectively false). Setting it to true will not change your chat behaviour; setting it to false will not either. The key exists but is inert.

Thumbnail and links

The visual assets and external links that appear in the server browser are the main tools for directing players to your community outside the game. This group covers the two image keys, the primary URL, and the array of link buttons.

Icon

Covered in detail in Identity above. To summarise: the 64x64 image in the upper-left of the lobby menu is the most visible image on your server's profile. It needs to be readable at 64 pixels, publicly hosted, and reliably reachable.

A broken icon -- one where the URL returns a 404 or the hosting is down -- leaves an empty slot in the lobby menu. An empty slot is worse than no icon at all because it signals that the server owner set something up and then let it break. If you are going to set an icon, make sure the hosting is stable.

Thumbnail

Covered in detail in Identity above. To summarise: the 32x32 image in the server list row is the first image a player sees. At that size, it is a colour and a shape, not a picture. Simple silhouettes, solid-colour icons, and minimalist logos work; text, faces, and photographs do not.

If you only have time to prepare one image, prepare the thumbnail. It appears in the server list, where every player sees it during their initial scan. The icon only appears after a player has already decided to click on your server. The thumbnail is the image that earns the click.

Url

A string field for a website URL. Based on its placement in the Browser section, this key sets a clickable web link associated with your server, displayed in the server lobby menu. The field accepts a URL string with no built-in default, so an unset Url produces no link and no visual element.

This is distinct from the individual link buttons set through the Links array. Where Links gives you multiple labelled buttons with distinct destinations and custom button text, Url is a single primary link with no custom label -- the game likely renders it with a default label like "Website" or uses the URL itself. Use Url for your server's main website, your primary community hub, or the single destination you want every player to see. Use Links for additional destinations that deserve their own labelled buttons.

If you do not have a website, leave this field empty. A blank URL field has no visual impact on the server lobby. Do not set it to a placeholder like https://example.com or a broken link; players who click it and land on an error page will conclude the server is abandoned. A missing link is invisible; a broken link is a negative signal.

Links

An array of Link objects, each containing a Message string and a URL string. These render as clickable buttons in the server lobby menu. The game's internal example shows the structure:

Links
[
    {
        Message Visit our website!
        URL https://smartlydressedgames.com/
    }
]

Each entry in the array produces one button. The Message field is the button label the player reads; the URL field is the destination that opens in the player's default web browser. You can add multiple entries to create a row of buttons -- one for your website, one for your Discord server, one for your rules page, one for your donation page, and so on.

The buttons appear in the server lobby menu alongside the server information. They are one of the few mechanisms for linking players to external resources from inside the game's own interface. Use them deliberately. A single well-placed Discord invite button is more effective than five buttons that all lead to variations of the same landing page. Too many buttons look spammy and train players to ignore them.

Because the links open in an external browser, the player leaves the game window. This is worth noting because players on single-monitor setups will have to alt-tab out of Unturned to see the linked page. A link that leads to a slow-loading or mobile-unfriendly page may frustrate a player and lose their attention before the page renders. Where possible, link to pages that load quickly and display well on a desktop browser.

The Links array uses a JSON array-of-objects syntax. Each object in the array must have both Message and URL fields. An object with only one of the two fields may cause a parse error or render a button with missing text or a broken destination. The order of objects in the array determines the order the buttons appear in the lobby menu. The game renders them in the sequence you define, so put your most important link first.

Server list visibility and filtering

This is the largest group in the Browser section and the one that most directly affects who can play on your server. Every key here controls either a gate that keeps certain players out -- ping limits, VAC bans, IP caps -- or a protection that keeps the server stable under load and abuse -- timeouts, rate limits, spam detection, and shutdown automation. These keys are the difference between a server that runs smoothly for weeks and one that buckles under its first wave of malicious or misbehaving clients.

The filtering keys in this group are progressive by design. They start with gentle restrictions (timeouts for silent clients, packet rate observation) and escalate to hard rejections (kicks for rate-limit violations, connection refusals for IP floods). A well-configured server uses the gentle restrictions as a first line of defence and reserves the hard rejections for clients that have demonstrably crossed a threshold. A poorly configured server skips straight to kicking, which punishes legitimate players for momentary network issues.

It is also worth stepping back and looking at the Browser section's filtering keys as a whole. They address four distinct layers of abuse that a server can face:

1. Network-level abuse: packet floods, bad packets, excessive connection attempts. Handled by Max_Packets_Per_Second, Bad_Packet_Rate_Limit_Window_Seconds, Bad_Packet_Rate_Limit_Threshold, and Join_Rate_Limit_Window_Seconds.
2. Connection-slot abuse: too many connections from one source, silent connections holding slots. Handled by Max_Clients_With_Same_IP_Address, Timeout_Queue_Seconds, and Timeout_Game_Seconds.
3. Gameplay abuse: lag-switching, input spam. Handled by Fake_Lag_Threshold_Seconds, Fake_Lag_Damage_Penalty_Multiplier, and Enable_Kick_Input_Spam.
4. Client-state abuse: frozen clients, input timeouts. Handled by Enable_Kick_Input_Timeout.

A server that only configures one of these four layers is protected against one category of problem and exposed to the other three. A comprehensive configuration addresses all four, even if the thresholds start generous.

VAC_Secure

A boolean that enables Valve Anti-Cheat on the server. When set to true, the server checks every connecting player's VAC ban status. Players who have been VAC-banned in Unturned or in related Source-engine games are blocked from joining. The check happens at connection time, before the player enters the queue.

VAC is the primary anti-cheat mechanism available to server owners and is widely expected on public servers. A server with VAC disabled will have a larger potential player pool -- including players who have been banned elsewhere -- but also a higher risk of encountering cheaters. The calculus depends on your server type. A competitive PvP server almost always enables VAC because a single cheater can ruin the experience for dozens of legitimate players. A private PvE server with a whitelist may choose to disable it because the player pool is already vetted.

VAC bans are permanent and issued by Valve, not by individual server owners. Enabling VAC_Secure does not give you the ability to VAC-ban players; it only enforces existing VAC bans. Your own server bans, administered through admin commands or plugins, are separate from VAC.

Max_Ping_Milliseconds

An unsigned integer setting a hard ping limit in milliseconds. Any player whose measured ping exceeds this value is kicked from the server. The ping measurement is the round-trip time between the client and the server, measured continuously during gameplay.

Ping limits are a blunt instrument. Setting this too low -- for example, 100 milliseconds -- will kick players who are geographically distant, on Wi-Fi connections, or behind congested home routers. Setting it too high -- for example, 1000 milliseconds -- will allow players with severe latency to remain, which degrades the hit registration and movement synchronisation for everyone else on the server.

There is no universal correct value. A server hosted in central Europe with a primarily European player base might set 150 or 200. A server hosted in North America that wants to welcome players from South America, Europe, and Asia might set 300 or 400. The trade-off is always between inclusiveness and playability. Start high and lower it if you receive complaints about laggy players affecting combat.

If you leave this key unset (the default state), the ping limit is effectively disabled. Players with any ping can connect and stay connected. This is the most inclusive setting and is appropriate for small servers, private servers, and PvE servers where latency is annoying but not game-breaking. The trade-off is that a single high-ping player in a PvP scenario gains a latency advantage that other players will notice and complain about.

Timeout_Queue_Seconds

A float specifying how long the server waits for a player in the pre-join queue before giving up and kicking them. The timer starts counting from the last time the server received any communication -- any packet at all -- from that client. If that many seconds pass with complete silence, the connection is dropped and the queue slot is freed for the next waiting player.

The pre-join queue is the period after a player clicks "Join" but before they are fully loaded into the game world. During this window, the client and server exchange a series of handshake messages: authentication, workshop file verification, world data synchronisation. A stalled handshake -- from a crashed client, a dropped internet connection, a hung loading screen, or a client-side bug -- holds a queue slot indefinitely. Other players waiting to join are stuck behind it.

Setting a reasonable queue timeout reclaims those slots. A value of 30 to 60 seconds is typical. Shorter values risk kicking players whose loading is genuinely slow (e.g., on a mechanical hard drive loading a large map). Longer values keep the queue moving but may make the next player in line wait that long before they get a slot.

Timeout_Game_Seconds

A float specifying how long the server waits for communication from a fully connected player before kicking them. Like the queue timeout, the timer resets every time a packet arrives from the client. If the server hears nothing for this many seconds, it assumes the client is gone and removes the player from the game world.

This is the in-game equivalent of the queue timeout. It catches players who have already loaded into the world but whose connection has gone silent: a client crash, a network outage, a game freeze, or a player who alt-tabbed out during a loading screen and never came back.

The game timeout is typically set longer than the queue timeout because a silent in-game client is less disruptive than a stalled queue slot. A value of 120 to 300 seconds is common. A player who disconnects for two minutes and comes back can rejoin; a player who is gone for five minutes is probably not coming back.

These two timeout keys work together with Enable_Kick_Input_Timeout (explained later in this section), which handles a different case: a client whose network connection is alive but which has stopped sending input packets. Together, the three keys cover the main failure modes of a connecting or connected client.

Max_Packets_Per_Second

A float capping the number of network packets per second that the server will accept from a single client. This is a rate limiter at the network transport level, distinct from the application-level rate limits covered by the other throttle keys in this section. It operates on raw packet count before the server inspects the content of those packets.

Packets that exceed the cap are dropped by the server silently. From the client's perspective, this can manifest as missed inputs, delayed state updates, rubber-banding, or items that appear to vanish and reappear as the server state diverges from the client's prediction. The cap is designed to prevent a single misbehaving client -- whether malicious or buggy -- from flooding the server with so many packets that other clients experience lag or packet loss due to the server's network buffer filling up.

Setting the cap requires balancing normal gameplay bandwidth against flood protection. An Unturned client during normal gameplay sends a modest number of packets per second for movement, input, and state synchronisation. A client that is deliberately flooding or a client with a buggy network loop will send orders of magnitude more. Set the cap high enough that normal play is never throttled, but low enough that a flood is contained before it saturates the server's network buffer.

If you leave this key unset, the cap is effectively disabled. The server will accept packets at whatever rate clients send them. For most small to medium servers, the default (no cap) is adequate -- packet floods are rare outside targeted attacks. If you are running a large public server that attracts attention, setting a reasonable cap adds a layer of network-level protection that complements the application-level rate limits.

Join_Rate_Limit_Window_Seconds

A float defining a rolling time window in seconds for join-rate enforcement. The server tracks how many ready-to-connect messages each client has sent within a recent lookback period. The rule is: if the server receives more than two ready-to-connect messages from the same client within this many seconds, that client is kicked.

This prevents a client from rapidly hammering the join process. A legitimate client sends one ready-to-connect message when the player clicks "Join" in the server lobby. A second message might arrive if the first was lost in transit or if the player retried after a connection timeout. A third message within a short window is not normal behaviour -- it is either a buggy client caught in a reconnect loop, a connection issue causing duplicate transmissions, or a deliberate attempt to stress the server's join pipeline.

The window is a rolling measurement, not a fixed-interval resetting bucket. The server continuously evaluates how many join attempts have occurred in the recent past for each connecting client. When the count exceeds two within the window, the kick fires immediately. This means a client that sends three join attempts spaced exactly at the window boundary -- for example, at second 0, second 59, and second 60 with a window of 60 seconds -- would not be kicked, because the first attempt falls out of the window by the time the third arrives. A client that sends three attempts in rapid succession within a few seconds would be kicked regardless of the window value, as long as it is longer than the spacing between the attempts.

Bad_Packet_Rate_Limit_Window_Seconds

A float defining a rolling time window measured in seconds. During this window, the server counts how many bad packets it has received from a given connection.

A "bad packet" in this context means a packet that may be legitimate but is malformed, unexpected, or arriving at the wrong time in the protocol sequence. The game's internal documentation explicitly notes that these packets may be legitimate -- a momentary network hiccup, a packet reordering, or a client-side timing edge case can all produce packets that look bad to the server but are not malicious. Because of this ambiguity, the server does not immediately reject a bad packet. Instead, it accumulates a count and uses this window together with the threshold (below) to decide when a pattern has definitively emerged.

Bad_Packet_Rate_Limit_Threshold

An integer paired with Bad_Packet_Rate_Limit_Window_Seconds. If the number of bad packets received from a connection exceeds this threshold within the window duration, the server rejects the calling connection entirely.

The combination of window and threshold gives you two knobs for tuning sensitivity:

• A shorter window or a lower threshold is more aggressive. It will reject borderline connections faster, which protects the server but may kick players who are experiencing genuine network instability.
• A longer window or a higher threshold is more forgiving. It gives the client more time to demonstrate a pattern before acting, which reduces false positives but may let a truly problematic client linger longer.

Because the game's documentation explicitly notes that bad packets may be legitimate, err on the side of a higher threshold until you have a specific reason -- such as a documented attack pattern -- to tighten it. A server that rejects legitimate players because of a momentary packet anomaly is driving away its own player base.

Rate_Limit_Kick_Threshold

An integer controlling how many times a rate-limited internal method can be called off-cooldown before the client is kicked. Internally, the server has methods that are protected by cooldown timers -- the server will only process them at a certain maximum frequency. If a client calls a rate-limited method during its cooldown window, that is a violation. This key sets how many violations a client is allowed before the server kicks them.

The game's example: a value of 1 means the client is kicked the very first time they call a rate-limited method outside its allowed timing window. The game's own documentation notes that a value of 1 is not recommended, because a single timing edge case -- a packet arriving a few milliseconds early due to network jitter -- would kick an innocent player.

This is a blunt instrument. It is one of the most aggressive keys in the Browser section because a rate-limit violation can be a deliberate attempt to exploit a timing loophole, or it can be a harmless synchronisation quirk. Start with a higher value, or leave it unset to use the game's internal default behaviour, and only lower it if you have evidence -- from logs or player reports -- that a specific client is exploiting rate-limited methods.

Max_Clients_With_Same_IP_Address

An integer that limits how many simultaneous connections the server will accept from a single IP address. This key only applies when Use_FakeIP is disabled. When a client attempts to connect, the server checks how many other active connections already exist from the same source IP. If adding the new client would push the total count past this limit, the connection is refused with an error.

The default is 64, which is intentionally high. The game's own documentation notes that some regions have many more clients behind a single IPv4 address than others. The most common scenario is Carrier-grade NAT (CGNAT), used by many residential ISPs, where an entire apartment building, neighbourhood, or city block shares a single public IPv4 address. Every player behind that CGNAT appears to the server as coming from the same IP. Setting this limit too low -- for example, 4 or 8 -- would block legitimate players in CGNAT environments from joining after a handful of their neighbours are already connected.

The practical use case for this key is defence against fake join requests from a single source IP. If your server is experiencing a flood of bogus connection attempts, all originating from the same address, lowering this limit can stem the flood without affecting legitimate players connecting from normal residential IPs. This is referenced in the game's public issue tracker as issue #5001.

If you are not experiencing a specific attack, leave this at the default of 64 or higher. A value that is too low creates a worse experience (blocked legitimate players) than the problem it solves (a theoretical flood).

Max_Clients_With_Same_IP_Address_Log_Warnings

A boolean that controls whether connection refusals caused by Max_Clients_With_Same_IP_Address are logged to the server console output. The default is true.

The game's documentation suggests using this log output as a tuning aid. When the limit is hit and a connection is refused, the server prints a warning to the console showing the IP address that was blocked and the current connection count from that IP. By monitoring these warnings over time, you can determine:

• Whether the limit is being hit at all (if you never see warnings, the limit is high enough for your player base)
• Whether the blocked IPs belong to residential ranges that are likely CGNAT environments (in which case your limit is too low for those players)
• Whether the blocked IPs are concentrated during specific times, suggesting an attack pattern

If you see warnings for IP addresses that you know represent legitimate players, raise Max_Clients_With_Same_IP_Address. If you see warnings only from a single IP that is clearly not a CGNAT range and the attempts are rapid-fire, you may be under a join flood attack.

Fake_Lag_Threshold_Seconds

A float setting the detection threshold for potential lag-switching, measured in seconds. Under normal conditions, the server expects to receive multiple input packets per second from each connected client. If more time than this threshold passes between consecutive input packets from a client, the server flags that client as potentially using a lag switch.

A lag switch is a deliberate network manipulation where a player interrupts their connection for brief moments to create an advantage. In a PvP context, a lag-switching player appears to teleport or skip around on other players' screens, making them nearly impossible to hit while they can still see and shoot at others. The server detects this by measuring the gap between input packets. A legitimate client sends input continuously; a client behind a lag switch goes silent for controlled bursts.

Lag-switch detection is inherently prone to false positives. A client whose framerate hitches -- for example, when loading a dense area of the map with many objects, vehicles, or players -- will naturally send fewer input packets during the hitch. From the server's perspective, a framerate hitch is indistinguishable from a lag-switch gap. The game's own documentation acknowledges this explicitly, noting that false positives are relatively likely when a client's framerate hitches.

When a client is flagged, the server applies a penalty for a duration corresponding to the length of the detected gap. The type and severity of the penalty are controlled by the next two keys. The default for this threshold is unset, meaning fake lag detection is inactive unless you explicitly configure it.

Fake_Lag_Log_Warnings

A boolean controlling whether fake lag detections are logged to the server console output. The default is unset, meaning no logging occurs unless you enable it.

The game's documentation recommends using this key for tuning the threshold rather than for issuing bans, precisely because false positives are common. When you are dialling in Fake_Lag_Threshold_Seconds, turn logging on and observe the console output during several play sessions. Note which players trigger detections and in what circumstances. If you see detections for players who are clearly not cheating -- for example, detections that coincide with map transitions, loading screens, or vehicle explosions -- your threshold is too tight.

Once you have a threshold that catches genuine lag-switching behaviour without flagging normal gameplay, you can turn logging off to keep your console output clean. Alternatively, leave it on for ongoing monitoring if you want to catch shifts in player behaviour or new lag-switch techniques.

Fake_Lag_Damage_Penalty_Multiplier

A float multiplier applied to the damage a player deals while under the fake lag penalty. This is a PvP-specific value: when the server flags a client as potentially using a lag switch, any damage that player inflicts on other players is multiplied by this number.

The multiplier scales damage output. A value of 0.5 halves the flagged player's damage. A value of 0.25 reduces it to a quarter. A value of 0.0 prevents them from dealing any damage at all. A value of 1.0 effectively disables the damage penalty while keeping the detection system active, which is useful if you only want logging without mechanical consequences.

The purpose of the damage penalty is to neutralise the advantage a lag-switching player gains. If they are teleporting and impossible to hit, reducing their damage output until the pattern stops is a proportional response. It does not kick them, so a false positive results in a temporary damage reduction rather than a removal from the server. The penalty expires when the fake lag condition clears, which happens when the client resumes normal input packet frequency.

The default for this key is unset, meaning no damage penalty is applied even if fake lag detection is active. You must set it explicitly to give the detection system teeth. The Fake_Lag_Log_Warnings key should be enabled while you are tuning this value so you can correlate penalties with player reports.

Enable_Kick_Input_Spam

A boolean controlling whether the server kicks players who are detected spamming calls to the internal askInput method. Input spam is a rapid-fire barrage of input packets -- movement, looking, firing, interacting -- sent far faster than a human player can physically generate. It is typically the result of a script, a macro, or a buggy client plugin.

When enabled, the server monitors the rate of incoming input calls and compares it against a reasonable threshold for human input. A client that exceeds this threshold -- for example, sending hundreds of input packets per frame when a human player sends one or two -- is flagged and kicked within a short detection window.

Most public servers should enable this. The only reason to disable it is if you are debugging a client-side input issue and need to observe the behaviour without the server intervening. The kick is immediate and the kicked player receives a disconnect message indicating the reason.

Enable_Kick_Input_Timeout

A boolean controlling whether the server kicks players who stop submitting inputs entirely for an extended period. This is distinct from the network-level timeouts (Timeout_Game_Seconds): a player whose network connection is alive and passing health-check packets but whose game client has stopped sending input packets will not be caught by the network timeout. This check catches that case.

The typical scenario is a player who loads into the game, then their game window loses focus and enters a frozen background state. The network connection stays open -- TCP keep-alive packets still flow -- but no input packets arrive because the game is not processing input. From the server's perspective, the player is standing motionless in the world, taking up a slot that an active player could use.

Enabling this frees those slots. The exact timeout duration for input silence is configured elsewhere in the server's settings (not in the Browser section). This key is the on/off switch for whether the check runs at all.

Enable_Scheduled_Shutdown

A boolean that, when set to true, causes the server to shut itself down automatically at the time specified by Scheduled_Shutdown_Time. This is useful for servers that run on a daily restart schedule. Many server owners restart their server once a day -- typically during the lowest-activity hours -- to clear accumulated memory, apply configuration changes, or refresh workshop content.

The shutdown is a full server stop. The game process exits. It does not restart itself. If you want the server to come back up after the scheduled shutdown, you need an external mechanism: a process manager (like systemd on Linux or a scheduled task on Windows), a hosting panel that monitors the process and restarts it, or a wrapper script that loops and relaunches the server executable.

Before the shutdown, the server announces it to connected players through the in-game chat or broadcast system, giving them time to finish what they are doing and disconnect gracefully. The exact lead time and message format depend on the server's broadcast settings.

Scheduled_Shutdown_Time

A string specifying the time of day when the automatic shutdown should occur. This key is only read when Enable_Scheduled_Shutdown is set to true. The default is "1:30 am".

The value is stored as a human-readable time string with an am/pm suffix, matching the default's format. Because this is a string rather than a structured time type, the exact parsing rules depend on how the game's code interprets it. Stick to the format shown in the default -- "H:MM am" or "H:MM pm" -- to ensure the server parses it correctly. For example, "3:00 am", "11:45 pm", "12:00 pm".

The time is interpreted in the server's local time zone, which is the time zone of the machine the server process runs on. If your server is hosted in a data centre in a different time zone than your player base, account for the offset when choosing the shutdown time. A shutdown set to "3:00 am" on a server in UTC will fire during European evening hours, which may be your peak player activity window.

Enable_Update_Shutdown

A boolean that, when set to true, causes the server to shut itself down automatically when a new game version is detected on Steam. The server periodically checks the Steam depot for the branch specified by Update_Steam_Beta_Name. If a newer build is available, the server initiates a shutdown.

This is a safety mechanism for maintaining version compatibility. When Unturned receives an update on Steam, all clients that update their game will be running a newer version than the outdated server. An outdated server cannot accept connections from updated clients; they will see a version mismatch error when attempting to join. By shutting down automatically when an update is detected, the server forces the owner to update the server files before it can run again.

Like the scheduled shutdown, this is a full process stop, not a restart. You need an external process to apply the update (through SteamCMD or your hosting provider's update tool) and bring the server back up. Without an external restart mechanism, an update shutdown leaves your server offline until you manually intervene.

Update_Steam_Beta_Name

A string specifying which Steam beta branch the server should monitor for updates when Enable_Update_Shutdown is true. The default is "public", which monitors the main public release branch of Unturned.

The game's internal documentation notes an important limitation: the server process cannot automatically determine which beta branch it is currently running. You must set this value manually to match the branch your server files were installed from. The possible values correspond to the beta branches listed in Steam's Betas tab for Unturned:

• "public" -- the default. Monitors the main release branch. Most servers should use this.
• Other branch names, such as "preview" or "experimental", correspond to opt-in beta branches that players can select in Steam.

If your server is on a preview branch and this key is set to "public", a new public update will not trigger a shutdown, and your server will still be outdated relative to public branch clients. Conversely, if your server is on the public branch and this key is set to a preview branch, a preview update (which your players have not installed) may trigger an unnecessary shutdown.

Make this key part of your server setup checklist: whenever you change the beta branch your server runs on, update this value to match. A mismatch silently breaks the update shutdown feature.

Validate_EconInfo_Hash

A boolean controlling whether the server checks the hash of EconInfo.json at startup. EconInfo.json is a game data file that defines economy-related content: item definitions, currency configurations, and their properties. The hash check is a data integrity verification: the server computes a cryptographic hash of the file on disk and compares it against the expected hash for the current game version. If the hashes do not match, the file has been modified -- whether intentionally by a server owner editing item properties, or accidentally through disk corruption or an incomplete update -- and the server can refuse to load it.

Most server owners should leave this in its default state, which the game treats as enabled (effectively true). The hash check prevents a corrupted or tampered economy file from loading, which could introduce item duplication bugs, missing item references, or economy exploits that affect every player on the server. A server that loads a corrupted economy file may run for hours before the corruption manifests as gameplay bugs, making the root cause hard to trace.

The only valid reason to disable this check is if you are actively developing or testing economy content and need to iterate quickly. During development, you may edit EconInfo.json frequently and restart the server to test each change. Recomputed hashes after every edit slow down the iteration loop. In that scenario, disable hash validation during the development session, then re-enable it before the server goes live to players.

Do not leave hash validation disabled on a production server. The check exists to catch corruption before it reaches players. A server that loads a corrupted economy file without warning may silently produce item bugs, lost inventories, or economy balance issues.

Reset_Vehicles_Outside_Horizontal_Distance

A float measured in world units. If this value is greater than zero, any vehicle whose XZ (horizontal) position exceeds this distance from the map centre is saved back at the centre of the map during the next save cycle. The default is 40000.0f, which is 40,000 world units -- roughly 40 kilometres from the map origin.

This key exists to address physics issues caused by vehicles that end up far outside the playable map area. A vehicle launched by an explosion, a physics collision with another vehicle, or a game engine edge case can travel enormous distances over time if the physics simulation does not settle it. At extreme coordinates, the floating-point precision of the physics engine degrades, which can cause vehicles to vibrate, teleport, or cause performance problems for every player on the server.

By resetting vehicles that cross the horizontal distance threshold back to the map centre, the server prevents these physics degradation problems from accumulating. The vehicle is teleported to the centre of the map (coordinates 0,0) and saved there. It does not lose its inventory, fuel, or damage state; only its position changes.

The default of 40,000 units is generous -- most Unturned maps are a few thousand units across, so a vehicle at 40,000 units is well beyond any playable area. If you set this to 0, the feature is disabled entirely and vehicles will stay wherever physics sends them. On a long-running server with high player counts and frequent vehicle use, disabled vehicle reset may lead to physics-related performance degradation over weeks or months. The game's documentation references public issue #4465 as the original motivation for this feature.

How keys interact

Several keys in the Browser section are not independent. They form clusters where the behaviour of one key changes the meaning of another. Understanding these clusters is more important than memorising each key in isolation, because a misconfiguration in one key can silently break another without producing an error.

BookmarkHost + Use_FakeIP

These two keys are a pair. Use_FakeIP enables Steam's relay system, which hides your real IP but assigns random ports at startup. A random port means you cannot give players a fixed address:port to reconnect to. BookmarkHost solves this by letting you provide a DNS name or a web endpoint that tells clients the current port.

If you enable Use_FakeIP without setting BookmarkHost to a web endpoint (the http:// or https:// form), players will be able to join through the server list but will not be able to bookmark the server or reconnect directly. Every time the server restarts and gets a new port, bookmarked clients will fail to connect.

If you set BookmarkHost to a plain DNS name while Use_FakeIP is enabled, the DNS name resolves to your server's public IP, but the port is still random. The client needs both the IP and the port; the DNS name only provides the IP. Use the web endpoint form of BookmarkHost with Fake IP.

The three timeout keys

Timeout_Queue_Seconds, Timeout_Game_Seconds, and Enable_Kick_Input_Timeout cover three different failure modes for a connected client:

1. Queue timeout: The client is in the pre-join queue (loading) and has gone silent at the network level. No packets at all.
2. Game timeout: The client is fully in the game world and has gone silent at the network level. No packets at all.
3. Input timeout: The client's network connection is alive (health-check packets still flow) but the game client has stopped sending input. This is a frozen or backgrounded game, not a network drop.

A client that is fully crashed -- game process dead, network connection closed -- will be caught by the game timeout relatively quickly. A client that is frozen -- game process alive, window in background, network connection maintained -- will not be caught by the game timeout because the network is still live. The input timeout catches this case.

For a well-rounded timeout configuration, enable all three. Set the queue timeout shortest, the game timeout longer, and the input timeout somewhere in between. The queue is the scarcest resource (one slot holds up the entire join pipeline), so reclaim those slots most aggressively. Game slots are less scarce, so allow more grace. Input timeouts sit in the middle because a frozen client is taking a slot without participating.

The bad packet window and threshold

Bad_Packet_Rate_Limit_Window_Seconds and Bad_Packet_Rate_Limit_Threshold are inseparable. Neither does anything without the other. The window defines the lookback period; the threshold defines the tripwire within that period. Changing one without adjusting the other changes the sensitivity in ways that are easy to misjudge.

A window of 5 seconds with a threshold of 5 means: 5 bad packets in 5 seconds triggers rejection. That is 1 bad packet per second on average. A window of 60 seconds with a threshold of 5 means: 5 bad packets in a full minute triggers rejection. The second configuration is 12 times more forgiving, yet both have the same threshold value. The threshold number alone tells you nothing; it is the ratio of threshold to window that matters.

When tuning, think in terms of bad packets per second: threshold divided by window. A ratio of 0.5 or lower (e.g., 5 bad packets in 10 seconds) is aggressive. A ratio of 0.1 or lower (e.g., 5 bad packets in 60 seconds) is relaxed. Start relaxed and tighten only if you see abuse.

The fake lag trio

Fake_Lag_Threshold_Seconds, Fake_Lag_Log_Warnings, and Fake_Lag_Damage_Penalty_Multiplier form a detection-logging-penalty pipeline. Enable only the threshold, and the server detects fake lag but does nothing with the information -- the detection is invisible to both you and the player. Enable threshold plus logging, and you can see detections in the console but the flagged player experiences no consequence. Enable all three, and the server detects, logs, and reduces the flagged player's damage output.

The intended tuning workflow is: enable threshold and logging, observe for several play sessions, adjust the threshold until false positives stop, then enable the damage multiplier. Do not enable the damage multiplier on day one. A player whose damage is halved because your threshold is too tight will leave and not come back. A player whose damage reduction is logged in your console as a data point costs you nothing.

Canned Beans

The Browser section of Config.json makes no reference to canned beans. This is expected and is not an omission. The Browser section governs server presentation, networking parameters, and anti-abuse behaviour. None of these concerns involve item spawns, loot tables, or food item statistics. Canned beans live elsewhere in the game's configuration: in the economy data that defines items (EconInfo.json), in the item asset definitions bundled with the game, and in the loot spawn tables that control which items appear in which containers across the map.

If you arrived here looking for bean data and found server configuration instead, the distinction is worth internalising: Config.json tells the server how to run. The economy files tell the server what items exist. The map files tell the server where items appear. These are separate systems with separate configuration surfaces. Browser section keys like Validate_EconInfo_Hash incidentally reference the economy system -- the hash check verifies the economy file's integrity -- but the Browser section does not itself contain any item data.

For the complete story on canned beans in Unturned, including their nutritional statistics relative to other food items, their spawn locations, and their long-running cultural significance in the Unturned community, see the canonical article at /lore/canned-beans-lore.

The absence of beans from the Browser configuration is itself a useful lesson in how Config.json is organised. The file is not a monolithic dump of every setting the game knows about. It is a structured document where each section owns a specific domain. The Browser section owns presentation and networking. The Server section owns game rules and world parameters. The economy files own items. Knowing which section owns which domain is the first skill a server owner develops; it saves hours of searching the wrong section for a setting that lives somewhere else.

Practical use for server owners

The Browser section is not the kind of configuration you set once and forget. Several of the keys interact with each other, and changes to one can shift the effective behaviour of another. A server that starts with generous, permissive settings during its launch week may need tighter limits as its player count grows and it attracts attention. A server that tightens its rate limits too aggressively may drive away players who experience false positives and never report them. The art of configuring the Browser section is finding the settings that protect your server without punishing your players.

The advice below is organised by server lifecycle stage -- from initial setup to ongoing maintenance -- and focuses on the interactions between keys that are not obvious from reading each key's description in isolation.

Initial setup

Start with the identity keys before you open the server to the public. Set Login_Token first, because without it your server will not appear in the server list at all. The token must be valid, not expired, and associated with the Steam account you used to create it. Test that the server appears in the list after setting the token; if it does not, the token is likely invalid or the server's firewall is blocking the Steam server browser port.

Set BookmarkHost next. If you own a domain, create a DNS A record pointing to your server's IP and use that hostname. If you do not own a domain, you can use a raw IP address, but understand that an IP change will break all bookmarks. If you are using Fake IP, you must set up the web endpoint before setting BookmarkHost, because Fake IP assigns random ports and the web endpoint is how clients learn the current port.

Write the description fields before you invite players. An empty Desc_Hint or Desc_Server_List looks abandoned. The three description fields (Desc_Hint, Desc_Full, Desc_Server_List) serve different positions in the user interface and should be written as a set, not as copies of each other. The server list description earns the click; the lobby hint earns the join; the full description answers questions.

Configure your timeout values before you have players to lose. Timeout_Queue_Seconds, Timeout_Game_Seconds, and Enable_Kick_Input_Timeout together determine how aggressively your server reclaims slots from silent clients. Set them too short and players will be kicked during normal loading. Set them too long and AFK players will occupy slots. Start with moderate values (e.g., 60 for queue timeout, 300 for game timeout) and adjust after observing real traffic.

Rate limiting and anti-abuse

Dial in rate limits with logging on, not with kicking on. The Bad_Packet_*, Fake_Lag_*, and Max_Clients_With_Same_IP_Address_Log_Warnings keys are all designed to let you observe behaviour before you enforce consequences. Enable logging, leave the threshold keys at their defaults or at generous values, and run the server for several play sessions. Watch the console output to understand what "normal" traffic looks like for your server's player count and geography.

Bad packet thresholds interact with the bad packet window. Bad_Packet_Rate_Limit_Window_Seconds and Bad_Packet_Rate_Limit_Threshold must be tuned together. A window of 10 seconds with a threshold of 3 is very different from a window of 60 seconds with a threshold of 3. The first rejects a connection after 3 bad packets in 10 seconds; the second rejects after 3 bad packets in a full minute. The window sets the memory of the system; the threshold sets the trigger. Start with a longer window and a higher threshold, then tighten only the parameter that is letting through actual abuse.

Fake lag detection is a three-key system. Fake_Lag_Threshold_Seconds sets the detection sensitivity, Fake_Lag_Log_Warnings lets you observe detections, and Fake_Lag_Damage_Penalty_Multiplier applies the consequence. Do not set the damage multiplier until you have used the log warnings to confirm that your threshold is not flagging innocent players during normal gameplay. A damage multiplier of 0.5 coupled with a threshold that fires on every map transition will frustrate legitimate players more than any lag-switcher ever could.

Rate_Limit_Kick_Threshold is the most aggressive key in the section. The game's own documentation warns against setting it to 1. A rate-limit kick is instant and final; there is no warning, no grace period, and no appeal. Leave this unset unless you have log evidence of a specific client exploiting rate-limited methods, and even then, start with a value of 5 or 10 and observe the results before going lower.

Visual assets

Test your thumbnail and icon at their real rendered sizes. An image that looks good at 512x512 pixels may be an illegible blur at 32x32. Before you point Icon and Thumbnail at your final URLs, take your chosen images and resize them to exactly 64x64 and 32x32 pixels in an image editor (not by zooming out in a viewer, which may apply smoothing). View them at 100% zoom on your monitor -- the size they will actually appear in the game. Ask yourself whether you can tell what the image is supposed to be. If you cannot, neither will a player scanning a list of 50 servers.

Use different images for thumbnail and icon if your logo is complex. The thumbnail needs to be a shape and a colour. The icon can carry more detail. If your server logo is a detailed illustration with text, create a simplified version -- just the central symbol or the first letter -- for the thumbnail, and use the full logo for the icon.

Host images somewhere reliable. A broken icon URL (404, timeout, or hosting suspension) leaves an empty slot in the lobby menu. Free image hosting services that delete files after inactivity or throttle bandwidth after a traffic threshold are not suitable for server assets. Use a reliable host or serve the images from the same web server that hosts your BookmarkHost endpoint.

Scheduled maintenance

Find your server's actual dead zone before setting Scheduled_Shutdown_Time. The default of 1:30 am is a reasonable starting point, but it assumes your player base is in a time zone where 1:30 am is genuinely low-traffic. Check your server's player count over at least one full week, broken down by hour, to find the window with the fewest active players. Schedule the shutdown for the middle of that window.

If your server has players from multiple continents, the dead zone may be smaller than you expect -- a 3:00 am shutdown in your time zone may be 8:00 pm prime time for players on the other side of the world. In that case, pick the time that affects the fewest players, even if the count is not zero. A shutdown that interrupts 2 players at 4:00 am is better than one that interrupts 20 players at 10:00 pm.

Pair shutdowns with automatic restarts. Both Enable_Scheduled_Shutdown and Enable_Update_Shutdown stop the server process but do not restart it. An external process manager -- systemd with Restart=always on Linux, a scheduled task that checks for the process on Windows, or a hosting panel's built-in restart feature -- is required to bring the server back up. Without it, your server will go offline at the scheduled time and stay offline until you manually start it.

Keep Update_Steam_Beta_Name in sync with reality. If you switch your server to a preview branch for testing, update this key to "preview". If you switch back to the public branch, update it back to "public". A mismatch between the monitored branch and the actual branch silently disables the update shutdown feature. Add this check to your server update procedure.

Ongoing maintenance

The Links array is your community funnel. Every player who opens the server lobby menu is a potential long-term community member. Give them one-click access to your Discord server, your website, and your rules page. A well-placed Discord invite button, visible in the lobby before the player even joins, converts casual browsers into community members at a higher rate than any in-game announcement.

Revisit your rate limits when your player count changes. A threshold that works well for a server with 8 concurrent players may be too aggressive for a server with 32 players, because the total volume of edge-case packets scales with player count. If your server grows significantly, check whether your bad packet and fake lag detections have started firing on legitimate players during peak hours.

Every server has a natural ceiling for how aggressively it can filter connections before it starts rejecting legitimate players. That ceiling is determined by your player base's geography, their connection quality, and the type of gameplay your server hosts. A competitive PvP server can justify tighter filters because players expect a controlled environment. A casual PvE server with players joining from mobile hotspots and rural connections should keep its filters generous. The Browser section gives you the knobs; your server's identity determines where to set them.

The Browser section is the face your server shows to the world. It deserves the same ongoing attention you give to your map, your mods, and your community management. An outdated description, a broken icon, or a ping limit that silently blocks players from an entire region are all problems that a player will notice before they have even joined your server. The Browser configuration is the first impression. Make it count.

Common pitfalls

Several misconfigurations recur across server setups and are worth calling out explicitly because they produce silent failures -- the server starts, appears in the list, and gives no error, but something is broken.

Setting Login_Token but not creating the Steam game server account first. The token is a value you copy from the Steam Game Server Account Management page. It is not a value you invent. If you type a random string into this field, the server will start but will not appear in the public server list. There is no error message for an invalid token; the server simply stays invisible.

Using BookmarkHost with a web URL that returns HTML instead of plain text. If your endpoint returns an HTML page (a common default for web servers that receive a request to a route they do not recognise), the client will try to parse the HTML as an IP address and fail. The endpoint must return a bare string like 127.0.0.1:27015 with no markup, no JSON wrapper, and no surrounding whitespace.

Setting Max_Clients_With_Same_IP_Address to a small number like 2 or 4. This will block legitimate players in CGNAT environments, and you will not know it is happening unless Max_Clients_With_Same_IP_Address_Log_Warnings is enabled. A player who cannot join your server because their neighbour is already playing will not send you a bug report; they will join a different server.

Pointing Icon or Thumbnail at a URL that requires authentication. The game fetches these images as anonymous HTTP GET requests. If your image host requires a login, an API key, or a referrer header, the request will fail and the image will not load. Host your server images on a public, unauthenticated endpoint.

Setting all three timeout values to the same number. The queue, game, and input timeouts address different failure modes at different stages of the connection lifecycle. A queue slot is scarcer than a game slot, so the queue timeout should be shorter. A crashed client recovers faster (or not at all) than a frozen client, so the network timeouts and the input timeout should differ. Identical values mean you are not distinguishing between these cases, and you are either kicking players too aggressively from one stage or letting them linger too long in another.