Rust Server Not Working? Diagnose Your Dedicated Server

If your Rust server is not working, find the last successful stage before changing settings: process launch, world loading, player admission, browser discovery or administration. A green panel indicator cannot prove all five. This guide is for the person administering a PC Rust dedicated server and produces a short incident record plus the next useful test. If your client cannot join any unrelated server, begin with the client and its connection instead. Console Edition has a separate server ecosystem; these PC commands and hosting options do not apply to it.

Narrow down why your Rust server is not working#

Start by asking who fails, on which server, and at what time. “Nobody can play” could mean one person tested once, everyone on the same home connection failed, or several independent players received the same rejection. Those are different observations. Record the exact error rather than translating every message into “offline.”

Facepunch’s empty-server-list guidance explains that the client gets server addresses through Steam and queries servers for details. An empty browser is therefore not proof that every dedicated server is down. Also check whether the player launched normal Rust or Staging; do not assume those environments are interchangeable.

If this installation has never worked, use the Rust setup-route and first-world checklist to establish the intended deployment first. For a previously working server, write down the last successful session and what changed afterward. Do not announce a general Rust outage based on one failed connection or an old incident report.

Find the last stage that actually succeeded#

Follow the startup evidence until you reach the first missing result. Later services can fail while earlier ones work, so avoid treating every symptom as a reason to replace the installation.

The startup marker comes from Facepunch’s dedicated-server documentation. Match it to the current launch, not a line left in yesterday’s log. Even a genuine startup-complete message does not prove that a remote player can join through your firewall or provider allocation.

World generation can take time. Compare successive log timestamps and actual progress instead of declaring a hang after an arbitrary number of minutes. A panel that repeatedly restarts the process may prevent it from finishing; record those restarts before making the cycle faster. Conversely, an alive process with no useful progress needs investigation rather than an indefinite wait.

Your result should be a narrow statement: “World readiness succeeded; the first external player attempt failed at this UTC time.” That gives the next operator a reproducible boundary. “The server is broken” leaves them to start again.

Capture a useful incident packet before restarting#

Preserve the evidence while it still describes the failure. Restarting may rotate logs, change the endpoint allocation or erase a transient symptom. If the console is unavailable, retain what the panel, process supervisor or host exposes and mark the missing fields as unknown.

1. Save the current launch and failure record

   Export the log from launch through the failure, including the first relevant error and surrounding lines. Record the time zone, last successful session and recent update, configuration or framework changes. Keep an untouched private copy and a redacted copy for support.

2. Read the running server's identity and endpoints

   If the dedicated-server console or an already secured WebRCON session responds, run the read-only commands below one at a time. Compare the reported identity with the world you intended to start and the ports with the provider’s actual allocation.

3. Add the player's observation

   Ask for the exact failure text, attempt time, selected server and whether other servers work. Record whether the attempt came from the host machine, the same LAN or a separate internet connection. Do not label an unperformed test successful.

These are dedicated-server console commands, not PowerShell, SteamCMD or instructions to paste into an ordinary player’s F1 console:

version
server.identity
server.port
server.queryport
serverinfo
status

The identity selects the server data directory; Facepunch documents persistent configuration under this installation-relative path:

server/<identity>/cfg/server.cfg

During this guide’s local Windows verification, these six commands returned results on dedicated-server Steam build 25353106. The instance used a new disposable identity, separate game/query ports and loopback-only administration. This verifies command responses; it is not a remote-player join, browser-listing, Linux or hosting-panel acceptance test. Record your own build because a later update may change output.

Inspect the responses before sharing. Player lists and logs can contain identifiers and addresses; launch arguments or panel exports may expose RCON secrets. Preserve useful error context while removing secrets from the support copy. A screenshot of the last line alone often discards the earlier error that explains it.

Test game access separately from browser and admin access#

Test the function that failed using its actual allocated endpoint. Copying a port number from another provider’s tutorial can send a valid test to the wrong service.

Facepunch documents these as distinct services. Read the allocation and effective settings instead of deriving every port from the game port. If you manage a rented instance, ask the host which public address and ports map to it; a local bind value need not be the player’s public destination.

If Rust+ alone is offline while players can still join, follow this Rust+ companion troubleshooting guide to check app.info, external TCP reachability and server identity without changing the world.

