Rust Server Port Forwarding: Route Traffic by Function

Rust server port forwarding works when each router rule sends the server’s real listener to the right computer using the right protocol. The game and browser-query listeners use UDP; Rust+ is a separate, optional TCP service. Start with the values your running server reports instead of copying a fixed port list. This guide maps the router layer for PC Rust, identifies when an upstream network blocks inbound traffic, and gives you a separate check for joining, discovery, and Rust+. Console Edition uses a different server ecosystem.

Record the listeners Rust is actually using#

Write down the effective values for the game, query, RCON, and companion listeners before opening your router. The numbers printed in an old guide are only useful when your server uses the same configuration.

Listener	Setting or check	Protocol	What it does
Game	server.port; default is 28015	UDP	Carries a player’s game connection
Query	server.queryport; use the configured value	UDP	Lets the server browser query the server
RCON	rcon.port; use the configured value	TCP	Gives an administrator remote console access
Rust+	Run app.info on the server	TCP	Reports the companion service’s active port

Facepunch documents server.queryport as a separate listener. If you leave it unset, Rust derives it as one greater than the larger of the game and RCON ports. That means the result depends on your effective RCON value; do not assume one query port for every installation. The dedicated-server setup reference also says the game port alone is enough for players to join, while the query port is needed for browser visibility.

Check the server’s active identity configuration at rust/server/<identity>/cfg/server.cfg as well as its startup arguments. Facepunch says that file is read at launch and can override command-line settings. A hosting panel may generate or replace configuration, so use its current values and the running server’s output as your confirmation rather than guessing which field wins.

If you’re still choosing an installation route, choose the complete Rust server setup route first. It covers Windows and Linux setup; this guide starts once the server launches locally.

Keep game, browser-query, and Rust+ traffic separate#

Create a mapping for each function you actually use. Game traffic and query traffic are both UDP, but they serve different jobs and may have different port numbers. Rust+ uses its own TCP listener. RCON is for remote administration and is not required for players to join.

Purpose	Forward when	Router protocol	Destination
Game connection	Always for off-network players	UDP	Effective server.port
Server-browser query	You want browser discovery	UDP	Effective server.queryport
Rust+ companion	You use the companion service	TCP	Port reported by app.info
RCON/WebRCON	Not for ordinary player access	Do not expose publicly	Keep administration restricted

Do not copy a search result that lists one fixed “Rust port” for everything. Facepunch’s Rust+ documentation specifies TCP for the companion listener and provides app.info to show the actual port. It also documents app.port=-1 as the way to disable that service. The same page’s default-port formula conflicts with its stated default in the unchanged example, so use the runtime output instead of publishing or forwarding a guessed Rust+ default. See Facepunch’s Rust+ server requirements for the current setting names.

RCON does not need an internet-facing router rule for a friend to play. Facepunch identifies the RCON listener as TCP and warns that WebRCON does not use HTTPS. If you administer the server remotely, use a restricted private route and unique credentials; do not add RCON to a broad range just because a port list includes it.

Check the WAN path and stabilize the server’s LAN address#

Reserve the server computer’s LAN address before making a rule. Otherwise, a router restart or a new DHCP lease can send the same port to another device. Use your router’s DHCP reservation feature when available, and note the address it assigns to the server.

1. Find the current server address

   On the server, check its local IPv4 address, then compare it with the device shown in the router’s connected-client list. Record the exact address you intend to reserve.

2. Reserve that address

   In the router’s DHCP or LAN settings, reserve the address for the server computer’s network adapter. Reconnect or renew the lease if the router asks, then confirm the computer still has the reserved address.

3. Compare the router WAN address

   Read the router’s Internet/WAN address and compare it with the public address seen from that network. If the router has a private WAN address or the two addresses do not match, another router or the ISP may be doing NAT upstream.

A second router you control may need its own matching rule before traffic reaches the inner router. If the upstream device belongs to your ISP, or the WAN path is behind carrier-grade NAT, a rule on your home router cannot create a public path by itself. Stop here and ask the network owner or ISP about a reachable address. The TP-Link port-forwarding overview explains the router fields and why forwarding depends on the WAN connection; menu names vary by model.

This is a quick eligibility check, not a full CGNAT diagnosis. Do not keep adding rules when the public route does not reach your router. Rust server port forwarding cannot solve an upstream address barrier; confirm that layer before you change anything else.

Add only the matching router mappings#

