Rust+ Cannot Pair with Your Server: Check Companion Connectivity

Rust+ can show your server as offline even while players can join because the companion service has its own TCP listener and registration path. Start by checking the active server’s app.info output, then test the reported companion endpoint separately from the game and WebRCON. This guide follows the evidence without deleting your world or exposing remote administration. It covers PC Rust dedicated servers; Console Edition uses a separate ecosystem and these PC server settings do not apply.

Confirm which Rust+ failure you are seeing#

First separate an initial pairing failure from a server that used to work and now appears offline. Also ask whether every paired player sees the same problem or only one phone, and whether alarms/notifications fail while the server itself remains visible. Those details tell you which part of the path to check.

Do not translate every Rust+ message into “the Rust server is down.” If people still play, note that as a successful test and preserve it. If players also cannot join, start with the broader Rust dedicated-server troubleshooting guide to identify the failed server stage, then return here if the companion path is the only one still failing.

Read the active companion port with app.info#

Run app.info on the currently running server instance. Use its server console or an already secured administration route, and copy the reported app/companion port and address into your incident notes. Facepunch identifies app.info as the way to see which port the companion service is using; do not rely on a port copied from a tutorial or an old forum answer.

app.info

The official Rust+ documentation says the configured app.port must be at least 10000 for Facepunch’s backend to reach it. A changed port takes effect after a server restart. If the value is below that floor, or the server log says the companion connectivity test failed, use the server’s controlling configuration surface to choose a valid, assigned port, restart once, and check app.info again. On a hosted server, ask the provider which app port is allocated before changing startup settings; a guessed port may collide with another service or fail to be reachable.

Do not infer a universal default from the game or RCON port. The Facepunch page describes a default formula but also gives an unchanged example that does not line up with it. The running server’s output is the actionable value. If a panel or startup argument can override the setting, check the effective value after restart rather than trusting a saved form field.

Test the companion TCP route separately#

Rust’s game and browser-query listeners use UDP; the Rust+ companion listener uses TCP. WebRCON also uses TCP but is a different service. A successful game join, a server-list entry or an RCON response therefore cannot prove the Rust+ path works.

Check the exact reported port in the host firewall, provider firewall, router/NAT rule, and server process binding—only the layers that apply to your setup. If you self-host behind a router, forward that TCP port to the server’s current LAN address. If you rent the server, ask the provider to confirm that the reported port is assigned and reachable. Keep RCON private; opening it broadly is not a Rust+ fix.

A test from the same computer or Wi-Fi may not follow the public route used by a phone away from home. Use a device outside the server’s LAN for an external check. Facepunch documents an optional WebSocket connection test to the server address and companion port, but a successful socket handshake proves listener reachability only; finish by confirming that Rust+ itself pairs and updates as expected. For general protocol mapping, see the published Rust server port-forwarding guide.

Check the address the service listens on and announces#

A service can listen on one network interface while Rust+ tries to reach another address. Before editing anything, compare the values shown by app.info with the server’s real public route and the provider’s assigned endpoint. Change one address setting only when the observed value is wrong.

Facepunch documents app.listenip for a more complex setup where the server must listen on a particular network interface. It documents app.publicip for cases where the IP address that the app connects to is incorrect. These values solve different situations; setting both blindly can make the mismatch harder to see. If a hosting panel or container allocates the address, ask the provider to confirm the public endpoint instead of substituting a private bind address.

After correcting a confirmed address mismatch, restart if the way you applied the setting requires it, then run app.info again. Retest from the same outside network that previously failed. If the displayed endpoint is right but the external TCP check still fails, return to the firewall/NAT/provider route rather than changing the server identity or unrelated game ports.

Follow registration errors to the outbound backend#

The direction of the failed connection matters. Your phone reaching the server is inbound TCP; the Rust server reaching Facepunch for companion registration or push notifications is outbound traffic. If startup logs mention registration errors or missing push notifications, verify that the server can reach companion-rust.facepunch.com over the internet.

Facepunch says the server runs an automatic connectivity test and disables Rust+ when that test fails. The log message is:

Rust+ companion server connectivity test failed! Disabling Rust+ features.

Read the surrounding log lines for the supplied details before changing a port. If this message appears, check the documented minimum port and the actual app.info endpoint first, then investigate the failed network direction identified by the log. A disabled Rust+ feature may be the consequence of the test, rather than an unrelated phone-app outage.

Facepunch also documents a limit of 10 connectivity checks per public IPv4 address in 5 minutes. If you operate several instances behind one address, repeated restarts can consume those attempts. Avoid reboot loops: correct a specific value, wait for the current check window if you hit the limit, and then perform one deliberate retest.

Separate a server-side issue from a phone or service-wide problem#

If one paired device fails while another can reach the same server, preserve that difference and check the affected device’s connection, app state and pairing entry. If every paired device fails but the game remains joinable, focus on the companion listener, announced address and server log. If several unrelated servers become unavailable at once, a broader Rust+ or network issue is possible; do not call it a current outage based on an old forum thread.

When available, test from a second independent network, such as switching the phone from Wi-Fi to mobile data. This can reveal a local network restriction, but it is not proof that the server port is correctly configured. Likewise, a server-specific WebSocket check and the phone app answer different questions: the former reaches the listener; the latter validates Rust+ pairing and its features. Record which one succeeded so the next person does not repeat the wrong test.

If the failure followed a host move, a wipe or a restore, compare the old and new endpoints and identity handling before asking everyone to pair again. The Rust server migration checklist covers the wider cutover and its acceptance checks. This page keeps the scope on the companion connection itself.

Protect companion.id and player tokens#

Facepunch identifies companion.id as the Rust+ identity for one server. Keep it with that server and its backups. Do not give it to other people, use someone else’s file, run the same identity on two live servers, change app.id, or delete the file as a first troubleshooting step. Facepunch warns that deletion creates a new identity and the old one cannot be recovered.

Player pairing data is separate. Facepunch’s server-file reference lists player.tokens as the store for player tokens and says deleting it forces players to re-pair. Neither file is a disposable cache to clear when an app displays offline. Protect these files as sensitive server data, especially when sharing logs or preparing a migration test. If a migration does require an isolated rehearsal, do not run a duplicate companion identity alongside production.

If a token or identity file was already removed, stop changing files and establish exactly which active server now owns the identity. Explain the change to players and test one pairing on the intended instance before asking the group to repeat setup. For recovery and migration planning, follow the separate checklist rather than assuming an old identifier can be restored from a screenshot.

Verify one correction before declaring Rust+ fixed#

After one evidence-based change, repeat the same check that failed: read app.info, test the external companion TCP route if that was the problem, and confirm pairing in Rust+ on the device that originally showed offline. If the app works but notifications do not, keep investigating the registration/push path; do not treat one symptom as proof that every companion feature is healthy.

If the direct TCP test fails, keep the server identity intact and return to the address, allocation and firewall layers. If the listener is reachable but the app still cannot pair, capture the exact in-game Rust+ status and log message, redact identifying details, and ask the host or network owner about that assigned endpoint. If only one phone fails, continue with its app/network path. A control-panel “running” state is not an end-to-end Rust+ result.

If you would rather not keep a PC server and home network available, Game Hosting’s Rust PC hosting provides a game-focused settings panel and three free backup slots for planned configuration and recovery. The panel and backups do not prove Rust+ compatibility or TCP reachability, so confirm the assigned companion port and network controls with any provider before relying on the app.

Rust+ should work only after the specific companion path that failed passes a repeat test. Keep the recorded endpoint and identity with the server, and change another layer only if new evidence points there.