<blockquote><p>Since the root cause turned out to be unrelated, I found that Axios works fine with its default settings—there’s no need for custom HTTPS agents, keep-alive, or timeout configurations. - 5/28/2025</p></blockquote><p>If you're running a high-traffic Node.js or Next.js app with APIs (like Feathers.js) and noticing high numbers of <code>TIME_WAIT</code> or <code>SYN_RECV</code> in <code>netstat</code>, you're not alone.</p><figure class="image"><img src="https://images.unsplash.com/photo-1508920291026-c344bbfca1ab?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxzb2NrZXR8ZW58MHx8fHwxNzQ4MjE5NjAzfDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@nevenkrcmarek?utm_source=DNX&amp;utm_medium=referral">Neven Krcmarek</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>At <strong>SwimStandards.com</strong>, we serve thousands of daily users, mostly over HTTPS. Recently, we noticed:</p><pre><code class="language-plaintext">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c

     9 CLOSING
    42 ESTABLISHED
     4 FIN_WAIT1
     7 LAST_ACK
     1 LISTEN
   256 SYN_RECV
   127 TIME_WAIT
</code></pre><p>These numbers raised concerns. Was it normal? Was performance at risk?</p><h3>🧠 Understanding the Terms</h3><p><code><strong>TIME_WAIT</strong></code>: Indicates a closed connection that the OS is keeping open for 60s (default) to prevent delayed packets from interfering with future ones.</p><p><code><strong>SYN_RECV</strong></code>: Part of the TCP handshake. A high number may mean your server is getting a lot of new connection attempts — possibly from bots or slow clients.</p><h3>✅ When Is <code>TIME_WAIT</code> a Problem?</h3><figure class="table"><table class="ui table celled"><thead><tr><th>Count</th><th>Typical Cause</th><th>Problem?</th><th>Action</th></tr></thead><tbody><tr><td>&lt; 500</td><td>Normal HTTPS/HTTP1.1 traffic</td><td>❌ No</td><td>None</td></tr><tr><td>500–2000</td><td>Moderate load, short connections</td><td>⚠️ Maybe</td><td>Monitor</td></tr><tr><td>&gt; 3000–5000</td><td>High turnover or scraping bots</td><td>✅ Yes</td><td>Optimize + tune OS</td></tr></tbody></table></figure><h3>🔧 Steps We Took to Fix It</h3><h4>1. <strong>Enabled Keep-Alive in Axios (Next.js client)</strong></h4><pre><code class="language-plaintext">import https from "https";

const httpsAgent = new https.Agent({
  keepAlive: true,
  keepAliveMsecs: 5000,
  timeout: 30000,
  maxSockets: 100,
  maxFreeSockets: 10,
});

const client = axios.create({
  httpsAgent,
  timeout: 30000,
});
</code></pre><p>This helped reduce the number of new TCP connections created per request.</p><h4>2. <strong>Verified Feathers.js Still Performs Well Without Custom Agents</strong></h4><p>We didn’t customize the Feathers.js server’s HTTP agent. Node.js by default reuses sockets where possible on the server side. No immediate action was needed.</p><h4>3. <strong>Tuned Kernel Parameters via </strong><code><strong>sysctl</strong></code></h4><pre><code class="language-plaintext"># Enable TCP SYN cookies (protect against SYN flood)
sudo sysctl -w net.ipv4.tcp_syncookies=1

# Allow more concurrent connections in backlog queue
sudo sysctl -w net.core.somaxconn=1024

# Optional: Reduce TIME_WAIT retention
sudo sysctl -w net.ipv4.tcp_fin_timeout=30
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
</code></pre><p>To persist these changes:</p><pre><code class="language-plaintext">sudo nano /etc/sysctl.conf
# Add or uncomment:
net.ipv4.tcp_syncookies=1
net.core.somaxconn=1024
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_tw_reuse=1
</code></pre><h3>🧪 How to Monitor</h3><p>Check connection states with:</p><pre><code class="language-plaintext">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c
</code></pre><p>Check which IPs are flooding your server:</p><pre><code class="language-plaintext">ss -tn state syn-recv | awk 'NR &gt; 1 {split($5,a,":"); print a[1]}' | sort | uniq -c | sort -nr | head
</code></pre><h3>Observation</h3><p>After these changes, we monitored TCP states with:</p><pre><code class="language-css">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c</code></pre><p>While the number of <code>SYN_RECV</code> and <code>TIME_WAIT</code> states <i>did</i> fluctuate, we noticed an increase in <code>TIME_WAIT</code> in some cases — suggesting that <code>somaxconn=1024</code> may not be ideal for our traffic.</p><h3>Reverting <code>somaxconn</code></h3><p>We reverted to the Linux default:</p><pre><code class="language-css">sudo sysctl -w net.core.somaxconn=128</code></pre><p>And updated <code>/etc/sysctl.conf</code>:</p><pre><code class="language-css"># net.core.somaxconn = 1024</code></pre><p>Then reloaded again:</p><pre><code class="language-css">sudo sysctl -p</code></pre><p>This helped stabilize things, and we learned that tuning these values isn’t always linear — it depends on how your app handles slow handshakes, timeouts, and bot traffic.</p><h2>Conclusion</h2><ul><li><strong>Keep-alive helps</strong> reduce new socket overhead.</li><li><strong>SYN cookies</strong> protect against SYN floods.</li><li><strong>Higher somaxconn</strong> isn't always better — monitor TCP state.</li></ul><h3>🟢 Final Thoughts</h3><p><code>TIME_WAIT</code> is normal — only take action if it causes port exhaustion.</p><p><code>SYN_RECV</code> spikes are often bot-related and may be harmless if your server is handling them.</p><p>Keep-alive agents in Axios reduce load and improve socket reuse.</p><p>Use <code>sysctl</code> carefully — tune only when your server shows real-world pressure.</p><p>If you're running an API + Next.js combo like us and want to reduce connection churn and socket errors, these steps are low-risk and effective.</p>

To reduce high SYN_RECV and TIME_WAIT states on our Next.js + Feathers.js server, we enabled HTTP keep-alive in Axios, monitored socket usage, and adjusted system settings (tcp_syncookies=1, somaxconn=1024). While keep-alive helped reduce overhead, increasing somaxconn didn’t clearly improve results and may need to be reverted. Final tuning may also depend on upstream traffic and reverse proxy behavior.

All Posts In Socket