Ping checks reachability and measures round-trip time and packet loss; traceroute reveals the hop-by-hop path a packet takes to reach its destination. Start with ping to confirm a target is reachable, then run traceroute when you need to find which hop or network segment is causing the slowdown or drop.
TL;DR:
- A failed ping does not prove a service is offline, because firewalls may block or limit ICMP while allowing HTTP traffic.
- Treat loss or high latency at one intermediate hop as inconclusive unless it persists through later hops, since routers often limit ICMP replies.
- Linux and macOS use UDP probes by default, while Windows tracert uses ICMP; try TCP probes to port 80 when firewalls hide the path.
- Repeat suspicious traces at different times, then use MTR to test persistent patterns and record timestamps, interface, and results from another endpoint before escalation.
Table of Contents
- What Ping Does: Reachability, RTT, and Loss
- What Traceroute Does: Mapping the Path Hop by Hop
- Why Ping and Traceroute Use Different Protocols and Ports
- How to Run Ping and Traceroute on Windows, Linux, and macOS
- Avoiding Misdiagnosis: Asymmetric Routing and ICMP Quirks
- A Practical Workflow: When to Reach for Each Tool
- How Pingfloat Supports This Workflow in Practice
- What Experienced Diagnosticians Check Before Blaming a Hop
- Run a Live Trace or Monitor Uptime with Pingfloat
- FAQ
- Sources
What Ping Does: Reachability, RTT, and Loss
Ping sends an ICMP Echo Request to a target and waits for an Echo Reply. The time between sending and receiving that reply is the round-trip time, and ping reports it for every probe it sends. Run several probes in a row and you get a picture of both latency and stability rather than a single data point.
The output tells you three things that matter for triage:
- Sent versus received counts, which reveal whether any packets were lost on the way out or back.
- Packet loss percentage, calculated from those counts and usually the first thing worth checking before anything else.
- RTT variation (jitter), which shows whether latency is consistent or spiking, a detail that matters a lot for voice and video traffic.
Ping is a fast sanity check, while traceroute is the localization tool; the two are built to work together, not as substitutes. Fortinet's documentation on running ping and traceroute frames exactly this pairing as standard practice.
One thing to watch for: a failed ping does not always mean a host is down. Many firewalls and routers block or rate-limit ICMP traffic for security reasons, so a target can be perfectly reachable over HTTP or another protocol while silently dropping every ping probe. Treat a single failed ping as a prompt to check further, not as confirmation that a service is offline.
Ping is best used for quick reachability checks, baseline latency measurements before and after a change, and confirming that DNS resolution and basic connectivity are working before you dig deeper.
What Traceroute Does: Mapping the Path Hop by Hop
Traceroute works by exploiting a quirk of how routers handle packet lifespan. Every packet carries a Time To Live value that a router decrements by one each time it forwards the packet; when that value hits zero, the router discards the packet and sends back an ICMP Time Exceeded message identifying itself. Traceroute sends a first probe with a TTL of 1, forcing the nearest router to respond, then increases the TTL by one for each subsequent probe until a response arrives from the destination itself. Microsoft Learn's guidance on using TRACERT describes this incrementing TTL process as the core mechanism behind the tool.
Reading the output is straightforward once you know what each column represents: hop number, then typically three round-trip times from separate probes sent to that hop, then the responding router's hostname and IP address. According to the Linux manual page for traceroute, the tool sends three probes per TTL value by default and prints the RTT for each one, which lets you spot inconsistent hops at a glance. An asterisk in place of a time means that particular probe got no response at all.
Pro Tip: Run the same traceroute two or three times before drawing conclusions. A hop showing loss on one pass but not the next is often just rate-limiting its ICMP replies, not actually dropping your traffic.
Traceroute has real blind spots. Some routers are configured not to send TTL-expired messages, which produces an invisible hop with no identifying information. Others deliberately rate-limit how many ICMP responses they generate per second, which can make a perfectly healthy hop look like it is losing packets. And because the per-hop RTTs measure control-plane ICMP handling rather than the data-plane path your application traffic actually takes, they are not a perfect stand-in for real application latency. For a closer look at probe counts and how to read inconsistent hop timing, our in-depth breakdown of traceroute technique walks through several real examples.
Why Ping and Traceroute Use Different Protocols and Ports
The two tools do not always speak the same language on the wire, and the differences matter when a firewall is involved. Ping almost universally relies on ICMP Echo Request and Echo Reply messages, regardless of operating system.
Traceroute is less consistent across platforms:
- On Linux and macOS, traceroute defaults to sending UDP probes to high-numbered destination ports starting at 33434, according to Linuxize's traceroute command guide.
- Windows tracert uses ICMP Echo Request packets by default instead of UDP.
- Many traceroute implementations support switching probe types with flags such as
-Ifor ICMP or-Tfor TCP, which is useful when a firewall blocks the default probe type. - RFC 4560, which documents remote ping and traceroute management operations, recommends UDP-based probes for remote traceroute specifically because they tend to have a lower failure rate than ICMP across intermediate networks.
This mismatch explains a common troubleshooting trap: a Windows tracert using ICMP can show a dead end or a string of asterisks where a UDP-based traceroute from a Linux box would sail right through, simply because the intervening firewall treats the two protocols differently. If you suspect filtering is hiding part of the path, switching probe type is often more revealing than switching tools.
IPv6 adds its own variants. Most platforms accept a -6 flag to force traceroute over IPv6, and ping6 or ping -6 performs the IPv6 equivalent of a standard ping, using ICMPv6 Echo Request and Reply instead of ICMPv4.
How to Run Ping and Traceroute on Windows, Linux, and macOS
Commands differ slightly by platform, but the logic is the same everywhere: confirm reachability first, then trace the path.
On Windows:
- Run
ping -n 5 example.comto send five Echo Requests instead of the default four and get a slightly steadier read on loss and latency. - Run
tracert -d -h 30 example.comto trace the path without resolving hostnames (-d) and with a maximum of 30 hops (-h), which speeds up the trace considerably since DNS lookups are often the slowest part.
On Linux and macOS:
ping -c 5 example.comsends exactly five probes and then stops, which is cleaner for scripting and logging than letting ping run indefinitely.traceroute -I example.comforces ICMP probes instead of the UDP default, useful when you want traceroute behavior closer to Windows tracert.traceroute -T -p 80 example.comswitches to TCP probes aimed at port 80, which frequently gets through firewalls that block UDP or ICMP outright.traceroute -n example.comskips reverse DNS lookups entirely, which is the fastest way to get a readable trace when you do not need hostnames.
A practical sequence for most troubleshooting tickets: run ping first to confirm the target responds and capture a baseline loss percentage, then run a standard traceroute to see where the path breaks down or latency jumps. If the default probe type gets blocked partway through, switch to TCP or ICMP mode and try again before concluding that a hop is actually unreachable. When reachability looks fine over IPv4 but reports suggest otherwise, confirm with the IPv6 variants too, since dual-stack environments sometimes route traffic very differently depending on which protocol wins.
Avoiding Misdiagnosis: Asymmetric Routing and ICMP Quirks
The most common mistake in reading traceroute output is treating every number on the screen as gospel. A single hop showing elevated latency or occasional timeouts is frequently just that router deprioritizing or rate-limiting its own ICMP responses, not an actual problem with the link carrying your traffic.
A few patterns to keep in mind before pointing fingers at a specific hop:
- Loss on one intermediate hop that does not continue to the destination usually means that hop is simply slow to generate Time Exceeded messages, not that it is dropping your actual packets.
- Asymmetric routing means traceroute only shows the forward path from your machine to the target. The return path can take a completely different route, so a problem that looks like it is happening at hop 8 outbound might actually be a return-path issue invisible to your trace.
- ICMP is often a lower-priority protocol on routers and switches, so ping and traceroute timings can run slower than the real application traffic those same routers are forwarding without delay.
APNIC's guide to interpreting traceroute and MTR makes the asymmetric routing point directly: because a single trace only captures one direction, confirming where a problem actually lives often requires a trace from the other endpoint as well, or at least a second vantage point. Red Hat's comparison of traceroute and tracepath echoes the ICMP deprioritization point, noting that some devices handle ICMP at noticeably lower priority than the traffic you actually care about.
Pro Tip: When a single traceroute looks alarming, run it three more times at different intervals. A pattern that repeats across all four runs is worth escalating; a pattern that only shows up once is probably noise.
When loss or latency looks real and persistent rather than a one-off blip, a continuous tool like MTR is the next step, since it aggregates repeated traceroute and ping measurements per hop over time instead of giving you a single snapshot. Our guide to fixing packet loss with MTR and packet capture tools covers that workflow in more detail, and for a broader walkthrough of network troubleshooting fundamentals, Ventis Consulting's practical guide for IT pros is a useful companion read.
A Practical Workflow: When to Reach for Each Tool
Treat ping and traceroute as the first two steps of a short, repeatable sequence rather than competing options.
- Ping the local gateway, then the target. This isolates whether the problem starts on your own network segment or further out.
- Run traceroute to the target once ping confirms there is a reachability or latency problem worth chasing, and watch for where timeouts or RTT jumps first appear.
- Switch probe type or run MTR if results look inconsistent, since a UDP block or ICMP rate-limiting can masquerade as a real outage.
- Escalate with evidence, not just a screenshot: timestamps, multiple trace runs, the local interface used, and ideally a packet capture if you are handing the issue to an ISP or peering partner.
| Step | Tool | What it confirms |
|---|---|---|
| Reachability check | Ping | Target responds, baseline RTT and loss |
| Path localization | Traceroute | Which hop or segment introduces delay or loss |
| Pattern confirmation | MTR | Whether loss is persistent or a transient blip |
| Escalation evidence | Packet capture, repeated traces | Enough detail for an ISP or peer to act on |
Our five-step traceroute playbook for IT teams walks through this same sequence with worked examples, including what to capture before escalating a ticket to an upstream provider.
How Pingfloat Supports This Workflow in Practice
The techniques above map directly onto tools built for exactly this kind of check. Our traceroute tool runs a hop-by-hop trace from the browser with no installation, which matters when you need a quick second vantage point from outside your own network rather than digging through a terminal on a locked-down machine.
A few things worth knowing about how the pieces fit together:
- Traceroute gives a snapshot of a single path at a single moment, useful for confirming or ruling out a specific hop during active troubleshooting.
- Our uptime monitor complements that by checking a target on a recurring schedule and alerting when it goes down, which catches intermittent problems a one-off trace would miss entirely.
- Our networking reference section covers the underlying terms, including TTL, ICMP, and DNS, for readers who want the background before running their own trace.
Running the examples in this article against our live traceroute tool is a fast way to confirm whether what you are seeing locally matches what a different vantage point reports.
What Experienced Diagnosticians Check Before Blaming a Hop
The habit worth building is correlating ping and traceroute output with logs and timestamps before pointing at a single hop. A trace that looks damning in isolation often lines up with nothing unusual in the application logs, which tells you the real issue is somewhere else.
On a team, standardize how trace files get named and keep them around for trend comparison. A single trace is a snapshot; a folder of traces collected over weeks is a dataset, and it is far more convincing when you need to make a case to an upstream provider.
Before escalating anything, record which local interface you tested from, repeat the test from at least one other endpoint, and attach a packet capture if the issue persists. That combination turns a vague complaint about slowness into evidence someone else can act on.
— Andreas
Run a Live Trace or Monitor Uptime with Pingfloat
Reading a trace on paper only gets you so far. The fastest way to apply everything above is to run it live: our traceroute tool lets you trace a path from the browser in seconds, with no account and no software to install, so you can check a reported problem from a different vantage point the moment a ticket comes in.
A few ways we fit into the workflow:
- Use the traceroute tool for one-off path checks when a user reports slowness or a connection seems to hang partway through.
- Set up the uptime monitor to catch outages and intermittent failures on a schedule instead of relying on someone noticing and reporting them.
- Pair both with our broader suite of diagnostic utilities, including IP lookup and SSL checks, when a single issue touches more than just routing.
Run a free trace now on our traceroute tool, or set up scheduled checks with our uptime monitor so the next outage shows up in an alert instead of a complaint.
FAQ
What is the difference between tracert and ping?
Ping sends ICMP Echo Request and Reply messages to check whether a target is reachable and to measure round-trip time and packet loss. Tracert (the Windows name for traceroute) maps every router hop between your machine and the target by sending probes with increasing TTL values, which reveals where along the path a delay or failure occurs.
How do I check IP ping?
Open a command prompt or terminal and run ping followed by the IP address or hostname, such as ping example.com on Windows or ping -c 5 example.com on Linux and macOS to send a fixed number of probes. The output shows round-trip time for each reply along with a summary of packets sent, received, and lost.
What is the traceroute command in Linux that uses a port number?
Linux traceroute defaults to UDP probes sent to high-numbered ports starting at 33434, as documented in Linuxize's traceroute guide. You can target a specific port directly with a command such as traceroute -T -p 80 example.com, which switches to TCP probes aimed at port 80, often useful for getting through firewalls that block the default UDP range.
What protocol do ping and traceroute use?
Ping uses ICMP Echo Request and Echo Reply messages on virtually every platform. Traceroute varies by operating system: Linux and macOS send UDP probes by default while Windows tracert uses ICMP, and many implementations also support switching to TCP probes to work around firewall filtering, as noted in the Linux traceroute manual page.
Sources
- Use TRACERT to Troubleshoot TCP/IP Problems - Microsoft Learn
- Traceroute command in Linux | Linuxize
- RFC 4560 — Remote Operations MIB (DISMAN REMOPS MIB)
- traceroute(8) — Linux manual page
- How to properly interpret a traceroute or mtr | APNIC Blog