A port-forward rule matches an outside port and protocol to a local device and port. For each required listener, enter the reserved LAN address, the listener’s effective port, and the protocol from the table. If you keep the same outside and inside port, the mapping is easier to compare with Rust’s configuration.

Rule	Outside port	Inside address	Inside port	Protocol
Game	Effective server.port	Reserved server LAN IP	Same game port	UDP
Query	Effective server.queryport	Reserved server LAN IP	Same query port	UDP
Rust+ (optional)	app.info result	Reserved server LAN IP	Same app port	TCP

1. Open the router's port-forwarding page

   Sign in to the router and open its current Port Forwarding, Virtual Server, or NAT rule page. Follow the manual for the router’s exact model; these labels are common examples, not a universal menu path.

2. Create the game mapping

   Add one UDP rule from the chosen outside game port to the reserved server IP and effective server.port. Save it, then verify the rule still shows the same address, port, and protocol.

3. Add query and optional companion rules

   Add a separate UDP rule for server.queryport if you need browser discovery. Add a TCP rule for the app.info value only when Rust+ is enabled. Leave RCON and unrelated ports closed to the public internet.

If your router offers “both” protocols, do not select it by habit. The game and query listeners documented here use UDP, while the Rust+ companion listener uses TCP. Do not forward a wide range such as 28015-28023 unless the software you run actually listens on every port and you have a reason to expose them.

This rule is only the router’s NAT layer. A computer firewall or provider firewall can still block the same traffic, and the server must be listening on the destination port. Keep those checks separate. Facepunch’s setup page covers the server’s settings and connection path; your router’s current manufacturer manual covers the exact controls you see.

Test the game join, browser listing, and companion path independently#

A saved router rule is not proof that the intended Rust feature works. Test from a device outside the home network, such as a friend’s PC or your own laptop connected through a phone hotspot. A second device on the same Wi-Fi may be affected by router hairpin behavior and does not prove that an internet player can reach the server.

1. Test joining by the game listener. Ask an off-LAN PC player to connect to the public address and effective game port. If you are walking them through the Rust console, the command format is connect PUBLIC_IP:GAME_PORT. A successful join shows that this player reached the game service through the path you tested.
2. Test browser discovery separately. Search for the server in the browser after confirming the query rule uses the effective server.queryport over UDP. A direct join can work while discovery fails because the query service is separate.
3. Test Rust+ only if you use it. Confirm app.info reports an active port and that the paired companion app reaches the server from its normal network. Rust+ uses TCP, so do not treat a generic UDP game check as proof of app connectivity.

A website that checks whether a TCP port is open cannot prove that Rust’s UDP game or query traffic works. Likewise, seeing a rule in the router only proves that the rule was saved. If the direct join fails, record whether the player sees a timeout, refusal, version error, or admission rejection before changing another setting. A browser-listing problem after a successful direct join points at a different function than a total connection failure.

If the tests fail, check one layer at a time: effective server listener, router destination, upstream WAN path, then host firewall. Do not disable the firewall or expose RCON as a shortcut. This guide stops at mapping; the separate diagnosis task owns a symptom-by-symptom connection investigation.

Keep the port map current and choose the next troubleshooting step#

Keep a small record of what each rule does. It saves time when the router reboots, the server gets a new address, or another administrator needs to find the right setting.

Keep in the record	Example of what to write
Purpose and protocol	Game — UDP; query — UDP; optional Rust+ — TCP
Effective listener values	Copy the current server and app.info values
Destination	Reserved LAN address and server identity
Router ownership	Device model and who can change its rules
Last external check	Date, test used, and what succeeded

Repeat the checks if you change a port, move the server to another computer, replace a router, or change a Rust+ setting. Remove an old mapping once you confirm that no process needs it. Keep host firewall rules separate from router rules, and troubleshoot the failing connection path instead of reopening every service.

If maintaining an inbound home connection is impractical, we recommend Game Hosting’s Rust PC hosting with provider-side networking, an integrated panel, free backups and DDoS protection. The hosted destination still needs the correct joining configuration. Console Edition cannot join this PC server.

Quick answers

Do Rust game and query traffic use the same port?

No. The game and query listeners are separate UDP endpoints. Players can join through the game port, while the query listener supports server-browser discovery.

Why can friends join by IP while the server is absent from the list?

The game listener may work while the separate query listener or listing path does not. Check the effective query port and its UDP mapping, then test discovery separately.

Does Rust+ need a separate connectivity check?

Yes, if you use the companion service. Check the TCP port reported by app.info and confirm the paired app works from its intended network.