Fix: 'Couldn't allocate dedicated server IP port' (Address in Use)

The server refuses to start and prints:

Couldn't allocate dedicated server IP port

The engine could not bind its UDP socket. There are only two real causes: the port is already in use by another process, or the +ip you asked it to bind is not an address the machine actually has. This walks both down, with the commands to find the offending process and the correct way to run several servers on one box.

1. Find what is holding the port

The default is UDP 27015. Check who owns it on Linux:

ss -ulpn | grep 27015

or, if ss is unavailable:

netstat -ulpn | grep 27015

A line here means another process — usually a previous HLDS instance that did not exit cleanly — still holds the socket. On Windows the equivalent is netstat -ano | findstr 27015 to get the PID.

2. Kill the stale instance

If the culprit is an old server that hung, stop it. Take the PID from the previous command:

kill 12345
# if it will not die:
kill -9 12345

This is the most common case after a crash: the process is gone from your view but the kernel still has the socket bound for a moment, or a zombie hlds is genuinely still running. Confirm the port is free — the ss command returns nothing — then start the server. An auto-restart wrapper that does not check for a running instance can also spawn a duplicate; see auto-restart on crash.

3. Check the +ip you passed

The other cause is a bad +ip. The engine can only bind an address that exists on the machine. If your start line says +ip 203.0.113.9 but that IP is not configured on any interface, the bind fails with the same error. List the machine's addresses:

ip addr show

Use an address that appears there, or drop +ip entirely to bind all interfaces. On a VPS with one public IP, omitting +ip is usually correct.

4. Running several servers: give each its own port

Two servers on the same box cannot share a port. Assign each a distinct +port:

./hlds_run -game cstrike +ip 0.0.0.0 +port 27015 +map de_dust2
./hlds_run -game cstrike +ip 0.0.0.0 +port 27016 +map de_inferno

Remember CS 1.6 uses UDP, and the client connects to that exact port. Open each port in the firewall — see server firewall ports — and give each instance its own game directory as described in running multiple servers on one VPS.

5. Handle the restart race cleanly

The most frustrating version of this error appears only intermittently, right after a crash-restart. What happens is that the old process has died but the kernel holds its UDP socket in a brief teardown state, and a restart script that relaunches instantly hits the port before it is released. The fix is to make the restart wait for the port to actually be free rather than firing on a fixed timer. A simple loop that checks the port before starting is enough:

while ss -ulpn | grep -q :27015; do sleep 1; done
./hlds_run -game cstrike +port 27015 +map de_dust2

This waits until nothing holds 27015, then starts, so the allocation never races the release. Build the same check into a systemd unit or a supervisor script and the intermittent version of this error disappears entirely — the guidance in auto-restart on crash covers wiring it into a proper restart loop.

Common errors

• Error after a crash — the previous process still holds the port. Find and kill it, then start.
• Error with a specific +ip — that address is not on the machine. Use one from ip addr or omit +ip.
• Second server fails, first is fine — both use 27015. Give the second a different +port.
• Works once, fails on restart — the restart script relaunches before the old socket releases; add a short wait or an instance check.
• Binds but is unreachable — that is a firewall problem, not this error; the port bound but traffic is blocked.

Verification

Before starting, run ss -ulpn | grep 27015 and confirm nothing is listed — the port is free. Start the server and watch the console reach map load without the allocation error. Then from another machine, confirm the server answers on that UDP port — it appears in the browser or responds to a query. If it starts clean and answers, the socket bound correctly. If the error returns on the next restart, your relaunch is racing the socket release.