Article
Paper's anti-xray: what it protects, and what it will never detect
"I turned on Paper's anti-xray, I'm covered." That is the sentence you read most often, and it rests on a misunderstanding: the built-in anti-xray does not detect anything. It hides. Those are two different jobs, and confusing them leaves a complete blind spot in your moderation.
What Paper's anti-xray actually does
The principle is server-side obfuscation: before sending terrain data to the client, the server replaces or hides certain blocks. The cheating player sees falsified information. One big advantage worth stressing: because everything happens server-side, no mod, texture pack or modified client can undo the protection.
The three engine modes
| Mode | What it does |
|---|---|
| engine-mode: 1 | Replaces the listed blocks with a dummy block (stone, deepslate, netherrack or end_stone depending on the dimension). Only ores entirely surrounded by solid blocks are hidden. This is the lightest mode. |
| engine-mode: 2 | Replaces both the hidden blocks and the replacement blocks with randomly generated ores. Better protection: the fake ores drown the real ones in noise. |
| engine-mode: 3 | Like mode 2, but the randomisation is applied per chunk layer instead of block by block. Cuts network load on join by a factor of about 2 and compresses chunk packets better. |
Where to configure it
On recent Paper versions the setting is per world, in config/paper-world-defaults.yml for the defaults, or in a specific world's paper-world.yml (on older versions it lived in paper.yml):
anticheat:
anti-xray:
enabled: true
engine-mode: 1
max-block-height: 64
update-radius: 2
lava-obscures: false
use-permission: false
hidden-blocks:
- diamond_ore
- deepslate_diamond_ore
- ancient_debris
# ...
replacement-blocks:
- stone
- deepslate
max-block-height— the height above which nothing is hidden any more. No point processing the surface.update-radius— update radius around a modified block.lava-obscures— also hides what is in contact with lava.use-permission— letspaper.antixray.bypassdisable obfuscation for specific players (staff).replacement-blocks— unused inengine-mode: 1.
Turn it on. It is free, built in, effective against the vast majority of opportunistic cheaters, and requires no plugin. Nothing below says otherwise.
The distinction that changes everything: a lock, not a camera
A lock stops people getting in. A camera tells you who tried. Paper's anti-xray is an excellent lock — and there is no camera behind it.
In practice, the built-in anti-xray produces no trace at all: no log, no alert, no name. It cannot tell you that a player attempted anything, let alone who. If somebody gets through — and we are about to see that the official docs describe three ways to do so — they become completely invisible to you.
Several articles claim that "if your diamonds per minute exceed a natural threshold, the system automatically alerts the moderation team". Paper does nothing of the sort. No engine mode counts anything or sends any alert. That feature always comes from a third-party plugin.
The three limits acknowledged by Paper's documentation
These are not outside criticisms: PaperMC documents them itself.
1. Ore exposed to air stays visible
In modes 1, 2 and 3, an ore in contact with air — typically on a cave wall — is not hidden. It is therefore visible to a cheating client just as it is to everyone else.
You can mitigate this in modes 2 and 3 by adding air to hidden-blocks, but the docs warn that it can tank the FPS of all your players, including those who do not cheat. The cure is often worse than the disease.
2. Range extension
Because world generation is deterministic, a client can exploit that regularity to extend what it infers beyond what the server actually sends it.
3. Seed recovery — the fundamental flaw
This is the most serious one. Since the world is generated deterministically from a seed, a client that manages to recover your world's seed knows the real location of every generated ore. Obfuscation then becomes entirely useless: it no longer even needs to look at what the server sends.
Paper's feature-seeds options, combined with the structure seed settings in spigot.yml, make the job harder. But the documentation is explicit: this is not a complete solution, and a client can still get there.
The fourth limit, a structural one
This one appears in no documentation, because it is not a technical defect: anti-xray only protects the future.
The day you enable it, everything that happened before stays out of reach. If a player x-rayed for six months, obfuscation changes nothing about it — your server's economy is already unbalanced, and you still have no way of knowing who is responsible. The only thing that can answer that question is your history.
What that means in practice
The two layers do not replace each other — they complement each other:
| Built-in anti-xray (Paper) | History analysis | |
|---|---|---|
| Role | Prevent | Establish |
| Acts on | What happens after it is enabled | What has already happened |
| Names a player | No, never | Yes |
| If bypassed | No trace at all | The behaviour stays in the logs |
| Cost | Free, built in | Requires history (CoreProtect) and a tool to read it |
The key point is in the second-to-last row: the three documented bypasses above let someone see the ore, but none of them lets them collect it without breaking it. The mining behaviour always ends up in your logs. That is what makes after-the-fact analysis robust exactly where obfuscation gives way.
The logical next step How to detect an x-rayer with CoreProtect: the full method →Key points
- Enable Paper's anti-xray: it is a good first layer, free and impossible to undo client-side.
- But it hides, it does not detect: no log, no alert, no name.
- PaperMC documents three bypasses itself: ore exposed to air, range extension, seed recovery.
- A cheater who gets through leaves no trace on the anti-xray side — only in your block history.
- And none of this says anything about what happened before you turned it on.
Technical details and limits verified against the official PaperMC documentation.
The camera missing behind the lock
TunnelVision works on the other half of the problem: it reads back the CoreProtect history your server already records, rebuilds mining sessions and surfaces the ones whose path has no innocent explanation — including for the period before your anti-xray was enabled. Every session comes with the indicators that explain its score, and the decision stays yours.