When a client is rejected with This server is using a different protocol (or the older Server uses different protocol), you are looking at the split between engine protocol 47 and protocol 48. Steam CS 1.6 and current builds speak protocol 48. A population of older non-Steam clients — and some very old builds — still speak protocol 47. A server that only accepts one turns the other away at handshake, before authentication even happens.
1. Confirm it is really a protocol split
The giveaway is that the rejection is selective: some players connect fine, a specific group (usually running an older non-Steam build) cannot, and the message is specifically about protocol — not STEAM validation rejected (that is an auth problem, see non-Steam players can't join) and not a version/consistency kick. If everyone is rejected, it is not this — check your engine and sv_lan first.
The two protocols map cleanly onto two eras of the client:
| Protocol | Who speaks it |
|---|---|
| 48 | Steam CS 1.6 and current builds (the modern default) |
| 47 | Older builds and a slice of older non-Steam clients |
A stock server is built to answer one, so whichever group does not match is turned away at the handshake. The engine decides this before Metamod, AMXX or any auth layer runs, which is why no plugin can rescue it — the fix has to sit at the same low level.
2. The clean answer: accept both protocols
On original HLDS, dproto is the component that lets a single server answer both protocol 47 and protocol 48 handshakes, so old and new clients coexist. Install it per the dproto guide, then enable dual-protocol handling in dproto.cfg. The relevant options control whether the server responds to protocol 47 clients in addition to 48; read the config file that ships with your dproto build for the exact key names, because they have changed between releases and setting a key that does not exist is a silent no-op.
The principle to get right: you want the server to answer both, not to force everyone onto one. Forcing protocol 47 to modernise the old clients, or forcing 48 to shut them out, both cost you players.
3. On ReHLDS, prefer Reunion
If you run ReHLDS, you should be using Reunion rather than dproto for the non-Steam and client-type handling. Reunion, kept current by the same organisation as ReHLDS, is maintained against the modern client landscape and handles the client variety you actually see today. Do not stack dproto on top of ReHLDS+Reunion — pick one auth/protocol layer.
4. The client side
Half of these reports are really "this player has an ancient client". If a single user cannot connect while an entire modern lobby can, the pragmatic fix is on their end: update their CS 1.6 to a current build, which speaks protocol 48. You cannot bend the whole server around one stale install, and after the 25th Anniversary update the gap between very old builds and current ones widened further.
Weigh the two audiences honestly before you decide. If your player base is largely modern Steam and non-Steam clients, accepting protocol 48 only and asking the rare straggler to update is the low-maintenance choice. If you deliberately court the older non-Steam population — common on servers in regions where that client is still dominant — then dual-protocol via dproto is worth the setup, because those players are a real slice of your traffic, not an edge case. There is no universally correct answer; there is the answer that matches who actually plays on your server.
Common errors
- You "fixed" it by forcing protocol 47 — now modern Steam clients are the ones rejected. Answer both instead of forcing one.
- Edited
dproto.cfgbut nothing changed — either the key name is wrong for your dproto version (check the shipped config), or dproto is not actually loaded. Confirm it is active before blaming the setting. - dproto and Reunion both installed — remove one. Two protocol/auth layers conflict and produce exactly these intermittent rejections.
- Message is about version, not protocol —
Server is enforcing consistencyor a build-version kick is a different issue; see map-change and consistency problems.
Verification
Test with two clients: one current Steam build (protocol 48) and one older non-Steam build (protocol 47). Both should reach the server and spawn. In the server console, status should list both without either being dropped at handshake. Watch Log/errors-*.log during the test — no protocol-rejection lines means the server is now answering both handshakes. If only one client type connects, you have forced a single protocol; revisit the dproto config so it responds to both.
