Rust Game, Query, and RCON Ports Explained

Capture the real startup values

1. 1Copy the active service or launch command with the RCON password redacted.
2. 2Record server.port, server.queryport, rcon.port, rcon.web, and app.port if Rust+ is enabled.
3. 3Confirm every configured port is unique where the official guide requires it and note TCP versus UDP.
4. 4Wait for Server startup complete before testing any path.

Test one service at a time

• UDP game port: use a direct client connection and confirm the Rust process is ready.
• UDP query port: check browser/listing reachability from outside the LAN.
• TCP RCON port: connect only through the trusted management path with the actual configured value.
• TCP Rust+ app port: test pairing/companion reachability separately; player joining does not prove it.

Build narrow protocol-correct rules

Create Windows Firewall rules for only the active server services. Forward the UDP game and query ports to the server PC's reserved LAN address when public play requires them. Keep RCON behind a VPN, LAN, or narrowly scoped firewall; a strong password is not a reason for broad exposure.

Avoid the common 28016 assumption

Many examples place RCON on 28016, while an explicit server.queryport can use that number instead. Protocols prevent a TCP/UDP collision from being identical at the socket level, but the operational ambiguity causes misconfigured clients and rules. Use the live command as the source of truth and label every rule by service.

If Rust+ alone is offline

Preserve companion.id and inspect the configured app.port. Facepunch derives a companion port well above the game/RCON values when one is not explicit, and it must meet the documented range. Do not delete the pairing identity while ordinary game/query/RCON traffic is being repaired.

Read the network result as a service-specific signal

A direct player join with no browser listing means the UDP game socket is reachable while the query advertisement still needs investigation. A browser entry followed by a join timeout proves only that query traffic reached the client; it does not prove the game port or a fully started world is reachable. Successful RCON is narrower still because it travels over its separately configured TCP service.

Capture the startup log through Server startup complete, the bound socket list, and one test from a real outside connection. Change one explicit port at a time and label each Windows Firewall/router rule with service and protocol. If the ISP uses CGNAT or a second upstream router, changing 28015 to another number cannot create an inbound public path; establish the public-address topology before rebuilding Rust or its identity.

Use a four-service verification matrix

Record each Rust service in its own row: configured value, transport, local bind result, LAN result, outside result, and relevant log line. The game row must prove a client can enter the world; the query row must prove an external listing or query reaches the intended server; the RCON row must prove an authenticated management connection through its approved private path; the Rust+ row must prove companion pairing without changing companion.id. A single green row never substitutes for another because these endpoints have different purposes and transports.

A service that fails locally points to launch arguments, a bind conflict, incomplete startup, or the service being disabled. A service that works locally but not from another LAN device points toward the host firewall or the address being tested. LAN success with WAN failure shifts attention to router forwarding, upstream NAT, or the ISP. WAN query success with WAN game failure preserves the query rule and narrows the repair to the game endpoint or world readiness.

Set stop conditions before changing ports

Before a port change, export the redacted launch definition and current firewall/router mapping. Make one service-specific change, restart once, and repeat only that service's local, LAN, and outside tests. If the result worsens, restore the saved definition and mapping rather than stacking another speculative change on top. Never use a successful public RCON test as a diagnostic shortcut when it creates an unnecessary management exposure.

• Stop if a proposed value duplicates another required Rust service or conflicts with an existing process on the host.
• Stop widening RCON exposure when authenticated access already works through LAN or VPN; public discovery does not require public RCON.
• Stop rebuilding firewall rules if the process has not reached Server startup complete or the socket is not bound locally.
• Stop changing the server identity, seed, or world size during a network incident; those selectors can create an unrelated fresh-world event.

Keep a network manifest that survives maintenance

Store a redacted manifest with the Rust identity: game, query, RCON, and companion values; their protocols; the reserved LAN address; rule names; router target; and the date/method of the last external test. After an update or router replacement, compare the live launch command and bound sockets to that manifest before opening new ranges. Re-run the four rows after a controlled restart, then close temporary test access. This makes the next browser, join, RCON, or Rust+ complaint traceable to one endpoint instead of an ambiguous block of copied defaults.