Server Whitelist and Connection Issues

You found a great-looking Unturned™ community server. The server browser entry looks healthy, the player count is in a comfortable range, the map is one you want to play, and your friends are already on it. You click Join, the loading screen appears for a moment — and then you are dropped back to the main menu with a message that says you are not on the server's whitelist. Or you are kicked the moment you spawn. Or the server accepts you for a brief window and then disconnects you without explanation.

Whitelist-related connection issues are among the most confusing failures in Unturned because the error messages are often vague and the resolution depends on context the player does not have. A whitelist is the server operator's allow-list of approved Steam accounts; players who are not on the list cannot connect, regardless of any other configuration on either side. The remedy is rarely something the player can fix on their own. It is something the server operator has to do, after the player has provided the right information and has gone through the right channel.

This article documents what a whitelist is, how Unturned servers implement them, what the symptoms of a whitelist block look like (and how to distinguish them from bans and IP blocks), how to request whitelist access, and what server operators do on their side to maintain whitelists. The aim is to make the workflow predictable for both players and operators, so neither side wastes time on a misdiagnosed connection failure.

Validate that the problem is real

Whitelist kicks are easy to misdiagnose. The on-screen message can read as a generic "kicked from server" or "unable to connect," and the player often does not know that the server they are trying to join even has a whitelist. Before assuming the issue is whitelist-related, work through the following short checklist:

• Does the server's published description, Discord, or website mention a whitelist?
• Did the disconnection happen immediately on connect, or after a few minutes of play?
• Does the kick message contain the words "whitelist," "not authorized," "permission," or "approved"?
• Have other players (not on the whitelist) reported the same symptom?

If the answers point to a whitelist block, this article is the right starting point. If the symptoms point to a generic connection failure, work Unable to Connect to the Server first; if the friend-specific case, see Cannot Join Friends Server.

Prerequisites

• A current installation of Unturned from the official Steam store page.
• The Steam client running and signed in.
• Your Steam ID (SteamID64) ready to share with the server operator.
• For operators: file system access to the server's configuration directory and any plugin configuration directories.
• A communication channel with the server's staff (typically Discord) for whitelist requests.

What you'll learn

• What a server whitelist is and why operators use them.
• The differences between the vanilla Unturned whitelist and plugin-driven whitelists (RocketMod, OpenMod).
• How to read the kick message and distinguish a whitelist block from a ban, IP block, or password failure.
• How to find your Steam ID in multiple formats (SteamID64, SteamID2, SteamID3, vanity URL).
• How to request whitelist access through the right channel.
• How operators add and remove entries from the whitelist on their side.
• The order in which the server applies its connection checks (ban check, whitelist check, password check, capacity check).
• The plugin-specific commands operators use to manage whitelists.

Background: what a whitelist is and why it exists

A whitelist is an allow-list of Steam accounts that the server permits to connect. The list is maintained by the server operator. When a client attempts to connect, the server consults the whitelist (where one is configured) and rejects any account that is not present. The rejected client sees a kick message that may or may not name the whitelist as the cause.

Whitelists exist because they let operators run a server for a specific community of players without dealing with random visitors. Roleplay servers (where lore consistency depends on knowing everyone in-world), private friend groups, premium-access servers, and community servers with high investment in moderation all commonly use whitelists. A whitelist is the strongest filter an Unturned server can apply: it overrides ping, browser visibility, and password — if the account is not on the list, the connection is rejected before any other check matters.

A whitelist is distinct from a ban list (which blocks specific accounts) and from an IP block (which blocks specific network addresses). The relationships are documented later in this article; the short version is that whitelist is an allow-list while ban list and IP block are deny-lists.

The flowchart above models the order of operations a typical Unturned server applies when a client connects. The ban check runs first; the whitelist check runs after IP blocks and before password. Each rejection produces a distinct kick message, but only the whitelist rejection requires action by the operator before the client can connect.

Did you know?

The order of connection checks varies slightly between vanilla Unturned and plugin-driven servers. RocketMod and OpenMod plugins can hook into the connection pipeline at multiple points and may apply their own checks before or after the stock checks. The order shown above is the most common, but operators using custom plugins may have a different sequence. The Unturned client log shows which check actually rejected the connection, which is useful when the order is unclear.

Vanilla whitelist versus plugin-driven whitelists

Unturned ships with a stock whitelist mechanism, but most community servers use a plugin-driven whitelist instead. The difference matters for both players (who see different kick messages) and operators (who use different commands to manage the list).

