Rust Server Troubleshooting: Common Issues and Fixes

These are the issues I see hit Rust owners most often. I'll walk through each one with what actually fixes it, in roughly the order I'd try things myself. Most of this you can diagnose without opening a ticket – the panel gives you everything you need if you know where to look.

Before you start: your panel lives at https://control.low.ms. Every tool I mention below is in the left-hand sidebar of your server page.

The server won't start

Nine times out of ten this is one of four things: a broken save, a half-finished Steam update, a bad convar, or you've run out of memory.

First stop is always Log Viewer. Scroll to the bottom and read the last thirty or forty lines – Rust is usually pretty loud about what broke. If you see save-related errors, skip to the restore step below. If you see Steam or update errors, run Steam Update from the sidebar and let it finish cleanly before trying again. Forced wipe day in particular likes to leave servers in a half-updated state.

If the logs point at a corrupted save, open File Manager and browse to server/<identity>/ – that's where .sav files live. Don't start deleting things yet. Instead, go to Cloud Restore (or Backup Manager if you want to pick a specific snapshot) and roll back to the last known-good backup. I'd rather lose an hour of progress than spend an afternoon hand-editing save files.

Bad convar edits are the other silent killer. If you were messing with server.cfg right before it broke, open Configuration Files, revert your last change, and try again. And if you're genuinely out of memory, the log will tell you – the fix there is either fewer plugins, a smaller map, or a bigger plan. For deep-dive crash hunting I've got a whole separate article: Rust Server Crashes on Startup or Randomly.

EAC is kicking everyone

Easy Anti-Cheat problems almost always fall into two buckets: the player's client is out of whack, or your server has server.secure set to false.

Check your end first. Open Configuration Files, confirm server.secure true is set, and restart. That one line enables EAC – without it, clients get kicked the moment they try to join a secure server.

If that's fine, it's a client issue. Have the affected player verify their Rust files through Steam (right-click Rust, Properties, Installed Files, Verify), then restart Steam entirely. That fixes the vast majority of authentication timeouts and "EAC disconnected" style kicks. If they're getting an actual EAC ban message, there's nothing you can do from the server side – EAC bans are global and enforced by Facepunch and Epic, not you.

For players whose client crashes on join rather than gets kicked, send them to Rust Crash or Crashing When Joining a Server.

Memory keeps climbing

Rust memory usage climbs naturally as a wipe ages. Every base, every deployable, every dropped item sits in memory until it despawns or decays. A vanilla server early in a wipe will sit comfortably; the same server three weeks in, with a full map of mega-bases, will use roughly double. Modded servers push it higher again because plugins cache their own data on top.

Things that actually help:

• Scheduled restarts. This is the single biggest win. Set up a daily restart in Scheduled Tasks – I like 6am local time. Clears leaked memory, reloads plugins cleanly, nobody's online to care.
• Let decay do its job. decay.scale defaults to 1.0. Bumping it to 2.0 or 3.0 makes abandoned bases crumble faster, which reclaims entities and memory. Don't go crazy – your players will notice.
• Audit your plugins. If memory spikes started the day you installed a plugin, that's your suspect. Disable it, watch for a cycle, confirm.
• Wipe. Forced wipes on the first Thursday of the month reset everything anyway. If you're bleeding memory with a week to go, a BP-only wipe is sometimes the right call.

If you're consistently pinned at your memory ceiling, the plan is simply too small for what you're running – have a look at /game-servers/rust-server-hosting for upgrade options.

Lag and tick drops

Server-side lag (rubber-banding, delayed hits, sluggish looting) is almost always CPU, not network. The usual culprits:

World size. A 4500 map is very different from a 3000 map. If you've only got 20 players rattling around a huge procedural map, shrink it – you'll feel the difference immediately. My recommended sizes per population live in the Rust Server Settings Guide.

Entity count from aged wipes. The longer a wipe runs, the more stuff is on the map for the server to simulate. Pair higher decay.scale with regular restarts and you'll claw most of it back.

A badly-written plugin. One plugin looping every tick over every player or entity can tank your tickrate on its own. oxide/logs/ will usually show warnings about slow hooks – read them. Disable suspects one at a time.

Network routing. If only players in one region feel lag, it's their route to the datacenter, not your server. Ask them to run a traceroute and compare.

Set a restart in Scheduled Tasks regardless – it papers over a lot of slow-drift issues.

Players can't connect

Rust uses three ports and people mix them up constantly:

• 28015 UDP – game port, what players connect on
• 28016 UDP – query port, what Steam and the server browser hit (always game port + 1)
• 28017 TCP – RCON, for admin tools

If your server is running but nobody can join, it's usually the query port. If the query port isn't reachable externally, your server won't appear in the browser and direct connects via the console can behave oddly. At LOW.MS we open these automatically, so it's rare – but if you've changed the game port in Configuration Files, make sure the query port followed it. Double-check what the panel says the ports are versus what you've given your players.

