Curl Error (6): Couldn't Resolve Hostname

The "curl error (6): couldn't resolve hostname" in WSL 1 is a known limitation caused by how Windows 10 handles DNS resolution for the legacy subsystem. Unlike WSL 2, which has its own virtual network adapter and DHCP client, WSL 1 shares the host's network stack directly but often fails to inherit the correct DNS server configuration from the Windows interface. This results in an empty or incorrect /etc/resolv.conf file within the Linux environment, preventing any domain name lookups from succeeding.

Understanding the Root Cause

The fundamental difference between WSL 1 and WSL 2 dictates why this specific error occurs. WSL 2 utilizes a lightweight utility VM with a NAT network, allowing it to manage its own networking settings independently of the Windows host’s primary interface. In contrast, WSL 1 operates as a translation layer that runs directly on the Windows kernel. While this provides better performance for certain I/O operations, it creates a dependency on the Windows host’s network configuration being perfectly mirrored in the Linux filesystem. In modern versions of Windows 10 and 11, Microsoft changed how DNS servers are exposed to WSL 1 instances. Previously, the /etc/resolv.conf file was automatically generated to include the DNS servers assigned to your active Windows network adapter. However, due to changes in the Windows networking stack, this automatic population often fails, leaving the file empty or pointing to invalid addresses. When curl attempts to resolve a URL like google.com, it queries the nameserver specified in this file. If the file is misconfigured, the query times out, resulting in the critical error code 6. This issue is distinct from general connectivity problems. You can often ping IP addresses directly (e.g., ping 8.8.8.8) successfully because ICMP packets do not require DNS resolution. The failure is isolated strictly to name resolution. For more context on general internet connectivity issues in Linux environments, you might find Troubleshooting: Cannot Connect to the Internet helpful, although the underlying mechanism here is specific to the WSL 1 architecture.

Verifying the Current Configuration

Before applying fixes, you must confirm that the DNS configuration is indeed the culprit. Open your WSL 1 terminal and check the contents of the resolv.conf file. Run the following command:

cat /etc/resolv.conf

If the output is empty, contains only comments, or lists IP addresses that are not valid DNS servers for your network, you have confirmed the problem. You can also test resolution manually using nslookup or dig. If these commands hang or return "server failed" errors while ping works, the diagnosis is solid. Note that editing this file directly is usually ineffective because WSL 1 regenerates it upon every restart, overwriting any manual changes. Therefore, the solution must address the source of the configuration rather than the symptom.

Solution 1: Manually Set DNS Servers

Since the automatic generation process is broken in many WSL 1 installations, the most reliable workaround is to manually populate the /etc/resolv.conf file with public DNS servers. Google Public DNS and Cloudflare DNS are widely available and highly reliable for this purpose. First, open the file with elevated privileges using a text editor like nano or vim. You may need to use sudo if your user account does not have write permissions to system files, although typically WSL users have access to their home directory.

sudo nano /etc/resolv.conf

Delete any existing content in the file and add the following lines. These specify Google’s primary and secondary DNS servers:

nameserver 8.8.8.8
nameserver 8.8.4.4

Save the file and exit the editor. Immediately test your connection by running:

curl https://www.google.com

If the command returns HTML content or redirects without error, the issue is resolved. Be aware that this change is not persistent across reboots in the same way a static configuration would be in a traditional Linux distribution. You may need to reapply this fix after significant Windows updates or if WSL detects a change in the host network state. To make this easier, you can create a simple alias or script in your .bashrc that reapplies these settings automatically.

Solution 2: Upgrade to WSL 2

While the prompt specifically addresses WSL 1, it is important to note that Microsoft has deprecated WSL 1 for new development scenarios. The networking limitations described above are inherent to the architecture of WSL 1 and cannot be fully patched by configuration tweaks alone. WSL 2 resolves this entirely by providing a full Linux kernel inside a Hyper-V virtual machine, complete with its own DHCP client and network interface. If you are able to upgrade, you can convert your existing WSL 1 distribution to WSL 2 using the PowerShell command:

wsl --set-version Ubuntu-20.04 2

Replace Ubuntu-20.04 with the name of your specific distribution. Once converted, the DNS resolution will work out-of-the-box because WSL 2 manages its own network stack. This is the long-term recommended solution for any developer facing persistent networking issues in WSL 1. For those interested in similar troubleshooting steps for other Linux distributions, see Kali Linux: Troubleshooting Temporary Failure in Name Resolution, as the principles of fixing resolv.conf are largely identical.

Solution 3: Check Windows Network Adapter Settings

In some rare cases, the issue stems from Windows itself not correctly assigning DNS servers to the active network interface. If you are on a corporate network or using a custom VPN, the DNS settings might be restricted or blocked from propagating to WSL 1. Open the Windows Settings app and navigate to Network & Internet > Status > View your network properties. Check the IPv4 DNS Servers section. Ensure that valid IP addresses are listed. If they are blank, you may need to manually configure them in the adapter settings via the Control Panel. After updating Windows network settings, restart the WSL instance completely by running:

wsl --shutdown

Then restart your WSL session. This forces WSL 1 to re-query the Windows host for the current network configuration. If the Windows adapter now has valid DNS entries, WSL 1 should ideally pick them up, though this behavior is inconsistent across different Windows builds.

Frequently Asked Questions

Why does ping work but curl fail?

Ping uses ICMP packets which communicate directly via IP addresses, bypassing the need for domain name resolution. Curl requires a DNS lookup to translate a domain name like "example.com" into an IP address before it can connect. If the DNS resolver is broken, the lookup fails, but the raw network path remains intact.

Will editing resolv.conf persist after a reboot?

No, in WSL 1, the /etc/resolv.conf file is often regenerated or overwritten when the WSL instance starts or stops. Manual edits will be lost unless you automate the process using a startup script or alias in your .bashrc profile to rewrite the file each time you open a terminal.

Can I use wslconfig to fix this in WSL 1?

No, the [wsl2] section in the .wslconfig file applies exclusively to WSL 2. WSL 1 does not support custom network configurations through this file because it relies entirely on the Windows host’s networking stack. Attempting to configure DNS via .wslconfig in WSL 1 will have no effect.

How do I check my current DNS servers in Windows?

You can view your active DNS servers by opening Command Prompt and running ipconfig /all. Look for the "DNS Servers" entry under your active network adapter. These are the addresses that WSL 1 attempts to use, but often fails to read correctly.

Is upgrading to WSL 2 difficult?

Upgrading is straightforward and reversible. You can use the wsl --set-version command to convert your distribution. Most applications and tools work identically, though you may notice slight differences in file system performance depending on whether you are accessing files from within WSL or from Windows.