A CS2 server can answer a TCP port checker and still be unreachable by players. The checker may have reached an administration socket; the game needs its UDP path. Start with the endpoint your running server actually uses, then trace that specific protocol through the container, host and network edge.
This guide assumes an existing Linux dedicated server that loads a map. For installation, version and admission failures, use the CS2 connection troubleshooting guide. Here the task is narrower: make a deliberate direct-IP endpoint reachable without opening every port in a Steam checklist.
Record what the server actually listens on#
On the Linux machine, inspect interfaces and sockets. These commands require iproute2; process details may require administrative privileges:
ip -br -4 address
sudo ss -lunp
sudo ss -ltnp
Identify the CS2 process and its UDP local address and port. Check the existing launch configuration for -port and any address binding; do not start another instance to test a different value. Maintained LinuxGSM configuration uses 27015 by default, but a second instance or deployment wrapper can change it. Substitute the observed value throughout the examples below.
A loopback-only socket cannot receive a direct connection from another machine. A wildcard IPv4 bind includes local IPv4 interfaces; it does not assign a public address or create a router rule. If the router owns the public address, that address is not an interface on the game machine. Do not bind CS2 to it as a substitute for forwarding.
Separate gameplay, queries and administration#
Treat the endpoint inventory as a service list, rather than a list of numbers to open:
| Function | What to establish | Public access |
|---|---|---|
| Gameplay | Actual UDP game port; commonly 27015 | Intended players |
| Server queries | Query behavior of the deployed server | Browser/query clients if needed |
| RCON | Actual TCP administration endpoint | Private administration route |
| CSTV | Enabled feature and configured spectator endpoint | Only when deliberately used |
Queries and gameplay have different jobs, but that does not imply every installation needs a second fixed query port. Valve's Steamworks interface supports query traffic sharing a UDP game socket. Follow your implementation and observed listeners rather than inventing an extra universal port.
In the maintained joedwards32 CS2 container, the usual game port number is also associated with TCP RCON, and CSTV is disabled by default with a separate configurable port. Those integration defaults are useful references, not proof that every wrapper has identical settings. Keep RCON behind a verified private route such as VPN or SSH access. Opening TCP 27015 to everyone is not a repair for a UDP gameplay timeout.
A client's local port is another role again. Do not forward a broad 27000-range on your server merely because a Steam client article mentions client communication ports.
Write the mapping before changing the router#
For a home machine, an example direct-IP route is:
| Boundary | Example |
|---|---|
| Public endpoint given to players | Your actual public IPv4, UDP 27015 |
| Router mapping target | 192.168.1.60, UDP 27015 |
| Game listener | That machine's configured UDP 27015 |
Reserve the LAN address through DHCP or your existing addressing plan. Select UDP explicitly in the router. Avoid forwarding a range when the deployment needs one game endpoint; document any intentional external/internal port difference.
On a VPS with a directly assigned public address, there may be no home-router forwarding step. Inspect the provider's firewall and, if the provider uses address translation, its documented mapping. The host rule and provider rule are different boundaries.
If the router's WAN address differs from the public address, identify the upstream device or provider arrangement. With two routers you control, both boundaries need a coherent route. With ISP carrier-grade NAT, changing only the inner router cannot establish the public mapping. Ask about a reachable address or choose infrastructure whose inbound UDP route you control. Do not give players instructions to forward your server's port on their routers.
Permit the chosen UDP endpoint, including the container boundary#
If UFW already manages the host, inspect it first:
sudo ufw status verbose
sudo ufw status numbered
For an intentionally public UDP 27015 listener, the protocol-specific example is:
sudo ufw allow 27015/udp
sudo ufw status numbered
Check existing deny rules and the provider filter as well. Preserve administrative access; do not reset the firewall or enable an unfamiliar ruleset remotely. A private group can use appropriate source restrictions instead of a public allowance.
For Docker bridge networking, inspect the running deployment's published ports. This is a fragment for the existing game service, not a replacement Compose file:
ports:
- "27015:27015/udp"
Without the protocol suffix, a Docker port publication defaults to TCP. That mapping would not establish UDP gameplay. Also, Docker's published bridge traffic can bypass UFW's usual INPUT/OUTPUT processing. Verify the effective Docker/provider policy; a UFW status display alone does not establish that an administration port is private. Do not publish RCON publicly while copying a container example.
Prove the outside route with a real player attempt#
Ask someone on another internet connection to try your public endpoint. In the CS2 console, the form is:
connect 203.0.113.20:27015
Replace the documentation address with your real address. A LAN connection tests the local path; reaching your public address from inside your LAN also depends on the router's loopback behavior. Neither replaces an external attempt. A TCP website checker cannot validate this UDP route.
If tcpdump and GNU timeout are installed, observe one agreed attempt on the host:
sudo timeout 20s tcpdump -ni any -nn 'udp port 27015'
This prints packet summaries without saving a capture. It stops after twenty seconds; timeout status 124 can simply mean the observation window ended. Correlate the player's address and attempt time. No matching packets points toward the endpoint, upstream path or capture filter. Incoming packets without replies call for host/container delivery, binding and server-log checks. Bidirectional traffic shows an exchange, not successful entry to the match.
Complete an actual join, then record the working route. If direct joining works but discovery fails, continue with CS2 browser and registration checks; a token or relay-setting change should not substitute for evidence about this direct UDP path. Avoid copying undocumented relay edits from unrelated forum setups.
For your own machines, Nexardo can help organize infrastructure administration alongside the endpoint record. Keep that record specific: public game access, private administration and optional features each have their own purpose and verification.
