How to Fix Chunks Not Loading on a Minecraft Server

Chunks failing to load is really two separate problems, and fixing the wrong one wastes an afternoon: either your client isn't drawing terrain the server already sent — render distance too low, a network stall, a GPU or mod hiccup — or the server can't keep up and is sending terrain late because its tick rate has dropped and chunk work is falling behind. Before you touch a config value, work out which side you're on. The order that saves time: rule out a version-mismatch kick, decide whether it's the client or the server, check the server's TPS, and only then tune distances, pre-generate, or upgrade the box. That last chain is the same investigation behind server TPS and lag spikes, so the two guides overlap once you've narrowed it to the host.

First, make sure it's actually a chunk problem

A connect-time kick is not a chunk problem, and people chase the wrong thing here constantly. If you get bounced before the world even draws with Outdated client! or Outdated server!, that's a protocol gap between your version and the server's, not terrain failing to load. Outdated client! means your side is behind and needs to update to match the server; Outdated server! is the one you usually see right after you update the game, because now the server is the one stuck on the older protocol. If that kick is your actual problem, the Outdated client / Outdated server fix walks through matching versions. Sort it out against the server's listed version before assuming anything about chunks — most plugin servers sit on the stable 26.1 target, with Paper's 26.2 "Chaos Cubed" builds still flagged experimental. Filter the 26.1 or 26.2 servers directly if you're not sure which one you're running.

Once you're in the world and seeing black voids, missing terrain at the edge of view, or a hang on Loading terrain..., that's a genuine chunk-loading symptom and the split below applies.

Is it you or the server? The one test that splits it

Open the F3 debug screen and watch the C: line, which shows client versus server chunk counts. The cleaner real-world signal, though, is whether everyone is affected. If you're the only one walking into black voids while other players see a full landscape, the terrain reached the server and got sent fine — the failure is on your machine. If the whole server is outrunning the terrain at once, it's the host.

That one question — me or everyone — decides which half of this guide you read, and getting it right stops you editing server.properties for a problem that lives in your graphics driver.

Player-side: terrain that's there but you can't see it

These are the fixes when the server is healthy and other players are fine.

Render distance set too low

Options > Video Settings > Render Distance is a client video setting, and on Java multiplayer it runs 3 to 32 chunks. Set it to 4 and you'll see four chunks and a wall of nothing past that — exactly like a loading failure, but it's just the slider, so raise it. The one catch worth knowing: the client can never see farther than the server's own view-distance. If the server is sending 8 chunks and you crank your slider to 32, you still get 8, so raising it past the server's ceiling does nothing.

A network stall mid-stream

Chunks are streamed as you move, so a lossy or stalled connection leaves holes — black chunks where packets dropped, or a hang on Loading terrain... on join. The cheapest fix is to relog, which restarts the chunk stream clean; lowering render distance helps too, since there's less data to push across a shaky line. Paper caps delivery at player-max-chunk-send-rate (75 chunks per second per player by default), so a congested connection can't catch up until it settles.

The client got the chunks but won't draw them

Sometimes the data arrived and your GPU just isn't drawing it — you're standing in a void the server thinks is full. Force a redraw with F3+A, which reloads chunks without rejoining. If that clears it only intermittently, update your GPU drivers and test with rendering mods disabled — Sodium and similar have shipped Loading terrain hang bugs before, so if the void only appears with one modpack, that's your answer. It's a client-performance issue, the same family as low FPS that only happens on servers.

Stuck on "Loading terrain" then disconnected

This has several roots: the client can't finish the initial chunk load before the login timeout, a corrupt spawn chunk, or genuine server overload. Work it as a symptom — relog, drop render distance to lighten the first load, update Java, and try vanilla with no mods. If a plain vanilla client loads in fine, a mod was the cause.

Server-side: the terrain is being sent late

If the whole server outruns its terrain, the root cause is almost always tick rate, and you diagnose before you tune.

Check TPS first

A healthy server runs 20 TPS — every tick finished in under 50 ms, which is your MSPT (milliseconds per tick). When MSPT climbs past 50, the server can't finish each tick on time, and chunk loading, sending, and generation all slip behind. Players walk into terrain that hasn't been sent yet, and it renders as black or void.

