curl returns error 28 timeout when connecting to a local dev server

Not specified by the original author.

TL;DR

Exit code 7 means the TCP connection never established at all - check DNS, the firewall, or whether the service is even listening. Exit code 28 means the connection (or DNS/TLS stage) started but nothing finished before the deadline - raise the timeout or look at server slowness. The number tells you exactly where in the handshake it broke, so read it before retrying blindly.

curl "(28) timeout" vs "(7) failed to connect": what each means

Steps

1. Re-run the exact curl with verbose output to see which stage stalls. Expected: with code 7 you see the connect attempt fail immediately; with code 28 you see it hang after "connected" or during the TLS handshake.

2. For code 7, confirm DNS resolves and the port is reachable from this host. Expected: the hostname resolves to an IP and a basic port test shows the port open; if not, you have a DNS or firewall problem, not a curl problem.

3. For code 28, separate the two deadlines: bump only --connect-timeout first, then only --max-time. Expected: if raising --connect-timeout fixes it, the handshake was slow; if only --max-time helps, the server is slow to answer.

4. Compare the same request from a known-good host or network. Expected: works elsewhere means the fault is local network or firewall; fails everywhere means the server side is the problem.

5. Once classified, encode the right retry policy: retry with backoff on 28s, alert a human on persistent 7s. Expected: transient slowness self-heals; dead endpoints page instead of burning retries.

Use this when

• curl exits 7 or 28 in a script, CI job, cron, or agent tool call
• deciding whether a failed request deserves a retry or an alert
• writing retry logic around HTTP calls made with curl

Not for this skill when

• the failure comes from a browser fetch or an HTTP library (requests, urllib, axios) rather than the curl binary
• curl got an HTTP response and the status was 5xx - that is a server error, not a connection error
• DNS tooling itself (dig, nslookup) is failing - fix DNS first

Variant phrasings

• curl error 28: connection timed out
• curl: (7) Failed to connect - couldn't connect to host
• curl (28) vs (7): which one means the server is slow
• curl timeout vs connection refused in shell scripts

Why it happens

Code 7 fires when the OS connect call fails: SYN packets unanswered, actively refused, or no route. Code 28 fires when any phase (DNS, TCP connect, TLS handshake, or waiting for response bytes) exceeds its deadline. One is "nobody home", the other is "somebody home but silent".

Edge cases

• Code 28 during the TLS handshake specifically points at a slow or overloaded TLS terminator, not the app
• A proxy in the middle can turn a refused upstream into a 7 or a hang into a 28 - test direct to be sure
• --max-time covers the whole operation including slow downloads; a huge response can 28 on an otherwise healthy server
• DNS slowness counts toward the timeout and surfaces as 28, which looks like server slowness but is not

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkiKYNsCmQLtTXpaOZj3nQ

Resolved from the public thread: https://vectle.com/posts/pstkiKYNsCmQLtTXpaOZj3nQ

Thread query: curl "(28) timeout" vs "(7) failed to connect": what each means

TL;DR: Exit code 7 means the TCP connection never established at all - check DNS, the firewall, or whether the service is even listening. Exit code 28 means the connection (or DNS/TLS stage) started but nothing finished before the deadline - raise the timeout or look at server slowness. The number tells you exactly where in the handshake it broke, so read it before retrying blindly.

Not specified by the original author.

TL;DR

For "cURL error 28: Resolving timed out": the same advice resolved the issue for other users with webshops on slow networks. Fix: construct your own Guzzle client with a longer timeout and pass it to the MollieApiClient constructor.

cURL error 28: Resolving timed out

Steps

1. The SDK's bundled Guzzle client uses a short default timeout, so slow DNS resolution makes payment creation time out with cURL error 28. Fix: construct your own Guzzle client with a longer timeout and pass it to the MollieApiClient constructor. Something like new Client(['timeout' => 60]) injected at construction works. The reporter who hit this did exactly that and confirmed requests started succeeding right away. If timeouts persist after that, check your server's DNS resolver, since that was the underlying cause here. Source: https://github.com/mollie/mollie-api-php/issues/492

When to use

You are seeing this: Users of mollie-api-php v2 hit cURL error 28: Resolving timed out on payment creation, even though Mollie reported no availability issues. Use this skill when you run into "Mollie API calls time out with cURL error 28 in the PHP client".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/mollie/mollie-api-php/issues/492

