Players Can Join but Your Bot Won't: RCON Port vs Server Port on Rust Console

The one-line diagnosis: two ports, two different jobs

Your Rust Console server listens on two separate ports, and they do completely different jobs. The game port (usually 28015, the value stored as server.port, running over UDP) is the one every console player's connection travels through when they load into your map. The WebRCON port (usually 28016, running over TCP as a WebSocket) is a second, admin-only door that a bot uses to send commands and read events. Different number, different protocol, different purpose.

So the symptom writes the diagnosis for you. If players are on the server, the game port is open and working perfectly. If the bot still can't connect, the problem lives entirely on the WebRCON side. Nine times out of ten the setup form has the game port (28015) sitting in the RCON port field, so the bot is knocking on the players' door instead of its own. Players get in. The bot never will, no matter how many times you retry.

The 30-second fix: change one number

The repair is almost always a single character. Open your bot's connection or server settings and find the field labelled RCON port, WebRCON port, or sometimes just "port." If it reads 28015, that is the game port, and it does not belong there. Change it to your WebRCON port, which is 28016 on most Rust Console setups, then save and reconnect. That is the whole fix.

A couple of honest cautions. The server IP is identical for both ports, so leave that alone. Only the port number and the RCON password differ from what a player would use. And do not assume the numbers are always 28015 and 28016. Most hosts follow that convention, but some assign a different WebRCON port per server, so copy the exact value your host shows rather than typing 28016 from memory. If you are not sure where that number lives, our guide on how to find your WebRCON IP, port and password walks through both official hosts screen by screen.

Where each value actually lives (G-Portal vs Nitrado)

Where these numbers live depends on your host, and the two official Rust Console hosts handle it very differently.

On G-Portal you connect by hand. The panel shows your server IP, your RCON port, and your RCON password, and you copy all three into the bot. This is exactly where the swap happens, because the game port and the RCON port sit near each other on the same screen and look almost identical at a glance. Copy the RCON port deliberately, not the one next to it.

Nitrado skips the ports entirely. Instead of copying an IP, port, and password, you link your Nitrado account to the bot once and the connection is handled for you behind the scenes. There is no port field to fill in wrong, which is why account-link setups almost never hit this particular problem. If you are on Nitrado and want to avoid the whole issue, the one-click account link is the shortcut around it.

Port is right and it still won't connect? Three more causes

If the port is correct and the bot still shows red, you are into the next layer, and it is worth checking these in order rather than firing off retries. Our full WebRCON not connecting troubleshooter covers the whole sequence, but here are the three that catch most owners.

First, WebRCON has to be switched on. A few hosts ship with the web console disabled, and the bot has nothing to connect to until rcon.web is set to 1 in your server config. If your host panel has a WebRCON or RCON-web toggle, make sure it is on.

Second, your RCON password itself can be the culprit. Host-generated passwords sometimes include spaces or special characters that get mangled on copy, and a single wrong character reads as a failed login. If you are seeing a Rust Console RCON authentication failed message rather than a plain timeout, that is the tell, and it points at the password, not the port. Copy it fresh, with no stray spaces at the start or end.

Third, slow down. Rust briefly rate-limits and locks RCON after repeated failed attempts, so a bot set to hammer retries every second can lock itself out and make a fixable problem look permanent. Change one thing, wait a moment, then test once. Hammering never helps.

Confirm the bot is really connected, not just hopeful

Once the status flips to connected, confirm it is actually talking to the server rather than just showing a green light. The cleanest test is to make something happen in game from the bot side. Trigger a small event with event_airdrop, or ask the bot for a player's location with printpos "<player>", and watch for the result in game or in your bot's log.

A live killfeed is the other quick proof. If your bot reads kills and they start appearing as players fight, the WebRCON pipe is open in both directions and you are done. If the status is green but nothing ever comes through, you are back to the port and password checks above, because a truly connected bot both sends and receives.

Keep it connected after wipes and patches

Solving the port swap once tends to solve it forever, but two normal events will briefly drop the connection again, and knowing about them saves you from re-diagnosing a non-problem. When Facepunch ships a patch, G-Portal auto-updates and reboots your server, which knocks any bot offline until it reconnects. Weekly wipe day does the same. Neither means your port is wrong again.

What matters is whether your bot climbs back on by itself. A reliable setup notices the server come back and reconnects on its own within about a minute, with no login from you. Vantic is built to reconnect automatically after patches, reboots, and wipes, so the port you fixed today stays fixed. If your current bot goes dark after every restart and waits for you to intervene, that pattern is worth understanding, and we cover it in our note on why a bot stops working after a restart.

Frequently asked questions

Keep reading

WebRCON not connecting troubleshooter · find your WebRCON IP, port and password · fix an RCON authentication failed error · stop a bot that keeps disconnecting · connect a G-Portal Rust Console bot