Rust Server Ban/Unban Player: A Fair, Reviewable Process

When you need a Rust server ban or unban, first identify which system owns the sanction. A local server list, a shared ban service, a plugin and an EAC or Facepunch action do not share one switch. This guide gives PC Rust community admins a fair, reviewable way to choose the right scope, confirm the Steam64ID, record the reason, and reverse the intended local decision later. It also covers a common surprise: a centralized ban stops a future join, but does not automatically disconnect someone already playing.

Choose the list that will enforce the sanction#

Before entering a command, identify where the player is restricted. Rust can have multiple moderation layers, and removing one entry does not clear records owned by another system.

Facepunch documents ban and banid as server commands and provides a separate centralized-banning API for servers that configure one. A plugin can maintain its own list as well. Start with the message or console record that identifies the denying layer; don’t issue the same ban everywhere just because the first unban didn’t work.

Keep the boundary clear when you reply to an appeal. If your community server added the local ban, you can review that decision. A community operator cannot promise to remove an EAC or Facepunch sanction made elsewhere. If the affected person reports a game or anti-cheat action, direct them to the authority named in that message.

Verify the Steam64ID and write down the decision#

Check the stable Steam64ID against a trusted server record before using a player name. Names can change or collide; a wrong digit can sanction the wrong account. For an offline player, corroborate the identifier from the original report or another reliable source instead of guessing from a nickname.

Keep a short case record in a private, access-controlled location. Include the evidence location rather than copying sensitive personal information into a public ban reason.

Case reference:
Observed time and timezone:
Player Steam64ID:
Community rule and version:
Evidence location and relevant timestamps:
Decision, scope, reason, and duration:
Operator and reviewer:
Appeal route and review date:

Use the same rule language that players can read. Record what happened, what evidence supports it, and why the action fits your policy. If the moderator is part of the dispute, ask another authorized person to review it. The Rust server administration handbook has a broader staff and evidence-custody register if your team needs one.

Apply a native ban to the intended server#

Facepunch’s command reference documents ban, banid, bans, banlistex and unban. It describes banid as Steam64ID-based and says the player does not have to be connected. The wiki labels its command list a work in progress, so confirm the current syntax in the target server’s console or your actual panel before using it.

1. Confirm the target server and identifier

   Check the server identity and compare the Steam64ID with your case record. If your console exposes more than one instance, confirm which Rust PC server will receive the command.

2. Choose the documented local command

   For an offline player, the Facepunch reference shows this shape:

   banid <Steam64ID> <name> <reason> <duration>

   Use the current console’s command help for quoting and duration syntax. Do not copy a sample duration or reason that does not match your rule and decision.

3. Inspect the resulting ban record

   Use the documented ban-list command supported by your build, such as banlistex or bans, then compare the Steam64ID, reason and intended scope with the case record. Save the command response or a restricted screenshot without exposing unrelated player information.

The native command is a server-local action. It is not an EAC appeal, a global Steam restriction or proof that every plugin list has been updated. If the record doesn’t match the person or server you intended, stop and resolve the mismatch before acting on another list.

Disconnect an online player only when needed#

A ban and a kick answer different questions. The ban controls whether an account can rejoin under that list; a kick ends a current session. Facepunch’s command reference says a kicked player can join again immediately, so a kick by itself is not a ban.

For the centralized API specifically, Facepunch states that adding an entry prevents the player from entering later but does not kick a player already on the server. If immediate removal is required, use the server’s documented kick command on the server where the player is connected, with the same verified Steam64ID. Preserve the reason and decision in the case record.

For a local or plugin ban, check what your current implementation does to a connected player rather than assuming it behaves exactly like centralized banning. If the player remains online and your policy requires immediate removal, use the authorized removal control documented for that layer. Confirm the observed session state; don’t describe a successful ban-list change as a completed disconnect.

Check centralized bans without confusing API errors for a decision#

Use centralized banning only if your group intentionally runs an external list and its endpoint is configured on the Rust server. Facepunch documents a lookup by Steam64ID: the API returns the ban record, while HTTP 404 means that the requested ID is not banned. A valid success response must follow the documented JSON format. Other error responses use the server’s configured failure mode.

The server.bansServerFailureMode setting determines what happens when a player could not be checked: value 0 allows that join and logs the error; value 1 rejects it and logs the error. Neither result is the same as a reviewed ban decision. If players are unexpectedly denied or allowed during an endpoint outage, inspect the server log and API health before changing individual sanctions.

The Rust wiki says the default centralized request timeout is five seconds and can be changed with server.bansServerTimeout. A longer timeout also makes affected joins wait longer. Measure your own endpoint before changing it; the published default is not a promise that a particular API will answer within that time.

Remove only the sanction you reviewed#

For a native server ban, Facepunch documents unban with a Steam64ID. Confirm the ID and the target server before running it, then inspect the local ban list again. If the player is still denied, identify which other layer returned the denial instead of repeatedly issuing unban against the native list.

For centralized banning, change the record in the system that supplies the endpoint response. Confirm that the API now returns the documented not-banned response for that ID. For a plugin list, follow that plugin’s current removal instructions and inspect its resulting record. Neither action reverses a separate Facepunch or EAC sanction.

After a review or appeal, append what changed to the case record: who reviewed it, which sanction was removed, why, and whether a new join was allowed by the relevant layer. Keep the original decision intact so another moderator can understand both versions later.

Keep the appeal separate from platform enforcement#

Your ban reason should name the community rule and a concise explanation that helps the player understand the server decision. Keep detailed evidence private and offer an appeal route that reaches someone other than the original decision-maker when practical. A fair review can correct mistaken identity, an unclear rule or new evidence without pretending that a community server controls every Rust account restriction.

When you handle a report, distinguish a local community-server sanction from an EAC connection message, a Facepunch account sanction or an external shared-list response. Record the exact message and source. If the issue comes from another authority, don’t promise that a local unban will fix it; point the player to the appeal path named by that authority.

For the next moderation decision, verify the account, rule, scope and reason before acting; then check the same list that made the decision. That keeps a Rust server ban and unban reviewable without implying that a community moderator controls sanctions outside the server.