Why anticheats false-ban good players, and how to stop yours

Every server owner who has run an anticheat for more than a month has had the same message in their DMs: "I got banned and I wasn't cheating." Most of the time the player is lying. Some of the time they are not, and that case is far more expensive than it looks.

A missed cheater annoys the players in that one fight. A false ban makes an honest, paying, long-term player feel cheated by the server itself, and they tell people. If you are choosing or tuning an anticheat, the false-positive story matters more than the detection-count story.

Here is where false positives actually come from.

1. Latency, and the fact that the server is always looking at the past

Everything the server knows about a player arrived over the network some milliseconds ago. A player at 40 ms and a player at 400 ms produce genuinely different packet timing for identical behaviour. Any check that measures rate (clicks per second, packets per tick, movement interval) is measuring the network as much as the player.

This is why naive timer and CPS checks are the classic false-ban sources. A player on bad wifi bursts packets after a stall; the raw rate over a one-second window looks like a speedhack. The fix is to measure over a balanced window that can absorb a stall and repay it, rather than flagging the instantaneous spike. If an anticheat's timer check has no concept of debt repayment, it will ban people on hotel wifi.

2. Physics edge cases the model does not know about

Movement checks work by simulating what the player's position should be and comparing. That simulation has to know about every mechanic the server has. Slime blocks. Bubble columns. Elytra with fireworks. Boats on ice. Riptide tridents. A knockback plugin with custom velocity. Vehicles inside moving entities.

Every one of those is a place where the model and reality legitimately diverge, and every one has produced false bans in every anticheat that has ever shipped. The pattern to look for is not "does it handle these" (nobody handles all of them) but "what does it do when the model and reality disagree by a small amount?" A well-built check treats an unexplained divergence as a reason to reset and observe, not as an instant violation.

3. Thresholds tuned on a server that is not yours

This is the big one, and it is rarely stated plainly. An anticheat's default thresholds were tuned against some specific mix of gamemode, plugins, player ping and hardware. If your server is a 0.5-second-combat KitPvP box and the defaults were tuned on survival, they do not transfer. If you run region-based movement plugins, custom knockback, or heavy entity counts, they definitely do not transfer.

An anticheat that ships every check on, at maximum sensitivity, out of the box is optimising for a good first impression, not for your ban list.

4. Mitigation is not just a softer punishment, it is a better signal

The most useful thing an anticheat can do with an uncertain detection is not to ban and not to ignore it, but to quietly break the cheat: set the player back, cancel the illegitimate hit, refuse the placement. An honest player who hit a physics edge case experiences one moment of rubber-banding and moves on. A cheater experiences a client that does not work, keeps trying, and accumulates violations until the case is no longer uncertain.

This is why setback-first designs produce fewer angry DMs than ban-first designs at identical detection rates. You are converting your uncertainty into more evidence instead of into a decision.

How to actually roll one out

The process that works, on any anticheat:

1. Run in alert-only first. Every check, no punishments, for at least a week of real traffic including your peak hours. You are not testing whether it catches cheaters yet.
2. Read every alert on a player you know is legitimate. Staff, long-term regulars, that one builder with 400 ms ping. Each one is a threshold that needs moving or a check that needs turning off for your server.
3. Enable mitigation before bans. Setbacks and cancels for another week. Watch for gameplay complaints that are not about bans: "the elytra feels weird near spawn" is a false positive telling you about itself.
4. Turn on bans per check, not globally. Start with the checks that have produced zero alerts on known-good players. Reach and client detection are usually safe early; movement checks on a server with custom velocity are usually last.
5. Keep experimental checks experimental. A new detection should never be allowed to punish on the day it ships, on anyone's server.

The uncomfortable trade-off

You cannot have zero false positives and zero missed cheaters. Every threshold you loosen to protect an honest player also widens the gap a careful cheater can sit in. Anyone who tells you otherwise is selling something.

What you can do is make the trade-off deliberately, per check, on your own server's data, and make sure the failure mode on your uncertain cases is a setback rather than a ban. That is the difference between an anticheat you can leave running and one you turn off after the third apology.