dproto vs Reunion: Which One in 2026?

Both dproto and Reunion do the same job — let a CS 1.6 server accept non-Steam clients and hand every player a usable SteamID — but they target different engines and are not interchangeable. Running the wrong one for your engine is the single most common non-Steam setup mistake. This lays out the differences and gives a clear recommendation for 2026.

1. The one rule that decides it: your engine

• ReHLDS → Reunion. Reunion is written for ReHLDS and hooks engine functions ReHLDS exposes cleanly.
• Original Valve HLDS → dproto. dproto predates ReHLDS and works on the stock engine.

Install Reunion on plain HLDS and it refuses to load or misbehaves; install dproto on ReHLDS and it may load but reject clients unpredictably. So the real question is not "dproto or Reunion" — it is "which engine am I on," and that answer picks the tool. Check with rehlds_version: a real version means ReHLDS and Reunion; Unknown command means stock HLDS and dproto.

2. Side by side

3. SteamID handling

Both generate a STEAM_ id for non-Steam players and pass real Steam ids through. The difference is configuration discipline. Reunion forces the decision on you: no SteamIdHashSalt of 16+ characters and it will not start, which is annoying once but guarantees stable, salted ids. dproto is more permissive — it starts without a salt — but its id-generation mode still has to be chosen deliberately or you get name-based collisions. In both, the golden rule is identical: pick your id source once and never change it, or every non-Steam player's admin access, stats and bans reset. Wrong-id symptoms are covered in wrong SteamIDs.

4. Protocol 47 and 48

Neither forces you to choose between old and new clients. Both answer protocol 48 (Steam and current non-Steam) and protocol 47 (older non-Steam) on the same port, so your audience is not split by client build. When a specific client is bounced, it is a protocol configuration issue in either tool, not a reason to switch products.

5. Why Reunion wins in 2026

The honest recommendation for a new server is ReHLDS + Reunion. ReHLDS is faster and actively maintained, Reunion is developed alongside it, and the pair behaves better with current AMX Mod X than dproto on the old engine. If you are standing up a server today, install ReHLDS, then Reunion, and you are on the maintained path with security fixes still landing. dproto remains the correct answer for one situation only: you are committed to running stock Valve HLDS and cannot migrate. It still works, it is stable, and it accepts non-Steam clients — but it is a legacy choice, not a forward-looking one.

6. Do not run both

Whichever you pick, run exactly one. dproto and Reunion both hook the connection handshake, and loading them together makes them fight over the same clients, producing random rejections that look like a dozen other problems. If you migrate from HLDS to ReHLDS, remove dproto from addons/metamod/plugins.ini entirely before adding Reunion — do not leave it commented-in "just in case." Confirm with meta list that only one non-Steam provider is loaded.

Common errors

• Chose a tool by reputation, not engine — the engine decides. ReHLDS uses Reunion, HLDS uses dproto.
• Both loaded at once — clients rejected unpredictably. Remove one from plugins.ini.
• Reunion will not start — missing or short SteamIdHashSalt. dproto has no such requirement, which trips people migrating between the two.
• Switched tools and lost every admin — the two derive ids differently, so migrating changes non-Steam ids. Re-map admin entries to the new ids.
• dproto on ReHLDS "sort of works" — it will bite you later. Move to Reunion.

Verification

Run rehlds_version to confirm your engine, then meta list to confirm exactly one provider — Reunion on ReHLDS or dproto on HLDS — is loaded and running. Connect one Steam and one non-Steam client and check status: both should join and hold a stable id. If that works with a single provider on the matching engine, you are on the right tool and can stop second-guessing the choice.