Aspect	Vanilla whitelist	RocketMod / OpenMod whitelist
Configuration	Server configuration files	Plugin configuration files
Format	Steam ID one per line	Varies per plugin
Add command	whitelist add <SteamID>	Plugin-specific (e.g., wl add <SteamID>)
Remove command	whitelist remove <SteamID>	Plugin-specific
Enforcement	Server core	Plugin hook
Kick message	"You are not on the whitelist"	Plugin-defined string
Default behaviour	Disabled (open server)	Disabled until plugin is configured
Visibility in browser	Not exposed	Not exposed

Players cannot tell from outside the server which whitelist mechanism is in use. The kick message string is the most reliable signal: a stock vanilla whitelist produces a consistent built-in message, while plugin-driven whitelists produce messages defined by the plugin's configuration.

Pro tip

If you are unsure which mechanism the server uses, paste the exact kick message you received into the server's Discord and ask. Operators recognise their own plugins' messages immediately and can route the request appropriately.

Vanilla whitelist file format

The vanilla Unturned whitelist is a plain text file that lists approved Steam IDs, one per line. The format is:

76561198000000000
76561198000000001
76561198000000002

Each line is a SteamID64. The format is unforgiving: extra whitespace, comments, or alternative ID formats can cause the line to be ignored without an error message. Operators editing the file by hand should preserve the strict format.

RocketMod whitelist configuration

RocketMod (legacy) whitelists are managed by plugins such as Whitelist (community-published) or EasyWhitelist. The configuration files live in the server's Plugins/<PluginName>/ folder and typically use XML or JSON format. The plugin's documentation describes the exact format; the cohort observation is that most RocketMod whitelist plugins use a simple list-of-Steam-IDs structure similar to the vanilla format.

OpenMod whitelist configuration

OpenMod whitelists are managed by OpenMod plugins. The configuration files live in the OpenMod installation directory and use YAML format. OpenMod plugins typically expose console commands such as wl add and wl remove that operators can run in-game or through the server console.

Symptom-to-cause map

The table below maps the symptoms a player observes to the most likely underlying cause and points to the resolution path.

Symptom	Most likely cause	Resolution
"You are not on the whitelist" kick on connect	Vanilla whitelist block	Request whitelist access
"Whitelist: access denied" or plugin-defined string	Plugin-driven whitelist block	Request whitelist access
Kicked immediately on join, no whitelist message	Could be ban, see ban section	Check log for ban message
Kicked after a few seconds with no message	Capacity or queue-related rejection	Wait and retry
Some friends can join, you cannot	Whitelist enforced, you are not on it	Request whitelist access
Can join briefly, then disconnected	Plugin-applied delayed whitelist check	Confirm whitelist status
Can connect during specific hours only	Time-based access control	Confirm operator's schedule
"Unable to connect" with no further detail	Could be whitelist or other cause	Read client log

The Unturned client log at %LOCALAPPDATA%\Unturned\Player.log records the exact server response. Reading the log is the most reliable way to confirm a whitelist-specific block versus another cause.

Whitelist block versus ban versus IP block

A player rejected by a server may have been blocked by any one of three distinct mechanisms. The mechanisms have different remedies, so distinguishing them is the first step in resolution.

Mechanism	What it blocks	How to recognise	Remedy
Whitelist	Accounts not in the allow-list	"Not on whitelist" or similar in log	Request whitelist addition
Ban list	Specific accounts the operator banned	"You are banned" message; may include reason and expiry	Submit ban appeal
IP block	Specific IP addresses the operator blocked	Connection refused before kick message	Use different network or contact operator
Region filter	Players outside the permitted geographic region	Region-specific message	Find a server in your region
Account-level restriction	Steam account flags such as VAC	Often at handshake stage	Resolve the underlying Steam restriction

A whitelist block is not a ban. A whitelisted account is not banned; it is simply not on the allow-list. The remedy is to be added to the list, not to appeal a ban. Confusing the two leads to time wasted on the wrong appeal process.

Common mistake

Treating a whitelist block as a ban appeal. Operators distinguish the two: a ban appeal asks the operator to reverse a moderation decision, while a whitelist request asks the operator to add a new account to the access list. Sending a ban appeal for a whitelist block confuses the operator and slows the resolution.

Diagnostic steps

Step 1: Read the Unturned client log

The Unturned client log records the exact kick reason returned by the server. The log is at %LOCALAPPDATA%\Unturned\Player.log. Open the log in Notepad++ immediately after the failed join and scroll to the end. The last few lines describe the most recent connection attempt.

A whitelist block typically produces one of the following log lines:

Kicked: You are not on the whitelist
Kicked: Whitelist: access denied
Kicked: Not authorized to connect
Disconnected: <plugin-defined whitelist message>

