Networking & Firewall (Ss/Netstat/Iptables/Curl)

Stop curl from lying to you about hidden connection failures

🧩 The Challenge

You ever run a curl command against an API and get nothing back, so you assume the server is just slow? I’ve spent way too much time staring at a blinking cursor only to realize the connection was actually getting reset by a middlebox halfway across the network.

💡 The Fix

Start using the verbose flag combined with a write-out format to expose the handshake details and the actual HTTP status code. It pulls back the curtain on whether you’re hitting a timeout, a proxy, or an actual server-side rejection.

curl -v -so /dev/null -w 'HTTP status: %{http_code}\nTCP Connect: %{time_connect}s\nTime Start: %{time_starttransfer}s\n' https://your-target-site.com

⚙️ Why It Works

By suppressing the body output and forcing the stats display, you stop the tool from burying the lead. The time_connect and time_starttransfer variables are your best friends for spotting where the latency is actually coming from.

🚀 Pro-Tip: Add –trace-ascii – to the command if you need to see the exact hex dump of what’s being sent over the wire.

Linux Tips & Tricks | © ngelinux.com | 7/31/2026