The short answer
Wait. A new Rust server spends up to ten minutes generating its map and NAV mesh before it will accept connections, and the process starts again from scratch every time the server is restarted. Watch the RCON console if you want to see progress rather than guess at it.
Key points
- The server looks online because the process is running. It is just not ready.
- Generation takes up to 10 minutes, longer on a big world size.
- Restarting to fix it is the one thing guaranteed to extend the wait.
- Changing the seed or the world size triggers the same process again.
- RCON shows you the stage, so you do not have to sit and hope.
What the server is doing
Starting a new Rust server is an exciting moment, and it is frustrating when the thing you just paid for will not let you in. The good news is that this is a wait rather than a fault.
On its first start, the server has to build two things before anyone can play on it:
- The map
- The terrain itself, generated from your seed and world size. Nothing exists until this finishes.
- The NAV mesh
- The pathfinding layer that animals and NPCs use to move around the terrain. It cannot be built until the terrain is there, so it runs afterwards, not alongside.
Together these can take up to 10 minutes, depending on the server's configuration and how large a world you asked for. The server process is up throughout, which is exactly why it looks like something is wrong. It is online. It is simply not finished.
Do not restart it. Restarting abandons the work in progress and begins generation again from the beginning. Almost every report of a server that "never finishes generating" turns out to be a server that has been restarted two or three times by someone trying to help it along.
What triggers a regeneration
The first boot is the obvious one, but it is not the only time you will meet this wait. Any change that invalidates the existing world forces a rebuild.
- The first start of a brand new server.
- Changing the server seed. A different seed is a different world.
- Changing the world size. Same reason, and larger sizes take longer to build.
- A wipe that clears the map. The terrain has to come back before anyone can land on it.
This is worth planning around if you run a server people expect to be available. Frequent map changes mean frequent downtime, and if you intend to keep the server consistently online, the time to experiment with seeds is before you tell anyone about it, not on a Friday evening.
Watching the progress
You do not have to sit and refresh hopefully. Both of these show you what stage the server is actually at:
- The built-in RCON console in your control panel. Nothing to install, and enough to tell generation from a genuine problem.
- An external RCON client for better visibility and management. We recommend RustAdmin or BattleMetrics.
Our Rust server admin tools guide compares those and the other options in more detail, including which ones are free.
How we keep it from slowing everyone down
Map generation is a heavy, largely single-threaded workload that can hold a CPU core at close to full utilisation for the whole run. On a shared machine that is a problem for everyone else, not just for the server doing the work.
Our platform handles it by detecting when a new seed or world size has been set and binding that server to a dedicated CPU core for the duration of the generation. The heavy work is isolated rather than allowed to spill across the machine.
The result is that a neighbour generating a 6,000 world size map does not produce lag spikes on your server, and yours does not produce them on theirs. It does not make generation faster, it stops it being everyone else's problem.
When it is not map generation
If you have genuinely left it alone for 15 minutes and still cannot get in, it is reasonable to start looking elsewhere.
- Version mismatch
- After a Rust update the client and server have to be on the same version. If the server has not updated, no method of connecting will work.
- Wrong address
- Check the connection info on your control panel rather than the address you wrote down earlier, particularly if the server has been rebuilt.
- Restarted mid-generation
- Check the RCON output. If it is at an early stage again, something restarted it and the clock reset.
- A config error stopping startup
- The console output will normally say so. A malformed line in
server.cfgcan halt a boot in a way that looks a lot like a long wait.
If you have worked through all of that, open a ticket with the RCON output attached. The console text is what turns a support conversation from guesswork into a fix.