A real Linux terminal, right in your browser
Run dig, whois, curl, ping and other read-only network diagnostic tools instantly — no install, no signup. Every session runs in a disposable, isolated sandbox that's destroyed right after your command finishes.
Available tools
Browse all tools →What's new
Full changelog →Network diagnostics from the command line: a practical guide
Why the terminal is still the fastest way to diagnose a network problem
When a website won't load, an email bounces, or an API call times out, the browser's network tab only tells part of the story. A handful of small, single-purpose command-line tools — dig, whois, ping, mtr, curl, openssl s_client, and nc — can usually pinpoint the actual failure in under a minute, long before you'd finish opening a GUI network monitor. They're old, they're boring, and that's exactly why they're still the first thing a network engineer reaches for.
DNS first: dig, host, and whois
Most "the site is down" reports are actually DNS problems. dig example.com is the fastest way to see exactly what a resolver returns for a domain — its A/AAAA records, the authoritative name servers that answered, and the query time in milliseconds. Add a record type, like dig example.com MX or dig example.com TXT, to check mail routing or domain verification records without opening a control panel. host example.com gives the same core answer in a shorter, script-friendly format when the full dig response is more detail than you need. Once a domain resolves, whois example.com answers a different question — who registered it, when it expires, and which registrar or DNS provider is responsible — the tool for "is this domain about to lapse", not for troubleshooting connectivity itself.
Is it slow, or is it actually down: ping and mtr
ping sends ICMP echo requests and reports round-trip time and packet loss, the two numbers that separate "the network is fine, the app is slow" from "packets are actually being dropped". A few milliseconds and 0% loss usually means the problem sits above the network layer; sustained loss or wildly inconsistent latency points lower, into routing or a saturated link. mtr goes a step further, combining ping and traceroute into one continuously updating report that shows loss and latency at every hop between you and the destination, not just the two endpoints — so when ping shows loss, mtr is the natural next command, because it tells you whether the loss happens at your own edge, somewhere in the middle of the path, or right at the destination.
Talking to the service directly: curl and openssl s_client
ping and mtr operate below the application layer — they know nothing about HTTP or TLS. curl -I https://example.com fetches just the response headers: status code, redirect chain, caching headers, and server banner, without downloading the page body, which makes it the fastest way to tell a real 404 from a CDN edge serving a cached error, or to see a request bouncing through several redirects before it fails. When the problem might be certificate-related — an expired cert, a broken chain, or a TLS version mismatch — openssl s_client -connect example.com:443 opens a raw TLS connection and prints the full certificate chain, issuer, validity dates, and negotiated protocol version, answering whether the certificate is actually the problem before looking anywhere else.
Checking a specific port: nc
Sometimes the question is narrower than "is the site up" — it's "is this one port even open". nc -zv host port attempts a bare TCP connection to a single port and reports whether it succeeded, without sending any protocol-specific data, making it the right tool for confirming a firewall rule actually took effect or that a service is listening at all, before debugging anything at the application layer above it.
A few numbers worth knowing
A round-trip ping under about 20ms is typical on the same continent, 80–150ms is normal across an ocean, and anything creeping past 200ms on a route that's usually fast is worth a second look. TTL (time to live) in a ping reply hints at how many hops away a host is and, loosely, its operating system — a TTL that drops steadily across mtr hops and then suddenly resets can mean traffic is being redirected somewhere unexpected. On the HTTP side, curl's status code tells most of the story before you read a single byte of body: 2xx means the request succeeded, 3xx means look at the Location header for where it's redirecting to, 4xx means the client's request was rejected (401/403 for auth, 404 for a genuinely missing resource), and 5xx means the failure is on the server, not in anything you sent. None of these numbers are exotic — they're just easy to forget until the one time you actually need them.
Running these without installing anything
All of the above normally means opening a real terminal, and on a phone or a locked-down work laptop that's not always an option. LinuxCLI runs dig, host, whois, ping, mtr, curl, openssl s_client, and nc inside a disposable, sandboxed Linux container reachable straight from the browser — no install, no account, and no state left behind once the command finishes. It won't replace a real shell for daily work, but for a one-off DNS check or a quick TLS inspection from a machine you don't control, it's often faster than finding one.