Minecraft anticheat guide
How FairPlay Decides When to Cancel a Hitbox Hit
How FairPlay's cone, reach and occlusion hitbox checks decide when to cancel an attack, why unknown results never punish, and what to verify.
How does FairPlay decide to cancel a hit?
FairPlay runs three independent hitbox checks on each attack: cone, reach, and occlusion. Each check returns its own result, either pass, fail, or unknown. Only a confirmed fail cancels the attack packet. An unknown result never cancels and never adds to a player's violation level, because missing data should not turn into punishment.
Per FairPlay engineering notes dated October 2026, this separation is deliberate. A check that cannot read the data it needs reports what it could not establish, and the decision is left open.
| Check | Fail means | Unknown means | Cancels the attack? |
|---|---|---|---|
| Cone | The target was outside the measured view cone. | Rotation or target data was unreliable or missing. | Only on a confirmed fail |
| Reach | The target box was beyond the allowed distance. | History or client view was not available. | Only on a confirmed fail |
| Occlusion | A confirmed block or cobweb stood between attacker and target. | Block captures were missing or still loading. | Only on a confirmed fail |
Why does an unknown result never cancel?
Most unknown results come from ordinary conditions. A chunk may not be captured yet, a movement packet may arrive late, or a client view may not be established. Treating any of these as a violation would punish players for server lag and sync gaps.
When occlusion cannot read a block, it queues a repair request for that area and reports unknown. The repair fills the cache so later attacks can get a definitive answer. The repair is not a violation and does not change the verdict on the attack that triggered it.
Which block data does occlusion trust?
Occlusion has two authority modes for block data. In the default Bukkit mode, the entity check uses fresh snapshots captured from the server's own world by the region that owns each chunk. Packet-derived geometry is used only as a narrow fallback, and only for a full-cube blocker that has been verified. In packet mode, the check keeps the older packet-world resolver, which reads block changes from the packet stream.
Bukkit mode gives up some reuse. Entity positive-cache reuse and rotation-based compensation are turned off, because their cache keys do not bind a fixed set of block revisions. A result that packet mode would pass with compensation can therefore come back as a fail or unknown in Bukkit mode. Compare both modes on recorded attacks in staging before you change the setting.
How are client view and server rewind weighed?
A player target can be judged from two sources: the position the client last showed, or the server's own movement history. When a usable client packet exists, it is definitive for both pass and fail. If the client box and the server box disagree, FairPlay keeps the client view as the authority and records the distance between them in diagnostics. It does not drop to a weaker check.
A server rewind on its own is pass-only. When rewind is the only source, the cone check can pass a hit but cannot fail one, and it returns unknown when it cannot establish a valid pass. The attacker is never rewound. The attacker is evaluated at the current server time, so a stale attacker position cannot excuse a hit.
How are movement-dependent cases handled?
Some occlusion failures depend on attacker movement that arrives just after the swing. For these, FairPlay can hold the attack as unknown for a short, bounded window and finish the decision once the movement is known. The held attack is not dispatched as an immediate fail.
The window cannot renew itself. Later world changes, teleports, or late movement cannot retroactively cancel a hit that was already sent. If the deferred evaluation does not confirm the original result, the decision made at attack time stands.
What should server owners verify?
What is not verified yet?
These are engineering notes, not a public benchmark. They do not state a false-positive rate or a detection accuracy figure, and this article does not give one. Runtime behavior on live servers is still pending, and the notes list live capture as the next evidence step.
Read the behavior here as the design intent FairPlay's source documents, not as a guarantee for every server, version, or client.
FAQ
Does an unknown hit get cancelled?
No. Unknown does not cancel the attack and does not add violation level. It means the check could not establish a fail, so FairPlay queues any needed repair and can decide later attacks with the new data.
Do punishment settings stop cancellation of confirmed occlusion fails?
No. Per the engineering notes, a confirmed occlusion fail cancels its attack packet independently of punishment handling, thresholds, alerts, and webhook cooldowns. Punishment settings control what happens to the player afterward.
Which block authority mode should I pick?
Bukkit is the default and packet mode is the compatibility path. Pick one by replaying recorded attacks on staging and comparing fails and unknowns. The notes do not say either mode is more accurate.
Why can a server rewind pass a hit but never fail one?
A rewind is an estimate of where the target was. It is less certain than the client's own view, so the notes restrict it to passes. A rewind that cannot confirm a clear result stays unknown.