Why Ping Works on IP But Not Hostname – DNS Fix Guide

What Does It Mean When Ping Works on IP But Not Hostname?

When you open a command prompt and type ping 8.8.8.8, you get a successful reply. But the moment you try ping google.com, it fails with an error like “Ping request could not find host” or “Name or service not known.” This is one of the most common and misunderstood networking problems, and it tells you something very specific: your internet connection is working, but your system cannot translate hostnames into IP addresses.

Every domain name on the internet is just a human-friendly label mapped to a numeric IP address. When you ping a hostname, your operating system first contacts a DNS (Domain Name System) server to resolve that name into an IP. Only after receiving the IP does the actual ping begin. So when ping works on IP but not hostname, the network path itself is fine — the breakdown is happening during this name resolution step, before any ICMP packet is even sent.

This distinction matters because it immediately narrows the troubleshooting scope. You are not dealing with a firewall block, a dead router, or a cable issue. The problem sits squarely in the DNS layer — either your machine is not reaching a DNS server, the server is not responding correctly, or something local is interfering with the lookup process.

For deeper diagnostics, running a continuous ping with timestamps can help identify exactly when packet loss, latency spikes, or routing issues occur. See our guide on ping with timestamp command explained.

Network rack with router, switch, and patch panel illustrating infrastructure involved when diagnosing DNS issues.
A realistic representation of the physical infrastructure that carries DNS and ICMP traffic.

Why Hostname Resolution Fails While IP Works

To understand why hostname resolution fails while IP-based connectivity remains intact, it helps to know what happens behind the scenes during a ping to a domain name. Your system follows a specific resolution order, often called the name resolution sequence. On Windows, this typically checks the local DNS cache first, then the hosts file, then queries the configured DNS server. On Linux, the behavior is governed by /etc/nsswitch.conf and /etc/resolv.conf. If any step in this chain is broken or misconfigured, the hostname never gets resolved — and the ping never even attempts to reach the target.

There are several reasons this chain can break. The DNS server configured on your adapter might be unreachable or unresponsive. Your local DNS cache might hold a corrupt or expired entry. The hosts file could contain a conflicting mapping that silently overrides the correct one. In some cases, IPv6 DNS queries are prioritized over IPv4, and if the IPv6 DNS path is non-functional, the resolution silently fails even though IPv4 connectivity is perfectly healthy.

What makes this issue tricky is that it does not always produce an obvious error. Some applications fall back to cached data or secondary resolvers, so a browser might partially work while ping consistently fails. Other times, the failure is intermittent — DNS works for a few minutes, then drops. This inconsistency often leads people to blame their ISP or router when the root cause is a local configuration problem that takes less than a minute to fix. The sections ahead walk through each cause systematically and provide exact commands to resolve them.

Common Causes of This Issue

Before jumping into fixes, it is important to identify exactly what is causing the hostname resolution to fail. The causes listed below cover the vast majority of scenarios where ping works on IP but not hostname. Each one targets a different part of the DNS resolution chain, so understanding them individually helps you apply the right fix on the first attempt instead of guessing.

DNS Cache Problems

Your operating system maintains a local DNS cache to speed up repeated lookups. When you visit a website or ping a hostname, the resolved IP address is stored temporarily so the system does not have to query the DNS server again for the same name. This works well under normal conditions, but the cache can become a problem when entries expire incorrectly, become corrupted after a network change, or hold stale data from a previously configured DNS server.

A corrupted DNS cache is one of the most frequent reasons why ping by IP works but not by name. The system believes it already has the answer locally, but the cached entry is either invalid or points nowhere. Instead of forwarding the query to an external DNS server, it fails immediately based on bad local data. This is especially common after switching between Wi-Fi networks, reconnecting through a VPN, or changing DNS settings without flushing the old cache.

Wrong or Slow DNS Servers

Every network adapter on your system has one or more DNS server addresses configured — either assigned automatically via DHCP from your router or set manually. If the configured DNS server is unreachable, overloaded, or misconfigured, hostname resolution will fail entirely. The ping to an IP address bypasses DNS completely, which is why it continues to work while hostname-based pings do not.

