Network diagnostic tools that show their working

Where the tests run, and why it matters

A browser can't open raw sockets, send DNS queries on port 53 or read a server's certificate chain, so the lookups on NetKit run on a server function on Vercel's network and the results come back to your page. That has consequences you should know when you read a result:

• Port checks, ping and SSL tests see your server from the internet side. That's what you want when you're checking port forwarding or a firewall rule, but a service that only listens on your LAN will correctly show as closed.
• DNS lookups go to public resolvers (Cloudflare 1.1.1.1 by default, or the one you pick) over DNS-over-HTTPS. Your ISP's resolver or your office's split-horizon DNS may cache a different answer. The propagation checker asks eight resolvers at once to show exactly that.
• Ping is TCP, not ICMP. Serverless platforms don't allow ICMP, so we time a TCP handshake instead. It's often a better predictor of real application latency anyway; the ping page explains the difference.
• The subnet, CIDR and conversion tools run entirely in your browser. Nothing you type there leaves your device.

Every tool page includes an interactive explainer for the concept behind it: drag a prefix across the 32 bits of an address, step a DNS query from your laptop to the root servers, raise a packet's TTL one hop at a time, or break a certificate chain to see why phones reject it while desktops don't. For learning beyond networking, ahaboo builds explainers you can manipulate, walking through ideas such as photosynthesis, lunar phases, and the difference between marginal and effective tax rates.

Stuck on something odd?

Paste the output of dig, traceroute, curl -v, openssl s_client or a confusing error message into the output explainer. It reads the output, tells you what it means and suggests the next command to run. Most tool results on NetKit also have an "Explain this result" button.