Rust Nexus System: Every Convar in the Shipped Server
Nexus is not a roadmap sketch. It is code inside the Rust dedicated server that operators are running today. Twenty one nexus.* convars, most carrying a help description the build stores itself, plus ferries, docks with a departure schedule, islands, a zone controller, a remote-call protocol, a replayable message journal and a cluster-wide clan backend. All of it was read out of the shipped Rust dedicated server binaries, and all of it is listed below.
An earlier version of this page said the opposite: that Nexus was unreleased and should not be configured. How that went wrong is worth a sentence. The prefix server.nexus.* genuinely is fake, along with the invented token and port flags that come with it. Somebody spotted the fake prefix, concluded the feature did not exist, and deleted the truth with the fiction. The real prefix is nexus.*, with no server. in front.
The one thing this page cannot tell you. The mechanism is real and every name below is exact. What the build does not reveal is how an operator provisions a Nexus endpoint and a secret key. There is no valid example value for nexus.uri or nexus.secretkey anywhere in the binaries, nothing identifying what software answers nexus.zonecontroller, and nothing saying whether Nexus is open to any server owner or reserved for partners. That is the question to put to Facepunch. Everything else here you can verify yourself.
How we know
The convar names, the descriptions the server stores for them, the class names and the exact console strings below were read from the managed assemblies that ship inside the Rust dedicated server build, not from any public Facepunch server documentation. The build we read reported Steam build id 25230300, dated 11 September 2026, and contained 409 distinct Nexus strings.
That cuts both ways. It is verifiable, because those names sit in files you already downloaded with the server. It is also unofficial: Facepunch has not published a server administration reference for Nexus.
What Nexus actually is
Nexus is a cluster of Rust servers presented to players as one world. Each server is a zone, and each zone holds an island in a shared layout. Players and entities move between zones, ferries run between docks on a schedule, and clans span the whole cluster. The pieces, by the names the build uses:
- Zones. Each server knows its own zone name (
nexus.zone) and the zones in the cluster (nexus.zones). - Islands. The class is
NexusIsland. The layout is not fixed at boot:nexus.refreshislandsforces a refresh. - A zone controller. Named by
nexus.zonecontroller. It assigns islands to zones and chooses which zone a player spawns into. - Transfers.
NexusServer.TransferEntitymoves an entity,nexus.transfermoves a named player, andNexusTransferTriggeris the in-world trigger that starts one. - Ferries and docks.
NexusFerry,NexusDockandNexusDockTerminal, the terminal carrying schedule entries. - A nexus server inside the game server.
Bootstrap.StartNexusServerbrings upNexusServer, which maintains the socket, the remote calls and the map image upload. - Clans.
NexusClanWrapperover aNexusClanBackend, with roles, ranks, invites, notes and a leaderboard. - Authentication. A server auth path (
Auth_Nexus) and a companion-app handler (CompanionServer.Handlers.NexusAuth).
The two convars that gate everything
Before any of the rest matters: a Rust server joins a cluster only if nexus.uri and nexus.secretkey are both set. If either is empty the server prints one line and carries on as an ordinary standalone server:
That is the most useful string here. If you see it, nothing else you configured has taken effect, and setting only one of the pair is the same as setting neither.
The zone controller is the next requirement. The message spells the convar with a capital C while the convar itself is lowercase, which matters when grepping a log:
We are deliberately not printing an example value for nexus.uri or nexus.secretkey. The binaries prove both exist and that they are required together; they do not show what a valid endpoint looks like or how a key is issued. A guessed example would be worse than none.
Every nexus convar in the build
Twenty one convars, grouped by what they touch. Stored help descriptions are quoted as written. Where the build stores none we say so rather than guess, because a name is not a specification.
Connection and identity
| Convar | What the build says |
|---|---|
nexus.uri | "URL endpoint to use for the Nexus API". Required together with the secret key. |
nexus.secretkey | The shared secret for that endpoint. Required together with the uri; without both there is no connection. |
nexus.zone | This server's zone name inside the cluster. |
nexus.id | Present as a convar. The build stores no description for it. |
nexus.zones | The zones known to the cluster. |
nexus.zonecontroller | The zone controller. If unset, the server logs "Zone controller was not specified (nexus.zoneController convar)". |
Transfers
| Convar | What the build says |
|---|---|
nexus.transfer | Usage: nexus.transfer <target_zone>. "Initiates a Nexus transfer of the specified player to a named destination server or zone in the cluster". |
nexus.transferflushtime | "Maximum amount of time in seconds that transfers should be cached before auto-saving". |
nexus.protectionduration | Present as a convar. No stored description, so do not assume what it protects or for how long. |
Map image
| Convar | What the build says |
|---|---|
nexus.uploadmap | "Reupload the map image to the nexus. Normally happens automatically at server boot. WARNING: This will lag the server!" |
nexus.mapimagescale | "Scale of the map to render and upload to the nexus". |
Tuning
| Convar | What the build says |
|---|---|
nexus.rpctimeoutmultiplier | "Multiplier for nexus RPC timeout durations in case we expect different latencies". |
nexus.messagelockduration | "Time in seconds to allow the server to process nexus messages before re-sending (requires restart)". |
nexus.pinginterval | Present as a convar. No stored description. |
nexus.playermanifestinterval | Present as a convar. No stored description. The protocol carries a player manifest request. |
nexus.timeoffset | "Time offset in hours from the nexus clock". The cluster therefore keeps its own clock. |
Diagnostics
| Convar | What the build says |
|---|---|
nexus.ping | Usage: nexus.ping <target_zone>. Reach for this first when zones are not talking. |
nexus.playeronline | Usage: nexus.playeronline <steamID64>. Asks about a player by Steam id, cluster-wide. |
nexus.refreshislands | "Forces a refresh of the Nexus island layout, re-querying the zone controller for current island assignments". |
nexus.logging | Present as a convar. No stored description. |
nexus.redirect | Present as a convar. No stored description. |
Ferries, docks and the schedule
Ferries are not decoration and not something you place. Two rules are enforced in code, each with its own console line, and between them they cover almost every way an admin gets ferries wrong. A ferry on a server not connected to a cluster deletes itself:
And a ferry an admin tried to spawn by hand deletes itself too, with the reason spelled out:
If you have been testing ferries on a single server with a spawn command, those two lines are why nothing stayed in the world.
The departure side is NexusDock and NexusDockTerminal, and the terminal carries schedule entries in its serialised form. That is the interesting detail: ferry movement is timetabled, so a dock terminal is what a player reads to find out when the next crossing leaves. The transfer itself goes through NexusFerry.TransferToNextZone. Docks are protected from deletion, and trying anyway prints:
That is a guard rail, not a bug: a dock removed by accident would strand a zone.
Transfers, spawns and what the protocol carries
Zones talk with a request and response protocol. Its message types map what actually crosses a zone boundary:
- Ping request and response. The reachability check behind
nexus.ping. - Ferry status request and response, and a ferry retire request. Ferries are tracked across zones.
- Player manifest request. Which players a zone is holding, refreshed on an interval.
- Spawn options request and response. Spawning is a cluster-level decision.
- Player secondary data. A player carries more than a position between zones.
- Sleeping bag destroy request, with a destroy-bag handler. Respawn points are cluster-aware.
On top sit a transfer handler and a cluster-wide unique identifier type. A transfer is a negotiated handoff, not a reconnect with a saved inventory.
Config a zone inherits from the cluster
This is the part most likely to bite you in production, and it is invisible unless you read the boot log. A zone can pull configuration from the nexus instead of its own files. Three strings describe it:
Read the third line carefully, because it is the rule. The nexus can supply the world config, but a locally set convar wins and the pull is skipped: you get an informational line at boot and no error. A zone with a world setting in its own startup arguments or config file keeps that setting and diverges from the cluster, looking healthy until players notice the map behaves differently on one island.
So decide, per setting, whether the cluster owns it or the zone owns it, and never set the same thing in both places. If the cluster should be authoritative for world generation, remove those convars from the zone's local config entirely rather than setting them to what you believe the cluster value is. Our Rust server configuration guide covers where those convars normally live, which is the list to audit.
The message journal
Nexus messages are journalled and replayed, which is how a zone catches up on what it missed while disconnected. Two lines mark it at startup:
The count is filled in at runtime and both lines are normal: a journal replay after a restart is the system working as designed.
Clans run on the nexus backend
This one surprises people. Clans are a Nexus-backed feature. The build wraps a clan backend supporting creating, updating and deleting roles, assigning a player to a role, swapping role ranks, accepting and cancelling invites, kicking members, per-player notes, last-seen tracking, score events, lookup by member and a leaderboard. The clan system sits on the same infrastructure as cluster transfers, which is how clan membership stays consistent across every island. The server also carries a clan.enabled convar, so the feature is switchable, and the Common Ground update covers the player-facing side. The message to know is what the two halves print when they disagree:
A server got clan chat traffic it has no backend to deliver, and the exclamation mark is the build's own. The clan side of your configuration does not match the cluster sending you messages.
Troubleshooting: the console messages and what they mean
These are the exact strings in the build, so they are what to search your log for. They are verbatim, truncated ones included, and each entry states only what the message says.
Connection, login and socket
| Console message | What it means |
|---|---|
Nexus endpoint and/or secret key is not set, not starting nexus connection | One or both of nexus.uri and nexus.secretkey is empty. The server runs standalone and never joins a cluster. |
Nexus login failure | A login was attempted and did not succeed. Look for this when both convars are set but the zone never joins. |
Server is not connected to a nexus | Something needing the cluster was attempted while there is no live connection. |
Nexus socket reconnect loop is exiting | The reconnect loop that maintains the connection has stopped trying. |
Nexus socket handlers terminated | The socket handlers shut down. Normal at shutdown, a problem while the zone should be live. |
Nexus socket incoming handler terminating | The inbound side is going away. Pairs with the line above. |
NexusServer was already started | A second start was requested; something starts the nexus server twice. |
Nexus server failed to start, terminating | Fatal. The nexus side did not come up. |
Messages and remote calls
| Console message | What it means |
|---|---|
Nexus RPC invocation timed out | A call to another zone or the controller got no answer in time. nexus.rpctimeoutmultiplier is the lever; its description names differing latencies. |
Received an unexpected nexus RPC response (likely timed out), ignoring | The answer arrived after the caller gave up. Read with the timeout above. |
Nexus RPC handler threw an exception but already sent a response! | A handler failed after answering. Nothing to configure; capture the log. |
Received a nexus RPC invocation with a missing or unsupported request, ignoring | An incoming call was not one this build handles. |
Received a nexus message from unknown zone ID 3, ignoring | The id is runtime. Traffic from a zone this server has no record of; compare nexus.zones across members. |
Received a nexus message with wrong protocol, ignoring | The traffic did not match the protocol this build speaks. Check every zone is on the same build. |
Received a nexus message that's not binary, ignoring | Something non-binary arrived on the socket. |
Received a nexus message without the request or request sections set, ignoring | A structurally incomplete message. Quoted as written, repeated wording included. |
Zones, spawns, islands and content
| Console message | What it means |
|---|---|
Zone controller was not specified (nexus.zoneController convar) | nexus.zonecontroller is unset. Note the capital C when searching logs. |
Zone name is not available after nexus initialization | Initialisation finished without the server knowing its own zone name. Check nexus.zone. |
Nexus spawn - exception while choosing spawn zone | Choosing where a player spawns in the cluster threw. The player has nowhere to go. |
Nexus spawn - exception while registering transfer to spawn zone | The zone was chosen but registering the transfer into it threw. |
ZoneController did not choose a spawn zone (returned ' | The controller answered with nothing usable; the line continues with what it returned. |
ZoneController picked a spawn zone which we don't know about ( | The controller named a zone this server has no record of. Cross-check nexus.zones; nexus.refreshislands re-queries the controller. |
NexusTransferTrigger doesn't have a valid controller assigned! | The trigger that starts a transfer has no controller, so it moves nobody. |
NexusFerry will not work without being connected to a nexus - destroying. | A ferry exists on a server with no cluster connection, so the server removes it. |
NexusFerry has not been initialized (you can't spawn them manually) - destroying. | Somebody spawned a ferry by hand. Ferries only come from a live cluster. |
Prevented killing NexusDock, set debugging flag to override | Deleting a dock was refused on purpose. |
Received a clan chat batch but this server isn't using the nexus clan backend! | Cluster clan traffic reached a server with no nexus clan backend configured. |
Rendering map image to upload to nexus... | Normal boot activity, drawing the map for the cluster. |
Uploading map image to nexus... | Normal boot activity, the upload itself. |
Nexus already has this map's image uploaded, will not render and upload again | Normal. The cluster already holds this image, so the work is skipped. |
map.contactRadius isn't set in the nexus (uses normalized c | Truncated in the string we read. The nexus holds map.contactRadius and this zone found it unset. |
No messages found in the nexus message journal | Nothing to replay at startup. Normal. |
Replaying 12 nexus messages from the journal | The count is runtime. The zone is catching up on messages it missed. |
Running server.cfg from nexus variable | This zone's server.cfg came from the cluster, not a local file. |
Will use world config from nexus: | The zone takes its world config from the cluster; the value follows on the line. |
World config convar(s) are already set, will not pull world config from nexus | The inheritance gotcha. A local convar already set the value, so the cluster's world config is ignored here. |
What Facepunch has not published
There are exactly three gaps, and no guide claiming to have filled them has better information:
- The value format of
nexus.uriandnexus.secretkey. The build proves the convars exist and that both are required. It does not show what a valid endpoint looks like, nor how a key is obtained. - What software answers
nexus.zonecontroller. The convar and its error message are in the build. Whether Facepunch runs a hosted zone controller or an operator runs their own is not established. - Who can use it. Nothing in the build says whether Nexus is open to any operator or gated to partners. Anyone answering either way with confidence is guessing.
Facepunch publishes release notes on the official Rust site, the only source that can settle those three questions.
Expect this to move
Everything here was documented by reading a shipped server rather than a published specification, so expect drift. Rust ships a forced update every month, and internal names, descriptions and log wording can change with one, quietly. Re-read this list against your own build after each monthly update. The wipe and update schedule tells you when those checkpoints land.
Two pieces of ordinary advice apply while the provisioning question is open. Keep every prospective zone on the same build, because a mismatch shows up as the "wrong protocol, ignoring" line and nothing more helpful. And give each server its own identity, ports, storage and backups before clustering anything, the groundwork in the Rust dedicated server setup guide, with server requirements and RCON setup alongside it.
Looking for managed Rust server hosting? Supercraft runs Rust dedicated servers with daily backups, instant setup, and four region options, so you can stand up a server and check your own build in minutes.