How to Fix Curl Could Not Resolve Host Error in Linux

The curl: (6) Could not resolve host error means curl reached the hostname lookup stage and your system could not turn that name into an IP address. Fixing curl could not resolve host errors starts by separating three different problems: a bad URL, a broken system resolver, or a network path that cannot reach DNS at all.

Most Linux systems use the same resolver path for curl, browsers, package managers, and tools such as SSH. Start with the least invasive checks so you can find the failing layer before changing DNS settings.

Understand curl Could Not Resolve Host Error 6

curl reports error code 6 when the remote host name cannot be resolved. The official curl error list describes this as a host resolution failure, which is different from a refused connection, TLS certificate error, HTTP 404, or timeout.

The error usually looks like this:

curl: (6) Could not resolve host: example.com

Use this quick triage map before editing resolver files:

Check	What It Proves	Likely Next Step
URL hostname	The domain is typed correctly and includes the required subdomain	Fix typos, quoting, or copied install URLs
IP connectivity	The machine can reach the network without DNS	Fix Wi-Fi, Ethernet, routing, VPN, or firewall issues first
dig or nslookup	A DNS server can answer for the domain	Compare with the system resolver path curl uses
getent hosts	The Linux name service path can resolve the host	Check /etc/hosts, NSS, proxy variables, or resolver services
/etc/resolv.conf	The system has usable nameserver entries	Apply a persistent DNS fix through systemd-resolved or NetworkManager

Check URL Syntax Before Changing curl DNS Settings

A copied command can make curl look broken when only the hostname is wrong. This is common with GitHub raw-file URLs: raw.githubusercontent.com is a real raw-content host, while bare githubusercontent.com is not the host used in normal raw download URLs.

Compare both hostnames with DNS:

dig githubusercontent.com A +noall +answer
dig raw.githubusercontent.com A +short

The first command can return no address records, while the second should print one or more IP addresses. If your failing command uses https://githubusercontent.com/..., copy the raw file URL again from GitHub and make sure it starts with https://raw.githubusercontent.com/....

Also quote URLs that contain shell-sensitive characters such as &, ?, #, or ;. Without quotes, the shell can split the URL before curl receives it:

curl -fsSI 'https://example.com/?file=tool&arch=x86_64'

If curl prints URL rejected: Bad hostname, fix the URL syntax first. That message means curl rejected the hostname format before a normal DNS lookup could succeed.

Verify Network Connectivity for curl Host Resolution

Test a known IP address before testing a domain name. This bypasses DNS and tells you whether the machine can reach the network at all:

ping -c 2 -W 2 8.8.8.8

A working network path returns replies and zero packet loss:

2 packets transmitted, 2 received, 0% packet loss

If this check fails with Network is unreachable or 100% packet loss, fix the network layer first. Check Wi-Fi association, Ethernet link state, routing, VPN state, or any upstream firewall before changing DNS servers.

Test DNS Resolution for curl with dig and getent

After the IP test works, query DNS directly with dig:

dig example.com A +short

A successful DNS query prints one or more IP addresses. Relevant output looks like this, although the exact addresses can change:

172.66.147.243
104.20.23.154

An empty response or a SERVFAIL status points to resolver trouble.

Then test the resolver path that curl normally shares with the rest of the system:

getent hosts example.com

A working system resolver returns address records too. IPv4 or IPv6 output is fine:

2606:4700:10::ac42:93f3 example.com
2606:4700:10::6814:179a example.com

If dig works but getent hosts fails, the DNS server can answer but the Linux name service path is not giving curl a usable result. Check /etc/hosts, resolver services, and proxy environment variables before replacing DNS servers.

If dig is unavailable, query DNS with nslookup instead. If neither tool is installed and package installation cannot work because DNS is broken, use getent hosts first because it is part of the normal system libraries on GNU/Linux systems.

Check /etc/hosts for curl Hostname Overrides

The /etc/hosts file overrides DNS for names listed inside it. It cannot create normal public DNS records, but a stale or mistyped entry can send curl to the wrong address or hide the real DNS answer.

Inspect the file:

cat /etc/hosts

A small local file often looks like this:

127.0.0.1       localhost
127.0.1.1       workstation
::1             localhost ip6-localhost ip6-loopback

Search for the failing domain before editing:

grep -nE 'example.com|githubusercontent|raw.githubusercontent.com' /etc/hosts

The -nE flags print matching line numbers and allow one pattern with alternatives. The grep command guide covers broader file-search patterns.

If the command prints a stale mapping for the hostname you are trying to reach, edit the file with root privileges and remove or correct that line:

sudo nano /etc/hosts

Save the file and retry getent hosts for the same hostname. Host file changes take effect immediately.

Configure DNS Servers to Fix curl Resolution

Change DNS servers only after the URL, network path, and hosts file checks point to a resolver problem. Cloudflare 1.1.1.1 and Google Public DNS are common public resolvers, but managed corporate, school, VPN, or split-DNS networks may require their own resolver addresses.

Configure systemd-resolved DNS for curl

Check whether systemd-resolved is active:

systemctl is-active systemd-resolved

An active resolver prints:

active

Edit the resolved configuration:

sudo nano /etc/systemd/resolved.conf

Set global DNS servers under the [Resolve] section:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=1.0.0.1 8.8.4.4