This issue commonly appears when an ISP’s default DNS server experiences downtime or heavy load. It also surfaces in corporate environments where internal DNS servers go offline or when a router hands out its own IP as the DNS server but fails to forward queries properly. A slow DNS server may not cause an outright failure but can trigger timeouts that make it appear as though hostname resolution is broken.

Hosts File Conflicts

Before querying any DNS server, most operating systems check a local hosts file. On Windows, this file is located at C:\Windows\System32\drivers\etc\hosts. On Linux and macOS, it resides at /etc/hosts. This file contains static hostname-to-IP mappings that override DNS entirely.

If someone — or some software — has added an incorrect entry to this file, it can silently redirect or block hostname resolution for specific domains. Malware is a known culprit for injecting hosts file entries that redirect legitimate domains to localhost (127.0.0.1) or invalid addresses. Even a stray entry left behind by a developer testing a local server can cause hostname ping failures that seem inexplicable until the hosts file is inspected.

IPv6 DNS Priority Issue

Modern operating systems prefer IPv6 over IPv4 by default. When your system attempts to resolve a hostname, it may send a DNS query over IPv6 first. If your network does not fully support IPv6 — or if the IPv6 DNS server is not configured correctly — this query fails silently. The system may not always fall back to IPv4 gracefully, resulting in a hostname resolution failure even though IPv4 DNS would have worked perfectly.

This is a particularly deceptive cause because most users are unaware that IPv6 is even active on their system. The network appears to function normally for direct IP communication, but the DNS lookup path is quietly broken on the IPv6 side. Disabling IPv6 DNS priority or forcing IPv4 resolution can resolve the problem instantly.

Two devices connected to a router during troubleshooting of ping IP working but hostname failing.
Two systems connected to the same router illustrate contrasting diagnostic paths used during DNS troubleshooting.

Quick Fixes You Can Try First

Now that you understand the common causes behind why ping works on IP but not hostname, the next step is to apply targeted fixes. The three methods below address the most frequent culprits and can be executed in minutes. Start with these before moving to advanced solutions — in most cases, one of them will resolve the issue immediately.

Flush DNS Cache

Since a corrupted or stale DNS cache is the most common cause, clearing it should be your first action. Flushing the cache forces your system to discard all stored DNS records and perform fresh lookups the next time any hostname is requested.

On Windows, open Command Prompt as Administrator and run:

ipconfig /flushdns

You should see a confirmation message stating the cache was successfully flushed. On Linux, the command depends on the DNS service your distribution uses. For systems running systemd-resolved:

sudo systemd-resolve --flush-caches

On macOS, use:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

After flushing, try pinging a hostname again. If the issue was caused by a bad cached entry, resolution should work immediately. If it does not, the problem lies elsewhere in the DNS chain, and the next fix targets that directly.

Switch to Public DNS

If your current DNS server is unresponsive or slow, switching to a reliable public DNS provider can bypass the problem entirely. Google Public DNS and Cloudflare DNS are two widely used options known for their speed and uptime.

  • Google DNS: 8.8.8.8 and 8.8.4.4
  • Cloudflare DNS: 1.1.1.1 and 1.0.0.1

To change your DNS on Windows, open Command Prompt as Administrator and run:

netsh interface ip set dns "Ethernet" static 8.8.8.8
netsh interface ip add dns "Ethernet" 1.1.1.1 index=2

Replace "Ethernet" with the name of your active network adapter. You can find it by running netsh interface show interface.

On Linux, edit /etc/resolv.conf and replace existing nameserver lines with:

nameserver 8.8.8.8
nameserver 1.1.1.1

On macOS, go to System Settings > Network > Your Connection > DNS and add the preferred addresses there.

After changing DNS, flush the cache again using the command from the previous step. Then test with ping google.com. If you now receive replies, your previous DNS server was the root cause. You can either keep the public DNS or investigate why your original server was failing.

Reset Winsock and TCP/IP

If flushing DNS and switching servers did not help, the issue may be deeper — at the level of your system’s network stack. Winsock is the Windows component that handles how applications interact with network services, including DNS. A corrupted Winsock catalog or TCP/IP configuration can silently break hostname resolution while leaving raw IP connectivity unaffected.

