Fix: 'Reliable channel overflowed' Disconnects

Reliable channel overflowed is the engine dropping a client because it queued more reliable network data for that player than the netchannel buffer can hold in one burst. Reliable messages are the ones the engine must deliver in order and cannot discard — HUD messages, menus, entity spawns, sounds triggered via reliable messages. When something floods a player with reliable data faster than it drains, the buffer bursts and that player is disconnected. It is a symptom of a plugin or a map event, not a bandwidth ceiling you can simply raise away.

1. Recognise the pattern

Overflow that hits one player at a time, often right at spawn or on a specific event, points at reliable-message spam aimed at that player. Overflow that hits everyone at map start points at a mass precache/entity burst or a plugin blasting messages to all clients in one frame. The console line names the affected client, and the timing tells you the trigger.

2. The usual causes

• HUD/DHUD spam — a plugin writing many message_begin/show_hudmessage updates per second to a player.
• Giant menus — a menu rebuilt and re-sent every frame, or a very long motd/menu pushed at connect.
• Mass entity creation — a plugin spawning many entities at once (effects, decals, temp entities sent reliably).
• Advert/announcement plugins firing several long chat lines simultaneously to every player.
• Broken loops — a plugin bug re-sending the same reliable message in a tight set_task or per-frame hook.

3. Give the netchannel more room (a little)

Higher client rates let the buffer drain faster, which can absorb a marginal burst. In server.cfg:

sv_maxrate 25000
sv_minrate 8000
sv_maxupdaterate 101
sv_minupdaterate 30

On ReHLDS there are additional netchannel controls, but do not treat rate as the fix — if a plugin sends unbounded reliable data, no rate value saves you. Raising rates only buys headroom for a legitimately busy but bounded server.

4. Find the offending plugin

Overflow that started after you added or changed a plugin is your prime suspect. Bisect with the standard method:

amxx pause somepluginname
// or disable half the plugins.ini list, restart, retest

See how to find which plugin is at fault for the halving technique. Watch which player overflows and when — a plugin that acts on spawn, on connect, or on a specific weapon/event narrows it fast.

5. Fix the plugin behaviour

The real fix is in the plugin: rate-limit HUD updates to a few per second instead of every frame, send menus once instead of rebuilding them continuously, and prefer unreliable temp-entity messages (MSG_BROADCAST/MSG_PVS) for cosmetic effects that do not have to arrive. If it is a plugin you did not write and cannot edit, replace it with one that behaves. Our own HUD/info plugins are written to stay inside the buffer — see the server adverts plugin for an advert system that paces its messages instead of dumping them.

6. When it is the map or entity count, not a plugin

A map that spawns a very large number of entities, or floods clients at load with a huge motd/overview, can overflow the reliable channel on join before any plugin runs. If overflow reproduces with every AMXX plugin paused and only on certain maps, the map is the source — you cannot rate-limit that away, only avoid or replace the map. On ReHLDS the log line naming the overflowing client is more precise, which makes it easier to tell a per-player plugin flood from a map-wide one.

Common errors

• One player overflows at spawn every round — a spawn HUD or a per-player message loop. Rate-limit it.
• Everyone overflows at map start — a mass precache/entity burst or an advert plugin firing all lines at once on map load.
• Overflow only for high-latency players — their channel drains slowly, so a burst that fine connections absorb overflows theirs. The plugin is still the root cause.
• Started right after a config change — you enabled a chattier HUD or lowered sv_maxrate. Revert and confirm.

Verification

Reproduce the exact trigger — the map, the round moment, or the player action that caused it — with the suspect plugin paused, and confirm the disconnect no longer happens:

status

Watch the player through the moment that used to drop them. A clean pass with the plugin disabled proves the diagnosis; then re-enable a fixed or replacement version and repeat. If disconnects continue with all AMXX plugins paused, the trigger is the map or the engine, and you should test on a stock map to separate the two.