dproto is the classic way to let non-Steam clients onto an original HLDS server. It loads as a Metamod plugin, intercepts the authentication path, and admits clients that do not present a genuine Steam ticket — while still allowing real Steam players. On the ReHLDS engine you would use Reunion instead; dproto is the tool for stock HLDS. This covers a correct install and the honest trade-offs.
1. Decide whether dproto is the right tool
Match the tool to your engine:
- Original HLDS — use dproto.
- ReHLDS — use Reunion, which is built for it and more actively maintained.
Running dproto means you are deliberately leaving the Steam-only model — you gain a larger potential audience and lose the guarantee that every player carries a unique, genuine SteamID. Know that before you install.
2. Confirm Metamod is running
dproto is a Metamod plugin, so Metamod must already be installed. Check from the console:
meta list
If Metamod is not present, install it first — dproto has nothing to load into otherwise.
3. Place the dproto files
Put the dproto binary where Metamod plugins live. On Linux that is the .so; on Windows the .dll:
cstrike/addons/dproto/dproto_i386.so (Linux) cstrike/addons/dproto/dproto.dll (Windows)
The package also ships a dproto.cfg; place it in the game folder where dproto expects it (commonly cstrike/). Keep the config that came with your dproto version — options change between builds and mixing an old config with a new binary causes silent misbehavior.
4. Register dproto with Metamod
Add dproto to addons/metamod/plugins.ini so Metamod loads it. Use the correct platform line:
linux addons/dproto/dproto_i386.so ; win32 addons/dproto/dproto.dll
Metamod reads plugins.ini at map load, so a restart or map change is required for dproto to come up.
5. Configure dproto.cfg
The behavior that matters most is which client types are admitted. dproto.cfg has an option that controls whether the server accepts only Steam clients, only non-Steam, or both — set it to admit both so you keep your Steam players while adding non-Steam ones. Also make sure the server is on the internet list:
sv_lan 0
Do not paste settings from a random forum config blindly; open the dproto.cfg that shipped with your build and read the commented option names, because they differ across dproto versions. The safe default is: accept both client types, leave the ID-generation options at their defaults unless you have a specific reason to change them.
6. Understand the SteamID consequence
Non-Steam clients do not have real Steam tickets, so dproto assigns them IDs by a configurable scheme. Depending on that scheme, non-Steam IDs can be less unique than genuine SteamIDs, which weakens SteamID-based bans and stats — two non-Steam players may end up sharing an ID. This is the core trade-off of any non-Steam patch and is covered from the server-policy side in making a server accept non-Steam. If integrity matters more than headcount, reconsider Steam-only.
7. How Steam and non-Steam coexist
The value of dproto over simply disabling validation is that it lets both populations play together. A genuine Steam client still authenticates against Steam and carries its real ID; a non-Steam client is admitted and given a generated ID. Your admin flags, ban lists and stats then span a mixed audience, which is exactly why the ID-generation scheme matters — you want non-Steam IDs stable enough that a banned player cannot trivially rejoin with a fresh identity. Read the ID options in your dproto.cfg and prefer a scheme that ties the generated ID to something durable about the client rather than one that changes every connection. There is no perfect answer here; a non-Steam ID is inherently weaker than a Steam-verified one, and honest server operators tell their admins to weight bans accordingly.
8. Keep dproto current
Valve's periodic updates — the 25th Anniversary update being the largest — have repeatedly changed the protocol in ways that break older non-Steam patches, causing clients to be rejected or the server to crash on start. If dproto stops admitting clients after a game update, the fix is almost always a newer dproto build compiled against the current protocol, not a config change. Because dproto targets the original HLDS engine specifically, teams running the actively-maintained ReHLDS generally migrate to Reunion, which tracks engine changes more closely. Match your non-Steam tool to your engine and keep it patched.
Troubleshooting
- dproto not loading — the
plugins.inipath or platform prefix is wrong. Runmeta list; dproto should appear as running. - Non-Steam players still rejected — the client-type option in
dproto.cfgis set to Steam-only, or the config is not being read. Verify the file location. - Server not on the internet list —
sv_lan 1. Set it to0. - Crash on start after adding dproto — the binary is built for the wrong engine (you are on ReHLDS). Use Reunion on ReHLDS instead.
Verification
Run meta list and confirm dproto shows as running. Then have a non-Steam client connect — it should join rather than being rejected at authentication — and confirm a genuine Steam client still connects normally. Run status to inspect the IDs both clients receive. If both client types join and appear in status, dproto is installed and admitting non-Steam players as intended.