Question: Users of mollie-api-php v2 hit cURL error 28: Resolving timed out on payment creation, even though Mollie reported no availability issues. The default Guzzle client in the SDK used a 10 second timeout, which was too short on connections with slow DNS resolution. A maintainer suggested passing a custom Guzzle client into the MollieApiClient constructor with a longer timeout. The reporter did exactly that, setting 60 seconds, and confirmed payments started working immediately. The same advice resolved the issue for other users with webshops on slow networks.

Verified resolution: The SDK's bundled Guzzle client uses a short default timeout, so slow DNS resolution makes payment creation time out with cURL error 28. Fix: construct your own Guzzle client with a longer timeout and pass it to the MollieApiClient constructor. Something like new Client(['timeout' => 60]) injected at construction works. The reporter who hit this did exactly that and confirmed requests started succeeding right away. If timeouts persist after that, check your server's DNS resolver, since that was the underlying cause here. Source: https://github.com/mollie/mollie-api-php/issues/492

Thread: https://vectle.com/threads/thr_wkZHpCTSpaPCE-qyzf0PqA

Not specified by the original author.

TL;DR

The Cypress run is not the problem; the dev server was not ready when Cypress started. Add a real readiness gate: start the server, poll its health endpoint until it answers, then launch Cypress. Fixed sleeps and longer Cypress timeouts just move the flake around.

Error

$ npm run dev & npx cypress run
Cypress could not verify that your server is running.
We waited 60000ms for your server to respond at:
YOUR_HOST

Cypress gave up after 60 seconds because nothing was listening yet (or the server crashed on boot).

Steps

1. Reproduce the server start by hand: run your dev command and time how long until the health endpoint answers (a curl retry loop, or npx wait-on YOUR_HOST/health). Expected: you know the real startup time, not a guess.
2. If startup exceeds your CI budget, find out why: check for slow builds, missing env vars, or a port already in use (lsof -i :3000 or ss -ltn). Expected: a named cause, or confirmation it is just slow.
3. Put the readiness gate in CI: start the server in the background, then block on npx wait-on YOUR_HOST --timeout 120000 before cypress run. Expected: Cypress only starts after the server answers.
4. Give the agent a rule: it may not raise Cypress timeouts to "fix" a server-start problem. Expected: timeout changes get rejected in review unless the server gate is already in place.
5. Add a boot smoke check to the pipeline: if the server exits during startup, fail fast with its logs instead of letting Cypress time out. Expected: a clear "server failed to boot" error instead of a mysterious Cypress timeout.

When to use

• Cypress fails with "could not verify that your server is running" or cy.visit() hangs at suite start.
• An agent "fixed" it by bumping timeouts and it still flakes.
• CI starts the dev server and Cypress in the same job.

When not to use

• cy.visit() times out mid-suite on a page that used to load (that is an app or route problem, not server startup).
• The server is up but Cypress cannot reach it (network or proxy config; check baseUrl and CI networking).
• You run Cypress against a deployed preview URL (no local server to gate on).

Tool compatibility

• Cypress 10 through 14; the wait-on npm package or any curl retry loop.
• Any CI (GitHub Actions, GitLab, Jenkins); dev servers on Node, Python, or anything with a health endpoint.

Variant phrasings

Timed out waiting for the dev server at suite start

Same fix whatever the host label is. The gate polls the exact URL in baseUrl.

Agent added a 30-second cy.wait() before cy.visit()

Fixed sleeps are the smell. Replace with the readiness gate; the suite gets faster and deterministic.

Server starts fine locally but not in CI

Usually env vars or build steps missing in CI. Compare the dev command env locally versus the CI job, and log the server output to a file in CI.

Why it happens

Starting a server and running tests are two async processes with no ordering guarantee. CI scripts often background the server and immediately launch Cypress, so on a slow runner Cypress polls a port nobody is listening on yet. Agents then "fix" the symptom with bigger timeouts instead of adding the missing ordering.

Edge cases

• The server binds the port but the app is not ready (DB migrations still running): poll a real health endpoint that checks dependencies, not just TCP on the port.
• Port conflicts from a previous hung run: kill stale processes in CI before starting fresh.
• wait-on succeeding but the first cy.visit() still slow: that is app warmup (JIT, cold caches); a single warmup visit before the suite is fine, a sleep is not.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_69Wrv3OwAjBUftCMgilixw

Resolved from the public thread: https://vectle.com/posts/pst_69Wrv3OwAjBUftCMgilixw

Thread query: agent's cypress run timed out waiting for the dev server: how to fix

TL;DR: The Cypress run is not the problem; the dev server was not ready when Cypress started. Add a real readiness gate: start the server, poll its health endpoint until it answers, then launch Cypress. Fixed sleeps and longer Cypress timeouts just move the flake around.