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 \u2014 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.<\/p>\n\n\n\n
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 \u2014 the TCP handshake collapses to zero extra round trips for that connection.<\/p>\n\n\n\n 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 \u2014 mobile apps, API consumers, and short-lived scraping jobs that reconnect constantly.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n Value 2 enables server-side TFO only \u2014 the safe choice if you never want your VPS to initiate TFO connections itself.<\/p>\n\n\n\n nginx exposes TFO as a Reload with Modern clients support TFO out of the box or behind a flag: curl has 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 \u2014 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 Do not trust the config; trust the counters. The kernel tracks TFO in After enabling the sysctl and reloading nginx, generate traffic with 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<\/a>, it shaves measurable milliseconds off every repeat connection \u2014 and if you are still deciding where to deploy, compare providers on our VPS comparison table<\/a> before you commit.<\/p>\n\n\n\nScenario<\/th> Without TFO<\/th> With TFO<\/th><\/tr><\/thead> First visit (no cookie)<\/td> 2 RTT to first byte<\/td> 2 RTT (cookie is learned)<\/td><\/tr> Repeat visit<\/td> 2 RTT<\/td> 1 RTT<\/td><\/tr> Keep-alive reuse<\/td> 0 extra RTT<\/td> 0 extra RTT<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Enable it on the server<\/h2>\n\n\n\n
# enable both client and server side\necho 3 | sudo tee \/proc\/sys\/net\/ipv4\/tcp_fastopen\necho \"net.ipv4.tcp_fastopen = 3\" | sudo tee \/etc\/sysctl.d\/99-tcp-fastopen.conf\nsudo sysctl --system<\/code><\/pre>\n\n\n\nTurn it on in nginx<\/h2>\n\n\n\n
listen<\/code> parameter; the number is the pending-SYN queue size for TFO connections:<\/p>\n\n\n\nserver {\n listen 443 ssl fastopen=3;\n listen 80 fastopen=3;\n # ... rest of the server block\n}<\/code><\/pre>\n\n\n\nsudo nginx -t && sudo systemctl reload nginx<\/code>. 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.<\/p>\n\n\n\nClient-side behavior<\/h2>\n\n\n\n
--tcp-fastopen<\/code>, recent Firefox enables it by default on desktop, and Chromium exposes --enable-tcp-fast-open<\/code>. You do not control your visitors’ browsers, which is exactly why the server-side setting matters \u2014 every TFO-capable repeat visitor gets the benefit with zero changes on their end.<\/p>\n\n\n\nWhere the milliseconds show up<\/h2>\n\n\n\n
curl -w '%{time_starttransfer}'<\/code> against curl --tcp-fastopen -w '%{time_starttransfer}'<\/code> over a few hundred requests and average the difference.<\/p>\n\n\n\nVerify with kernel counters<\/h2>\n\n\n\n
nstat<\/code>:<\/p>\n\n\n\nnstat -az | grep -i fastopen<\/code><\/pre>\n\n\n\nCounter<\/th> Meaning<\/th><\/tr><\/thead> TCPFastOpenActive<\/td> Outbound TFO connections (client role)<\/td><\/tr> TCPFastOpenPassive<\/td> Inbound TFO connections accepted (server role)<\/td><\/tr> TCPFastOpenFail<\/td> Cookie rejected or handshake failed<\/td><\/tr> TCPFastOpenListenOverflow<\/td> TFO dropped because the accept queue was full<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n curl --tcp-fastopen https:\/\/your-vps\/<\/code> and watch TCPFastOpenPassive<\/code> 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<\/code>.<\/p>\n\n\n\nCaveats and when to skip it<\/h2>\n\n\n\n