How to Fix "Flying Is Not Enabled on This Server"

Flying is not enabled on this server is the server's built-in flight check firing, not an accusation that you were cheating. By default the server runs with allow-flight=false, which tells it to kick any Survival or Adventure player whose feet leave the ground for too long — the Minecraft Wiki puts the threshold at roughly five seconds airborne. Most of the time you weren't flying at all; lag, a low frame rate, or a shaky connection delayed your movement packets just long enough that the server thought you were hovering. As a player you can usually clear it by relogging and trimming lag, and if you run the server, one line in server.properties stops the false kicks for good.

What the kick actually means

The server is constantly checking where every non-Creative player is, and one of those checks asks a simple question: is this person off the ground with no legitimate reason to be? With allow-flight=false — the default — a yes that lasts long enough ends in a disconnect with that exact message. It's a movement guard baked into vanilla, Spigot, and Paper alike, and it behaves the same across current versions, so there's no patch note or version number to chase here.

The wording is the misleading part. "Flying" sounds like the server caught you with a hacked client, and occasionally it has, but far more often the check is wrong. A laggy connection that delays your position updates looks identical to floating from the server's point of view. So do plenty of perfectly normal things: gliding with an elytra (especially when a firework boosts you or the server stutters mid-flight), bouncing off a slime block, getting launched by an ender pearl or strong knockback, a long fall, or a horse or boat jump landing oddly. Any of those can put air under you for a beat longer than the check tolerates, and out you go.

In Creative mode none of this applies — the check ignores Creative players entirely, which is why you can fly freely there regardless of the setting. It only ever governs Survival and Adventure.

Player-side: work it in order

You can't change the server's settings from your seat, so your job is to rule out the cheap, common causes and stop feeding the check false positives. Go in this order.

1. Reconnect first

The kick is very often a one-off. A single dropped packet or a momentary spike trips it, and the moment you rejoin everything is fine. Hit the server again before you assume anything is actually wrong — this clears it more often than any other step, and it costs you ten seconds.

2. Cut your lag

If it keeps happening, the usual culprit is lag on your end delaying the movement updates the server relies on. Lowering your render distance is the single biggest lever; close the background apps and browser tabs eating your bandwidth and CPU, and if you're on Wi-Fi, a wired connection removes a whole category of stutter. Check your ping in the tab-list once you're in — a number that's all over the place is the thing tripping the check. This is the same housekeeping that fixes most rubber-banding, and the owner's side of that story is covered in stopping lag spikes on a multiplayer server if you want to point a server admin at it.

3. Avoid the move that triggers it

If the kick lands every time you do one specific thing — fire off the elytra over spawn, hit a particular slime-block launcher, pearl across a ravine — that motion is what the check is catching. Dismount the elytra near the ground, take the launcher more gently, or route around the spot until you're back somewhere stable. It's a workaround rather than a cure, but on a server you don't control it's often all you've got, and a quick word to the staff about where it happens helps them fix the real cause.

A genuinely hacked-flight client will also get caught here, which is the check doing its actual job — but if you're a normal player seeing this after a pearl throw or a laggy glide, you're looking at a false positive, not a ban.

Owner-side: the one-line fix and the better one

If you run the server and legitimate players keep getting bounced, the direct fix lives in server.properties. Open it, find allow-flight=false, change it to allow-flight=true, save, and restart the server — the change won't take until a restart or reload. If the line isn't there at all, add allow-flight=true on its own row at the bottom and restart.

The thing nobody tells you clearly: allow-flight=true does not let players fly, and it does not turn on cheating. All it does is switch off the blunt vanilla flight check and hand that judgment to your plugins, mods, and Creative mode. A player still needs an elytra, a mod or jetpack, a /fly permission from an Essentials-style plugin, or /gamemode creative to leave the ground. You're not opening the floodgates; you're telling the server to stop kicking people for movement it doesn't understand.

Fix the cause before you reach for the switch

Flipping allow-flight is the right call when real flight on your server — elytra routes, jetpacks, mod movement — keeps getting eaten. But if players are kicked while just walking around, that's a symptom of server lag, and the switch only hides it. A server holding a steady 20 TPS almost never false-flags flight, so the real fix is keeping TPS healthy: lower view-distance and simulation-distance so the server isn't drowning in chunk work, and trim whatever's dragging the tick. A lean, well-chosen plugin set helps more than people expect, and the must-have Paper plugins for a new server leans toward the lightweight end on purpose.

If a dedicated anti-cheat plugin is the one doing the kicking — NoCheatPlus, AntiCheatReloaded, Vulcan, Spartan, Grim, Matrix, and the like — don't gut the vanilla check and call it done. A proper anti-cheat already understands elytra, vehicles, pistons, and slime blocks, so the move is to tune or exempt its fly check for the spot or the players it's misfiring on, not to disable everything. Pair that with a tidy /fly permission setup — LuckPerms makes that exemption a one-line grant — and you keep the protection while killing the false kicks.

A couple of related checks worth knowing

The flight check has cousins that fire on the same laggy, fast movement and can look related even though they're separate. In spigot.yml, moved-too-quickly-multiplier (default 10.0) caps how far a player may move per packet, and moved-wrongly-threshold (default 0.0625) limits how far off a single move can land. When those trip you'll see console warnings along the lines of moved too quickly! or moved wrongly! and the server simply rejects the move — they don't produce the flying kick, but they spring from the same lag, so a server that's false-flagging flight is often spamming these too. Fix the TPS and most of them quiet down together.

FAQ

Why do I get kicked for flying in my own singleplayer world?

Because opening a world with Open to LAN without ticking Allow Cheats runs it as a small server with allow-flight effectively off, so it applies the same check to you. Press Esc, choose Open to LAN, switch Allow Cheats on, and start the LAN world — flight and commands both work after that. The setting resets when you reload the world, so you'll re-enable it next session.

Will setting allow-flight=true let hackers fly around my server?

It removes the vanilla guard, so on its own it does make a flight hack harder to catch — but that guard was never real protection, just a tripwire that hit honest players as often as cheaters. The actual defense is an anti-cheat plugin that understands legitimate movement plus a server holding 20 TPS. Run those and turn allow-flight on, and you lose nothing real while your elytra and /fly users stop getting bounced.

I edited server.properties but the kicks didn't stop — what's wrong?

Two usual reasons. First, the file only reloads on restart, so if you saved while the server was running, the old value is still live until you restart it. Second, on a hosted panel make sure you edited the active config and that a separate flight setting in the panel UI isn't overriding the file. And if the kick message is coming from an anti-cheat plugin rather than vanilla, allow-flight won't touch it — that one's tuned in the plugin's own config.

Does any of this change between version 26.1 and 26.2?

No. The allow-flight property and the airborne check work the same on the 26.1 stable line and on 26.2, so there's no version-specific step here. If you're picking which build to run a plugin server on, that's a separate decision — the listings split cleanly at /servers/version/26.1 and /servers/version/26.2 — but the flight fix is identical either way.