Rust Server Not Showing in the Server List: Fixes

Your server is running, you can join it with client.connect, but nobody can find it in the Rust server browser. That almost always comes down to one of a handful of causes, and you can tell which one in a few minutes if you check them in the right order: is the server actually up, does Steam know about it, does it answer queries from the internet, and is it in the tab you are looking at.

Everything below was checked against a live server on our Ubuntu 26.04 test host, which is listed and answering queries on the default ports.

How the server list works

The in-game browser does not ask your game port. When the server finishes starting, it registers with Steam, and Steam then lists it by its query port. Players' clients ask that query port for the name, player count and tags using Valve's A2S query protocol over UDP. So there are two separate paths:

• Joining uses server.port (28015 by default, UDP).
• Being listed uses server.queryport (28017 by default, UDP), plus the server's outbound connection to Steam.

This is why "I can connect but I am not listed" is so common: the game port is open and the query port is not.

Step 1: Make sure the server finished starting

A server is not listed while it is still loading. Watch the log for these lines, in this order. From our test host, a restart on an existing map:

16:52:31 systemd[1]: Started rust-instance-<id>.service
16:54:04 SteamServer Initialized
16:54:12 Server startup complete
16:54:13 SteamServer Connected

SteamServer Connected is the moment the server has registered with Steam. On a first start or after a map wipe, the server generates the map first: that took about 6 minutes 40 seconds on our 4 vCPU test box, and the whole start about 8 minutes. If you check the browser 30 seconds after systemctl start, it is too early.

If Server startup complete appears but SteamServer Connected never follows, suspect outbound traffic to Steam. Check that the box has working DNS and that no egress firewall rule blocks outbound UDP or HTTPS.

Step 2: Ask Steam whether it knows your server

Steam has a public Web API call that lists the game servers registered at an IP address. It needs no API key:

curl -s "https://api.steampowered.com/ISteamApps/GetServersAtAddress/v1/?addr=YOUR_PUBLIC_IP"

This is the real reply for our test host:

{"response":{"success":true,"servers":[{"addr":"2.28.97.149:28017","steamid":"90293622083629077","appid":252490,"gamedir":"rust","region":-1,"secure":true,"lan":false,"gameport":28015,"specport":0}]}}

Read it carefully:

• servers is empty: Steam has no registration from this IP. Go back to step 1, or the server is registering with a different public IP (see the NAT section).
• addr shows a port you did not expect: that is the query port Steam will use. If it is not the port you opened in the firewall, fix the port or the firewall.
• secure is false: EAC is off. See the EAC section.
• Listed here but not in game: registration works, so the problem is reachability of the query port or the tab you are looking at.

Step 3: Query the server from outside

Run a query from a machine that is not the server, such as your PC or another VPS. Querying from the server itself goes through the loopback interface and skips every firewall in between.

With Python, python-a2s does it in one line:

pip install python-a2s
python3 -c "import a2s; print(a2s.info(('YOUR_PUBLIC_IP', 28017)))"

Or with Node.js and GameDig:

npx gamedig --type rust --port 28017 YOUR_PUBLIC_IP

Against our test host, python-a2s returned the server name, Procedural Map, 0 of 100 players and the keyword string, and GameDig returned "queryPort":28017 and "connect":"2.28.97.149:28015". Two things we saw that trip people up:

• Query the query port, not the game port. The same query to port 28015 timed out. A timeout on 28015 is normal; a timeout on 28017 is your problem.
• Pass the port to GameDig. Without --port 28017 it failed against our server.

If the query times out from outside but Steam lists the server, a firewall or NAT is dropping UDP to the query port.

Get the query port right

Facepunch's rule: if server.queryport is not set, it defaults to one above the higher of server.port and rcon.port. With the defaults, 28015 and 28016, that is 28017. It is UDP, and it can never be the same as server.port.

The default moves when you change other ports. Put RCON on 28020 and the query port silently becomes 28021, while your firewall still allows 28017. Run two servers on one box and the second one's query port follows its own ports. Set it explicitly on the command line so it never moves:

+server.port 28015 +server.queryport 28017 +rcon.port 28016

Then check what the process actually listens on:

ss -ulpn | grep RustDedicated

On our test host:

UNCONN 0 0 0.0.0.0:28015 0.0.0.0:* users:(("RustDedicated",pid=164694,fd=71))
UNCONN 0 0 0.0.0.0:28017 0.0.0.0:* users:(("RustDedicated",pid=164694,fd=67))

The log also prints the value it used, as server.queryport: "28017".

Open the firewall: ufw and your provider

There are usually two firewalls between a player and your server: one on the box and one in your hosting provider's panel. Both must allow the game and query ports over UDP. A TCP rule for 28017 does nothing.

With ufw on Ubuntu:

ufw allow 28015/udp
ufw allow 28017/udp
ufw allow 28082/tcp
ufw status

28082 TCP is the Rust+ companion app port (app.port). It is not needed for listing, only for players who pair the Rust+ app. Do not open the RCON port to the internet.

Then check the provider side. Hetzner, OVH, AWS, Google Cloud, Azure and most other hosts have a network firewall or security group that applies before traffic reaches your box. If that firewall only allows TCP, UDP to both ports is dropped. Add the same UDP rules there.

