The performance settings
Three entries account for most of the performance you can win or lose in this file. Everything else is rounding error by comparison.
| `view-distance` | How far chunks are sent to players. The biggest lever in the file — cost scales with roughly the square of the value. 8 is a sensible default; 10 is generous |
| `simulation-distance` | How far entities, redstone and block updates actually tick. Can usually sit below view-distance without players noticing |
| `max-players` | Not just a cap — it sets the ceiling on how much load the box can be asked to carry. Setting it far above what your hardware handles is how you discover the limit during peak hour |
| `network-compression-threshold` | Packet size above which packets are compressed. A CPU-versus-bandwidth trade, not free performance |
| `sync-chunk-writes` | Whether chunk writes are flushed synchronously. Disabling can smooth tick times at some durability risk on an unclean shutdown |
| `entity-broadcast-range-percentage` | How far entities are sent to clients. Lowering reduces per-tick network and client load on entity-heavy servers |
If your server is struggling, `view-distance` is where to start and it is not close. Go from 12 to 8 and re-measure before changing anything else — and see finding the source of lag with spark if the improvement is not what you hoped, because that means chunks were not your problem.
The settings that are actually security decisions
A few entries look like ordinary configuration and are not. Getting these wrong is not a performance regression; it is an incident.
- `online-mode` — the big one. `true` verifies every player against Mojang's session servers. `false` disables that check entirely, so anyone may connect as any username, including one your permissions plugin has made an administrator. Only run `false` on a backend that a proxy authenticates for you, and only when that backend cannot be reached from the internet.
- `enforce-secure-profile` — governs whether players must present a signed profile. Understand what you are relaxing before relaxing it.
- `white-list` and `enforce-whitelist` — the whitelist only takes effect if enforcement is actually on. A whitelist you believe is protecting you and is not is worse than none.
- `prevent-proxy-connections` — despite the name, this performs a lookup on connecting players. It is not DDoS protection and does not filter floods.
- `server-port` — changing it is mild obscurity, not defence. Anyone scanning finds it in seconds.
- `server-ip` — bind to a specific interface where appropriate. On a backend behind a proxy this is part of not being publicly reachable.
Behind a proxy, several of these change meaning
On a network where players connect to Velocity or BungeeCord rather than directly to a game server, the backends are no longer public-facing, and their properties should reflect that. The proxy performs authentication, so backends typically run with `online-mode=false` — which is safe only because they are firewalled to accept connections from the proxy alone. If that firewall is missing, you have not configured a network; you have published an open server that trusts whatever username it is handed.
The same goes for whitelists and player caps: enforce them at the proxy where the player actually arrives, not only on individual backends, or a player bounced between servers can hit inconsistent rules.
Settings people change hoping for speed
`max-tick-time` is a watchdog, not a throttle — raising it does not make ticks faster, it just delays the point at which the server declares itself hung and shuts down. `spawn-protection` costs essentially nothing. `difficulty` and `gamemode` have no meaningful performance implication. And `max-players` does not make a server faster by being lower; it makes it *not get slower* by refusing load it cannot carry, which is a different thing worth being clear about.
The real performance work happens in your server software's own configuration — Paper's entity activation ranges and chunk settings do more for a struggling server than anything left in server.properties once view-distance is sensible. That is one reason which server software you run matters.
What this file cannot do
Every setting here applies to connections that already arrived. There is no entry that drops a packet flood, none that distinguishes a bot from a player before login, and none that stops someone connecting to a leaked backend IP. `max-players` will not save you from a join-flood — it just means the bots fill the slots and your actual players get "server full". That work happens before traffic reaches the server, on a network with the capacity to absorb it. Tune this file for performance and correctness, and handle protection separately.
Common questions
What is the best view-distance for a Minecraft server?+
For most public servers, 8 is a good balance and 10 is generous. The cost scales with roughly the square of the value, so dropping from 12 to 8 removes well over half the chunks the server has to keep loaded per player — usually the single biggest performance change available in the file. Pair it with a lower simulation-distance, which most players never notice at all.
What is the difference between view-distance and simulation-distance?+
view-distance controls how far chunks are sent to players so they can see terrain. simulation-distance controls how far the server actually ticks entities, redstone and block updates. Simulation is the expensive one per chunk, so a common tuning is a comfortable view-distance with a noticeably smaller simulation-distance — players see a long way, but the world only comes alive nearer to them.
Should online-mode be true or false?+
True, unless you have a specific, well-understood reason and a plan for the consequences. With online-mode=false the server stops verifying accounts with Mojang's session servers, which means anyone can connect as any username, including your administrators. The legitimate use is a backend server behind a proxy that does the verification — and that backend must be firewalled so it is unreachable from the internet.
Does lowering network-compression-threshold improve performance?+
It changes a trade, it does not create free performance. The threshold sets the packet size above which packets are compressed: lower means more CPU spent compressing but less bandwidth used, higher means the reverse. Servers on a fast local network sometimes raise it to trade bandwidth for CPU. It is a tuning knob for a known constraint, not a general optimisation.
Does changing server.properties protect against DDoS attacks?+
No. Nothing in server.properties filters traffic — the settings apply to connections that have already reached your server. Even prevent-proxy-connections, which sounds relevant, only does a lookup on connecting players and does nothing about a flood. Attack traffic has to be absorbed and filtered upstream of the server, before a connection slot is spent.
File tuned and still going down under load? Start free with Arvoris — L4/L7 mitigation and antibot on every plan, one DNS record, no plugin to install.