Fix: Players Stuck with STEAM_ID_PENDING

A player connects, but in status their SteamID reads STEAM_ID_PENDING and never resolves to a real STEAM_0:.... Depending on your setup that player either plays with no valid identity (so stats, admin flags and bans keyed to SteamID do not apply) or gets dropped. Pending means the server asked Steam to validate the ticket and has not gotten an answer. This explains why that happens and how to clear it.

1. Know what PENDING means

When a Steam client connects, the server hands the auth ticket to Valve's Steam backend and waits for a verdict. Until the verdict arrives the player is STEAM_ID_PENDING; on success it becomes their real SteamID, on failure they are dropped with a validation error. So persistent pending is almost always the server being unable to reach Steam's auth servers, or the server not being configured to authenticate at all. Confirm the state:

status

Every player parked on STEAM_ID_PENDING points at a server-side auth problem, not a client one — one player pending is a fluke, everyone pending is your server.

2. Check sv_lan

The most common cause on a public server is that it is accidentally in LAN mode:

sv_lan 0

With sv_lan 1 the server does not authenticate against Steam at all — every SteamID stays pending or blank, and the server never appears in the master list either. Set it to 0 in server.cfg for any internet-facing server. This one cvar fixes a surprising share of pending reports.

3. Confirm the box can reach Steam

If sv_lan is correct, the server may be firewalled off from Steam's auth backend. The server needs outbound access to Valve's Steam servers; a locked-down VPS that only opens the game port inbound but blocks outbound to Steam will leave every real Steam client pending. Verify outbound connectivity is not being blocked by the host firewall, and that the box's clock is roughly correct — a badly skewed system clock breaks TLS to Steam and stalls validation. On Linux, check the clock:

timedatectl
# or: date

A clock that is wrong by more than a few minutes will silently break Steam auth.

4. For a non-Steam server, install an emulator

If you run a non-Steam server, real validation against Valve will never complete for non-Steam clients — that is expected, and pending is what you get without an ID emulator. You need Reunion (for ReHLDS) or dproto (for original HLDS) to hand out stable IDs locally instead of waiting on Steam:

• ReHLDS → Reunion. It requires a SteamIdHashSalt of at least 16 characters in its config or it refuses to load, leaving everyone pending.
• Original HLDS → dproto.

With the emulator loaded, non-Steam clients get a deterministic STEAM_0:... derived from their client data, and status shows real IDs. See finding a player's SteamID for how those IDs are formed and why a good salt matters for bans.

5. Rule out a Steam-side outage

Occasionally the whole thing is Valve's fault: during a Steam auth outage every server everywhere shows connecting players as pending until the backend recovers. If sv_lan is 0, outbound connectivity is fine, and it started suddenly across all your servers at once, wait it out — there is no config that fixes a Steam-side outage. Check whether other unrelated servers are affected before you tear your config apart.

Troubleshooting

• Everyone pending, server also not on master list — sv_lan 1. Set it to 0.
• Real Steam clients pending on a VPS — outbound firewall to Steam, or a skewed system clock. Fix connectivity and time sync.
• Non-Steam clients always pending — no ID emulator. Install Reunion (ReHLDS) or dproto (HLDS); give Reunion a 16+ character salt.
• Reunion loaded but still pending — SteamIdHashSalt is missing or under 16 characters, so Reunion refused to load. Check the config and the startup log.
• Started suddenly on every server at once — likely a Steam auth outage. Confirm elsewhere and wait.

Verification

Have a player reconnect and run status on the server. Their line should now show a real STEAM_0:... ID rather than STEAM_ID_PENDING. For a Steam server, confirm the ID matches the player's actual Steam account; for a non-Steam server with Reunion, confirm the same player gets the same ID on every reconnect — stable IDs are what make stats and bans work. If IDs resolve correctly, your auth path is healthy and SteamID-keyed features will behave.