Rust RCON Not Connecting: WebRCON Checklist

Rust RCON problems almost always come down to one of six things: the wrong protocol, the wrong port, a password that does not survive being put in a URL, a firewall, a server that is still booting, or a tool that was never going to work. This checklist goes through them in the order that finds the fault fastest, using real log lines and commands from our Ubuntu test host.

Step 1: read what the server says about RCON

Before touching any client, look at the server's own startup log. On a systemd setup (use your own unit name):

journalctl -u rust-instance-1 -o cat | grep -iE "rcon|startup complete" | tail -20

A healthy start on our test host (Rust build 25582902) prints this:

Command Line: "..." "+rcon.port" "28016" "+rcon.web" "1" "+rcon.password" "******"
rcon.port: "28016"
rcon.web: "True"
Command 'rcon.password' not found
WebSocket RCON Started on :28016
...
Server startup complete

What each line tells you:

• WebSocket RCON Started on :28016 is the one that matters. It confirms WebRCON (not the old protocol) and the port the server really listens on. No line, no listener: check that +rcon.port and +rcon.password reached the command line, and look for a boxed warning that says RCON password is very insecure, RCON is disabled. (see step 4).
• "+rcon.password" "******" shows the password arrived. The server masks it, so you cannot read it back from the log.
• Command 'rcon.password' not found is normal on this build and harmless. It is also the reason rcon.password belongs on the command line and not in server.cfg: it is not a console variable the server knows, so a server.cfg line has nothing to set. It is missing from the published ConVar list too, while rcon.port, rcon.web and rcon.ip are there. The Facepunch wiki also says to set up RCON on the command line.

Then confirm the socket from the host:

ss -ltnp | grep 28016

On our host that prints LISTEN ... 0.0.0.0:28016 ... users:(("RustDedicated",...)). 0.0.0.0 means every interface. If you see a specific address here, see binding.

Step 2: make sure it is WebRCON

rcon.web picks the protocol. 1 is WebSocket RCON, which Facepunch recommends. 0 is the legacy Source engine RCON, which the server's own help text marks as deprecated. The two are not compatible: a Source RCON client speaking to a WebRCON port gets nothing useful back, and the other way round.

Set it explicitly so nothing depends on the default:

+rcon.web 1

Tools and what they need:

• Source RCON clients (mcrcon and the "Source RCON" option in multi-game tools) do not speak WebSocket. They fail against rcon.web 1.
• rcon-cli by gorcon works, but only with -t web. Without it, it uses Source RCON.
• Facepunch's own WebRCON page is a browser app on GitHub Pages, reachable over both http:// and https://. Opened over https://, the browser blocks the plain ws:// connection to your server (mixed content), which is why it often "does nothing". Do not weaken your browser settings for it; use a desktop client or the host itself.
• Hosted tools such as BattleMetrics connect from their own servers, so they need your RCON port reachable from their IPs. See step 5.

Step 3: check the port

rcon.port is TCP. The game and query ports are UDP, and a firewall rule or port forward for the wrong protocol is a classic cause of "it just times out". The Facepunch wiki says the default equals server.port, so always set it explicitly, for example +rcon.port 28016 next to a game port of 28015, and connect to exactly the number in the WebSocket RCON Started on line.

If two servers run on one box, give each its own RCON port. The second server cannot open a port the first one already holds.

Step 4: get the password right

With WebRCON the password is not sent in a login packet. It is the path of the WebSocket URL:

ws://<host>:<rcon port>/<password>

That has consequences a plain text field hides:

• # and ? break it. In a URL, # starts a fragment that is never sent, and ? starts a query string, so the server may see only part of your password.
• /, % and spaces change the path or need escaping, and not every tool escapes them.
• Quotes and spaces on the command line need correct shell quoting, or the server gets a different password than you typed. In a systemd unit, ${RCON_PASSWORD} is passed as one argument, exactly; $RCON_PASSWORD is split at spaces.

The fix is to avoid the problem entirely: use a long password of letters and digits only. Panelra generates 32 random alphanumeric characters for every server. Length gives the strength, so you lose nothing by skipping symbols.

Two server rules can also stop RCON with a password that is technically correct. The strings below are in the server binary of build 25582902:

• Common passwords switch RCON off. With a password such as password, changeme, 123456 or qwerty, the server prints RCON password is very insecure, RCON is disabled. and never opens the listener. A password under 8 characters only prints a warning today, and the same banner says that support for such passwords may be removed.
• Repeated failures get an IP banned. After too many wrong attempts the server logs RCON: IP <ip> banned for <n> seconds due to reaching max password failure attempts, and later bans can be permanent. A banned IP is refused even with the right password (RCON: Banned IP <ip> attempted to connect.). Bans are kept in a file named rcon-bans.cfg. We have not measured the threshold: five wrong attempts spread over our test server's history did not trigger a ban. Note that every tool on the host itself connects as 127.0.0.1, so a script retrying with an old password can get the local address banned for everyone.

A wrong password is easy to spot on the server side. Every attempt logs:

RCON: IP 127.0.0.1 attempted to connect with incorrect password.

If you see your client's IP there, the network path is fine and only the password is wrong. If you see a Banned IP line, the password is not the problem: wait out a temporary ban and check rcon-bans.cfg for a permanent one. If you see nothing at all, the connection never reached the server: go back to the port, binding and firewall.

