Quick Summary
- Ping uses raw IP (ICMP) and does not need DNS -- browsing needs DNS to translate domain names to IP addresses
- If you can ping 8.8.8.8 but not google.com, you have a DNS resolution problem, not a network problem
- Firewalls can block ports 80 (HTTP) and 443 (HTTPS) while still allowing ICMP ping traffic through
- The fix is usually as simple as changing your DNS server or adjusting a firewall rule
Why Ping and Browsing Are Different
This is one of the most common and confusing networking problems beginners encounter. You open a terminal,
type ping 8.8.8.8, and get perfect replies. Everything looks fine. But when you open your browser
and try to visit any website, nothing loads. The page just spins and eventually times out.
The confusion comes from assuming that if ping works, the internet works. But ping and web browsing use completely different protocols and depend on different services. Ping sends a tiny ICMP (Internet Control Message Protocol) packet directly to an IP address. It does not need DNS, does not use port 80 or 443, and does not involve any application layer processing. It is the simplest possible network test -- can this machine reach that IP address? That is all it checks.
Web browsing, on the other hand, is a complex chain of operations. First, your browser must resolve the
domain name (like google.com) to an IP address using DNS. Then it must establish a TCP connection
on port 443 (HTTPS) or port 80 (HTTP). Then it must perform a TLS handshake for encrypted connections. Only
then can it actually request and receive the web page. If any single step in this chain fails, your browser
shows an error -- even though ping works perfectly fine.
Diagnostic Flowchart
Follow this decision tree to pinpoint exactly where the problem is:
Try It Yourself: Diagnostic Flowchart
Walk through the same decision tree interactively. Answer each question to diagnose the problem.
The Three Most Common Causes
When ping works but browsing does not, the problem almost always falls into one of these three categories. Let us walk through each one.
DNS Resolution Failure
This is the most common cause by far. When you type ping 8.8.8.8, you are giving ping a raw IP
address -- no DNS lookup is needed. But when your browser tries to reach google.com, it first needs
to ask a DNS server to translate that name into an IP address. If your DNS server is misconfigured, unreachable,
or returning errors, the browser cannot even begin to connect. You will see errors like "DNS_PROBE_FINISHED_NXDOMAIN"
or "This site can't be reached." To test this directly, run nslookup google.com in your terminal.
If it fails or times out, you have confirmed a DNS problem. The quickest fix is to manually set your DNS servers
to a known-good public resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).
Firewall Blocking HTTP/HTTPS Ports
Firewalls can be configured to allow ICMP (ping) traffic while blocking TCP ports 80 (HTTP) and 443 (HTTPS).
This is actually a common security configuration in corporate and school networks. Ping uses the ICMP protocol
which operates at the network layer -- it does not use TCP or UDP ports at all. Web browsing requires TCP connections
to specific ports. If a firewall sits between you and the internet and it blocks outgoing connections on ports
80 and 443, your browser will time out even though ping works fine. You can test this with
curl -v https://google.com -- if the connection hangs at "Connecting to..." then the port is being
blocked. Check your local firewall rules with iptables -L (Linux) or your network administrator for
corporate firewalls.
Proxy or Browser Misconfiguration
Sometimes the network is perfectly fine but the browser itself is misconfigured. If your browser is set to use a proxy server that no longer exists or is unreachable, every web request will fail -- but ping, which does not use the browser or any proxy settings, will work normally. This is common in corporate environments where proxy settings were applied via group policy and then the proxy was decommissioned. Check your browser's proxy settings (usually under Settings > Network or System > Proxy). Also check for browser extensions that might be intercepting traffic, or try using a different browser or an incognito/private window to rule out extension interference.
Your Diagnostic Checklist
Run through these commands in order. Each one narrows down the problem. By the end, you will know exactly what is broken and how to fix it.
Step 1: Ping an IP
Run ping 8.8.8.8 to confirm basic network connectivity. If this fails, your problem is not
DNS -- it is your network connection, gateway, or ISP. Check cables, Wi-Fi, and your default gateway.
Step 2: Ping a Domain
Run ping google.com. If the IP ping worked but this fails with "could not resolve host," you
have confirmed a DNS problem. Your network works but DNS does not.
Step 3: Test DNS Directly
Run nslookup google.com or dig google.com. These tools query DNS directly and show
you which DNS server is being used and whether it responds. If they fail, change your DNS server.
Step 4: Test HTTP/HTTPS
Run curl -I https://google.com. This makes an actual HTTPS request, testing TCP port 443, DNS,
and TLS all at once. If DNS works (Step 3 passed) but curl fails, a firewall is blocking ports 80/443.
Step 5: Check Firewall
On Linux, run sudo iptables -L -n to see active firewall rules. On Windows, check Windows Defender
Firewall settings. Look for rules blocking outgoing traffic on ports 80 and 443. On macOS, check
pfctl -sr.
Step 6: Check DNS Config
On Linux/Mac, check /etc/resolv.conf to see which DNS servers your system uses. If the file is empty
or points to an unreachable server, replace it with nameserver 8.8.8.8 or nameserver 1.1.1.1.
Real-World Scenarios
Here are the most common situations where this problem shows up and how to fix each one:
VPN Just Disconnected
When a VPN disconnects, it sometimes leaves your DNS settings pointing to the VPN's internal DNS server, which is no longer reachable. Your network still works (ping succeeds) but DNS queries go to a dead server. Fix: disconnect and reconnect your VPN, or manually reset your DNS settings.
DHCP Gave Bad DNS
Your router's DHCP server might hand out DNS server addresses that are wrong or no longer valid. This is especially common with misconfigured home routers or after switching ISPs. Fix: manually set DNS servers on your device instead of relying on DHCP, or fix the router's DHCP configuration.
Corporate Firewall / Captive Portal
Hotel and airport Wi-Fi often requires you to log in through a captive portal before allowing full internet access. ICMP (ping) might be allowed immediately, but HTTP/HTTPS is redirected until you authenticate. Fix: open a browser and visit any HTTP site (not HTTPS) to trigger the portal login page.
Understanding the Protocol Stack
To really understand why ping and browsing behave differently, you need to know that they operate at different layers of the networking stack. Ping uses ICMP, which lives at Layer 3 (the Network layer) alongside IP itself. ICMP packets are handled directly by the operating system's network stack and do not involve any ports, TCP connections, or application-layer processing.
Web browsing, in contrast, involves every layer of the stack. It starts with DNS (application layer, using UDP port 53), then opens a TCP connection (transport layer, using port 443), then performs a TLS handshake (session/presentation layer), and finally sends and receives HTTP requests and responses (application layer). Each of these steps can fail independently. A firewall might allow ICMP and DNS but block TCP port 443. Or DNS might work but the destination server might be down. Understanding these layers is the key to efficient troubleshooting -- you test from the bottom up, layer by layer, until you find the one that is broken.
This layered approach is exactly what professional network engineers use. They do not randomly try fixes. They systematically test each layer, starting with physical connectivity, then IP reachability (ping), then DNS, then TCP ports, then application protocols. Each test either passes or fails, and each failure points to a specific layer and a specific type of problem.
Frequently asked questions about this troubleshooting scenario
Why does ping work but my browser can't load websites?
Ping only tests raw IP reachability via ICMP. A browser additionally needs DNS, a TCP connection on port 80 or 443, and a TLS handshake. Any one of those can break independently — most commonly DNS or a firewall blocking ports 80/443 — while ping still succeeds.
How do I test whether the problem is DNS?
Run nslookup google.com or dig google.com. If those fail or hang, your DNS resolver is broken — even though ping 8.8.8.8 works. Quick fix: change your DNS to 1.1.1.1 or 8.8.8.8.
Can a firewall block web traffic while allowing ping?
Yes — common on corporate, hotel, and school networks. ICMP, TCP/80, and TCP/443 are independent filter rules. Test with curl -v https://example.com to see if the TCP connect hangs.
What is a captive portal?
A captive portal is the login page hotel, café, and airport WiFi networks force you through. Until you sign in, HTTP traffic is intercepted and redirected — but ping is allowed. Try visiting an HTTP (not HTTPS) site to trigger the portal page.
Why does this happen after I disconnect from a VPN?
VPNs often push their own DNS server while connected. When the VPN drops, those DNS settings can stick around, pointing at a now-unreachable internal resolver. Reconnect cleanly, restart the interface, or manually reset DNS to 1.1.1.1.
Try the troubleshooter
You just learned why ping can succeed while the browser fails. Now diagnose it in a pre-broken lab where ping gets through and the web connection does not: trace both, find out why, and fix it.
Launch the Works Locally But Not Remotely lab →