Connection failed after 4 retries means the client sent its connection request four times and never got a usable reply. The game found the server in a list (or you typed connect), but the UDP handshake did not complete. This is a reachability or handshake problem, essentially never a "the map is wrong" problem. The whole job is to find where the packets are being dropped.
1. Prove the server is actually listening
On the server host:
ss -lunp | grep 27015
You must see hlds_linux (or hlds.exe) bound to UDP 27015. If it is bound to 127.0.0.1 only, remote clients can never reach it — start with an explicit bind address:
./hlds_run -game cstrike -ip 0.0.0.0 -port 27015 +maxplayers 20 +map de_dust2
If nothing is listening, the server is not running and the retries are expected; fix the server start first.
2. Test UDP reachability from outside
Ping and TCP tools lie here because CS 1.6 is UDP. Query the port from another machine. A raw check with netcat confirms the port is at least reachable:
nc -u -v -w3 YOUR_SERVER_IP 27015
The cleanest external test is to open the server browser on a friend's connection and query by IP. If the server answers a query but the connect still fails after 4 retries, the problem is in the handshake (rate/netchan), not raw reachability — jump to step 5.
3. Firewall on the host
The rule people forget is that both directions of UDP 27015 must pass. On Linux with ufw:
sudo ufw allow 27015/udp sudo ufw status
Also check the provider's firewall/security group — many VPS panels have a separate network-level firewall that ufw cannot see. And check iptables -L -n for a stray DROP rule if you did not set up ufw yourself.
4. Wrong port or sv_lan
If you moved the server off 27015 with -port, clients must use connect IP:PORT with the real port. And on the server, sv_lan 1 makes the engine treat the world as a LAN: it will reject or fail public clients. For an internet server it must be:
sv_lan 0
See the base install guide for the full launch-line context.
5. Rate and netchannel limits rejecting the handshake
If the query works but connect fails, the client's requested rate can fall outside the server's allowed band and the connection is dropped mid-handshake. Sane values in server.cfg:
sv_minrate 5000 sv_maxrate 25000 sv_minupdaterate 30 sv_maxupdaterate 101 sv_max_queries_sec 3 sv_max_queries_window 30
Overly aggressive query-throttle cvars (sv_max_queries_sec set very low) can also drop the initial packet under load. On ReHLDS, an over-strict sv_rehlds_force_dlmax plus a client that cannot negotiate the download size can also stall the join — turn security cvars on one at a time and retest.
6. The 25th Anniversary / steam_legacy split
Since the 2023 25th Anniversary update, protocol changes between the modern client and old server builds cause connect failures that look exactly like this. If only some players fail, ask whether they are on the modern client or the steam_legacy branch, and make sure your engine is a current ReHLDS build that speaks the current protocol.
7. Watch the handshake from the server side
The server console tells you how far each attempt gets. Leave it open while a test client tries to connect:
status developer 1
If you see the client appear and then vanish (a connect line followed by a drop), the packets are arriving and the handshake itself is failing — that is the rate/netchan or protocol case, not a firewall. If nothing at all shows up on the server when the client tries, the request never reached you: firewall, wrong IP/port, or provider-level UDP filtering. That single observation splits the entire problem in half. Turn developer back to 0 afterwards — it is noisy.
Common errors
- Query works, connect fails — rate/netchan mismatch or a query-throttle cvar dropping packets. Widen the rate band.
- Nothing responds at all — firewall (host or provider), server bound to localhost, or wrong port.
- Only some players fail — client protocol split (modern vs
steam_legacy), or their own ISP blocking UDP. - Works on LAN, fails on the internet —
sv_lan 1, or the public UDP port is not forwarded/allowed.
Verification
From a machine on a different network, run:
connect YOUR_SERVER_IP:27015
A successful join that spawns you into the map is the only real proof. If the server still cannot be reached at all after opening the firewall, it may also be missing from the master list for the same UDP reason — cross-check with the same reachability tests, and confirm sv_lan 0 is set and the server can heartbeat outbound.
