TCP Fast Open on a VPS: Cut a Full Round Trip From Every Connection

Latency is measured in round trips. Every new TCP connection to your VPS costs one full round trip (SYN, SYN-ACK, ACK) before a single byte of application data moves — and TLS adds another on top. TCP Fast Open (TFO) is a Linux feature that lets repeat connections skip the handshake round trip by carrying the first data inside the SYN packet itself. It is one of the cheapest latency wins available on a VPS: one sysctl, one nginx directive, and a counter check. This guide covers what it saves, when it helps, and how to verify it is actually working.

What TFO actually saves

A normal new connection costs two round trips before the first byte of an HTTPS request reaches your application: one for the TCP handshake and one for the TLS handshake. With TFO, a client that already holds a valid cookie sends its first request data inside the SYN, so the server can answer immediately — the TCP handshake collapses to zero extra round trips for that connection.

Scenario	Without TFO	With TFO
First visit (no cookie)	2 RTT to first byte	2 RTT (cookie is learned)
Repeat visit	2 RTT	1 RTT
Keep-alive reuse	0 extra RTT	0 extra RTT

The effect is real but bounded: it only applies to new connections, and keep-alive already eliminates handshakes for browsers that hold connections open. TFO pays off most for connection-heavy clients — mobile apps, API consumers, and short-lived scraping jobs that reconnect constantly.

Enable it on the server

The kernel switch is a single sysctl. The value is a bitmask: bit 1 enables TFO for outgoing (client) connections, bit 2 for incoming (server) connections. Most distributions default to 1, which is why you must set it explicitly:

# enable both client and server side
echo 3 | sudo tee /proc/sys/net/ipv4/tcp_fastopen
echo "net.ipv4.tcp_fastopen = 3" | sudo tee /etc/sysctl.d/99-tcp-fastopen.conf
sudo sysctl --system

Value 2 enables server-side TFO only — the safe choice if you never want your VPS to initiate TFO connections itself.

Turn it on in nginx

nginx exposes TFO as a listen parameter; the number is the pending-SYN queue size for TFO connections:

server {
    listen 443 ssl fastopen=3;
    listen 80 fastopen=3;
    # ... rest of the server block
}

Reload with sudo nginx -t && sudo systemctl reload nginx. Reverse proxies in front (HAProxy, and most load balancers) pass TFO through once the kernel supports it, but verify with the counters below rather than assuming.

Client-side behavior

Modern clients support TFO out of the box or behind a flag: curl has --tcp-fastopen, recent Firefox enables it by default on desktop, and Chromium exposes --enable-tcp-fast-open. You do not control your visitors’ browsers, which is exactly why the server-side setting matters — every TFO-capable repeat visitor gets the benefit with zero changes on their end.

Where the milliseconds show up

The clearest wins appear in anything that opens many short connections: mobile apps that sync on launch, payment and API integrations that call your endpoint per request, analytics beacons, and pages that load resources from the same origin without keep-alive. On a page with dozens of same-host requests, TFO removes a full round trip per new connection on repeat views — often the difference between a 400 ms and a 250 ms page load on a high-latency link. Measure it with a real client: compare curl -w '%{time_starttransfer}' against curl --tcp-fastopen -w '%{time_starttransfer}' over a few hundred requests and average the difference.

Verify with kernel counters

Do not trust the config; trust the counters. The kernel tracks TFO in nstat:

nstat -az | grep -i fastopen

Counter	Meaning
TCPFastOpenActive	Outbound TFO connections (client role)
TCPFastOpenPassive	Inbound TFO connections accepted (server role)
TCPFastOpenFail	Cookie rejected or handshake failed
TCPFastOpenListenOverflow	TFO dropped because the accept queue was full

After enabling the sysctl and reloading nginx, generate traffic with curl --tcp-fastopen https://your-vps/ and watch TCPFastOpenPassive climb. If it stays at zero, check that the sysctl survived a reboot and that no firewall is stripping the TFO option from SYN packets. You can also inspect individual packets: a SYN carrying the TFO option (kind 34) is visible in tcpdump.

Caveats and when to skip it

• Middleboxes. A small number of firewalls drop SYN packets that carry data. The kernel detects this and retries without TFO, so the failure mode is a slow first attempt — measure, but do not fear it.
• Repeat connections only. First visits are unchanged; TFO’s benefit compounds with returning traffic.
• No bandwidth effect. TFO removes a round trip; it does not change throughput. Pair it with modern congestion control for the full latency story.
• Security. The TFO cookie prevents address spoofing for SYN-carried data; the design has held up in production for years, but keep the kernel updated as usual.

TFO is one of those rare optimizations where the whole change is a sysctl, a directive, and a counter check. Combined with solid VPS hosting, it shaves measurable milliseconds off every repeat connection — and if you are still deciding where to deploy, compare providers on our VPS comparison table before you commit.

Want to test it on a fresh box? InterServer’s VPS plans give you full root access and a stock kernel, so the sysctl and nginx settings above apply exactly as written.