There is a specific kind of network problem that every sysadmin recognizes: the internet is broken, you do not know whether the fault is local, somewhere on the route, or at the remote service, and you have fifteen minutes to figure it out before someone escalates. The standard answer is to chain together ping, dig, traceroute, mtr, and curl, in that order, until one of them gives you a clue. Network Doctor is a free, open source Go terminal app that runs that chain for you and returns a plain-English diagnosis. It is not a replacement for any of those tools, but it is a useful front-end for the chain.
The project lives at github.com/heymaikol/network-doctor under the GNU GPL v3.0. It runs on Linux, macOS, and Windows. It does not require root for most checks, which is meaningful because most of the underlying CLI tools it orchestrates also do not require root, and the tool keeps that property end to end. If you have ever opened six terminals to debug a network problem, this is the tool that consolidates the six terminals into one and produces a single status report you can paste into a ticket.
What the diagnostic actually checks
The default run walks through a fixed set of checks and reports a status for each: pass, warning, failure, skipped, or not-applicable. The checks fall into a few broad buckets:
- Local network interfaces and connectivity (link state, default route, DNS resolver reachability).
- DNS resolution against the configured resolvers, including DNSSEC where the upstream validates it.
- TCP connectivity to a target host, with timeout, retry, and connection-state evidence.
- TLS handshake and certificate validation, with expiry warnings and chain-of-trust details.
- HTTP and HTTPS response checks, including status code, redirect chain, and time-to-first-byte.
- Proxy configuration as set in the environment, including whether the configured proxy is reachable.
- Path MTU (the largest packet size that survives the route without fragmentation), checked without needing root.
Multiple diagnostic probes run in parallel under the hood, which makes the full default run take seconds rather than minutes. Color-coded status output is the default in a terminal, and structured JSON output is also available for scripts and automation pipelines that need to consume the same diagnostic data.
Where it earns its keep
Help-desk and sysadmin workflows are the clearest use case. Anyone who has ever been handed “the internet is broken” without further detail will recognize the chain: open a terminal, run ping, run dig, run traceroute, run mtr, run curl, and stitch the results together by hand. Network Doctor produces a triage report that points to one of three buckets (local network, route, or remote service) in a single command. That triage is what you would otherwise do with six tools, and it is what the tool is designed to produce.
Watch mode is the second clear use case. Network Doctor can re-run the same diagnostic on an interval and report only the deltas, so the output stays small even on a long-running session. That is the right shape for catching intermittent failures that do not reproduce on demand: DHCP lease flaps, brief DNS resolver outages, and the occasional TCP reset that does not show up in a one-shot probe. A watch session of an hour or two over a flaky VPN is the kind of problem this mode was built for.
Reproducible reports are the third use case. The structured output makes it cheap to capture the same diagnostic from the same machine on a schedule, so you can compare a working state to a broken state without remembering what you ran. That is the kind of habit that pays back the first time you need to write up an incident and cannot remember whether MTU was the cause.
What it is not
Network Doctor is a front-end for the standard CLI tools. It is not a packet capture tool. It is not a flow analyzer. It is not a replacement for Wireshark, tcpdump, or a proper network monitoring stack. If the bug is inside a TLS handshake or below the IP layer, the tool will tell you the handshake failed but it will not show you the bytes.
Network Doctor is a front-end for the standard CLI tools that most operators already trust, and it deliberately does not try to replace them. If the bug is inside a TLS handshake or below the IP layer, the tool will tell you the handshake failed but it will not show you the bytes; reach for Wireshark or tcpdump at that point. Likewise, the tool does not implement a flow analyzer or a long-running packet capture; it answers a single question per run, not a stream of questions.
The default checks assume the standard ports and protocols. If the failure is in a non-default port or a non-HTTP service, the tool will report the connection failure but will not dig into the application layer. The MTU check is also a path MTU check, not a per-flow PMTUD check; it is enough to find the obvious MTU problems and not enough to find the subtle ones that only show up under specific traffic patterns.
Trade-offs
Running multiple diagnostic probes concurrently is a feature for triage and a hazard for shared machines. On a heavily loaded production host, the diagnostic itself can perturb the thing it is measuring; the README is honest about this and asks users not to run the default suite against a machine that is already at the edge of its capacity.
LAN scanning and network mapping are useful for a home or small office network and out of scope for an enterprise environment. Pointing this at a corporate network can trip a security alert on the scan itself; treat the LAN mode as a small-network feature, not a discovery tool.
Copy-and-save reports write the diagnostic output to a file in the format you choose, which is convenient for tickets but also convenient for accidental leakage. Default save paths are local, but a report that includes full DNS resolution and TLS certificate details can carry more information than the ticket needs. Trim the output before pasting it into any public channel.
What I would tell past me
If you spend more than a few hours a month debugging network problems and you are still running ping, dig, traceroute, and curl by hand, give Network Doctor a week before deciding whether it fits your workflow. The default triage run is the right entry point for most “the internet is broken” tickets, and the watch mode catches the intermittent failures that hand-rolled scripts usually miss. It is not a replacement for the underlying tools, and the JSON output is what makes it useful as a front-end rather than a black box.
Install it once, keep it in your triage toolkit alongside the CLI tools it orchestrates, and reach for it before opening the sixth terminal. If a week in it does not earn its place, fall back to the manual chain. If it does, you have saved yourself a few hundred keystrokes a week and a lot of tickets that used to need a full re-investigation.