curl (28) Operation Timed Out: Find Which Phase Stalled

Exit code 28 is CURLE_OPERATION_TIMEDOUT: a time limit was reached before the transfer finished. The limit can be one you set (--connect-timeout, --max-time) or a built-in one. The useful part is the wording, because curl names the phase that ran out of time:

curl: (28) Resolving timed out after 5001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds
curl: (28) SSL connection timeout
curl: (28) Operation timed out after 30001 milliseconds with 0 bytes received
curl: (28) Operation timed out after 30000 milliseconds with 1048576 out of 5242880 bytes received

Exact wording varies a little between curl versions, but the pattern holds. "Resolving" is DNS. "Connection" is the TCP handshake. "with 0 bytes received" means the request was sent and the server never answered. "N out of M bytes" means the transfer started and then stalled or ran longer than --max-time.

Step 1: measure each phase

Run one request with timing output. This tells you where the time goes without guessing:

curl -sS -o /dev/null --connect-timeout 10 --max-time 30 \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

The values are cumulative seconds from the start, so subtract the previous one to get each phase. A healthy request prints something like dns=0.012 connect=0.045 tls=0.110 ttfb=0.230 total=0.250. If the command times out, the phase that never printed a sensible value is the culprit; run curl -v and see which line is the last one printed.

Step 2: DNS timeouts

A resolver that does not answer causes this. Test with another resolver, such as getent hosts example.com against the system resolver and dig @1.1.1.1 example.com against a public one. If the public one answers, your configured resolver (often /etc/resolv.conf or a corporate DNS server) is the problem. A fast failure is a different error: see curl (6) could not resolve host.

Step 3: TCP connect timeouts

A connect timeout means packets are leaving and nothing comes back. That is the signature of a firewall that silently drops (DROP) rather than rejects. A closed port with no firewall fails immediately with curl (7) instead.

Check from outside with the पोर्ट चेकर, then look at:

• A cloud security group or network ACL that does not allow port 443 or 80 from your source address.
• A host firewall such as ufw, firewalld or iptables with a default drop policy.
• A wrong IP: stale DNS pointing at a server that no longer exists.
• IPv6 that is published in DNS but not actually served. Compare curl -4 -I https://example.com/ with curl -6 -I https://example.com/. If only one works, fix or remove the broken AAAA record.
• An outbound proxy requirement on your network. Check env | grep -i proxy.

Step 4: TLS handshake stalls

If the TCP connection succeeds but the handshake hangs, suspect a middlebox or an MTU problem. Large packets such as the server certificate chain get dropped while small ones pass, so the handshake freezes after the first exchange. Try a smaller path MTU test, ping -M do -s 1400 example.com on Linux, and try the request from a different network. Also confirm the server speaks a TLS version your client allows with the TLS वर्शन चेकर. Handshake errors that return immediately are covered in curl (35) SSL connect error.

Step 5: the server accepted the request and did not answer

with 0 bytes received means the web server or its backend is overloaded, deadlocked or waiting on a database. Look at the server side:

1. Check the application and web server logs for requests that never complete.
2. Look at load, memory and worker counts. A saturated PHP-FPM or worker pool queues requests until they time out.
3. If a reverse proxy sits in front, it may be returning 504 on its own timeout. See Fix 504 Gateway Timeout और nginx upstream timed out.

The वेबसाइट स्पीड टेस्ट shows time to first byte from a neutral location, which separates a slow server from a slow local network.

Raise the limit only when the work is legitimately long

Report generation, large downloads and slow APIs can exceed your own --max-time. Set values deliberately, and add retries for transient network failures:

curl --connect-timeout 5 --max-time 120 --retry 3 --retry-delay 2 https://api.example.com/report

Without --max-time, curl waits indefinitely for a response once connected. For scripts and cron jobs, always set both limits so a hung server cannot hang your job.

अगले कदम

• Check the port from outside with the पोर्ट चेकर.
• Run the वेबसाइट हेल्थ चेक for DNS, TLS and response time in one pass.
• Read the connection refused, timed out and reset guide.
• Alert on slow or stuck responses with an अपटाइम मॉनिटर.

सामान्य प्रश्न

What is the default curl timeout?

There is no overall time limit unless you set --max-time. The connection phase has a built-in default of 300 seconds, which is why a silently dropped connection can hang for minutes.

Is a timeout the same as connection refused?

No. Refused means the host answered immediately with a reset, so nothing is listening. A timeout means no answer came back, which usually points to a firewall drop or an unreachable network.

Why does it time out in curl but load in my browser?

Browsers can use a system proxy, try IPv4 and IPv6 in parallel, and have different DNS settings. Compare with curl -4, curl -6 and your proxy environment variables.

Does --retry fix curl error 28?

It retries timeouts and some transient errors, which helps with brief network hiccups. It does not help if a firewall or a hung server is the cause.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.