Every engineer has run the same incantation a thousand times: ping to see if a host is up, traceroute to see where packets die, dig to check a DNS record. These tools are decades old, universally available, and genuinely good at their jobs — which is exactly why almost nobody questioned them. But the same wave of Rust and Go tooling that modernized the rest of the command line has reached network diagnostics, and the new tools are not merely prettier. They combine multiple legacy tools into one coherent view, expose information the originals never surfaced, and produce machine-readable output that fits modern automation. When you are staring at a latency problem at 2 a.m., the difference between scrolling walls of traceroute text and watching a live per-hop latency chart is the difference between minutes and an hour.
This guide covers the modern terminal network toolkit as it stands in 2026, organized by the question you are actually trying to answer: where is the latency, what is the route doing, and is DNS lying to me. The headline tools are Trippy, which fuses ping and traceroute into one rich TUI, and doggo, a modern DNS client that speaks the encrypted protocols dig barely touches. Along the way it places them against the classics so you know when the old tool is still the right call.
Why the classics needed an upgrade
The traditional tools are excellent at their narrow jobs, but they share a few limitations that show up precisely when you are under pressure. The first is fragmentation: diagnosing a slow connection means running ping to measure latency, traceroute to find the path, and mtr to combine them — three tools, three mental models, three output formats. The second is shallow output: traceroute tells you the hops but not the per-hop packet loss over time, the jitter, or which autonomous system owns each hop. The third is text-only, human-only output: parsing dig or traceroute output in a script means brittle regex against formats that were designed for eyes, not programs. And the fourth, increasingly important, is protocol coverage: dig predates the encrypted-DNS era and has limited support for DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC, which are now how a great deal of real-world DNS actually travels.
None of this means the classics are bad. It means there is room for tools that combine their functions, deepen their output, emit structured data, and cover modern protocols — which is exactly what the new generation does. The right framing is not "replace everything" but "reach for the tool that answers your question fastest," and increasingly that is one of the modern ones.
Where is the latency? Trippy
Trippy (the binary is trip) is the standout modern network diagnostic tool, and it earns the spot by collapsing the ping + traceroute + mtr workflow into a single live interface. Point it at a host and it continuously probes every hop along the path, showing for each one the packets sent and received, loss percentage, and a full latency distribution — last, average, best, worst, and standard deviation. Instead of a static snapshot, you get a living view that updates as conditions change, which is what you need when chasing intermittent problems.
What makes Trippy more than a prettier mtr is the depth. It does jitter analysis, so you can distinguish a link that is slow-but-stable from one that is erratic — a crucial difference for diagnosing voice and video quality. It integrates GeoIP and AS lookups, so each hop can be annotated with its location and the network that owns it, turning "packets slow down at hop 8" into "packets slow down when they enter this specific transit provider." It supports ICMP, UDP, and TCP probes, which matters because many networks rate-limit or drop ICMP; switching Trippy to TCP probes against port 443 often reveals a path that ICMP-based tools cannot trace at all. And it can trace multiple targets simultaneously from one instance, so you can compare two upstreams side by side in real time.
For automation, Trippy is not TUI-only. It emits report, JSON, CSV, and streaming output modes, so the same tool that gives you an interactive chart during an incident can produce a structured artifact to attach to a ticket or feed into a monitoring pipeline. A typical incident workflow is to run trip interactively with AS information to eyeball where the path degrades, switch to TCP probes if ICMP is being dropped, and then capture a JSON report for the record. The Trippy cheatsheet covers the full option surface.
Is DNS lying to me? doggo
DNS is the cause of an embarrassing share of "the network is down" incidents, and doggo is the modern client for interrogating it. It does what dig does — query any record type against any resolver — but with output designed for humans (clean, colorized, tabular) and for machines (a --json mode that pipes straight into jq). For everyday checks, doggo --short example.com gives you just the answer without dig's verbose ceremony, and doggo example.com MX TXT checks mail configuration in one command.
The more important advantage is protocol coverage. Modern DNS increasingly travels encrypted, and doggo speaks all of it: DNS-over-HTTPS (@https://...), DNS-over-TLS (@tls://...), DNS-over-QUIC (@quic://...), and DNSCrypt, in addition to plain UDP and TCP. This matters for two reasons. First, you can actually test the resolvers your users hit — if your application talks to a DoH endpoint, querying it over plain UDP tells you nothing useful, whereas doggo can query the exact transport in play. Second, you can diagnose whether an encrypted resolver is the problem by comparing its answer to an authoritative one. When a record looks wrong, the ability to ask several resolvers over several transports and compare is what isolates a caching or propagation issue from an actual misconfiguration.
doggo also handles the diagnostic staples cleanly: reverse lookups with --reverse, query timing with --time, and DNSSEC checks. It sits alongside the venerable dig rather than fully replacing it — dig remains the universal baseline present on every server — but for interactive DNS debugging and for any DNS check that needs structured output or encrypted transport, doggo is the faster path. The doggo cheatsheet lays out the transports and record types.
The supporting cast
A few other modern tools round out the terminal network toolkit, each answering a specific question better than the classics. For live bandwidth attribution — "what process is saturating my uplink right now?" — bandwhich shows utilization broken down by process, connection, and remote host, which neither iftop (per-connection) nor nethogs (per-process) fully delivers on their own. For a quick latency graph to a single host without the full traceroute machinery, gping plots ping times live and can compare several hosts on one chart. For HTTP-level checking, modern clients like httpie and xh make probing endpoints and inspecting headers far more pleasant than raw curl for interactive use, though curl stays unmatched for scripting breadth.
The pattern across all of them is the same as Trippy and doggo: take a job the classics did adequately, then add structured output, richer information, and a better interactive experience. None of these tools asks you to abandon the fundamentals; they ask you to reach for a sharper instrument when the question is specific.
A worked incident
To see how the modern toolkit changes the actual work, walk through a realistic incident: users report that your web app is intermittently slow. The classic approach would have you running ping in one terminal, traceroute in another, and dig in a third, mentally stitching together three text outputs. The modern approach is more direct.
Start by asking whether it is DNS, because it usually is. doggo --time yourapp.com @https://1.1.1.1/dns-query checks resolution over the actual encrypted transport and reports how long it took; comparing that to an authoritative query tells you instantly whether resolution is slow or wrong. If DNS is clean, move to the path: sudo trip yourapp.com -z traces every hop with AS annotations, and within seconds you can see whether loss and latency spike at a particular hop and which network owns it. If ICMP is being rate-limited and the trace looks artificially bad, sudo trip yourapp.com --tcp -p 443 re-runs the trace over the port traffic actually uses, revealing the real path. If the problem is local saturation rather than the path, bandwhich shows which process is eating the link. Each step answers one question with one tool, and each tool's output is rich enough to either confirm or eliminate a hypothesis immediately.
The contrast is not subtle. The classic tools could reach the same conclusions, but slower, with more manual correlation and more opportunities to misread a wall of text. The modern toolkit compresses the diagnostic loop, which is the whole point when a system is down.
Structured output and the automation payoff
A theme worth pulling out on its own is structured output, because it is where the modern tools quietly change more than the interactive experience. The classic network tools emit text formatted for human eyes, which means any script that consumes them is built on fragile regular expressions against output that was never meant to be a data format — and that breaks the moment a tool version tweaks its spacing or wording. The modern tools emit JSON. doggo --json, trip -m json, and their peers produce structured data that a script can parse reliably with jq and feed into monitoring, alerting, or reporting without a single brittle pattern match.
This unlocks workflows the classics made painful. You can run a scheduled DNS check that parses doggo's JSON and alerts when a record drifts from its expected value, with no regex against dig output. You can capture a Trippy JSON report as a structured artifact attached to every network incident, building a queryable history of how paths behaved during outages. You can pipe results into the same observability stack you use for everything else, so network diagnostics become data rather than terminal scrollback. The interactive TUIs get the attention because they are visible, but for teams building automation, the structured-output modes are arguably the more durable advantage — they turn one-off manual checks into repeatable, alertable, recordable pipelines. It is the same lesson the rest of the modern CLI taught: tools that emit structured data compose into systems, while tools that emit only formatted text stay stuck as manual instruments.
When to stick with the classics
Modern does not mean mandatory. The classic tools retain real advantages worth respecting. Universality is the big one: ping, traceroute, and dig are present on essentially every system, including the locked-down production box or the minimal container where you cannot install anything. When you are debugging on a host you do not control, the classics are what you have, and knowing them cold is non-negotiable. Scripting ubiquity is another: countless existing scripts and runbooks are built on the classic tools' output, and curl in particular remains the most portable HTTP client for automation. And for the simplest possible check — is this host reachable at all — plain ping is instant and sufficient; reaching for a TUI would be overkill.
The mature stance is fluency in both. Use the modern tools on your own machine and in your interactive diagnostic work, where their speed and depth pay off every day. Keep the classics sharp for the constrained environments where they are the only option and for the scripts that already depend on them. The modern toolkit is an upgrade to your reflexes, not a replacement for the foundation.
The bottom line
Network diagnostics joined the command-line renaissance, and the modern terminal toolkit makes finding latency, routing, and DNS problems genuinely faster. Trippy fuses ping and traceroute into a live, deep, multi-protocol view that answers "where is the latency" in seconds; doggo brings DNS debugging into the encrypted era with human and machine-readable output; and supporting tools like bandwhich and gping sharpen specific questions further. Learn the modern tools for your daily interactive work, keep the classics for constrained boxes and existing scripts, and match the instrument to the question. The fundamentals of how networks fail have not changed — but how quickly you can see the failure has.
References and Resources
Tools
- Trippy — website and GitHub
- doggo — GitHub and docs
- bandwhich and gping
Background and analysis
- Trippy: combining ping and traceroute — Terminal Trove
- doggo: a command-line DNS client for humans — LinuxLinks
- Best DNS Monitoring Tools in 2026 — Dotcom-Monitor
Related 1337skills cheatsheets