Step 5: binding and firewall

By default RCON listens on every interface (0.0.0.0). rcon.ip limits it to one address. Two things go wrong here:

• You bound it and connect elsewhere. With +rcon.ip 10.0.0.5, connecting to 127.0.0.1 or the public IP fails. Connect to the address shown by ss -ltnp. rcon.ip also works as a server.cfg line: on our host the log shows Server Config Loaded two seconds before WebSocket RCON Started. Panelra's agent follows the same rule: it connects to rcon.ip if set, then the server IP, then 127.0.0.1.
• A firewall drops it. Remember both layers: ufw or nftables on the host and any network firewall in your provider's control panel.

WebRCON is plain ws:// by default, not TLS, and the password is in the URL, so anyone on the path can read it. The server binary does contain +rcon.ssl and +rcon.sslpwd switches, but they are undocumented and we have not tested them. Keep the port closed and pick one of these:

1. Use it on the host. Run your client on the box and connect to 127.0.0.1.
2. SSH tunnel. From your PC, ssh -L 28016:127.0.0.1:28016 root@your-host, then point your client at ws://127.0.0.1:28016/<password>. The connection rides inside SSH.
3. Allow only known IPs. If a hosted tool needs direct access, allow just its addresses:

ufw allow from 203.0.113.10 to any port 28016 proto tcp

203.0.113.10 is a placeholder; use the IPs your tool publishes. Never open 28016 to everyone.

Step 6: the server may simply be busy

The RCON listener opens early. On our host, WebSocket RCON Started came 9 seconds after systemd started the unit, while Server startup complete arrived about a minute and a half later on a restart with an existing map. On a brand new 4000 map, generation alone took about 6 minutes 40 seconds on the same 4 vCPU box.

In that window the port accepts connections, and simple commands can answer about 45 seconds into boot, but heavier commands such as serverinfo can be slow or time out until the server has finished loading. A client that connects, sends a command and gives up after a few seconds reports "not connecting" when the server is only busy. Watch the log for Server startup complete before you conclude anything. If it never arrives, see Rust server stuck on startup.

A server that hangs while running looks similar: the socket still accepts, but no replies come back. In our tests with a frozen server, our agent's 10 command slots were all waiting on replies within about 20 seconds.

Step 7: connection limits

Rust caps RCON connections. On our host (defaults, not set by us):

Five per IP is easy to hit from one machine: a panel, a bot, a Discord integration and a couple of scripts that open a new connection per command and never close it. Every tool running on the same host shares 127.0.0.1. Keep one long-lived connection per tool, close connections in scripts, and check what is connected:

ss -tnp state established '( sport = :28016 )'

Both limits are set as startup parameters; the server help text says a change needs a restart.

Step 8: test with a client you trust

Rule out your tool by testing the handshake with curl (8.11 or newer, where WebSocket support is on by default; we used 8.18.0). Run it on the host, where the password in the command line is not exposed to the network:

curl -v -m 3 --no-buffer "ws://127.0.0.1:28016/YourPassword" 2>&1 | grep -E '^< HTTP|curl:'

What the results mean, as seen on our host:

• < HTTP/1.1 101 Switching Protocols: port, protocol and password are all correct. curl then times out after 3 seconds because it has nothing to send; that is expected. If this works and your tool does not, the tool is the problem.
• curl: (1) Received HTTP/0.9 when not allowed: the server answered without a handshake. Together with the incorrect password log line, the password is wrong. If the log says Banned IP instead, your IP is banned (see step 4).
• curl: (7) Failed to connect: nothing is listening at that address and port.
• A timeout with no output: a firewall is dropping packets, or you are connecting to the wrong address.

To send a real command, use rcon-cli in web mode, with the password in a chmod 600 config file as shown in automating Rust wipes:

rcon -c /etc/rust-wipe/rcon.yaml -e rust -t web "serverinfo"

A JSON reply with Hostname, Players and Uptime means RCON works end to end.

Quick checklist

• Log shows WebSocket RCON Started on :<port>.
• +rcon.web 1 on the command line; your tool speaks WebRCON (-t web for rcon-cli).
• Connecting to the TCP port from that log line.
• +rcon.password on the command line, letters and digits only, not a common password.
• No incorrect password or Banned IP lines for your IP.
• Address matches rcon.ip and ss -ltnp.
• Port closed to the world; SSH tunnel or IP allowlist for remote use.
• Server startup complete reached before testing.
• Under 5 connections from your IP.
• curl handshake returns 101 Switching Protocols.

Let Panelra handle RCON for you

Panelra's agent runs on your host and connects to RCON locally, so the RCON port never has to be open to the internet. It generates a 32 character alphanumeric password per server, keeps it in a chmod 600 environment file, passes it to the server on the command line and holds one persistent connection, reconnecting with backoff if the server restarts. While a server boots it waits for two successful serverinfo replies before calling it running, and it limits itself to 10 outstanding commands so a busy server is reported as busy instead of being flooded.

You get a web RCON console in the browser, with the traffic going through the agent instead of an open port, plus server monitoring and alerts when a server stops answering. If you also use a hosted RCON tool, see Panelra vs BattleMetrics RCON.

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