Linux Kernel Parameters to Tune for Better VPS Network Performance

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 — 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.

Before You Start: Measure Your Baseline

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:

# Current sysctl values (save this for comparison)
sudo sysctl -a | grep -E 'net.(core|ipv4|ipv6)' > /tmp/sysctl-baseline.txt

# Measure latency
ping -c 100 google.com | tail -3

# Measure throughput (install iperf3 first)
iperf3 -c your-test-server

# Check current connection state
ss -s

1. TCP Buffer Sizes: The Most Impactful Tuning

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:

# Increase TCP read/write buffer auto-tuning range
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

What this does: rmem_max and wmem_max set the ceiling for per-socket buffer sizes. The tcp_rmem and tcp_wmem 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.

2. TCP Congestion Control: BBR for Modern Networks

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:

# Enable BBR congestion control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Verify it is active
sysctl net.ipv4.tcp_congestion_control
# Expected output: net.ipv4.tcp_congestion_control = bbr

BBR is especially effective on VPS hosts because it does not rely on packet loss as a congestion signal — 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 (fair queueing) qdisc, BBR can significantly improve throughput and reduce latency for most workloads.

3. Connection Handling: Reducing Latency and Overhead

Several parameters control how TCP handles connection establishment and teardown. These are especially important for web servers handling many short-lived connections:

# Enable TCP Fast Open (reduces latency on repeat connections)
net.ipv4.tcp_fastopen = 3

# Enable window scaling (required for efficient high-latency links)
net.ipv4.tcp_window_scaling = 1

# Reduce the time to reuse TIME_WAIT sockets
net.ipv4.tcp_tw_reuse = 1

# Reduce the FIN-WAIT-2 timeout (default is 60 seconds)
net.ipv4.tcp_fin_timeout = 15

TCP Fast Open (TFO)

TFO allows data to be sent during the TCP handshake (SYN packet), saving one round trip on repeat connections. Setting tcp_fastopen = 3 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.

Window Scaling and TIME_WAIT

Window scaling is required for TCP windows larger than 64 KB — without it, the buffer increases above are pointless. tcp_tw_reuse allows the kernel to reuse connections in TIME_WAIT state for new outgoing connections, which prevents port exhaustion on busy servers. tcp_fin_timeout reduces how long the kernel waits for a FIN response before closing the connection.

4. Backlog and Accept Queues

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:

# Maximum number of SYN-ACK retransmits (default 5, lower is faster rejection)
net.ipv4.tcp_synack_retries = 2

# Maximum number of SYN retransmits (default 6)
net.ipv4.tcp_syn_retries = 3

# Maximum length of the SYN backlog queue
net.core.somaxconn = 1024

# Maximum number of packets queued on the input side
net.core.netdev_max_backlog = 5000

For a VPS running a web server, somaxconn should match or exceed the web server’s listen backlog setting. Nginx’s listen directive has a backlog= parameter that should be set in tandem with this kernel parameter.

5. Memory Pressure and Connection Tracking

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:

# TCP memory pressure limits (pages, often 4 KB each)
# Format: min, pressure, max
net.ipv4.tcp_mem = 65536 131072 262144

# Connection tracking limits (adjust based on expected connections)
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 86400

# Enable TCP keepalive (detect dead connections faster)
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

The tcp_mem values are in memory pages (usually 4,096 bytes). The min value is the threshold below which the kernel does not apply memory pressure; pressure is where it starts to throttle; max is the hard limit. For a 1-2 GB VPS, the values above provide a reasonable balance. For larger VPS instances, scale them proportionally.

6. Applying the Changes Safely

Apply all changes to /etc/sysctl.d/99-vps-network-tuning.conf (a separate file keeps your custom settings organized and survives kernel updates):

# /etc/sysctl.d/99-vps-network-tuning.conf
# TCP Buffer Tuning
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Congestion Control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Connection Handling
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Backlog and Accept Queues
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# Memory and Connection Tracking
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
net.netfilter.nf_conntrack_max = 262144

Apply immediately:

sudo sysctl --system

7. Testing and Validation

After applying the changes, validate that the parameters are active and measure the improvement:

# Verify specific parameters
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.rmem_max
sysctl net.ipv4.tcp_fastopen

# Re-run your baseline tests
ping -c 100 google.com | tail -3
iperf3 -c your-test-server
ss -s

# Compare against the baseline you saved earlier

If you see a regression (e.g., higher latency or connection errors), revert individual parameters by commenting them out in the .conf file and running sudo sysctl --system again. Some providers have hypervisor-level network settings that override kernel parameters — if you see no improvement after tuning, check with your provider whether they apply any rate limiting or traffic shaping at the host level.

Summary of Recommended Settings

Parameter	Default	Tuned	Benefit
tcp_congestion_control	cubic	bbr	Better throughput on variable-latency links
tcp_rmem / wmem max	~6 MB	16 MB	Higher throughput on high-BDP connections
tcp_fastopen	1	3	Reduced latency on repeat connections
somaxconn	128	1024	Prevents connection drops under load
tcp_fin_timeout	60	15	Faster connection cleanup

These kernel parameter tunings are part of a broader VPS optimization strategy. For more on choosing a provider with the right network infrastructure for your workload, see the VPS provider comparison table.