If you run iptables or nftables rules directly, look for a default DROP policy on INPUT without a UDP accept for 28017. For reference, our test host has ufw inactive and an ACCEPT policy, and relies on the provider firewall.

Re-run the outside query from step 3 after every change.

Check server.ip and the bind address

server.ip decides which local address the server listens on. The default, 0.0.0.0, means every IPv4 address on the box, and it is the right choice unless you have a reason to change it.

Problems start when server.ip is set to something else:

• An address that is not on this machine. Copying a config from another host, or putting the public IP on a NAT'd machine that only has a private address, leaves the server listening on nothing useful. Compare with ip -4 addr.
• A private address on a VPS with several IPs. The server then only listens on that one address, and queries to the public IP go nowhere.
• Tunnels. If you route traffic through a GRE tunnel for DDoS protection, set server.ip to the address the tunnel delivers traffic to, and make sure the tunnel forwards UDP to the query port as well as the game port.

After changing it, confirm with ss -ulpn that the query port is bound to the address you expect.

NAT, CGNAT and IPv6

Home hosting behind a router. Forward both UDP ports, 28015 and 28017, to the machine running the server. Forwarding only the game port is the classic "friends can join, nobody can find it" setup.

CGNAT. Compare the WAN address shown on your router with the address a site like ifconfig.me shows. If they differ, or the router's address starts with 100.64 to 100.127, your ISP puts you behind carrier-grade NAT and no port forward on your router can make the server reachable. You need a public IPv4 address from your ISP, a VPS, or a tunnel.

IPv6. Our test host has a global IPv6 address, yet ss shows the Rust server only on IPv4 sockets (0.0.0.0), and Steam registered it by its IPv4 address. Do not count on IPv6 for listing: make sure your VPS has a public IPv4 address.

Modded or Community: check the right tab

The in-game browser splits servers into tabs such as Official, Community and Modded. Oxide and Carbon set the modded flag by default, and modded servers are listed under Modded, not Community. Many admins install a framework, look in Community and conclude the server is gone.

• Oxide: "Modded": true in oxide/oxide.config.json (the default).
• Carbon: "IsModded": true in carbon/config.json (the default), which Carbon documents as "making the server to show up on the Modded Rust browser tab".

Do not turn the flag off to get into Community with gameplay-changing plugins: Facepunch's plugin guidelines say any plugin that changes gameplay, or shows or changes in-game UI, requires a Modded listing. If you think the framework is not loading at all, check the log. On our test host the Rust crash marker line reports "modded":"false" on a run where the Carbon launcher script failed to load its environment file, which is a quick hint that the framework did not start.

EAC and server.secure

server.secure turns Easy Anti-Cheat on. Servers with EAC off are not shown in the in-game list, and Steam's reply in step 2 shows "secure":false for them. Keep server.secure 1 in server.cfg unless you run a private test server that you only join by IP.

What is usually not the cause

• server.description, server.url and the header image only change what players see in the server details. They do not affect whether you are listed.
• An empty server.tags is fine. Our test server has server.tags "" and is listed. Tags matter only for filtered searches: the Facepunch wiki warns that tags from the same group are mutually exclusive, and mixing them means your server does not show up when players filter by that tag. Use one tag per group, for example one wipe schedule tag.
• Hostname. A long or odd hostname does not unlist you, but searching by name only finds what the browser can match, so test with a plain word from it.

How long listing takes

Registration with Steam happens about a second after Server startup complete, and the Steam Web API call in step 2 shows it right away. What players see in game can take longer to catch up, and some hosting companies report that brand new servers can take much longer to show up in the in-game browser than servers that were already listed. Do not change settings while you wait. If Steam lists you, an outside A2S query answers and you are looking in the right tab, the network side is done.

In the meantime, players can join directly: F1, then client.connect YOUR_PUBLIC_IP:28015.

Diagnostic checklist

Work through it top to bottom and stop at the first failure:

• The log shows Server startup complete and then SteamServer Connected (allow about 8 minutes on a new map).
• GetServersAtAddress for your public IP lists the server, with the query port and "secure":true.
• ss -ulpn shows RustDedicated on the query port, on 0.0.0.0 or the address you set in server.ip.
• server.queryport is set explicitly, is not equal to server.port, and matches what you opened.
• ufw (or iptables/nftables) allows the game and query ports over UDP.
• The provider firewall allows the same UDP ports.
• An A2S query from another machine to the query port answers (python-a2s or GameDig with --port).
• At home: both UDP ports forwarded, and you are not behind CGNAT. The server has public IPv4.
• With Oxide or Carbon: look in the Modded tab.
• Wait before changing anything else; players can join with client.connect meanwhile.

Let Panelra handle the ports for you

Panelra writes the game, query, Rust+ and RCON ports into every server's systemd unit, including an explicit +server.queryport, so the query port never drifts when you change another port. You can change each one per server in the network ports settings. It always writes server.secure 1, and it only writes a server.ip that is a valid IP address, falling back to 0.0.0.0. The host install screen lists the exact ports to open, and server monitoring shows each server's status and live player count and alerts you when it crashes, hangs or gets stuck while starting, so you know whether to look at the network or at the server itself.

Free during the open beta. Pricing will be announced before the beta ends.