Beyond the ping

“I can’t get this website to load.”

As common help requests go, this sort of ticket can cause any tech to roll their eyes in anticipation of wasting time on a wild goose chase. If example.com isn’t working for one of your users, it could be caused by any of a dozen or more points of failure—everything from the user making a simple typo to a major Internet outage.

In between those two extremes, the problem could exist on the user’s computer, or at the web server itself, or any link in the long chain that connects the two. It could also be a temporary glitch that fixes itself before you can track it down.

NB: The command line tools I mention in this post are generally preinstalled on Mac and Linux, and are mostly available on Windows as optional downloads. These same tasks can be run from various web-based tools, but if the problem involves connecting to websites, that’s not really an option is it?

“Give me a ping, Vasily. One ping only, please.”

The first tool most troubleshooters will turn to when diagnosing a network problem is the old reliable ping. The Internet Control Message Protocol (ICMP) utilized by the ping command is so foundational to the functioning of the Internet, it’s designated as Internet Protocol number one. (Transmission Control Protocol, the TCP part of TCP/IP, is number six.)

While a successful ping can tell you that the server you’re trying to reach is in fact reachable and currently online, it’s not much help beyond that. There are also too many false negative scenarios to rule anything out from a failure.

The next step up from ping is traceroute (abbreviated tracert on Windows) or the more capable mtr (originally “Matt’s Trace Route”). Either tool will send a series of pings not only to the destination but to each router that sits between you and that server. The resulting report should tell you if the problem exists at one end of the connection or at a specific link along the chain.

As helpful as this is, it still relies on ping to do its job. The problem server may be online and functioning normally but ignoring ICMP traffic or your firewall rules could be blocking the response.

And most of the time the problem is DNS anyway.

What’s in a name?

You can get to example.com from your computer, but it still won’t load for the user. Maybe the trouble isn’t even with example.com but with the user’s DNS resolution. (I could go into a long sidebar about how the domain name system works, but this article explains it better than I could: https://computer.howstuffworks.com/dns.htm)

ping relies on DNS to come up with where to send its packets, so you’ll need to try some different tools to check if DNS is working.

nslookup—the Name Server Lookup utility—exists on Mac, Linux, and Windows. There’s also dig, but it’s not typically installed on Windows by default. Either one will query the default DNS server and return where that server thinks example.com resides. Like so:

nslookup example.com

Often the trouble with your ISP’s default DNS server is that everyone connected to your ISP is using it. ISP servers get overloaded and slow, and while your Internet speeds are still snappy, every site you go to feels sluggish because of the delay in resolving the domain for each connection. Luckily, plenty of alternatives exist, including public DNS servers run by companies with a stake in the Internet’s infrastructure like Cloudflare, Cisco, and Google. Obviously, if you can’t reach Google you have bigger problems than not being able to load one random website.

So, this command will look up example.com using Google’s public DNS instead:

nslookup example.com 8.8.8.8

If you get a different response from 8.8.8.8 than you do from your default settings, then the problem is with your DNS server.

Netcat, not to be confused with LOLcats

netcat (or its modern replacement ncat) is a network testing Swiss army knife. Like ping, it can make connections to a remote server to see if it’s online. But unlike ping, netcat can connect to any port and listen for a response on any protocol.

For instance, to properly test a web server, you need to try and connect to it on the ports a web browser would use, primarily 80 and 443—for HTTP and HTTPS respectively. To do that, you would do this:

nc -z example.com 80

nc -z example.com 443

And to determine if that DNS server you’re using is actually listening for DNS requests on UDP port 53:

nc -uz dns.example.com 53

Detangling curls

If the server is showing signs of life with ping and netcat but still not giving you anything useful when you try it with a web browser, get a more useful web browser.

The command line URL downloader, curl, negotiates the same connections a graphical browser can but curl will tell you what it’s doing at every stage. Give this command a shot:

curl -Lv https://example.com

The -L option tells curl to follow redirects and other server responses that normally tell a browser that the page it’s looking for has moved. Verbose mode, invoked with -v, can sometimes be just the trick you need to discover why that website isn’t loading in Chrome. Unfortunately, the problem might still be on the server’s side and there’s nothing you can do about it.

Then it’s time to file the ticket “unresolved” and move on to something you can actually fix.