To reset both, open Command Prompt as Administrator and run these commands in sequence:

netsh winsock reset
netsh int ip reset

After executing both commands, restart your computer. This is not optional — the reset does not take full effect until the system reboots. Once you are back in, test hostname ping again.

On Linux, equivalent recovery involves restarting the network manager service:

sudo systemctl restart NetworkManager

This reset approach is particularly effective when the DNS issue appeared suddenly after a software installation, system update, or malware removal. It restores the networking configuration to a clean baseline without affecting your files or applications.

Telecommunications infrastructure at dusk representing the global DNS and internet backbone network.
Large-scale telecommunications infrastructure supporting global DNS and internet connectivity.

Advanced Solutions

If the quick fixes did not resolve the problem, the cause is likely rooted in a specific configuration conflict rather than a general DNS failure. The solutions below require slightly more technical effort but target precise scenarios that basic troubleshooting often misses. Each one addresses a different layer of the resolution chain — local file overrides, protocol preference, and adapter-level DNS assignment.

Edit Hosts File Manually

When hostname resolution fails for specific domains while others work fine, the hosts file is a prime suspect. As covered earlier, this file overrides DNS for any hostname it contains. Inspecting and cleaning it manually can eliminate silent conflicts.

On Windows, open Notepad as Administrator, then navigate to:

C:\Windows\System32\drivers\etc\hosts

On Linux and macOS, open the file with a terminal editor:

sudo nano /etc/hosts

Look for any entries that map the failing hostname to an incorrect or local IP address. A clean hosts file should contain only a few default lines, typically mapping localhost to 127.0.0.1 and ::1. If you see entries pointing real domains like google.com or microsoft.com to 127.0.0.1 or 0.0.0.0, those are almost certainly problematic — either leftover from ad-blocking software, development tools, or in some cases, malware.

Remove or comment out any suspicious entries by adding a # at the beginning of the line. Save the file and test hostname ping again. If the issue was caused by a hosts file conflict, resolution will immediately begin working for the affected domains.

Force IPv4 Resolution for Ping

If your system is sending DNS queries over IPv6 and the IPv6 DNS path is broken, you can force ping to use IPv4 exclusively. This bypasses the IPv6 resolution attempt entirely and sends the query through the functional IPv4 DNS path instead.

On both Windows and Linux, use the -4 flag:

ping -4 google.com

If this command succeeds while a regular ping google.com fails, the problem is confirmed to be IPv6-related. To make this change persistent on Windows, you can reduce IPv6 priority through a registry adjustment. Open Command Prompt as Administrator and run:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0x20 /f

This does not disable IPv6 entirely — it only tells Windows to prefer IPv4 over IPv6 for DNS and general connectivity. A reboot is required for this change to take effect. On Linux, you can configure preference in /etc/gai.conf by uncommenting or adding the line:

precedence ::ffff:0:0/96  100

This instructs the system to prefer IPv4-mapped addresses over native IPv6 during name resolution.

Check Network Adapter DNS Settings

Sometimes the DNS server your system is actually using is not the one you expect. This happens when multiple network adapters are active — for example, a physical Ethernet connection and a VPN adapter — or when DHCP assigns a DNS server that differs from what you configured manually.

On Windows, verify which DNS server each adapter is using:

ipconfig /all

Scroll through the output and locate the active adapter. Check the DNS Servers field. If it shows an unexpected address — such as your router’s IP when you intended to use a public DNS — the DHCP assignment is overriding your manual setting.

On Linux, check the active resolver configuration:

cat /etc/resolv.conf

Or, if using systemd-resolved:

resolvectl status

If the listed DNS server is incorrect or unreachable, update it directly in the adapter settings or in your router’s DHCP configuration to push the correct DNS to all connected devices. After correcting the adapter-level DNS, flush the cache one more time and test with a hostname ping to confirm resolution is working end to end.

Macro view of Ethernet network interface hardware used when diagnosing hostname resolution ping failures.
A close inspection of the hardware layer that enables physical packet transmission.