A ban typically produces:

Kicked: Banned: <reason>
Kicked: Banned until <date>
Disconnected: You are banned from this server

An IP block typically produces:

Connection refused
No response from server

The log's exact wording is the highest-signal diagnostic. Capture the line and share it with the server operator when requesting access.

Step 2: Find your Steam ID in the format the operator needs

Operators add entries to the whitelist by Steam ID. Steam has several distinct ID formats, and operators may request a specific format. The four common formats are:

Format	Example	Used by
SteamID64	76561198000000000	Modern Unturned and most plugins
SteamID2	STEAM_0:0:00000000	Older RocketMod plugins
SteamID3	[U:1:00000000]	Specific console commands
Vanity URL	gabelogannewell	Steam community URL

To find your SteamID64:

1. Open Steam and click your profile name in the top-right.
2. Click "Account Details."
3. Your SteamID64 is displayed beneath your profile name.

If the SteamID64 is not visible, find it on Steam's website by navigating to your profile page and copying the numeric ID from the URL.

Pro tip

Bookmark a third-party Steam ID lookup tool that converts between formats. When an operator requests a specific format you don't have on hand, the lookup tool produces every format from any one of them. Share all formats in your whitelist request to avoid back-and-forth.

Step 3: Confirm the server's whitelist policy

Before requesting whitelist access, confirm the server's policy. Some servers have:

• An open whitelist where any active player can request and is approved automatically.
• A community-vouched whitelist where existing players vouch for new members.
• An application-based whitelist where prospective players fill out a form.
• A purchase-based whitelist where access is sold as a premium tier.
• A closed whitelist where new members are not currently being added.

