---
title: "How to Install dproto on a CS 1.6 Server"
excerpt: "Install dproto to admit non-Steam clients on an original HLDS server, configure it through dproto.cfg, and understand how it differs from Reunion on ReHLDS."
category: "installation"
tags: "dproto, non-steam"
image: ""
read_time: "8 min read"
---
<p>dproto is the classic way to let non-Steam clients onto an <em>original</em> 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 <a href="/tutorials/install-reunion">Reunion</a> instead; dproto is the tool for stock HLDS. This covers a correct install and the honest trade-offs.</p>
<h2>1. Decide whether dproto is the right tool</h2>
<p>Match the tool to your engine:</p>
<ul>
<li><strong>Original HLDS</strong> — use <strong>dproto</strong>.</li>
<li><strong>ReHLDS</strong> — use <strong>Reunion</strong>, which is built for it and more actively maintained.</li>
</ul>
<p>Running dproto means you are deliberately leaving the <a href="/tutorials/install-cs16-steam-only-server">Steam-only</a> model — you gain a larger potential audience and lose the guarantee that every player carries a unique, genuine SteamID. Know that before you install.</p>
<h2>2. Confirm Metamod is running</h2>
<p>dproto is a Metamod plugin, so Metamod must already be installed. Check from the console:</p>
<pre>meta list</pre>
<p>If Metamod is not present, install it first — dproto has nothing to load into otherwise.</p>
<h2>3. Place the dproto files</h2>
<p>Put the dproto binary where Metamod plugins live. On Linux that is the <code>.so</code>; on Windows the <code>.dll</code>:</p>
<pre>cstrike/addons/dproto/dproto_i386.so (Linux)
cstrike/addons/dproto/dproto.dll (Windows)</pre>
<p>The package also ships a <code>dproto.cfg</code>; place it in the game folder where dproto expects it (commonly <code>cstrike/</code>). 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.</p>
<h2>4. Register dproto with Metamod</h2>
<p>Add dproto to <code>addons/metamod/plugins.ini</code> so Metamod loads it. Use the correct platform line:</p>
<pre>linux addons/dproto/dproto_i386.so
; win32 addons/dproto/dproto.dll</pre>
<p>Metamod reads <code>plugins.ini</code> at map load, so a restart or map change is required for dproto to come up.</p>
<h2>5. Configure dproto.cfg</h2>
<p>The behavior that matters most is <em>which client types are admitted</em>. 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:</p>
<pre>sv_lan 0</pre>
<p>Do not paste settings from a random forum config blindly; open the <code>dproto.cfg</code> 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.</p>
<h2>6. Understand the SteamID consequence</h2>
<p>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 <a href="/tutorials/make-server-accept-nonsteam">making a server accept non-Steam</a>. If integrity matters more than headcount, reconsider Steam-only.</p>
<h2>7. How Steam and non-Steam coexist</h2>
<p>The value of dproto over simply disabling validation is that it lets <em>both</em> 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 <code>dproto.cfg</code> 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.</p>
<h2>8. Keep dproto current</h2>
<p>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 <a href="/tutorials/install-reunion">Reunion</a>, which tracks engine changes more closely. Match your non-Steam tool to your engine and keep it patched.</p>
<h2>Troubleshooting</h2>
<ul>
<li><strong>dproto not loading</strong> — the <code>plugins.ini</code> path or platform prefix is wrong. Run <code>meta list</code>; dproto should appear as running.</li>
<li><strong>Non-Steam players still rejected</strong> — the client-type option in <code>dproto.cfg</code> is set to Steam-only, or the config is not being read. Verify the file location.</li>
<li><strong>Server not on the internet list</strong> — <code>sv_lan 1</code>. Set it to <code>0</code>.</li>
<li><strong>Crash on start after adding dproto</strong> — the binary is built for the wrong engine (you are on ReHLDS). Use <a href="/tutorials/install-reunion">Reunion</a> on ReHLDS instead.</li>
</ul>
<h2>Verification</h2>
<p>Run <code>meta list</code> and confirm dproto shows as <code>running</code>. 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 <code>status</code> to inspect the IDs both clients receive. If both client types join and appear in <code>status</code>, dproto is installed and admitting non-Steam players as intended.</p>
