ping, traceroute, nslookup: Three Commands That Close Most Tickets

Network monitoring platforms and packet analyzers are powerful, and there's a time for them. But when someone calls to say "the network is slow" or "I can't reach the server," I start with three commands that come with every computer: ping, traceroute and nslookup.

I used them constantly as a Network Support Engineer at an internet service provider, and again while supporting more than 1,200 users at a manufacturing plant. Between them, they answer three essential questions:

1. Can I reach it? (ping)
2. Where does the path break or slow down? (traceroute)
3. Is the name resolving correctly? (nslookup)

This article explains what each command does, how to read the results and how to use them together.

ping: can I reach it?

Ping sends a small message called an ICMP echo request to a destination and waits for a reply. It tells you whether the destination answers and how long the round trip takes.

How to run it

• Windows: ping 192.168.1.1 (sends four requests by default)
• macOS and Linux: ping -c 4 192.168.1.1 (otherwise it runs until you stop it)

What to look at

• Replies or timeouts. Replies mean the destination is reachable. "Request timed out" or "Destination host unreachable" means something is in the way.
• Time (latency). Measured in milliseconds. A local device usually responds in a few milliseconds. Sites across the country might take 30 to 80 ms. Sudden jumps or very high numbers suggest congestion or a weak link.
• Packet loss. The summary shows how many replies came back. Even a few percent of loss can make video calls and remote sessions feel broken.

How I use it in practice

I ping in steps, moving outward from the user:

1. The device's own default gateway (usually the router or core switch).
2. A server inside the organization.
3. A public IP address on the internet.

The first step that fails tells me where to look. If the gateway doesn't answer, the problem is local: cable, Wi-Fi, switch port or the device's network settings. If the gateway answers but nothing beyond it does, the problem is further upstream.

A caution about ping

Many firewalls block ICMP on purpose. A server that doesn't answer ping may still be running perfectly. So ping is great evidence when it succeeds, and only a clue when it fails. If ping fails, I confirm with another test, such as connecting to the service's actual port.

traceroute: where does it break?

If ping tells you whether you can reach a destination, traceroute shows you the path. It lists each router, or "hop," along the way, along with how long each one takes to respond.

How to run it

• Windows: tracert example.com
• macOS and Linux: traceroute example.com

How it works, briefly

Every packet has a "time to live" value that drops by one at each router. When it reaches zero, the router discards the packet and sends a message back. Traceroute sends packets with increasing time-to-live values, so each router along the path reveals itself in turn.

What to look at

• Where the trace stops. If hops respond up to a point and then show only asterisks, the problem may be at or just beyond the last responding hop.
• Where latency jumps. A sudden increase that continues for every hop afterward points to a slow link at that stage. A jump at one hop that disappears at the next usually means that router simply gives traceroute replies low priority, which isn't a real problem.
• Whether traffic goes where you expect. Unexpected paths can reveal routing mistakes, or traffic leaving through the wrong internet connection.

How I use it in practice

At the ISP, traceroute helped show whether a customer's problem was inside their home, on our network or further out on the internet. That distinction mattered: it decided whether we needed to send a technician, escalate to the network team or explain that the issue was with another provider.

Inside a company, it helps separate internal problems from external ones. If the trace dies before leaving the building, it's an internal network issue. If it reaches the internet provider and then struggles, it's time to call the provider, with evidence in hand.

Asterisks aren't always bad

A row of asterisks means a hop didn't respond within the time limit. Many routers are configured not to answer traceroute at all. If later hops respond normally, an asterisk in the middle is nothing to worry about.

nslookup: is the name right?

Many "network" problems are really name resolution problems. The connection works, but the device can't turn a name into an address, or gets the wrong address.

How to run it

• nslookup example.com (works on Windows, macOS and Linux)
• nslookup example.com 1.1.1.1 to ask a specific DNS server
• On macOS and Linux, dig example.com gives more detail

What to look at

• Which server answered. Is it the DNS server you expected?
• Whether there's an answer. A timeout means the DNS server isn't responding. "Non-existent domain" means it answered but has no record of that name.
• Which address came back. Is it the right one? Compare it with what you expect, or with the answer from a different DNS server.

How I use it in practice

If ping by IP address works but ping by name fails, I go straight to nslookup. Comparing the answer from the normal DNS server with a public resolver quickly shows whether the problem is the name itself or the server being asked.

Using all three together

The real power comes from using them as a sequence. Here's a common example.

A user says a cloud application is "down." I check:

1. nslookup for the application's address. It returns a valid address, so DNS is fine.
2. ping to the gateway, then to a public IP. Both succeed with low latency, so the local network and internet connection are fine.
3. traceroute to the application's address. The trace leaves the building normally, crosses the provider's network and then stops responding near the application's hosting network.

The conclusion: the problem is very likely on the application provider's side, not ours. I check the provider's status page, record the results in the ticket and let the user know what's happening and what workaround is available. Instead of guessing, I have a clear, evidence-based answer within minutes.

Common misreadings to avoid

These tools are simple, but their output is easy to misread. Here are the mistakes I see most often.

"Ping failed, so the server is down." Not necessarily. The server may block ICMP, or a firewall between you and it may drop ping while allowing real traffic. Confirm by testing the actual service, for example with Test-NetConnection server -Port 443 in PowerShell, or nc -vz server 443 on Linux.

"One slow hop means a slow network." Routers treat traceroute replies as low priority. A single hop with high latency, followed by normal hops, usually isn't a problem. It's the hop where latency rises and stays high that matters.

"nslookup works, so DNS is fine." nslookup queries DNS servers directly and can skip parts of how the operating system resolves names, such as the local cache or the hosts file. If nslookup returns the right address but applications still fail, flush the cache and check the hosts file.

"It works for me, so it works." Testing from the help desk's own network doesn't prove anything about a user in another building, on Wi-Fi or on a VPN. Whenever possible, run the commands from the affected device, or from the same network segment.

"Low latency means everything is fine." Ping uses tiny packets. A connection can show good ping times and still struggle with large transfers because of packet loss under load, a duplex mismatch or a saturated link. If users report slowness but ping looks fine, run a longer ping during the slow period and watch for loss.

Why these matter for security too

These commands are also basic reconnaissance tools, which is why attackers use them and why defenders need to understand them. Unusual volumes of ping sweeps across a network can signal someone mapping it. Traceroute can reveal internal network structure. DNS lookups are one of the richest sources of evidence in an investigation.

Knowing exactly what these tools show, and what they reveal about your own network, helps you decide what to block, what to monitor and what's normal.

Quick reference

• ping answers "Can I reach it, and how fast?" Use it in steps, from the gateway outward.
• traceroute / tracert answers "Where on the path does it break or slow down?"
• nslookup / dig answers "Is the name resolving to the right address?"
• Write down every result in the ticket. Good evidence saves the next person from repeating your work.

Which command do you reach for first?