Try a direct connection before changing a Rust server that is missing from the list. If direct joining works, you already have evidence that the game endpoint is reachable. Browser discovery adds a separate query path and client-side filtering, so an absent listing does not by itself justify a world reset.
This guide covers Rust PC dedicated servers on Linux. Console Edition uses a different ecosystem. Examples continue our Ubuntu server setup: service rust, identity friends, installation /srv/rust/game, game UDP 28015, query UDP 28017, private RCON TCP 28016. Adapt these values to your actual installation; other administrators may have allocated different ports.
Establish whether players can join directly#
In a matching Rust PC client, press F1 and replace the example address with your server's real reachable address:
connect 203.0.113.10:28015
203.0.113.10 is a documentation placeholder, not a usable destination. For a home server, test from outside its LAN as well; a local connection does not exercise provider firewalls or router forwarding. Record the time and the result, including whether the player reached the world.
If direct joining also fails, investigate startup readiness, client/server version alignment and the game UDP path first. Read the game log rather than assuming an active service has finished generating the map:
sudo systemctl status rust --no-pager
sudo tail -n 100 /srv/rust/rust.log
sudo ss -lunp 'sport = :28015 or sport = :28017'
The example log path comes from the setup article's -logfile argument. Find the actual path if your service differs. Preserve world and identity files while investigating; browser visibility is not a reason to wipe them.
Separate game, query and administration ports#
Facepunch's server documentation requires separate game and query UDP ports. The query default depends on the configured game and RCON ports, so assuming it always equals game-port-plus-one is unreliable. Set an explicit query value in the actual launch configuration.
For our example, the following is a fragment of the existing launch command, not a complete replacement:
+server.port 28015 +server.queryport 28017
Retain the identity, world parameters, RCON configuration and other required arguments. Inspect the service definition privately, because some installations place administration secrets directly in the command line. Avoid posting complete process arguments.
The identity configuration can override launch settings. Check just the relevant non-secret entries in the file used by this identity:
sudo sed -n '/^server\.port /p; /^server\.queryport /p; /^server\.tags /p' /srv/rust/game/server/friends/cfg/server.cfg
Resolve conflicting values before the next planned restart. Changing a port requires updating the corresponding firewall and forwarding rules, then checking the listener after startup. Do not start a second Rust process against the same identity to test another port.
Follow query UDP through every firewall boundary#
On an existing UFW-managed host, inspect the current rules and add only the missing game/query allowances:
sudo ufw status verbose
sudo ufw allow 28015/udp
sudo ufw allow 28017/udp
These commands do not enable UFW or change SSH rules. If the host uses another firewall, edit that system's rules instead. Permit the same UDP endpoints at the VPS provider. Behind a router, forward them to the correct server's private address. Container port publishing must also specify UDP; a TCP mapping with the same number is a different endpoint.
Leave public RCON blocked. Opening TCP 28016 cannot fix UDP browser queries and unnecessarily exposes administration. For an already private setup, keep its SSH-based RCON access intact.
Test the query port from an independent external machine using a trusted Steam-compatible A2S query tool. If it fails, compare the exact destination and protocol with the listener and each boundary. A TCP port-checking website tests the wrong protocol, while a UDP scan reporting no response is not a definitive closed-port result.
Remove filters before changing the server again#
If external queries return the intended server information, inspect the game browser. Clear text, player-count, ping, map and tag restrictions; check the category appropriate to the actual server. A plugin-enabled server should not be diagnosed solely through the vanilla category. Confirm the expected public branch rather than a staging client.
Use a distinctive hostname, then reapply filters individually. Facepunch's tag reference explains that conflicting tags in one group can break filtered discovery. For example, do not advertise both weekly and monthly wipes. Tags describe policy; setting one does not implement the corresponding wipe schedule.
Historical player reports after query-port sharing was retired show why older launch examples can mislead. They do not establish that every missing server has the same cause. Likewise, one player's cached browser result is weaker evidence than a reproducible external query and join.
Keep evidence that distinguishes discovery from admission#
Record three results separately: external A2S query, listing with relaxed filters and a normal player's successful world join. If queries succeed but listing remains absent across multiple clients, inspect startup registration errors and any explicit hidden-server configuration before changing storage or reinstalling.
For support, provide the current build, hostname, public game/query endpoints, failure times and redacted relevant logs. Exclude RCON passwords and full environment files. After a correction, restart once in a maintenance window, repeat the external checks and confirm the intended world still loads. Keep the identity and map parameters unchanged throughout this repair; discovering the server should not cost the group's progress.
