What is the difference between curl error 6 and curl error 7?

They fail at different stages, and the distinction is the fastest way to narrow the problem. Error 6 — 'Could not resolve host' (CURLE_COULDNT_RESOLVE_HOST) — happens during name resolution, before curl has an IP address to connect to. Nothing has touched the network path to the server yet, so it is never a firewall, closed-port, or server-down issue. Error 7 — 'Failed to connect' (CURLE_COULDNT_CONNECT) — happens after resolution succeeded: curl has an IP, tried to open a TCP connection to it, and was refused or couldn't reach it. So if you see 6, look at DNS and proxy configuration; if you see 7, the name resolved fine and you should look at the port, the firewall, or whether the service is actually up.

nslookup and dig resolve the name fine, but curl still says (6). Why?

This is the classic tell that the problem isn't your DNS at all — it's a proxy environment variable. curl reads http_proxy, https_proxy, and no_proxy (and their uppercase forms) from the environment. dig and nslookup don't. If https_proxy points at a proxy host that itself can't be resolved, or the proxy is down, curl fails at the resolution step — but the name it can't resolve is the proxy's, not your target's. Run 'env | grep -i proxy' to see what's set. A stale proxy variable left in a shell profile or a container's environment is one of the most common causes of a (6) that makes no sense next to a working dig.

Why does curl fail to resolve a hostname that works in my browser?

Usually because the browser and curl are resolving through different paths. The name might be an internal or VPN-only hostname your browser reaches through a system proxy or VPN DNS that curl on the command line isn't using. Or the browser has its own DNS cache or secure-DNS (DoH) setting that curl ignores in favor of the system resolver in /etc/resolv.conf. Check whether the name is meant to be public at all, whether you're on the VPN curl expects, and what /etc/resolv.conf actually points at.

curl: (6) Could not resolve host: Fix DNS

What This Error Is Telling You

curl: (6) Could not resolve host is a DNS failure, and knowing that rules out half the internet before you touch anything. curl got as far as trying to turn the hostname into an IP address and couldn’t. It never opened a connection, never sent a byte to the server, never checked a port. So whatever you’re tempted to blame — the firewall, the remote server being down, a bad certificate — none of it is in play yet. The name didn’t resolve, and that’s a problem at your end of the wire, in resolution.

That’s genuinely good news, because it means the causes are a short, checkable list. The internal error code is CURLE_COULDNT_RESOLVE_HOST, and there are really only three families of reason it fires.

Rule Out the Typo First

It’s boring and it’s often the answer. A hostname with a transposed letter, a stray space, a copied-in zero-width character, or htttp:// mangling the parse will all produce a (6). Read the exact name in the error back against what you meant to type. If you’re building the URL in a script, echo it right before the curl call — a variable that expanded to empty turns https://$HOST/api into https:///api, and curl can’t resolve an empty host either.

Separate “My Resolver Is Broken” from “curl Is Special”

Once the name looks right, the single most useful move is to resolve it without curl:

getent hosts example.com     # or: dig example.com  /  nslookup example.com

This splits the problem cleanly in two:

The name doesn’t resolve here either. Then it’s your system resolver or the DNS itself. Check /etc/resolv.conf points at a working nameserver; check you’re on the VPN or network where that name is valid; check the domain actually exists and hasn’t expired or lost its records. A container is a frequent offender — a minimal image may ship with no resolver configured, or inherit a nameserver it can’t reach.
The name resolves fine with dig/getent, but curl still says (6). Then the DNS is healthy and something specific to curl is in the way. The usual culprit is a proxy environment variable (see the FAQ) — curl honors http_proxy / https_proxy / no_proxy and the other tools don’t. Less often it’s a curl built without a working resolver backend, or a --resolve / --connect-to override you forgot was there.

The Proxy Trap

This deserves its own callout because it wastes so much time. If https_proxy is set to a proxy that’s misspelled, decommissioned, or unreachable, curl tries to resolve the proxy’s hostname, fails, and reports (6) — pointing the blame at your target host, which was never the issue. Symmetrically, if a host should bypass a working proxy but isn’t listed in no_proxy, curl routes it through the proxy and inherits the proxy’s resolution failure. Check the environment:

env | grep -i proxy

Clear or fix what’s stale, and re-run. In containers and CI, these variables are often injected globally and forgotten.

Diagnose with DechoNet

DNS Lookup resolves the hostname from outside your machine, over public resolvers. That’s the tie-breaker: if DechoNet returns an address but your local getent/dig doesn’t, the name is fine on the public internet and your problem is local — your resolver, your VPN, your /etc/resolv.conf, or a proxy variable. If DechoNet also can’t resolve it, the record genuinely doesn’t exist (typo, expired domain, or missing A/AAAA), and no amount of local fixing will help.

Verification Checklist

Re-read the exact hostname in the error for typos, stray characters, or an empty variable.
Resolve the name without curl (getent hosts, dig, or nslookup) to isolate resolver vs. curl.
If only curl fails, run env | grep -i proxy and clear any stale http_proxy / https_proxy; add the host to no_proxy if it should bypass one.
Confirm /etc/resolv.conf lists a nameserver you can actually reach (especially inside containers).
Confirm you’re on the network or VPN where the name is supposed to be valid.
Confirm with an external DNS lookup that the record exists at all — that separates a local problem from a genuinely missing record.

When It’s Actually Error 7 in Disguise

If the name resolves everywhere and curl still won’t complete, look again at the error number. Once resolution succeeds, curl stops reporting (6) and moves on to connecting — a refused connection is (7) Failed to connect, a stall is (28) timeout. Those are port, firewall, and server-health problems, not DNS, and they’re a different guide. The moment your error stops being (6), you’ve left name resolution behind.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.