Rust Server Not Showing in the Server List

Your Rust dedicated server is running, the console says it is up, players can even connect if you give them the IP, and yet it is nowhere in the in-game community browser. This is one of the most common problems in Rust server hosting and it has a small number of causes, almost all of them about the Steam query port rather than the game port. Here is how to work out which one you have and fix it.

First: prove the server is actually reachable

Before touching any configuration, check whether the server itself is fine and only its listing is broken. In Rust, press F1 to open the console and type:

client.connect your-server-ip:28015

If you get in, the game port and the server process are healthy and your problem is purely one of visibility. That is good news, because every fix below is a networking or configuration change and none of them require rebuilding anything. If the direct connect also fails, the server is not running or the game port is closed, and this is a different problem: check the console output for a startup error and confirm 28015/UDP is open.

Cause 1: the query port is not open

Rust uses three ports and they do different jobs. Confusing them is the single biggest source of "my server is invisible" reports:

Port	Protocol	What it does	If it is closed
28015	UDP	Game traffic	Nobody can play at all
28016	TCP	RCON / admin	No remote admin, game unaffected
28017	UDP	Steam query	Server runs but never appears in any list

The Steam master server discovers your server by querying it on the query port, not the game port. If 28017/UDP is blocked by your firewall or missing from your port forwarding rules, the query never gets an answer, Steam concludes there is nothing there, and your server is left out of the community browser while continuing to accept direct connections perfectly. That mismatch is exactly the symptom most people describe.

Open 28017 on UDP specifically. A TCP rule on the same number does nothing here, and it is a very easy mistake to make when you copy a rule from the RCON port next to it.

Cause 2: the query port was never declared

Opening the port in the firewall is only half of it. The server also has to be told which port to answer queries on, with the -queryport launch parameter:

./RustDedicated -batchmode +server.port 28015 -queryport 28017 +server.hostname "My Rust Server"

Without an explicit -queryport, some setups end up querying on a port nobody opened, and you get the same invisible-server behaviour with a firewall that looks correct. State it explicitly and keep it consistent with the rule you opened. If you run more than one Rust server on one machine, every instance needs its own game port and its own query port, and they must not collide.

Cause 3: port forwarding through a home router

Self-hosting behind a consumer router means the query has to survive one more hop. Two things go wrong here regularly:

Forwarding the ports as a single range. Some routers handle a 28015 to 28017 range rule badly. Create separate rules per port, each mapping the same external and internal port number, and set the protocol correctly per rule rather than leaving everything on "both".
Forwarding to the wrong internal address. If the machine's local IP was assigned by DHCP it can change, silently pointing your rules at nothing. Give the server a static local address or a DHCP reservation.

This whole class of problem does not exist on a managed host, because there is no router in front of your server and the ports are opened at deploy time.

Cause 4: the server is listing itself with the wrong address

A server behind NAT, or on a machine with several network interfaces, can end up advertising an address that nobody outside can reach. If you have bound the server to a specific local IP, try binding to all interfaces instead and let the network layer decide. Setting a hard-coded internal address is a common cause of a server that queries fine from inside your own network and is invisible from everywhere else.

The quick test for this: ask someone outside your network to search for the server by name. If it is visible on your LAN and invisible to them, this or the port forwarding above is your cause.

Cause 5: you are looking in the wrong place

Not every invisible server is broken. Rust's community browser is large, heavily filtered and sorted by player count, so a brand new empty server sits at the very bottom of a very long list.

Search by your exact server.hostname rather than scrolling. Partial names and default names like "My Rust Server" will bury you among hundreds of identical entries, so set something distinctive.
Check your filters. Modded servers do not appear under the Community tab filter set for vanilla, and vice versa.
Give it a few minutes. Listing is not instant after a start, and the master server takes a little while to pick a new server up.
Have players favourite the server by IP once. After that it appears under Favourites regardless of how the browser is sorted, which is worth doing for your regulars anyway.

Cause 6: it disappeared after a wipe or an update

Facepunch ships a mandatory patch on the first Thursday of every month. A server still on the previous build does not just reject players, it can drop out of the browser entirely because it fails to match the current version the master server expects. If your server was listed yesterday and is not today, check the date against the wipe schedule before debugging anything else.

Self-hosters need to re-run app_update 258550 validate in SteamCMD and restart. On Flux the update is handled for you and a restart picks it up, which is the main reason this cause is so much more common on hand-rolled servers.

The order to check things in

Direct connect with client.connect ip:28015. If that works, it is a visibility problem, not a server problem.
Confirm 28017 is open on UDP, not TCP.
Confirm -queryport 28017 is on the launch line.
If you are behind a router, check the forwarding rules are per-port and pointed at a static local address.
Search by your exact hostname and check your browser filters before assuming anything is wrong.
Check whether a forced wipe or patch has landed and your server is still on the old build.

Almost every case ends at step two or three. The pattern to remember is simple: the game port decides whether people can play, and the query port decides whether they can find you.

Deploy a Rust server on Flux with 28015, 28016 and 28017 already open, automatic monthly updates and DDoS protection included.

Server visibility FAQ

Why is my Rust server not showing in the server list?

In almost every case the Steam query port, 28017/UDP, is either closed or not declared with -queryport. Steam discovers servers by querying that port, so when it is unreachable your server keeps running and accepting direct connections while never appearing in any list.

What ports does a Rust server need open?

28015/UDP for game traffic, 28017/UDP for the Steam query, and 28016/TCP for RCON if you use remote admin. The query port is the one that controls whether your server is listed.

How do I join a Rust server that is not showing in the browser?

Press F1 in Rust and type client.connect your-server-ip:28015. This works whether or not the server is listed, and it is also the fastest way to prove the server itself is healthy and only its listing is broken.

My Rust server was listed and now it is gone. What happened?

Check the date first. Facepunch patches on the first Thursday of every month and a server left on the previous build can drop out of the browser entirely. Update the server and restart it.

Do I need the query port if players connect directly?

Only if you want to be discoverable. A server with 28015 open and 28017 closed is perfectly playable for anyone who has the address, and completely invisible to everyone who does not.

Does a managed host solve this?

Yes, because there is no firewall or router of yours in the path. On Flux all three ports are opened at deploy time and the monthly Facepunch update is applied for you, which removes both the port causes and the stale-build cause.