If a CS2 dedicated server runs but remote players cannot join, follow one connection attempt from the advertised address to the game log. This guide diagnoses an existing Linux server with direct public-IP access. It does not install CS2 or prescribe current launch flags. Use an account with sudo on Ubuntu 24.04 and a tester connecting from another network.
A server listing, a running process and a successful game join prove different things. Start with the failure you can reproduce: the process exits; everyone times out; one player receives a rejection; or joining works while discovery does not. Record the exact message and the attempt time, including timezone.
Identify the actual process and socket#
On the server, inspect process names without printing full arguments, which may contain credentials:
ps -eo pid,user,comm
sudo ss -lunp
Find the CS2 process and its UDP socket. The ss manual describes the socket and process fields. Write down the PID, listening address and actual port. On a busy VPS, a socket belonging to a different game is easy to mistake for this server.
If the process is absent, inspect the startup log before changing network rules. If your installation uses systemd, substitute its actual unit name in these commands; YOUR_CS2_UNIT is a placeholder:
sudo systemctl status YOUR_CS2_UNIT --no-pager
sudo journalctl -u YOUR_CS2_UNIT -n 100 --no-pager
A process can exist before map loading finishes. Read its own readiness and failure messages. Repeated exits, missing libraries or a map-loading failure belong to startup diagnosis, even if the service manager briefly reports active.
For a direct IPv4 connection, a listener bound only to 127.0.0.1 cannot accept packets addressed to the host's external interface. A 0.0.0.0 listener covers local IPv4 interfaces; it does not publish the server through a provider firewall or NAT. Do not put an address from a router's public side into a bind setting unless that address actually belongs to the server.
Compare the endpoint with the connection path#
Confirm the player uses the VPS's current public address and the port you observed. A private LAN address cannot be used from the public Internet. If you use a hostname, compare its resolved address with the intended host; temporarily testing the verified public IP separates DNS from transport.
For home hosting, compare the router's WAN address with the ISP-provided public address. A forwarding rule on your router cannot create inbound reachability through an upstream NAT you do not control. Ask the ISP about a public inbound-capable address if the WAN side is private or shared.
Test from another network. Connecting from the same LAN to the public address can depend on the router's hairpin NAT behavior; failure there does not establish failure for all Internet players.
This flow applies to direct IP traffic. Valve's Steam Datagram Relay documentation describes a different routing path and FakeIP addresses that are not ordinary Internet endpoints. If your logs and configuration show relay networking, diagnose that path separately; do not treat a failed direct-IP probe as proof the relay is broken.
Check both firewalls without losing SSH#
Review the existing Ubuntu rules:
sudo ufw status verbose
Use the actual UDP game port from ss. The following numbers are an example, not a discovered CS2 default. Replace 27015 if your socket uses another port, and 22 if SSH uses another port:
sudo ufw allow 22/tcp
sudo ufw allow 27015/udp
sudo ufw status numbered
Ubuntu documents UFW's protocol-specific rules. If UFW is currently disabled and you intend to enable it, preserve all other required service rules first. Keep the current SSH session open:
sudo ufw enable
Verify a second SSH connection before closing the first. Also allow the same UDP game port in the provider firewall. For a home server, the router must forward that UDP port to the correct, stable LAN host. A TCP-only rule for the same number does not admit UDP game traffic.
Do not open remote-administration ports globally to fix a player timeout. Do not disable the firewall as a standing configuration.
Observe one bounded join attempt#
If the socket and rules look correct, see whether the tester's packets reach the host. Install the packet tool on the server:
sudo apt update
sudo apt install -y tcpdump
Replace the example game port and documentation-reserved address 198.51.100.24 with the actual port and the tester's public IPv4 address:
sudo tcpdump -ni any -c 30 'udp port 27015 and host 198.51.100.24'
Have the tester attempt one direct join while capture runs. Stop with Ctrl+C if thirty packets never arrive. This command displays packet summaries, without requesting payload dumps or saving a capture file; see the tcpdump manual.
| Observation | What it establishes | Next check |
|---|---|---|
| No matching packets | Nothing matching this filter was observed | Recheck tester IP/filter, destination, provider rules and router/ISP path |
| Incoming packets, no apparent replies | Packets reached an interface; delivery to CS2 is still unproved | Host firewall, matching bind/socket, process health and logs |
| Traffic in both directions, then failure | Some bidirectional UDP traffic exists | Game rejection, version/content mismatch and client log |
| One tester joins, another cannot | The server can admit at least that tester | Compare failing client's route, endpoint and rejection message |
An interface capture can see traffic before a host firewall drops it. Conversely, a wrong filter can hide a real attempt. Treat capture as evidence of one boundary, not a complete connection test. A TCP port checker is also insufficient for this UDP path.
Act on explicit game rejections#
If the server records the player attempt, preserve the rejection message before restarting. Compare client and server releases and the requested map/content. If failure began after an update or plugin change, preserve the current configuration and test a known compatible vanilla configuration on an isolated copy. Repeatedly reinstalling the live server destroys evidence and can overwrite configuration.
If logs identify Steam login or token problems, review the account/token in Steam's server-account management page and the current CS2 dedicated-server documentation. Keep the token out of screenshots and shared logs. Token requirements and launch behavior are version-sensitive; changing a token cannot repair a missing network route.
Once fixed, ask the original failing tester to join again and confirm they reach the map. Keep the working endpoint, relevant rules and exact corrective change in your administration notes.
Send evidence that someone else can use#
A useful support report includes the attempted endpoint, exact error, time/timezone, server build, listener address/port, sanitized startup and rejection logs, and whether the bounded capture showed incoming and outgoing traffic. State whether the test used direct IP or a relay. Redact tokens, passwords and unrelated player data.
This lets a provider investigate an upstream drop while a game administrator investigates an explicit rejection. “The port is open” leaves both guessing.