Final DNS Resolution Checklist

Before closing out your troubleshooting session, run through this checklist to confirm that hostname resolution is fully restored and stable. Each item corresponds to a fix or verification step covered in this guide.

  • Flush DNS cache — Run the appropriate flush command for your OS and confirm it completes without errors.
  • Verify DNS server — Use ipconfig /all on Windows or resolvectl status on Linux to confirm your system is pointing to a responsive DNS server.
  • Test hostname ping — Run ping google.com and confirm you receive replies with a resolved IP address.
  • Test multiple hostnames — Ping at least two or three different domains to rule out a single-domain issue caused by the hosts file.
  • Check hosts file — Open the hosts file and verify no rogue entries are overriding DNS for the domains you are testing.
  • Confirm IPv4 vs IPv6 behavior — Run ping -4 google.com and compare results with a standard ping google.com to rule out IPv6 DNS failure.
  • Validate with nslookup — Run nslookup google.com to test DNS resolution independently from ping. If nslookup succeeds but ping does not, the problem is local to how ping handles resolution, not DNS itself.

If every item on this checklist passes, your DNS resolution is working correctly. If hostname ping still fails after completing all steps, the issue likely exists outside your local machine — either at the router level, within your ISP’s DNS infrastructure, or due to a network policy (such as a corporate firewall blocking outbound DNS on port 53). At that point, contact your ISP or network administrator with the specific test results you have gathered. Providing them with outputs from ipconfig /all, nslookup, and ping -4 will significantly speed up their diagnosis.

FAQ – Common Questions & Answers

Why does ping work on IP but not hostname?

This happens because ping to an IP address bypasses DNS entirely. When you ping a hostname, your system must first resolve that name to an IP through a DNS server. If the DNS server is unreachable, misconfigured, or if local settings like the hosts file or DNS cache interfere, the resolution fails — even though the underlying network connection is perfectly functional.

How do I fix hostname resolution in ping?

Start by flushing your DNS cache using ipconfig /flushdns on Windows or the equivalent command on your OS. If that does not work, switch to a public DNS server like Google DNS (8.8.8.8) or Cloudflare (1.1.1.1). Check your hosts file for conflicting entries and verify your network adapter is using the correct DNS server through ipconfig /all or resolvectl status.

Should I change my DNS server?

If your current DNS server is slow, unreachable, or causing resolution failures, switching to a public DNS provider is a practical solution. Google DNS and Cloudflare DNS offer high reliability and fast response times globally. For most home users, using a public DNS server is safe, straightforward, and often improves both resolution speed and consistency compared to ISP-assigned defaults.

What does flushing DNS actually do?

Flushing DNS clears your operating system’s local cache of stored hostname-to-IP mappings. This forces your system to perform fresh DNS lookups for every hostname instead of relying on potentially stale or corrupted cached records. It does not change your DNS settings or affect your network configuration — it simply wipes the temporary lookup table and lets it rebuild naturally.

Can IPv6 cause this problem?

Yes. Many systems prioritize IPv6 DNS resolution over IPv4 by default. If your network does not fully support IPv6 or if the IPv6 DNS path is misconfigured, hostname queries sent over IPv6 can fail silently. Using ping -4 to force IPv4 resolution or adjusting your system’s protocol preference can resolve this without disabling IPv6 entirely.

How do I test if DNS is working properly?

Use nslookup followed by a hostname, such as nslookup google.com. This tool queries your configured DNS server directly and reports whether it received a valid response. If nslookup returns an IP address, your DNS is functioning. If it times out or returns an error, your DNS server is either unreachable or not responding — confirming that DNS is the root cause of the hostname ping failure.


In summary, when ping works on IP but not hostname, the issue is always DNS — never the network path itself. The fix usually takes less than five minutes once you identify whether the cause is a stale cache, a bad DNS server, a hosts file conflict, or an IPv6 priority problem. Work through the checklist methodically, and the resolution will surface. If all local fixes are exhausted and the problem persists, your ISP’s DNS infrastructure is the next place to investigate — contact them with your test results and request a DNS server status check on their end.

Leave a Comment