Restart the resolver, then verify the active server list:

sudo systemctl restart systemd-resolved
resolvectl dns

Relevant output includes the configured resolver addresses:

Global: 1.1.1.1 8.8.8.8

Configure NetworkManager DNS for curl

If NetworkManager manages the connection, set DNS on the connection profile instead of editing a generated resolver file. First list active profiles:

nmcli connection show --active

Use the profile name from the NAME column in the next commands. Bringing the profile back up can briefly interrupt network access, so avoid doing this over a remote session unless you have a fallback path.

sudo nmcli connection modify "<connection-name>" ipv4.dns "1.1.1.1 8.8.8.8" ipv4.ignore-auto-dns yes
sudo nmcli connection up "<connection-name>"

Run the DNS and curl verification checks again after the connection comes back up.

Use /etc/resolv.conf as a Temporary curl DNS Fix

Directly editing /etc/resolv.conf is a fallback for systems without systemd-resolved or NetworkManager. Check whether the file is generated before writing to it:

readlink -f /etc/resolv.conf

If the path points under /run/systemd/, use the systemd-resolved method instead. If your system uses a plain resolver file, back it up and write temporary nameservers:

sudo cp /etc/resolv.conf /etc/resolv.conf.backup
printf '%s\n' 'nameserver 1.1.1.1' 'nameserver 8.8.8.8' | sudo tee /etc/resolv.conf

DHCP clients, VPN tools, NetworkManager, and systemd-resolved can overwrite /etc/resolv.conf. Treat direct edits as a rescue step unless you know your system keeps that file static.

Verify the curl Could Not Resolve Host Fix

Check DNS first:

getent hosts example.com

A successful lookup prints one or more address records for the hostname. Then test curl with quiet, failure-aware header flags:

curl -fsSI https://example.com

A working request returns HTTP headers:

HTTP/2 200
content-type: text/html

The flags keep this check clean: -f fails on HTTP error responses, -sS hides the progress meter while still showing errors, and -I requests headers only. For broader transfer examples, see the curl command guide.

Troubleshoot Common curl Host Resolution Errors

curl Fails but dig or nslookup Works

If dig or nslookup resolves the domain but curl still fails, compare the system resolver path and curl-specific environment:

getent hosts example.com
env | grep -iE '^(http|https|all|no)_proxy='

If getent hosts fails, curl is not receiving the same resolver answer as dig. Confirm that the system host lookup order still includes DNS:

grep '^hosts:' /etc/nsswitch.conf

The line should include dns. If it only lists local files or another resolver source, fix that name service configuration before changing curl itself. If proxy variables appear in the earlier output, curl may be resolving the proxy host or sending DNS through the proxy path instead of directly resolving the target domain.

Temporarily clear proxy variables in the current shell when you need a direct test:

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY http_proxy https_proxy all_proxy

If your network requires a proxy, fix the proxy hostname or NO_PROXY list instead of leaving those variables unset permanently.

Temporary Failure in Name Resolution

Many Linux tools show this resolver-level error when DNS is unavailable:

ping: google.com: Temporary failure in name resolution

This usually means the resolver service has no usable nameserver, the network is not ready yet, or the current resolver cache is stale. On systems using systemd-resolved, restart the resolver and query again:

sudo systemctl restart systemd-resolved
resolvectl query google.com

Relevant output includes an address line for the queried host:

google.com: 142.250.195.174 -- link: wlp3s0

The address and link name vary by network, but the hostname should return at least one address.

If the system does not use systemd-resolved, reconnect the network profile or restart the network manager your distro actually uses.

GitHub raw.githubusercontent.com Fails in curl

Queries for githubusercontent.com often come from copied install commands with the wrong host. Test the exact host from the URL:

getent hosts raw.githubusercontent.com
curl -fsSI https://raw.githubusercontent.com

If raw.githubusercontent.com resolves but githubusercontent.com does not, DNS is not the real problem. Replace the URL with the complete raw GitHub URL from the project page.

Raspberry Pi curl Could Not Resolve Host Errors

On Raspberry Pi systems, especially fresh Wi-Fi or Pi-hole setups, the same checks apply. Confirm the Pi has a route, then verify the exact installer or repository host before running any script:

ping -c 2 -W 2 8.8.8.8
getent hosts install.pi-hole.net

If the IP ping works but the hostname lookup fails, fix DNS on the Pi or router first. If both fail, troubleshoot Wi-Fi, Ethernet, DHCP, or gateway configuration before rerunning curl.

Use curl --resolve Only for Temporary Testing

The --resolve option can force one hostname and port to a specific IP address for a single curl command. It is useful for testing DNS suspicion, virtual hosts, or a known endpoint, but it is not a system DNS repair.

curl --resolve raw.githubusercontent.com:443:185.199.108.133 -fsSI https://raw.githubusercontent.com

Use this only when you know the current IP address is valid for that host. Public service IPs can change, and hardcoding one address can break later even if it works once.

Conclusion

curl host resolution is healthy when the URL is correct, the machine can reach the network, getent hosts returns an address, and curl -fsSI reaches the same hostname. Keep nslookup DNS queries handy for cross-checking resolver answers when the next failure looks like a DNS problem rather than an HTTP or TLS issue.