Your VPS network performance is governed by a set of kernel parameters that control how TCP connections are established, maintained, and terminated. The default values in most Linux distributions are tuned for general-purpose servers \u2014 not for the specific constraints of a virtualized environment. This guide covers the most impactful sysctl parameters for VPS network performance, what they do, and how to tune them safely.<\/p>\n\n\n\n
Never tune blindly. Before changing any kernel parameter, measure your current network performance. Record baseline latency, throughput, and connection counts so you can evaluate the impact of each change:<\/p>\n\n\n\n
# Current sysctl values (save this for comparison)\nsudo sysctl -a | grep -E 'net.(core|ipv4|ipv6)' > \/tmp\/sysctl-baseline.txt\n\n# Measure latency\nping -c 100 google.com | tail -3\n\n# Measure throughput (install iperf3 first)\niperf3 -c your-test-server\n\n# Check current connection state\nss -s<\/code><\/pre>\n\n\n\n1. TCP Buffer Sizes: The Most Impactful Tuning<\/h2>\n\n\n\n
TCP buffer sizes control how much data the kernel buffers for each connection before the application reads it. Defaults are often too conservative for modern VPS networks with decent bandwidth but higher latency (typical of virtualized environments). The three key parameters form a “min, default, max” tuple:<\/p>\n\n\n\n
# Increase TCP read\/write buffer auto-tuning range\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216<\/code><\/pre>\n\n\n\nWhat this does: rmem_max<\/code> and wmem_max<\/code> set the ceiling for per-socket buffer sizes. The tcp_rmem<\/code> and tcp_wmem<\/code> tuples set the minimum, default, and maximum. The kernel auto-tunes between the default and maximum based on connection conditions. Raising the max to 16 MB allows connections with high bandwidth-delay products to perform better, particularly for file transfers and streaming.<\/p>\n\n\n\n2. TCP Congestion Control: BBR for Modern Networks<\/h2>\n\n\n\n
The default CUBIC congestion control algorithm works well on wired networks but is suboptimal on VPS instances where bandwidth varies and packet loss is not always a sign of congestion. BBR (Bottleneck Bandwidth and Round-trip propagation time) is a model-based algorithm that performs significantly better on virtualized infrastructure:<\/p>\n\n\n\n
# Enable BBR congestion control\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n\n# Verify it is active\nsysctl net.ipv4.tcp_congestion_control\n# Expected output: net.ipv4.tcp_congestion_control = bbr<\/code><\/pre>\n\n\n\nBBR is especially effective on VPS hosts because it does not rely on packet loss as a congestion signal \u2014 it paces packets based on measured bandwidth and RTT, which is a better fit for environments where the hypervisor may introduce variable latency. Combined with the fq<\/code> (fair queueing) qdisc, BBR can significantly improve throughput and reduce latency for most workloads.<\/p>\n\n\n\n3. Connection Handling: Reducing Latency and Overhead<\/h2>\n\n\n\n
Several parameters control how TCP handles connection establishment and teardown. These are especially important for web servers handling many short-lived connections:<\/p>\n\n\n\n
# Enable TCP Fast Open (reduces latency on repeat connections)\nnet.ipv4.tcp_fastopen = 3\n\n# Enable window scaling (required for efficient high-latency links)\nnet.ipv4.tcp_window_scaling = 1\n\n# Reduce the time to reuse TIME_WAIT sockets\nnet.ipv4.tcp_tw_reuse = 1\n\n# Reduce the FIN-WAIT-2 timeout (default is 60 seconds)\nnet.ipv4.tcp_fin_timeout = 15<\/code><\/pre>\n\n\n\nTCP Fast Open (TFO)<\/h3>\n\n\n\n
TFO allows data to be sent during the TCP handshake (SYN packet), saving one round trip on repeat connections. Setting tcp_fastopen = 3<\/code> enables TFO for both client and server roles. The impact is most noticeable on HTTPS connections where the TLS handshake adds additional round trips. For a VPS behind a load balancer or CDN, TFO can shave 20-50 ms off the initial connection time.<\/p>\n\n\n\nWindow Scaling and TIME_WAIT<\/h3>\n\n\n\n
Window scaling is required for TCP windows larger than 64 KB \u2014 without it, the buffer increases above are pointless. tcp_tw_reuse<\/code> allows the kernel to reuse connections in TIME_WAIT state for new outgoing connections, which prevents port exhaustion on busy servers. tcp_fin_timeout<\/code> reduces how long the kernel waits for a FIN response before closing the connection.<\/p>\n\n\n\n4. Backlog and Accept Queues<\/h2>\n\n\n\n
When a web server is under load, the kernel’s SYN backlog (the queue of half-open connections waiting for the handshake to complete) can fill up, causing connection refusals. Increase it for busy VPS instances:<\/p>\n\n\n\n
# Maximum number of SYN-ACK retransmits (default 5, lower is faster rejection)\nnet.ipv4.tcp_synack_retries = 2\n\n# Maximum number of SYN retransmits (default 6)\nnet.ipv4.tcp_syn_retries = 3\n\n# Maximum length of the SYN backlog queue\nnet.core.somaxconn = 1024\n\n# Maximum number of packets queued on the input side\nnet.core.netdev_max_backlog = 5000<\/code><\/pre>\n\n\n\nFor a VPS running a web server, somaxconn<\/code> should match or exceed the web server’s listen backlog setting. Nginx’s listen<\/code> directive has a backlog=<\/code> parameter that should be set in tandem with this kernel parameter.<\/p>\n\n\n\n5. Memory Pressure and Connection Tracking<\/h2>\n\n\n\n
Two kernel subsystems can become bottlenecks under network load: the socket memory pressure system and the conntrack table. On a small VPS with limited RAM, these settings prevent the kernel from using excessive memory for network connections:<\/p>\n\n\n\n
# TCP memory pressure limits (pages, often 4 KB each)\n# Format: min, pressure, max\nnet.ipv4.tcp_mem = 65536 131072 262144\n\n# Connection tracking limits (adjust based on expected connections)\nnet.netfilter.nf_conntrack_max = 262144\nnet.netfilter.nf_conntrack_tcp_timeout_established = 86400\n\n# Enable TCP keepalive (detect dead connections faster)\nnet.ipv4.tcp_keepalive_time = 120\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 3<\/code><\/pre>\n\n\n\nThe tcp_mem<\/code> values are in memory pages (usually 4,096 bytes). The min<\/code> value is the threshold below which the kernel does not apply memory pressure; pressure<\/code> is where it starts to throttle; max<\/code> is the hard limit. For a 1-2 GB VPS, the values above provide a reasonable balance. For larger VPS instances, scale them proportionally.<\/p>\n\n\n\n6. Applying the Changes Safely<\/h2>\n\n\n\n
Apply all changes to \/etc\/sysctl.d\/99-vps-network-tuning.conf<\/code> (a separate file keeps your custom settings organized and survives kernel updates):<\/p>\n\n\n\n# \/etc\/sysctl.d\/99-vps-network-tuning.conf\n# TCP Buffer Tuning\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\n\n# Congestion Control\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n\n# Connection Handling\nnet.ipv4.tcp_fastopen = 3\nnet.ipv4.tcp_window_scaling = 1\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\n\n# Backlog and Accept Queues\nnet.core.somaxconn = 1024\nnet.core.netdev_max_backlog = 5000\nnet.ipv4.tcp_synack_retries = 2\nnet.ipv4.tcp_syn_retries = 3\n\n# Memory and Connection Tracking\nnet.ipv4.tcp_mem = 65536 131072 262144\nnet.ipv4.tcp_keepalive_time = 120\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 3\nnet.netfilter.nf_conntrack_max = 262144<\/code><\/pre>\n\n\n\nApply immediately:<\/p>\n\n\n\n
sudo sysctl --system<\/code><\/pre>\n\n\n\n7. Testing and Validation<\/h2>\n\n\n\n
After applying the changes, validate that the parameters are active and measure the improvement:<\/p>\n\n\n\n
# Verify specific parameters\nsysctl net.ipv4.tcp_congestion_control\nsysctl net.core.rmem_max\nsysctl net.ipv4.tcp_fastopen\n\n# Re-run your baseline tests\nping -c 100 google.com | tail -3\niperf3 -c your-test-server\nss -s\n\n# Compare against the baseline you saved earlier<\/code><\/pre>\n\n\n\nIf you see a regression (e.g., higher latency or connection errors), revert individual parameters by commenting them out in the .conf<\/code> file and running sudo sysctl --system<\/code> again. Some providers have hypervisor-level network settings that override kernel parameters \u2014 if you see no improvement after tuning, check with your provider whether they apply any rate limiting or traffic shaping at the host level.<\/p>\n\n\n\nSummary of Recommended Settings<\/h2>\n\n\n\n