Minecraft anticheat guide
Client-Server Sync and Anticheat Accuracy Explained
How client-server state sync affects Minecraft anticheat checks, why ping is not enough, and how to read FairPlay transaction modes and diagnostics.
Short answer: what sync means for anticheat accuracy
Client-server sync is the agreement between what a player's client has applied and what the server believes is true. Anticheats judge movement and combat against the server's view, so when the two drift apart, a check can compare against a state the client never reached. Ping alone does not reveal this. Per FairPlay engineering notes, FairPlay orders checks with acknowledgements that come back from the client.
Why ping does not show whether the client is in sync
Ping measures one round trip. It answers how long a request and its reply took. It does not say whether the client applied the latest entity update, or whether the update arrived in the order the server sent it. Staff often look at ping first because it is easy to see, so it is worth checking the other signals before you blame a player's connection or an anticheat check.
The table below separates the common signals. Each one answers a different question.
| Signal | What it tells you | What it does not tell you |
|---|---|---|
| Round-trip time | How long one request and reply took | Whether the client applied the latest entity update |
| Acknowledgement progress | The client answered the server's ordering probes in sequence | Whether one target's entity tracker matches the server |
| Time since last entity packet | How old the most recent entity packet is | Whether the target's position disagrees with the server (diagnostic only) |
How acknowledgements order server-side checks
When the transaction channel is available, the server sends small ordering probes to the client, and the client echoes each one back. The server advances its logical sequence only as replies arrive. A reply therefore confirms every earlier probe in the same order, which lets later logic rely on a known point in the timeline.
A lost reply does not freeze the sequence forever. A later acknowledgement covers the earlier gap. A probe that expires without a reply does not count as acknowledged, and the sequence does not move for it. This is the main reason an expired probe should never be read as proof that the client was in sync.
Some logic needs a fence, which is a callback that runs once the sequence passes a chosen point. Reach compensation and rewind-style checks depend on this kind of ordering. If the server cannot confirm recent acknowledgements, it should grant no timing leniency, and that is the intended fail-closed behavior described in the engineering notes.
What reconnects do to old sync state
Each reconnect starts a new session epoch. Markers from the old session are ignored when a reply arrives, so a late reply from an earlier connection cannot be matched to a new probe. For admins, this means a reconnect is a clean sync state. Logs and diagnostics restart from the new epoch.
If a problem returns right after a reconnect, the cause is more likely the network path, the client version, or server load. Reconnecting will not fix those.
Which transaction mode your server is using
FairPlay selects one transaction mode at startup. The mode decides who owns the ordering channel, and therefore which signals FairPlay can read. The modes below are described in FairPlay engineering notes and the transactions configuration page.
Mode selection does not fall back from Grim to native automatically. Once Grim is present and its API hook works, FairPlay stays in Grim mode, because an automatic switch could let two plugins write the same packet channel.
| Mode | What it means for your server |
|---|---|
| NATIVE | FairPlay sends and matches its own ordering probes. |
| GRIM | FairPlay reads Grim's transaction stream and does not send its own active probes. |
| DISABLED | Transaction ordering is off, by configuration or by the global switch. |
| GRIM_UNAVAILABLE | Grim is present, but its API hook failed. FairPlay keeps its own probes off to avoid a packet-owner collision. |
| POLAR_CONFLICT | PolarLoader or Polar owns the pong channel. FairPlay does no transaction packet work. |
| VULCAN_CONFLICT | Vulcan is enabled. FairPlay does no transaction packet work, and some transaction-dependent features are unavailable. Flag hooks stay active. |
How to check the mode after installing FairPlay
Run this procedure on staging first, then on production during a low-traffic window. Record the result each time.
grep -F "[FairPlay/Transaction]" logs/latest.logRead diagnostics without overreading them
Diagnostics show counters and stages, and each stage points to a different part of the path. Use the table to narrow the cause before you change any setting.
A healthy session with acknowledged progress proves that the reply channel works and that the server can measure round trips. It does not prove that every target entity tracker is correct.
| Symptom | Check first |
|---|---|
| Probes stay in the prepared stage | The write was not confirmed. Check the send failure count and whether the network thread is blocked. |
| Written, but never seen leaving | The outbound observer is missing, or the packet was filtered before the observer ran. |
| Sent, but no reply | The client stalled, went offline, or uses a protocol version that does not answer the probe. |
| Unmatched reply | A late reply from an older session, or a wire ID collision. |
| Duplicate reply | The network redelivered a reply. The marker was already consumed, so it is safe to ignore. |
| Timeouts | Round-trip delay is high, or server tick load delayed polling. |
Use the right signal for spatial disagreement
Packet age is a diagnostic field only. A large age means an old packet arrived, not that the position is wrong. The clearer signal is the authority reason recorded in trace diagnostics when the client's view of a target and the server's primary box do not overlap. The value to look for is client_server_target_diverged.
Use the target label and authority reason together when you review a trace. Do not use packet age as a stand-in for divergence.
What we have not verified
These notes are written against FairPlay 4.0.7 and later. The public site documents 4.0.5, so behavior on your build may differ. None of the statements on this page is a measured accuracy, latency, or performance result, and runtime behavior is still pending.
In staging, reconnect a test client, confirm that the session resets, and compare the printed mode with the table above. Then run a short combat test while the test client sends normal traffic, and record whether any symptom in the diagnostics table appears.
FAQ
Does a healthy transaction status mean my anticheat is accurate?
No. A healthy status shows that the reply channel works and that round trips can be measured. It does not show that each target's tracker matches the server, and it does not prove that a check flags the right player.
Is ping a useful sync metric?
It is useful as a connection metric, but it measures one round trip. Sync asks whether the client applied and confirmed updates in order, which is a different question.
Should I turn transaction handling off to clear a conflict warning?
Not by default. A conflict mode means another plugin owns the channel. Disabling FairPlay's transaction system changes which checks work, so test that choice in staging before production.
Will a reconnect clear a bad sync state?
A reconnect starts a new session epoch, so old markers stop matching. If the problem returns immediately after reconnecting, look at the network path, the client version, and server load.