Minecraft Server Network Optimization: Reduce Latency and Fix Connection Issues

# Minecraft Server Network Optimization: Reduce Latency and Fix Connection Issues

High ping and unstable connections are among the most frustrating issues for Minecraft players — and they're often misdiagnosed. Many server admins assume lag is always a TPS problem, but network-level issues can cause rubber-banding, teleportation glitches, and disconnections even on a perfectly optimized server. This guide walks through every layer of Minecraft's network stack and gives you concrete settings to fix it.

Understanding the Difference Between TPS Lag and Network Lag

Before touching any config, it's important to know what you're dealing with:

• TPS lag = the server tick loop is too slow (use /tps to check)
• Network lag = packets are being delayed, dropped, or rate-limited between the server and client

A server running at 20 TPS can still feel laggy if network throughput is throttled or if the netty thread pool is overwhelmed. Players will see their character "snap back" to previous positions — a classic sign of network-level issues.

Key Config Files for Network Optimization

server.properties

This is the first place to look:

network-compression-threshold=256
rate-limit=0

network-compression-threshold controls the minimum packet size (in bytes) before compression is applied. The default is 256, which is reasonable, but on servers with fast CPUs and slower network connections, lowering it to 128 can reduce bandwidth at the cost of more CPU usage. If your server has plenty of CPU headroom, try 128. On dedicated high-bandwidth servers, you can raise it to 512 to reduce compression overhead.

rate-limit defines how many packets a player can send per second before being kicked. The default 0 means no limit, which is fine for trusted communities. If you're experiencing bot attacks or packet flooding, set this to 500.

spigot.yml

settings:
  bungeecord: false
  sample-count: 12
  player-shuffle: 0
  user-cache-size: 1000
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

The moved-wrongly-threshold and moved-too-quickly-multiplier settings control anti-cheat movement validation. If legitimate players are being rubber-banded on a high-latency connection, consider slightly raising moved-too-quickly-multiplier to 12.0. This gives players with 150–200ms ping more tolerance before the server corrects their position.

world-settings:
  default:
    enable-zombie-pigmen-portal-spawns: true
    item-despawn-rate: 6000
    arrow-despawn-rate: 1200
    nerf-spawner-mobs: false
    mob-spawn-range: 6

While these aren't directly network settings, reducing item counts in the world directly reduces the number of entity update packets the server sends each tick.

paper-global.yml (Paper 1.19+)

Paper has dedicated network-level optimizations:

network:
  max-joins-per-tick: 3
  kick-for-out-of-memory: true

max-joins-per-tick prevents connection spikes when many players join simultaneously (e.g., after a restart). Setting this to 3 staggers logins and prevents the netty pipeline from being overwhelmed. On large servers with frequent mass-joins, lower this to 2.

paper-world.yml

chunks:
  delay-chunk-unloads-by: 10s
  entity-per-chunk-save-limit:
    experience_orb: 16
send-ticks-before-login: 0
entity-tracking-range:
  players: 48
  animals: 48
  monsters: 48
  misc: 32
  other: 64

Entity tracking range is one of the biggest network optimizations available. Every tracked entity generates update packets every tick. Reducing players from the default 128 to 48 blocks (or even 64) dramatically cuts downstream bandwidth per player — without meaningfully impacting gameplay for most server types.

For minigame servers or PvP arenas, keep player tracking range at 64–96. For survival servers, 48 is often sufficient.

Netty Thread Tuning (JVM Flags)

Minecraft uses Netty for its networking layer. By default, Netty auto-detects thread count, but you can tune it explicitly via JVM flags:

-Dio.netty.eventLoopThreads=4

For servers with 4+ CPU cores and 50+ concurrent players, explicitly setting this to 4 or 6 can improve packet processing consistency. Don't exceed your physical core count.

Also ensure you're using the Netty native transport when available. Paper automatically uses epoll on Linux, which is significantly more efficient than the default Java NIO transport.

Using a Proxy: BungeeCord and Velocity

If you run a network of servers, the proxy layer itself can become a bottleneck. [Velocity](https://papermc.io/software/velocity) is the modern, performance-focused alternative to BungeeCord and handles packet forwarding more efficiently.

Key Velocity settings in velocity.toml:

compression-threshold = 256
compression-level = -1
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000

Setting compression-level = -1 tells Velocity to use the default compression algorithm, which balances speed and size well. Raising login-ratelimit helps absorb connection floods without kicking legitimate players.

Monitoring Network Health in Real Time

Network problems are notoriously hard to reproduce. You need visibility into packet rates, player ping distributions, and connection errors over time — not just a snapshot. This is where [PulseNode](https://pulsenode.tech) helps: it continuously monitors your server's performance metrics, including per-player latency trends and connection events, so you can correlate network spikes with specific times, player counts, or plugin activity.

On the server side, Paper exposes useful diagnostics:

/ping <player>       — check a specific player's latency
/mspt                — mean server tick time

For OS-level network monitoring on Linux:

ss -s                          # socket summary
netstat -an | grep :25565      # active connections on Minecraft port
iptables -L -n -v              # check for any traffic filtering

Firewall and Port Configuration

Make sure your firewall isn't throttling Minecraft traffic. On UFW:

ufw allow 25565/tcp
ufw allow 25565/udp

UDP is used by some proxy implementations and query protocols. Also verify your hosting provider isn't applying DDoS mitigation rules that rate-limit legitimate player traffic — this is a common issue with budget VPS providers.

Summary: Network Optimization Checklist

• [ ] Set network-compression-threshold to 128–256 based on your CPU/bandwidth tradeoff
• [ ] Reduce entity tracking ranges in paper-world.yml
• [ ] Set max-joins-per-tick: 3 in paper-global.yml
• [ ] Tune moved-too-quickly-multiplier if high-latency players are rubber-banding
• [ ] Use Velocity instead of BungeeCord for proxy setups
• [ ] Set Netty event loop threads explicitly for high-player-count servers
• [ ] Confirm firewall rules allow TCP/UDP on port 25565
• [ ] Monitor per-player ping and connection events continuously

Network optimization is an ongoing process. A setting that works well at 20 players may need adjustment at 100. Continuous monitoring makes the difference between guessing and knowing.

---

Want to stop guessing when network issues appear? [PulseNode](https://pulsenode.tech) gives you real-time server health monitoring with historical data, so you can catch latency patterns before your players notice them.