Ping Works but the Browser Does Not: Separating IP, DNS and Applications

One of the most useful beginner troubleshooting cases is a machine that can ping an IP address but cannot open a website by name. The symptom feels inconsistent only if 'the network' is treated as one thing. In reality, several independent steps have to work: the interface needs an address, the route has to reach the destination, DNS has to translate a name, TCP has to reach the service port, and the application has to speak the expected protocol.

I started separating the tests. First I checked the local interface with ip addr or the equivalent platform command. Then I checked the routing table and default gateway. A ping to the local gateway tests a much smaller path than a ping to a public address. If the gateway is unreachable, there is little value in changing DNS settings.

If a remote IP responds, the Layer 3 path is at least partly functional. That still does not prove that a website should open. ICMP echo and TCP port 80 or 443 are different traffic. Firewalls can treat them differently, and the remote host may answer one but not the other. A TCP test to the actual service port gives better evidence for the application path.

Name resolution is another independent step. If ping 8.8.8.8 works but ping example.com reports that the name cannot be resolved, I look at DNS before touching routes. Tools such as dig or nslookup show whether the resolver is receiving an answer and what address is returned. The configured DNS server itself also has to be reachable. A host can have perfectly good Internet routing and still fail every name-based application if the resolver information is wrong.

The opposite can happen as well. DNS may successfully return an address even though the service is unreachable. That is why seeing an IP appear in a lookup result does not mean the website is healthy. After resolution, the client still needs a transport connection and a valid application exchange. HTTPS adds TLS negotiation and certificate validation on top of TCP, so browser errors can come from a layer that ping never touches.

A simple troubleshooting sequence became much more reliable than random configuration changes: check link, address and mask; check the local route and default route; test the gateway; test a known remote IP; test DNS resolution; test the target service port; then inspect the application. Each step depends on some earlier pieces but isolates a different failure domain.

This is also where I stopped using ping as a verdict. Ping is one probe. It can prove that certain ICMP packets completed a round trip at a particular moment. It cannot prove DNS, TCP, TLS, HTTP or the remote application's health. Once I treated each tool as evidence for a specific layer, network troubleshooting became much more systematic.