Run /tps for the built-in Paper/Spigot reading, then reach for spark — the tool that tells you why. /spark tps and /spark health give the numbers, and a profile captures the spikes:

/spark profiler start --only-ticks-over 300 --timeout 300

Read the report. High time in the chunk or ServerChunkCache system points straight at a chunk-loading bottleneck. High entity or plugin time means something else is eating the ticks and chunks are just collateral — check /paper mobcaps and /paper playermobcaps if mobs look like the culprit. Fix the actual TPS drain — a laggy farm, a heavy plugin, a mob pile-up — and chunk loading recovers on its own. Your headroom comes down to allocation, and how much RAM a 20-player server needs covers sizing it so the box isn't starved before it starts.

Get view-distance and simulation-distance right

These two keys in server.properties get conflated constantly, and they do different jobs:

• view-distance is how far the server sends terrain, as a radius in chunks. It's what governs visibility. Default is 10.
• simulation-distance is how far the server ticks things — mob spawning, crop growth, redstone driving hoppers and pistons, entity movement. Beyond it, those systems pause. Default is 10, and it's the heavier of the two on CPU.

Both are radius, not diameter, and that's where the cost hides. Each player loads a square of (2r+1)² chunks, so view-distance=10 is 21×21 — 441 chunks per player. Multiply that across a full server and a high value floods RAM and CPU and slows loading for everyone. On a modest host, drop view-distance to 6–8.

But the opposite mistake produces an identical-looking symptom: set view-distance too low and players hit a wall of missing chunks at the edge because the server simply never sends them. Same black void, opposite fix — here you raise it. The way to tell them apart is load: if lowering the value smooths everything out, you were overloaded; if the void sits at a fixed short range while TPS is healthy, you were sending too little. Keep simulation-distance equal to or below view-distance, since ticking is the expensive part — a common pairing is view-distance=8, simulation-distance=4. Setting simulation above view just wastes work on entities you can't even see.

Disk, hardware, and new terrain

Chunks are read from disk, so an SSD versus an HDD genuinely shows up in load times; sync-chunk-writes=true is the safe-but-slower I/O setting. An oversold shared host, thin RAM, or a weak CPU can't keep up no matter how you tune the keys.

The worst case is exploration. Generating brand-new chunks at the frontier is far heavier than loading ones that already exist, which is why lag is nastiest where players are pushing into fresh terrain. The fix is to pre-generate with the Chunky plugin — run a 5k–10k radius from spawn before you open the doors — so players load existing chunks instead of forcing the server to build them on the spot. Paper generates asynchronously through chunk-system.worker-threads, but an already-overloaded server still generates slowly, so pre-gen plus fixing TPS is what holds up under a crowd.

FAQ

My render distance is at 32 but I still see a wall of terrain — why?

Open F3 and compare the chunk counts on the C: line. If the server number is lower than your slider, the server's view-distance is the ceiling and your slider above it does nothing — only the owner can raise view-distance in server.properties. Your client slider only ever matters when it's set below the server's value.

What's the difference between view-distance and simulation-distance if I just want chunks to load?

view-distance is the one — it controls how far terrain gets sent. simulation-distance won't make distant chunks appear at all; it only sets how far the server keeps ticking. The telling case is a high view with a low simulation: you can see a distant field, but its crops never grow until you walk closer. Set simulation equal to or below view so you're not ticking entities past where players can reach them.

Spark says most tick time is in entities, not chunks — is that still why chunks lag?

Yes, and it's the most useful thing spark tells you. Chunk loading doesn't get its own time slice — it competes for each tick. If entities or a heavy plugin are eating ticks, the server blows past 50 ms MSPT and chunk sending falls behind, even though "chunks" isn't the top line of the profile. Fix what's consuming the tick — clear the laggy farm, cap the mobs, pull the offending plugin — and chunk loading recovers without you touching view-distance.

Chunks only fail to load when I explore into new areas — what fixes that specifically?

That's terrain generation, not loading, and it's much heavier — existing chunks get read from disk, but new ones are built from scratch, so the frontier is where it chokes. Pre-generate with the Chunky plugin out to a 5k–10k radius before launch, so players move through already-built terrain instead of forcing live generation under load. It won't rescue an underpowered host that's also low on TPS — fix that first — but on a healthy box it's what stops the frontier from lagging.