The server's Discord or website describes the policy. Following the operator's documented process is the fastest path to access; bypassing the process (DM'ing the owner directly, for example) is typically slower because the owner has built the process to filter requests efficiently.

Step 4: Request whitelist access through the right channel

Once you have your Steam ID and you understand the policy, submit the request through the operator's documented channel. A well-formed request typically includes:

• Your SteamID64 (and other formats if requested).
• Your Steam profile link.
• Your in-game username.
• A short statement of why you want to join (for community servers that vouch new members).
• The exact kick message you received (helps the operator confirm the issue is whitelist-related).

The response time depends on the operator. Some operators respond within minutes; others have a queue of requests and may take days. Patience is appropriate; nagging the operator does not speed the process.

Step 5: Retry the connection after approval

Once the operator confirms you are on the whitelist, retry the connection. The whitelist takes effect immediately on most server implementations; some plugins require a server restart or a config reload before the change is active. If the connection still fails after the operator confirms addition, ask whether a reload is needed.

The flowchart above is the recommended order of operations. Following it produces predictable resolution times across the cohort.

Resolution methods

Method 1: Submit a whitelist request

The standard resolution for a whitelist block is to be added to the list. The request process varies by server but the components are consistent.

1. Read the kick message in the client log.
2. Find your SteamID64.
3. Locate the server's whitelist request channel (Discord channel, forum thread, web form).
4. Submit a request including SteamID64, profile link, and the exact kick message.
5. Wait for operator response.
6. Retry the connection after approval is confirmed.

For closed-whitelist servers, the operator may have an application process with specific requirements (interview, vouching, paid access, etc.). Follow the documented process; deviations slow the response.

Common mistake

DM'ing the server owner with a one-line "let me in" request. Operators of community servers receive many such messages and typically ignore them in favour of properly formatted requests submitted through the documented channel. The community channel exists to make the operator's process efficient; using it benefits everyone.

Method 2: Verify whitelist application after approval

Sometimes the operator confirms the addition but the server's whitelist file or plugin has not yet reloaded. The result is that the player continues to see the whitelist kick even after approval.

1. Confirm the approval timestamp with the operator.
2. Ask whether a server restart or config reload is needed for the change to take effect.
3. If the operator confirms a reload is needed, wait for it to complete.
4. Retry the connection.

A small fraction of plugin-driven whitelists cache the list in memory and do not pick up changes until the plugin is reloaded. The operator will know whether their setup has this behaviour.

Method 3: Confirm the SteamID format the operator used

A whitelist entry that does not match the player's account exactly will not unblock the player. The most common cause of a mis-entered whitelist is a SteamID format mismatch — the operator added a SteamID3 when the plugin expected SteamID64, for example, or vice versa.

1. Ask the operator to share the exact Steam ID format they added to the list.
2. Verify the ID against your account.
3. If the ID does not match (typo, wrong format, wrong account), ask the operator to remove the incorrect entry and add the correct one.

This method resolves the case where the operator believes they have added the player but the player is still blocked.

Method 4: Request a fresh check after approval delay

Some servers cache connection rejections at the network layer for a short time. After being added to the whitelist, the player may see continued rejections for a few minutes until the cache expires.

1. After approval, wait five to ten minutes.
2. Retry the connection.
3. If the rejection persists beyond ten minutes, the issue is not cache-related; ask the operator to confirm the configuration.

The cache duration varies by server configuration. Most servers do not cache rejections at all; the few that do typically use very short cache windows.

Method 5: For operators: add a whitelist entry

The operator-side workflow for adding a whitelist entry varies by the mechanism in use. The most common variants are:

Mechanism	Add command or procedure
Vanilla whitelist (in-game console)	whitelist add <SteamID64>
Vanilla whitelist (file edit)	Append SteamID64 to whitelist file, reload
RocketMod plugin	Plugin-specific command (e.g., wladd <SteamID>)
OpenMod plugin	wl add <SteamID> or similar
Web panel	Add through the panel's whitelist UI

After adding, confirm the entry took effect by checking the file or running the plugin's list command (e.g., whitelist list for vanilla, plugin-specific for plugins).

For the broader context of server-side panel configuration, see Setting Up Your Server Panel.

Method 6: For operators: remove a whitelist entry

When a player should no longer be on the list (left the community, moderation action, etc.), remove the entry.

Mechanism	Remove command or procedure
Vanilla whitelist	whitelist remove <SteamID64>
Vanilla whitelist (file edit)	Delete the SteamID64 line, reload
RocketMod plugin	Plugin-specific remove command
OpenMod plugin	wl remove <SteamID>
Web panel	Remove through the panel's whitelist UI

Removing a player from the whitelist does not ban them; the next time they connect, the whitelist check will reject them, but no ban entry is created. If a ban is appropriate (because of a moderation action), use the ban command separately.

Method 7: For operators: convert vanilla whitelist to plugin-driven

Operators who outgrow the vanilla whitelist (typically because they want per-player permissions, vouching workflows, or integration with a Discord bot) commonly migrate to a plugin-driven whitelist.

1. Export the vanilla whitelist file (it is already a flat list of SteamID64s).
2. Install the chosen plugin (RocketMod or OpenMod-based).
3. Import the existing IDs into the plugin's whitelist file or database.
4. Disable the vanilla whitelist in server configuration.
5. Restart the server and verify the plugin's whitelist takes effect.

The migration should be tested with a non-staff test account before being deployed in production. Test by attempting to connect as a non-whitelisted account and confirming the kick.

Method 8: For operators: audit whitelist for stale entries

Whitelists accumulate stale entries over time. Players leave the community, accounts get sold, accounts go inactive. Periodically auditing the whitelist removes entries that no longer correspond to active community members.

1. Export the current whitelist.
2. Cross-reference against recent server activity (the server's connection log records who has joined in the past N days).
3. Identify entries that have not connected in a long window (six months, twelve months).
4. Confirm with the community before removing (some inactive members return).
5. Remove the confirmed stale entries.

The audit cadence depends on the community size; cohort observation suggests quarterly audits for active community servers.

Method comparison

Method	Time required	Who runs it	When to apply
1. Submit whitelist request	Minutes to days	Player	Whitelist kick observed
2. Verify post-approval	Minutes	Player	Still blocked after approval
3. Confirm SteamID format	Minutes	Player + operator	Mismatch suspected
4. Wait for cache	5-10 minutes	Player	Recent approval, slow take-effect
5. Add whitelist entry	1-2 minutes	Operator	Approved player needs addition
6. Remove whitelist entry	1-2 minutes	Operator	Player should no longer have access
7. Convert to plugin-driven	30-60 minutes	Operator	Outgrowing vanilla whitelist
8. Audit whitelist	30-90 minutes	Operator	Quarterly or as needed

Order of connection checks: detailed reference

The order in which the server applies connection checks determines which rejection message a player sees when multiple conditions could apply. The detailed order for a typical Unturned server (vanilla, no plugin overrides) is:

1. Network reachability — can the client reach the server's IP and port at all? Failure here produces "connection timeout" rather than any of the other messages.
2. Version check — is the client on the same version as the server? Failure produces "Different game version."
3. EAC handshake — does the client pass Easy Anti-Cheat? Failure produces "EAC error" or related strings.
4. Steam authentication — does Steam confirm the client's session is valid? Failure produces auth-related messages.
5. Ban check — is the account on the ban list? Failure produces "You are banned."
6. IP block check — is the IP on the IP block list? Failure produces "Connection refused" or similar.
7. Whitelist check — if whitelist is enforced, is the account on the list? Failure produces "Not on whitelist."
8. Password check — if the server is password-protected, is the password correct? Failure produces "Incorrect password."
9. Capacity check — is there a free slot? Failure produces "Server is full."
10. Region check — is the client in a permitted region (if region filtering is configured)? Failure produces region-specific messages.

A client that fails an earlier check never sees the later checks. A whitelisted account that is also banned will see the ban message (because the ban check runs before the whitelist check). A non-whitelisted account that supplies the wrong password will see the whitelist message (because the whitelist check runs before the password check).

Did you know?

The order of checks means that a player on a whitelist still needs to supply the correct password for a password-protected server, but a player not on the whitelist will be rejected before the password is checked. The remedies stack: each check has to pass independently for the connection to succeed.

Common kick messages and their causes

The table below documents the exact kick message strings the cohort has observed and the underlying cause for each. Use the table to map the on-screen message to the resolution path.

Kick message	Cause
"You are not on the whitelist"	Vanilla whitelist enforced, account not present
"Whitelist: access denied"	Plugin-driven whitelist, account not present
"You are banned from this server"	Ban list entry exists
You are banned: <reason>	Ban list entry with reason
Banned until <date>	Temporary ban active
"Incorrect password"	Password supplied does not match
"Server requires a password"	Server is password-protected, no password supplied
"Server is full"	All slots in use
"Different game version"	Client/server version mismatch
"EAC handshake failed"	Easy Anti-Cheat check failed
"Connection refused"	IP block or network rejection
"Disconnected from server"	Generic disconnect, cause not specified

Some plugins produce custom kick messages. The plugin author chooses the wording; operators may also configure custom messages. When the message does not match anything in the table above, ask the operator what the message means.

Advanced considerations

Whitelist plus password plus ban check

A server can apply all three filters simultaneously. The order of operations described above means that:

• A banned account is rejected by the ban check and never sees the whitelist or password prompts.
• A non-whitelisted account is rejected by the whitelist check and never sees the password prompt.
• A whitelisted account with the wrong password is rejected by the password check.
• A whitelisted account with the correct password and no ban is admitted.

For operators, this layering provides defence-in-depth: even if one filter is misconfigured, the others provide backup protection. The cohort recommendation is to use the layering deliberately, with each filter serving a specific purpose (ban for moderation, whitelist for community membership, password for casual gatekeeping).

Per-group whitelists

Some plugins implement per-group whitelists, where different player groups have access to different features within the server. The "whitelist" in this context is not a connect-time filter but a feature-access filter; players can connect but cannot use certain features. The kick message in this case may read You do not have permission to <action> rather than the connection-time whitelist message.

For operators, the choice between per-group whitelist and connect-time whitelist depends on the access model: connect-time whitelists are simpler and more visible, while per-group whitelists allow finer-grained access control.

Whitelist synchronisation with external systems

Larger communities sometimes synchronise the server's whitelist with an external system (Discord roles, forum membership, a custom CRM). The synchronisation runs periodically (every few minutes, hourly, daily) and updates the whitelist file to match the external source.

For players, the implication is that getting a Discord role does not necessarily grant immediate whitelist access; the sync needs to run first. The operator's documented process should describe the expected delay.

Whitelist size limits

Vanilla Unturned does not impose a hard limit on whitelist size, but very large whitelists (thousands of entries) can slow the server's connection check, especially on lower-end hosting hardware. Plugin-driven whitelists are typically more efficient because they use proper data structures (hash sets) rather than linear scans.

For operators with large whitelists, the cohort recommendation is to use a plugin-driven whitelist on appropriately sized hardware (see Recommended Server Hardware for hardware guidance).

Steam ID changes

Steam IDs do not change for the lifetime of the account. A player's SteamID64 is permanent; there is no scenario where the operator needs to update an existing entry because the player's ID changed. If a "new" ID is presented, it is a different account (possibly a friend's account, or an alt). Whitelisting the new ID is a separate decision from whitelisting the existing one.

For operators, this means whitelist entries do not require maintenance for ID drift; they only require maintenance when the operator chooses to add or remove access for specific accounts.

Whitelist and Family Sharing

A player using Steam Family Sharing borrows another account's library. The Steam ID presented to the server is the borrower's, not the lender's. A whitelisted account (the lender) who lends Unturned to a friend (the borrower) does not extend the whitelist to the borrower; the borrower's own ID must be whitelisted separately.

Many servers disallow Family Sharing entirely for whitelist-protected access; the operator's policy should document this.

Frequently asked questions

Why did Unturned kick me when I joined?

The most common kick reasons for whitelist-protected servers are: the server has a whitelist and your account is not on it; you are banned from the server; you supplied the wrong password; or the server is full. The exact reason is in the client log at %LOCALAPPDATA%\Unturned\Player.log. Read the last few lines of the log to identify the specific cause.

How do I get whitelisted on an Unturned server?

Find the server's Discord, forum, or website. Locate the whitelist request channel or form. Submit a request that includes your SteamID64, your Steam profile link, the exact kick message you received, and any other information the operator's documented process requires. Wait for the operator to confirm the addition. Retry the connection after the confirmation.

What's my Steam ID for whitelist?

The format servers typically need is SteamID64, a 17-digit number that starts with 7656119. Find your SteamID64 in Steam → Account Details, or on your Steam profile page (the numeric portion of the URL). If the operator requests a different format (SteamID2, SteamID3, vanity URL), use a Steam ID lookup tool to convert. Including multiple formats in the initial request avoids back-and-forth.

What does "not on the whitelist" mean in Unturned?

The server has an allow-list of approved Steam accounts (a whitelist), and your account is not on the list. The server has rejected your connection at the whitelist check stage. You can resolve this only by being added to the list, which only the server operator can do. Request access through the operator's documented channel.

Can I bypass a whitelist?

No. A whitelist is enforced at the server level, before the player has any visibility into the world. There is no client-side action that bypasses the server's whitelist check. Requesting access through the operator's documented process is the only resolution.

How long does whitelist approval take?

Approval time varies widely by server. Active community servers with dedicated staff often approve within minutes to a few hours. Larger servers with formal application processes may take days. Closed-whitelist servers may not be accepting new members at all. The operator's documented process should describe the expected timeline; if it does not, ask in the request channel.

Why am I still kicked after the operator added me?

A few possible reasons: the operator added the wrong Steam ID format (entered SteamID3 when the plugin expected SteamID64, for example); the server's whitelist plugin requires a reload after additions; the operator added a different account by mistake; or a different filter (ban, password, capacity) is now rejecting you. Ask the operator to verify the exact ID they added and whether a reload is needed.

Is a whitelist block the same as a ban?

No. A whitelist block means your account is not on the allow-list; you have not been banned. A ban means the operator has actively added your account to the deny-list, typically as a moderation action. The remedies are different: whitelist blocks are resolved by requesting addition to the allow-list, while bans are resolved through the operator's appeal process. The kick messages are also different (whitelist kicks say "not on whitelist" or similar; ban kicks say "banned" or similar).

Can I see who is on the whitelist?

No, not from the player side. The whitelist is server-side configuration that is not exposed to players. The operator can see the full whitelist on their side, but players cannot query it.

Do I need to be friends with the operator to be whitelisted?

No, but the operator's documented process may require it for some communities. Some servers require existing community members to vouch for new members; in those cases, you need at least one existing member to support your application. The operator's whitelist policy describes the requirements.

What if the operator never responds?

If the operator does not respond within the documented timeline, the server is likely not actively maintained for new member additions. Options include: trying a different server, asking in the community's public channels (some communities have member-driven vouching processes that bypass operator response), or accepting that the server is effectively closed to new members.

Why is the whitelist check done before the password check?

The order is by operator preference, but it reflects the typical use case: whitelists are stronger filters than passwords (whitelists name specific accounts, while passwords are shared secrets that can leak). Rejecting non-whitelisted accounts before they have a chance to attempt a password reduces the load on the password check and gives the player a clearer error message. Some plugin configurations invert the order; the server's configuration determines the actual order.

Can I use the same whitelist on multiple servers?

For operators, yes: the whitelist is a file or database that can be copied between servers. For players, this means an operator running multiple servers can grant access to all of them in a single addition (where the operator has configured cross-server sync) or may need to add the player to each server separately (where the configurations are independent).

Will my whitelist status carry over if the server changes plugins?

Not automatically. When an operator migrates from one whitelist plugin to another, the existing whitelist must be exported and imported into the new plugin's format. A poorly managed migration may lose entries; players who were on the previous list should confirm their status after a migration. Ask the operator to confirm the migration was complete and that your ID was preserved.

Appendix A: SteamID format reference

The four common Steam ID formats and their conversions are documented below. Use this reference to convert between formats when the server operator requests a specific one.

SteamID64

The 17-digit numeric ID Steam uses internally. Always starts with 7656119 for Steam accounts.

Example: 76561198000000000

SteamID2

The legacy format. Looks like STEAM_X:Y:Z where X is the universe (typically 0 or 1), Y is the lower bit, Z is the account number divided by 2.

Example: STEAM_0:0:20000000

SteamID3

The modern bracketed format. Looks like [U:1:Z] where Z is the account number.

Example: [U:1:40000000]

Vanity URL

The custom URL portion of a Steam community profile. Looks like a human-readable username.

Example: gabelogannewell (the URL steamcommunity.com/id/gabelogannewell)

Conversion approach

Online Steam ID converters take any one of the four formats and produce the other three. The cohort recommendation for whitelist requests is to provide the SteamID64 (the format most servers use) along with the Steam profile link (which works regardless of which ID format the operator's tool expects). For operators who specifically request a legacy format, the converter produces it from the SteamID64 in a single step.

Pro tip

When requesting whitelist access, paste your SteamID64 and your full Steam profile URL into the request. The two together unambiguously identify your account in any format the operator's tool uses. Operators appreciate the redundancy; the small additional effort on the player's side saves significant operator time.

Appendix B: operator workflow reference

The operator-side workflow for managing a whitelist is documented below. The workflow varies by mechanism (vanilla, RocketMod, OpenMod), but the high-level steps are consistent across mechanisms.

Initial whitelist setup

1. Decide the whitelist mechanism (vanilla, RocketMod plugin, OpenMod plugin, web panel).
2. Install the chosen mechanism per its documentation.
3. Enable the whitelist enforcement in server configuration.
4. Add the operator's own SteamID64 as the first entry (avoids locking the operator out).
5. Add initial trusted members.
6. Test by attempting to connect from a non-whitelisted account and confirming the kick.

Routine whitelist management

Action	Frequency	Workflow
Add new approved member	As requests come in	Run add command, confirm with player
Remove inactive member	Quarterly audit	Confirm with community, run remove command
Remove banned member	After moderation action	Run remove command followed by ban command
Audit for typos	Quarterly	Compare whitelist against active player log
Backup whitelist	After every change	Copy whitelist file to backup location

The cohort recommendation is to back up the whitelist file every time it changes. A backup is the only reliable rollback if a mass-edit operation goes wrong.

Whitelist plugin selection

Plugin family	Best for	Notes
Vanilla (stock)	Small communities, simple needs	No additional dependencies
RocketMod (legacy)	Servers already on RocketMod	RocketMod is in legacy maintenance
OpenMod (current)	New servers, plugin ecosystem	Active development
Web panel	Operators preferring a GUI	Depends on the panel's plugin

The cohort recommendation for new servers is OpenMod, since RocketMod is in legacy maintenance and the plugin ecosystem is migrating to OpenMod. Existing RocketMod servers can continue to run their existing whitelist setup until the operator chooses to migrate.

For broader server-side guidance, see Recommended Server Hardware and Setting Up Your Server Panel.

Appendix C: kick message wording catalogue

The cohort has catalogued the exact wording of whitelist-related kick messages across the most common server configurations. The catalogue below is useful for players trying to identify whether they have hit a whitelist block versus another rejection.

Vanilla Unturned

Message	Trigger
"You are not on the whitelist"	Account not in whitelist file
"Server is whitelisted"	Connection attempt to whitelisted server (older clients)
"Banned"	Account on ban list

RocketMod plugins

Plugin	Typical message
EasyWhitelist	"You are not whitelisted on this server"
RocketWhitelist	"Whitelist: access denied"
Custom RocketMod plugins	Plugin-defined string

OpenMod plugins

Plugin	Typical message
OpenMod.Core.Whitelist	"You are not authorized to connect"
Community OpenMod plugins	Plugin-defined string

The catalogue is not exhaustive; operators commonly customise the messages. The general pattern is that the message contains the word "whitelist," "authorized," or "permission" when the whitelist is the cause.

Did you know?

Some operators configure intentionally vague kick messages to avoid revealing that a whitelist is in use. The cohort observation is that this practice is uncommon; most operators prefer clear messages because they reduce the support burden (players who know they hit a whitelist can request access through the right channel without contacting the operator first).

Best practices

For players:

• Read the Unturned client log before assuming a connection failure is a whitelist block.
• Use SteamID64 as the default format in whitelist requests; include a Steam profile link as a fallback.
• Submit requests through the operator's documented channel, not through DMs to the owner.
• Include the exact kick message in the request to help the operator confirm the issue.
• Be patient; approval times vary by community.

For operators:

• Choose a whitelist mechanism that matches the community size (vanilla for small, plugin-driven for larger).
• Back up the whitelist file every time it changes.
• Use clear kick messages that indicate the cause; vague messages produce more support load, not less.
• Audit the whitelist quarterly for stale entries.
• Document the whitelist request process publicly (Discord channel, website page).
• Add your own SteamID64 as the first entry to avoid locking yourself out.
• For broader operator workflows, see Setting Up Your Server Panel.

Cross-references

• Cannot Join Friends Server — the previous article in the troubleshooting section, covering friend-specific connection failures.
• Server Lag and Latency Troubleshooting — the next article, covering performance issues after a successful connection.
• Unable to Connect to the Server — covers the generic "unable to connect" error, including the diagnostic flow that identifies a whitelist block as one possible cause.
• Server Not Showing in Server Browser — covers browser-visibility issues; relevant when a whitelisted server is also not appearing in the browser.
• Server Connection Timeout — covers the timeout class of connection failures, distinct from whitelist blocks.
• Recommended Server Hardware — for operators; the hardware practices that affect whitelist plugin performance.
• Setting Up Your Server Panel — for operators; the panel configuration that exposes whitelist management.

Smartly Dressed Games publishes additional reference at the official modding documentation for operators implementing custom whitelist plugins.

Document history

Version	Date	Notes
1.0	2024-04-18	Initial publication. Vanilla whitelist coverage.
1.1	2024-07-22	Added RocketMod and OpenMod plugin sections.
1.2	2024-10-15	Added SteamID format appendix and conversion reference.
2.0	2025-03-11	Major revision. Added order-of-checks reference and kick message catalogue.
2.1	2026-05-18	Refresh. Expanded operator workflow appendix and best practices.

Glossary

• Whitelist — an allow-list of Steam accounts permitted to connect to a server.
• Ban list — a deny-list of Steam accounts blocked from connecting.
• IP block — a deny-list of network addresses blocked from connecting.
• SteamID64 — the 17-digit numeric Steam account identifier.
• SteamID2 — the legacy Steam account identifier format (STEAM_X:Y:Z).
• SteamID3 — the modern bracketed Steam account identifier format ([U:1:Z]).
• Vanity URL — the human-readable portion of a Steam community profile URL.
• RocketMod — a legacy plugin framework for Unturned servers.
• OpenMod — the current plugin framework for Unturned servers.
• Vouching — a community practice where existing members support new member applications.

Closing note

Whitelist-related connection issues are among the easier classes of Unturned multiplayer failures to diagnose and resolve, once both the player and the operator understand the workflow. The player's role is to identify the whitelist block (via the client log), gather their Steam ID in the correct format, and submit a well-formed request through the documented channel. The operator's role is to maintain a clear request process, respond to requests in a reasonable timeframe, and use the appropriate whitelist mechanism for the community's size.

The largest single source of friction in whitelist workflows is communication: vague kick messages, undocumented request channels, mismatched SteamID formats, and missing confirmations. The cohort recommendation is to standardise on clear messages, documented channels, SteamID64 as the default format, and explicit operator confirmations. With those standards in place, whitelist additions take minutes from request to retry, and both players and operators can spend their time on game-related work rather than connection troubleshooting.

Appendix D: communication templates

The cohort has assembled communication templates that produce consistent, low-friction whitelist requests and operator responses. The templates are starting points; customise them for the specific server's process and the specific situation.

Player template: initial whitelist request

Subject: Whitelist request

SteamID64: 76561198XXXXXXXXX
Steam profile: https://steamcommunity.com/profiles/76561198XXXXXXXXX
In-game username: <your-username>
Server you want to join: <server-name>

Kick message I received:
"<paste the exact kick message from the client log here>"

Brief background on why I want to join:
<one or two sentences>

Thanks for your time.

Operator template: approval confirmation

You have been added to the whitelist. SteamID64 <id> was added at <timestamp>.
The change is live; you should be able to connect now. If the connection
still fails, please share the new kick message so we can confirm whether a
plugin reload is needed.

Operator template: denial with reason

Your whitelist request was not approved. The reason is:
<specific reason>

If the reason can be addressed, you are welcome to reapply once the
underlying issue is resolved. The application channel is open for follow-up
questions.

The templates produce clear, complete communication that reduces back-and-forth. Both players and operators benefit from the consistency.

Next steps

If the connection succeeds but the in-game experience is laggy or unresponsive, continue to Server Lag and Latency Troubleshooting. If the connection issue turns out not to be whitelist-related, return to Unable to Connect to the Server for the broader diagnostic flow. For the full list of troubleshooting articles, see the Troubleshooting section overview. For server operators implementing whitelists, see Setting Up Your Server Panel for panel-side configuration and Recommended Server Hardware for the hardware considerations that affect whitelist plugin performance.