You open a terminal, type ping google.com, and get clean replies. Then you switch to Chrome, type the same address, and the page just spins. No error, no explanation, just a blank tab staring back at you.
I ran into this exact problem last year while setting up a small office network for a client in Lahore. The router showed a green internet light, and ping worked perfectly on every machine, yet three out of five laptops couldn’t open a single website.
It took about forty minutes of layer‑by‑layer testing to find the actual cause, and I’ll walk you through that same process here.
This guide explains why ping works but websites don’t open, what’s actually happening at the network layer, and how to fix it with real commands on Windows, Linux, and macOS.
1. Ping and Browsing are two different things
This is the part most people miss. Ping only tests one thing: whether a remote host responds to an ICMP echo request. It doesn’t touch DNS resolution, TLS handshakes, HTTP requests, or your browser’s proxy settings at all.
A website loading in your browser depends on several separate steps working together:
- DNS resolves the domain name to an IP address.
- Your device opens a TCP connection to that IP, usually on port 80 or 443.
- For HTTPS, a TLS handshake negotiates encryption.
- The browser sends an HTTP request and waits for a response.
Ping skips all of that. It only checks step zero – basic reachability using ICMP. So when someone says “ping works but browser not working,” what they’re really describing is a failure somewhere between steps 1 and 4, while ICMP traffic sails through untouched.
Quick Comparison: What Each Protocol Actually Tests
| Test | Protocol Used | Port | What It Proves | What It Doesn’t Prove |
|---|---|---|---|---|
| ping | ICMP | None (no port) | The host is reachable at Layer 3. | DNS works, and HTTP/HTTPS works. |
| nslookup / dig | DNS | 53 | The domain resolves to an IP | The IP actually serves a website. |
| telnet / Test‑NetConnection | TCP | 80 / 443 | The port is open and reachable. | The website returns valid content. |
| curl/browser | HTTP/HTTPS | 80 / 443 | Full-page loads correctly. | Nothing further is needed; this is the goal |
Notice how ping sits at the bottom of this chain. Passing the ping test tells you almost nothing about whether a website will actually load.
2. The Most Common Causes
Cause #1: DNS Resolution Is Broken
This is the single most common reason someone can ping a server but cannot open a website. Your DNS resolver either isn’t responding, is misconfigured, or has been hijacked by malware or a rogue router setting.
Test it directly:
Windows: nslookup google.com
Linux: diggoogle.com
macOS: dig google.com+short
If ping works using a raw IP address (like ping 8.8.8.8) but fails using a domain name (ping google.com), you’ve confirmed the problem is DNS, not connectivity. Fix it by switching to a public resolver:
If that resolves instantly, change your adapter’s DNS to 1.1.1.1 or 8.8.8.8 and flush the cache:
ipconfig/flushdns (Windows)
Sudo system-resolve–flush–caches (Linux, systemd-based)
sudo dscacheutil-flushcache (macOS)
Cause #2: A Proxy or Firewall Is Blocking HTTP/HTTPS
ICMP and HTTP are treated as completely separate traffic types by most firewalls. Many corporate and campus networks explicitly allow ICMP for diagnostics while blocking or filtering outbound HTTP/HTTPS through a proxy.
This produces exactly the symptom people search for as “browser cannot access website” even though basic connectivity checks pass.
Check whether the ports are actually reachable:
Windows (PowerShell):Test-NetConnection google.com -Port 443
Linux /macoS telnet google.com 443
If this hangs or refuses the connection while ping succeeds, something between you and the destination is filtering TCP 80/443 specifically. Check your browser’s proxy settings too a leftover proxy configuration from a VPN or corporate policy is a frequent silent cause.
Cause #3: MTU or Fragmentation Issues
This was the actual cause in my client’s office. Their new router had a slightly lower MTU on the WAN interface after a firmware update.
Small ICMP packets sailed through fine, but larger TLS handshake packets used during HTTPS negotiation got fragmented and silently
dropped by an upstream device that didn’t handle fragmentation correctly.
You can test this with a non‑fragmenting ping at full packet size:
Windows: ping -f-1 1472 google.com
Linux: ping -M do -s 1472 google.com
If you see “packet needs to be fragmented, but DF set,” you’ve found an MTU mismatch. Lowering the MTU on the router’s WAN interface (commonly to 1400 or 1436 for PPPoE/VPN links) resolved it in our case.
Cause #4: Outdated ARP or Routing Table Entries
Occasionally a stale ARP cache or an incorrect route sends your HTTP traffic down a dead path while ICMP happens to use a different, still‑functioning route.
| Commands | Use |
| arp-a | View ARP table,all OSes |
| Arp-d | Windows,clear ARP cache |
| Sudo ip neigh flush all | Linux,clear ARP cache |
| Route print | Windows,view routing table netstat-rn(Linux/macOS,view routing table |
Cause #5: Browser‑Specific Problems
Sometimes the network is fine, and the issue lives entirely inside the browser. Common culprits: a corrupted browser profile,
a misbehaving extension (ad blockers and VPN extensions are notorious), a wrong proxy setting, or DNS‑over‑HTTPS pointing to an unreachable resolver.
Quick isolation test: open the same URL in a different browser or in incognito mode with extensions disabled. If it loads, the problem is local to your original browser, not the network.
Cause #6: HTTPS‑Specific Failures (HTTP Works, HTTPS Doesn’t)
If plain HTTP sites load but HTTPS ones fail, look at certificate trust, system clock accuracy, and TLS inspection software.
A wrong system date is a surprisingly common reason expired‑looking certificates get rejected outright. curl-v https://example.com
The verbose output tells you exactly where the handshake stalls.
3. Real Troubleshooting Scenario
Here’s the exact sequence I used to diagnose that office network issue, in order:
Step 1: Confirmed the symptom. Ping to google.com and 8.8.8.8 both succeeded on the affected laptops. Chrome and Firefox both hung on every site.
Step 2: Tested DNS in isolation. nslookup google.com returned a valid IP immediately; DNS was healthy.
Step 3: Tested the port directly.Test-NetConnection google.com port 443 timed out. This confirmed the failure was at the TCP/TLS layer.
Step 4: Ran a traceroute. It stalled right after the router’s WAN hop a strong clue pointing at the gateway device.
Step 5: Tested MTU with a large non‑fragmenting ping. This immediately returned a fragmentation error, confirming an MTU mismatch on the WAN link.
Step 6: Fixed the MTU value on the router from 1500 down to 1400 and rebooted the WAN interface.
Step 7: Re‑tested. Websites loaded normally on the first try across all affected machines.
4. Your Complete Troubleshooting Checklist
Work through this list in order; each step rules out one layer:
- Ping the domain name to confirm basic reachability
- Ping the same host by raw IP address isolates DNS as a variable
- Run nslookup or dig against your default DNS and against 1.1.1.1
- Test port 443 with Test‑NetConnection or telnet
- Run `curl -v` against the failing HTTPS site
- Run a traceroute and note where the path stalls
- Test with a large, non‑fragmenting ping to check MTU
- Check ARP and routing tables for stale entries
- Flush DNS cache and restart the network adapter
- Try a different browser or incognito mode with extensions off
- Verify system date and time are correct
- Disable any active VPN or proxy temporarily and retest
5. When It’s ISP‑Side, Not Yours
If every device on your network shows the same symptom, and public DNS servers, direct IP pings, and port tests all fail identically, the fault likely sits with your ISP—commonly DNS hijacking, transparent proxy misconfiguration, or upstream routing trouble.
In that case, calling your provider with the exact traceroute output where the path breaks will get you a faster resolution than a generic “internet not working” report.
Frequently Asked Questions
Ping only checks ICMP reachability, not DNS or HTTP/HTTPS. “Internet doesn’t work” almost always means DNS resolution or port 80/443 traffic is blocked, even while ICMP passes freely.
Yes, if you ping a raw IP address like 8.8.8.8 rather than a domain name. Pinging by IP bypasses DNS entirely, which is exactly why it’s the first test in any real diagnosis.
This points to a browser‑level issue—a stuck proxy setting, a bad extension, or a corrupted profile — rather than a network problem, since the underlying connection is clearly functional for at least one app.
Very common. VPNs can lower the effective MTU on your connection and push all traffic through a different DNS resolver, producing the exact “ping works, browsing doesn’t” pattern.
If nslookup returns a correct IP address quickly but Test‑NetConnection or curl to that same IP on port 443 times out, the block is happening at the firewall or proxy layer, not at DNS.
Final Thought
Ping is a starting point, not a diagnosis. The moment you see “ping works but website won’t open,” treat it as a signal to move up the stack: check DNS, then ports, then TLS, then the browser itself. Work through each layer in order, and you’ll find the actual break far faster than randomly restarting the router and hoping.
Author Profile
-
Muhammad Kazim Ali – Owner & Principal Engineer at SubnetLab.com (real-world networking labs).
10+ years in routing, switching & infrastructure design. Helps students, pros & enterprises master networking via practical labs. Based in Lahore, works with ISPs, data centers & tech teams.
📞 +92 343 5201037 (WhatsApp) | ✉️ subnetlab.official@gmail.com | 🌐 subnetlab.com
Latest entries
Network BlogAugust 3, 2026Why Ping Works But Websites Won’t Open (Real Fix)
Network BlogJuly 31, 2026What Is APIPA? 169.254.x.x Meaning, Causes & Fixes
Network BlogJuly 15, 2026IPv6 Subnetting for Beginners:How /48, /56, and /64 Actually Work
Network BlogJuly 10, 2026IP Address Conflict:How to Find, Fix, and Prevent Duplicate IPs