Full walkthrough of connecting (server list, F1 console, Steam favourites): How to Connect to a Rust Server via IP.

World file mismatch

This one is purely a wipe-day or post-update problem. A player tries to join, gets dropped with a "Disconnected: World File Mismatch" or "World cache version mismatch" message, and the cause is almost always that the client and the server are looking at different versions of the same map file.

The most common trigger is Facepunch shipping a procedural-map regeneration as part of a monthly update – the server regenerates the map, the client has the old one cached, the hashes don't line up. Custom map servers see it more often, especially when the .map file is updated mid-wipe or the source URL is wrong.

What I'd do as the admin:

1. Confirm the server actually finished its Steam Update cleanly. A half-updated server post-wipe is the single most common cause.
2. Open File Manager and browse to server/<identity>/. If you see stale .map and .sav files for an old map version, the cleanest fix is to stop the server, delete those files, and let the server regenerate on next boot. Change server.seed first if you want a different layout.
3. If you're running a custom RustEdit map and pulling it from Dropbox, double-check the URL ends with dl=1, not dl=0. That single character is the difference between Dropbox serving the file and serving an HTML page.
4. Renaming the map (changing the .map filename and the server reference to it) forces clients to fetch the new copy rather than use a cached old one. Useful when nothing else has worked.

What players should do on their end (give them this if they ask): clear their local Rust cache by verifying game files through Steam (right-click Rust, Properties, Installed Files, Verify), then restart Steam. That's enough to clear the cached old map for most people.

If you've just wiped and only some players are seeing the error, it's a client-cache issue. If everyone is seeing it, it's the server.

Oxide broke after a Rust update

This one catches people every single month. Facepunch overwrites Oxide files every time the server is updated. After the forced wipe (or any forced client patch), you have to reinstall Oxide or your plugins will refuse to load and your server may not even start. There is no way around this – it's just how Rust's patching works.

The fix is to grab the latest Oxide build from umod.org the moment it's released and reinstall over the top. Carbon (carbonmod.gg) is a drop-in Oxide-compatible alternative some owners prefer for performance – same idea, same workflow.

For plugin config and permission problems day-to-day, it's worth knowing these commands: oxide.grant <user/group> <perm>, oxide.revoke <user/group> <perm>, and oxide.show perms to list everything registered. Plugin errors get logged to oxide/logs/ – read there first before anything else. My shortlist of plugins worth running is in Top Rust Oxide Plugins.

RPC Error: doplace (and friends)

Players getting kicked with Disconnected: RPC Error in DoPlace (or DoUpdate, OnRespawnInformation, OnProjectileAttack) almost always means a plugin is out of date relative to the current Rust build. RPC errors are Rust's way of saying the client and the server disagree about a function call – and on modded servers, the disagreement is nearly always a plugin reaching for an API that Facepunch changed in the latest patch.

The diagnostic loop:

1. Check oxide/logs/ (or the Carbon equivalent) for the timestamp of the disconnect. There's usually a stack trace pointing at a specific plugin.
2. If the trace doesn't make it obvious, the historical pattern is that build- and place-related plugins (BGrade, Magic Hammer, anything that messes with placement RPCs) are the most common culprits. They hook into exactly the call paths that throw DoPlace errors when the API drifts.
3. Disable the suspect plugin and have a player retry. If the error goes away, you've found it. If not, work through the plugin list one at a time.

The fix isn't to write a workaround – it's to update. Either grab the current build of the affected plugin (most uMod authors push updates within a day or two of force wipe), or remove it for the wipe and reinstall when the author catches up.

If you can't tell which plugin is broken and you need the server back online for players, the nuclear option is to disable the entire oxide/plugins/ folder by renaming it (so Oxide loads with no plugins), bring the server up, and re-enable plugins in batches until the error returns. Nobody enjoys this, but it gets you back up and isolates the problem cleanly.

This whole class of error is why I never let a player rage-quit one of my servers without first asking which plugin they think it is. It's almost always plugins.

Not showing in the server browser

The Rust server browser is picky. For a server to appear in the Community tab you need a hostname, a description, and the right tags. Set these in Configuration Files:

• server.hostname "Your Server Name" – empty hostname = invisible
• server.description "..." – shows up in the browser panel
• server.tags "monthly,vanilla,eu" – drives which filter categories you appear under

If you're running Oxide or Carbon, the "modded" tag is appended automatically and your server will land in the Modded tab instead. Perfectly normal. And remember the query port has to be reachable externally – if Steam can't hit it, you don't exist as far as the browser is concerned. Give it five to ten minutes after startup to register.

Still stuck?

If none of that has sorted it, open a ticket with your server name, the error, and what you changed most recently – that's the fastest path to a fix. Otherwise, the deeper reads worth knowing about are Getting Started with Your Rust Server, the Rust Server Settings Guide, and Best Rust Server Settings (Community). Not hosting with us yet? /game-servers/rust-server-hosting.