Compare authorized player attempts from different paths. A same-machine success does not test the router. A LAN success does not establish internet reachability. If local players succeed while someone on an independent connection fails, inspect the external mapping and access policy next. A failed public-address attempt from inside the same LAN alone cannot settle what outside players experience.

A generic TCP port-check result cannot certify Rust’s UDP game service. Likewise, successful RCON proves an administration path, not player admission. Keep RCON restricted to trusted access; broad exposure is not a sensible discovery test.

When direct joining succeeds but discovery fails, preserve that success as evidence and investigate the query path. Do not wipe the world to make a browser listing appear. If discovery works but joining fails, capture the actual rejection and follow its evidence instead of reopening every endpoint.

Choose the next check from the observed failure#

Use the first meaningful observation to choose one investigation. An error near the end of a log may be a consequence of an earlier failure, and a recent update is a lead rather than proof of the cause.

For configuration differences, use the effective-setting and restart worksheet. A file that contains the desired value is not enough if a launcher or panel overrides it. Compare the running value and its owner before editing several configuration layers at once.

For a modded server, the plugin maintenance register helps identify dependencies and a rollback owner. Test a suspected extension change in an isolated recoverable environment when possible. Removing a plugin may change gameplay or data handling even if the process still starts.

If players can join and the actual complaint is degraded simulation or pauses, continue with measured Rust performance diagnosis. H01’s job is to locate the failed operating stage; that guide handles workload measurements. A plan’s advertised RAM or recommended player count cannot diagnose a crash.

Check the date and applicability of copied fixes. Facepunch’s Maintenance announcement removed an older server security setting, yet old troubleshooting pages still recommend it. Use current official guidance and the actual build rather than reviving a command because it appears in several search results.

Change one thing and repeat the same test#

A useful repair changes one relevant variable and then repeats the observation that failed. Write down the expected result and the rollback before touching configuration. If you cannot explain which failed stage the change addresses, collect more evidence first.

1. Prepare a reversible change

   Record the current value, file or component version and its exact scope. Keep the corresponding recoverable copy. For changes involving world data, use a stopped, consistent inventory and an isolated recovery check before proceeding.

2. Apply the smallest supported correction

   Correct the one mismatch demonstrated by the evidence, such as an admin client’s endpoint not matching its assigned allocation. If a restart is required, announce it and retain the previous logs first. Avoid bundling an unrelated map, framework and network change.

3. Repeat the failed stage and record the outcome

   Use the same relevant client, network path and operation. Confirm the intended identity and world, then compare the new result with the original error. Restore the previous configuration if the change introduces a regression and your recovery plan allows it.

Facepunch’s file guide distinguishes world, map, player and other server data. Copying one conveniently named file is not a universal recovery plan. Use the Rust data-operation and recovery record to define what must survive and how you will verify it.

Close the incident only at the stage you actually retested. “Process starts again” is a useful partial result; “players can rejoin the expected world through the affected route” is stronger acceptance evidence. If you have only the first result, leave the second explicitly pending.

Escalate with evidence and assign the next owner#

Send support a compact reproduction record rather than a folder of unexplained screenshots. It should let another operator locate the same instance, correlate the same time window and see which hypotheses have already been tested.

Affected instance / identity:
PC client and dedicated-server builds / branches:
First failure time and time zone:
Last successful stage and evidence:
First failed stage and exact redacted error:
Affected players / network paths:
Recent changes:
One change tested and its result:
Recovery copy and verification status:
Requested next check / responsible person:

Ask for a specific next action within the recipient’s responsibility: checking a provider’s endpoint mapping, explaining an enforced resource limit, or reviewing an extension’s error against its supported version. Keep private secrets out of tickets unless the provider supplies a suitable secure process and actually needs them. Assign one incident owner so two administrators do not make conflicting changes during diagnosis.

Self-hosting remains a reasonable choice when your group can maintain connectivity, updates and recovery. If this incident exposes infrastructure work you want to delegate, compare hosting responsibilities and support scope before migrating. Changing providers does not automatically fix a client error or an incompatible plugin.

For supported PC Rust groups that want to hand off home-server infrastructure, we recommend Game Hosting’s Rust hosting with an integrated panel and free backups. Diagnose the incident first: a new host cannot repair a broken client or incompatible plugin. Keep the incident record so the next administrator starts from evidence.