🚨 Linux Error: curl: (6) Could not resolve host — Cause, Fix, and Troubleshooting Guide

Summary

curl: (6) Could not resolve host is curl’s exit code 6 (CURLE_COULDNT_RESOLVE_HOST): curl asked getaddrinfo() to turn the URL’s hostname into an IP and got nothing back. It is a DNS/name-resolution failure at the client, before any TCP connection is attempted — so it is never a firewall, port, or server-down problem. Fix DNS and curl works.

Common Symptoms

• curl https://example.com prints curl: (6) Could not resolve host: example.com.
• curl https://1.1.1.1 (a raw IP) connects fine while hostnames fail.
• wget, apt, pip, and git fail with their own resolution errors at the same time.
• The failure is instant (no connect timeout), confirming it never left the resolver.

Most Likely Causes of the ‘curl: (6) Could not resolve host’ Error

1. No working nameserver — /etc/resolv.conf is empty, wrong, or a dangling symlink.
2. systemd-resolved down — the 127.0.0.53 stub is not listening, so every lookup fails.
3. Typo in the hostname or a name that genuinely does not exist in DNS.
4. A proxy env var pointing at an unresolvable proxy — http_proxy/https_proxy set to a bad host.
5. Container inherited broken DNS from the host’s resolv.conf.
6. Missing search domain for a short/internal hostname.

Quick Triage

# Isolate DNS from connectivity: does raw IP connect?
curl -sSI https://1.1.1.1 --resolve one.one.one.one:443:1.1.1.1 -o /dev/null -w '%{http_code}\n' 2>&1 | tail -1
curl -v https://example.com          # watch for the resolution line

# Does the OS resolver see the name at all?
getent hosts example.com

# Any proxy hijacking the request?
env | grep -i proxy

Diagnostic Commands

# Resolution through the real NSS path curl uses
getent hosts example.com

# Direct DNS queries: configured resolver vs a known-good one
dig example.com
dig @1.1.1.1 example.com +short
nslookup example.com

# What resolver config is in effect
cat /etc/resolv.conf
resolvectl status

# Prove it is DNS by bypassing it entirely (skip resolution)
curl -v --resolve example.com:443:93.184.216.34 https://example.com

# Verbose trace — the '*   Trying' / 'Could not resolve' lines
curl -v https://example.com

# Is the stub resolver up and is 53 reachable?
systemctl status systemd-resolved
ss -tulpn | grep ':53'
nc -vz 1.1.1.1 53

# Resolver-side errors
journalctl -u systemd-resolved --since "10 min ago"

If curl --resolve succeeds with a hardcoded IP but plain curl fails, you have proven the problem is DNS and not the server.

Fix / Remediation

1. Restart the stub resolver (Ubuntu/Debian):

   sudo systemctl restart systemd-resolved
   getent hosts example.com
   curl -sSI https://example.com | head -1

2. Unset a bad proxy if env | grep -i proxy showed a broken host:

   unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY
   curl -sSI https://example.com | head -1

3. Repair resolv.conf / nameservers:

   # Ubuntu (systemd-resolved managed):
   sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
   sudo resolvectl dns <IFACE> 1.1.1.1 8.8.8.8
   
   # RHEL/Rocky (NetworkManager):
   sudo nmcli con mod "<CONN>" ipv4.dns "1.1.1.1 8.8.8.8"
   sudo nmcli con up "<CONN>"

   Warning: Hand-editing /etc/resolv.conf on a managed host is temporary — DHCP or the network stack rewrites it. Use resolvectl/nmcli for a durable fix.

4. Add a search domain or /etc/hosts entry for internal/short names:

   echo '10.0.3.20  internal-api internal-api.corp.example.com' | sudo tee -a /etc/hosts

5. Containers — pass DNS explicitly (docker run --dns 1.1.1.1 ...) instead of editing inside the container.

Validation

getent hosts example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com   # e.g. 200
curl -sSI https://example.com | head -1

curl should complete without exit code 6.

Prevention

• Configure redundant nameservers via resolvectl/nmcli, not raw resolv.conf edits.
• Keep proxy env vars in one managed place so a stale value cannot silently break curl.
• Add --connect-timeout / --max-time and --retry to scripted curl calls so DNS blips degrade gracefully.
• Monitor systemd-resolved and run synthetic curl/getent checks for critical endpoints.

Related Errors

• Temporary failure in name resolution
• Name or service not known
• Connection refused
• Connection timed out
• Docker: Temporary failure in name resolution

Final Notes

Exit code 6 is unambiguous: curl never got an IP for the hostname, so it is always a resolver problem, never the remote server. Prove it with curl --resolve against a hardcoded IP, then fix DNS at the stub resolver or nameserver level and re-test with getent hosts.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.