{"id":1049,"date":"2026-09-05T02:00:21","date_gmt":"2026-09-05T02:00:21","guid":{"rendered":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/?p=1049"},"modified":"2026-09-05T02:00:21","modified_gmt":"2026-09-05T02:00:21","slug":"game-server-network-optimization-latency-reduction","status":"publish","type":"post","link":"https:\/\/bestdedicatedwebhostingserver.com\/blog\/game-server-network-optimization-latency-reduction\/","title":{"rendered":"Game Server Network Optimization: Reduce Latency, Configure UDP, and Tune Kernel Parameters"},"content":{"rendered":"\n

Network latency is the silent killer of game server performance. You can have the fastest CPU and the most RAM, but if your network stack is misconfigured, players experience rubber-banding, delayed hit registration, and disconnects. This article covers the Linux kernel parameters, UDP tuning, and network architecture decisions that reduce latency and improve player experience on dedicated game servers.<\/p>\n\n\n\n

Before tuning your network, check our dedicated server comparison table<\/a> to ensure your hardware includes adequate bandwidth and DDoS protection for game hosting.<\/p>\n\n\n\n

Why Game Servers Are Sensitive to Latency<\/h2>\n\n\n\n

Unlike web servers, which can tolerate 100\u2013200ms of latency, game servers need sub-50ms round-trip times for competitive play. Every millisecond of delay between a player’s action and the server’s response degrades the experience. First-person shooters are the most sensitive: a 30ms delay in hit registration makes the difference between a headshot and a miss. Survival games and MMOs are more forgiving but still benefit from low latency.<\/p>\n\n\n\n

UDP vs TCP: Why Game Servers Use UDP<\/h2>\n\n\n\n

Nearly all game servers use UDP for real-time game traffic. The reason is simple: UDP has no handshake, no acknowledgment, and no retransmission overhead. If a packet is lost, it is lost \u2014 the game continues with the next update. TCP’s reliability features (retransmission, in-order delivery, flow control) add latency that is catastrophic for real-time games. A single lost TCP packet can stall the entire data stream for 200ms while the retransmission timer fires.<\/p>\n\n\n\n

Some game servers use TCP for non-real-time traffic (authentication, chat, leaderboards) and UDP for game state updates. This hybrid approach is common in games like Minecraft (TCP for game state, with optional UDP for voice chat) and Rust (UDP for game state, TCP for RCON).<\/p>\n\n\n\n

Linux Kernel Network Tuning<\/h2>\n\n\n\n

The default Linux kernel network settings are conservative \u2014 optimized for web servers, not game servers. Apply these changes to \/etc\/sysctl.conf<\/code> and reload with sysctl -p<\/code>:<\/p>\n\n\n\n

UDP Buffer Sizes<\/h3>\n\n\n\n
# Increase UDP receive and send buffer sizes\nnet.core.rmem_max = 134217728\nnet.core.wmem_max = 134217728\nnet.core.rmem_default = 262144\nnet.core.wmem_default = 262144\nnet.ipv4.udp_mem = 262144 327680 393216\nnet.ipv4.udp_rmem_min = 16384\nnet.ipv4.udp_wmem_min = 16384<\/code><\/pre>\n\n\n\n
These settings increase the maximum UDP buffer from the default 212 KB to 128 MB, preventing buffer overflows during traffic spikes (e.g., 50 players connecting simultaneously after a server restart).<\/p>\n\n\n\n
TCP Tuning for Non-Real-Time Traffic<\/h3>\n\n\n\n
# TCP optimizations for RCON and admin traffic\nnet.ipv4.tcp_fastopen = 3\nnet.ipv4.tcp_slow_start_after_idle = 0\nnet.ipv4.tcp_tw_reuse = 1\nnet.core.netdev_max_backlog = 5000\nnet.core.somaxconn = 1024<\/code><\/pre>\n\n\n\n
Congestion Control<\/h3>\n\n\n\n
Switch from the default cubic to BBR for better throughput on high-bandwidth links:<\/p>\n\n\n\n
# Enable BBR congestion control\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr<\/code><\/pre>\n\n\n\n
BBR is particularly effective on dedicated servers with 1 Gbps+ connections, reducing bufferbloat and improving throughput under load.<\/p>\n\n\n\n
Firewall Configuration for Game Servers<\/h2>\n\n\n\n
Game servers need specific UDP ports open. Use iptables<\/code> or nftables<\/code> to allow only the necessary ports and block everything else:<\/p>\n\n\n\n
# Allow established connections\niptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT\n\n# Game-specific UDP ports\n# Rust\niptables -A INPUT -p udp --dport 28015 -j ACCEPT\n# ARK: Survival Ascended\niptables -A INPUT -p udp --dport 7777 -j ACCEPT\niptables -A INPUT -p udp --dport 7778 -j ACCEPT\n# Palworld\niptables -A INPUT -p udp --dport 8211 -j ACCEPT\n# Valheim\niptables -A INPUT -p udp --dport 2456:2457 -j ACCEPT\n# 7 Days to Die\niptables -A INPUT -p udp --dport 26900:26902 -j ACCEPT\n\n# RCON (TCP)\niptables -A INPUT -p tcp --dport 28016 -j ACCEPT\n\n# SSH\niptables -A INPUT -p tcp --dport 22 -j ACCEPT\n\n# Drop everything else\niptables -P INPUT DROP<\/code><\/pre>\n\n\n\n
Rate Limiting to Prevent DDoS<\/h2>\n\n\n\n
Even with provider-level DDoS protection, rate limiting at the server level adds a layer of defense:<\/p>\n\n\n\n
# Limit UDP connections per IP to prevent flooding\niptables -A INPUT -p udp -m state --state NEW \\\n  -m hashlimit \\\n  --hashlimit-name udp_limit \\\n  --hashlimit-above 100\/second \\\n  --hashlimit-burst 200 \\\n  --hashlimit-mode srcip \\\n  -j DROP\n\n# Limit new TCP connections (SSH brute force protection)\niptables -A INPUT -p tcp --dport 22 \\\n  -m state --state NEW \\\n  -m recent --set \\\n  -m recent --update --seconds 60 --hitcount 4 \\\n  -j DROP<\/code><\/pre>\n\n\n\n
Network Interface Card (NIC) Tuning<\/h2>\n\n\n\n
Modern NICs have hardware offloading features that can interfere with game server traffic. Disable unnecessary offloading:<\/p>\n\n\n\n
# Disable TCP segmentation offload and generic segmentation offload\nethtool -K eth0 tso off gso off gro off\n\n# Increase the transmit queue length\nip link set dev eth0 txqueuelen 10000\n\n# Check current settings\nethtool -k eth0<\/code><\/pre>\n\n\n\n
TSO (TCP Segmentation Offload) and GSO (Generic Segmentation Offload) can fragment packets in ways that game servers do not expect, causing dropped packets. Disabling them adds a small CPU cost but improves reliability.<\/p>\n\n\n\n
Reducing Latency with Geographic Proximity<\/h2>\n\n\n\n
No amount of kernel tuning can overcome the speed of light. If your players are in Europe and your server is in Los Angeles, they will experience 150ms+ latency regardless of configuration. Choose a data center location close to your player base:<\/p>\n\n\n\n
Player Region<\/th>Recommended Data Center<\/th>Typical Latency<\/th><\/tr><\/thead>
North America East<\/td>New York, Ashburn, Montreal<\/td>5\u201330ms<\/td><\/tr>
North America West<\/td>Los Angeles, Seattle, San Jose<\/td>5\u201330ms<\/td><\/tr>
Europe West<\/td>Frankfurt, Amsterdam, London<\/td>5\u201330ms<\/td><\/tr>
Europe East<\/td>Warsaw, Helsinki, Bucharest<\/td>10\u201340ms<\/td><\/tr>
Asia-Pacific<\/td>Singapore, Tokyo, Sydney<\/td>5\u201350ms<\/td><\/tr>
South America<\/td>S\u00e3o Paulo, Santiago<\/td>5\u201340ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Testing Network Performance<\/h2>\n\n\n\n
After tuning, verify your network configuration:<\/p>\n\n\n\n