Network problems rarely announce their cause. "The site is slow", "calls keep freezing" and "the server is unreachable" can each come from DNS, routing, a congested link, Wi-Fi, a firewall rule or the application itself. The network diagnostics on NetTools.tech each measure one part of that picture, and used together they narrow a vague complaint down to a specific segment or setting.
This guide explains what each tool measures, where it measures from, and which one to reach for first.
What these tools cover
The category contains eight tools in three groups.
Path and reachability, measured from the NetTools.tech server in Latvia:
- Ping — 1 to 10 ICMP echo requests with RTT, TTL, loss and jitter.
- Traceroute — the hop-by-hop path, up to 30 hops, three UDP probes per hop, with reverse DNS names.
- MTR — repeated ICMP, UDP or TCP probing of every hop for up to 120 seconds, with loss, latency, variation, ASNs, findings and exports.
Your own connection, measured in your browser:
- Internet Speed Test — download and upload over parallel streams, HTTP latency, jitter and request loss between your browser and the NetTools server through Cloudflare.
- Network Jitter Test — 10 to 60 seconds of round-trip measurements with a stability rating, in browser (HTTP) mode or, from our server, in ICMP mode.
Services and networks:
- Port Check — one TCP connection attempt: open, closed or filtered.
- Port Scanner & Firewall Test — an Nmap TCP connect scan with fixed profiles of up to 100 ports, limited to your own IP, a DNS-verified domain or the Nmap demo host.
- ASN Lookup — the registered holder of an autonomous system number, from the responsible registry's RDAP record.
All server-side probes share the same safeguards: input is validated, hostnames are resolved and re-checked on the server, private and reserved addresses are refused, fixed binaries run without a shell, and per-client, per-target and global limits apply. IPv6 targets are not supported yet.
Why they matter
- Outside view. Testing from inside your own network cannot show what customers on the internet experience. Server-side tests give a neutral second vantage point.
- Separating layers. A successful ping with a filtered port points at a firewall; an open port with a failing application points at the service; loss that continues to the destination in MTR points at the path.
- Avoiding false alarms. Many "problems" are measurement artifacts: routers that rate-limit ICMP, hosts that ignore ping, Wi-Fi variation. Knowing how each test works prevents chasing them.
- Evidence. ISPs, hosting providers and transit carriers ask for MTR output, speed results and timestamps. Most tools here export CSV, JSON or text.
- Exposure control. Port tests show exactly what is reachable, which is the starting point for closing what should not be.
The tools at a glance
| Tool | What it does | Best for | Guide |
|---|---|---|---|
| Ping | Test network connectivity and latency. | Check whether a host responds to ICMP echo requests and measure round-trip latency and packet loss from our server (IPv4). | Guide |
| Traceroute | Trace the network path to a destination. | Trace the route packets take from our server to a host, hop by hop, with latency at each step. | Guide |
| MTR | Traceroute and ping combined: loss and latency per hop. | Run MTR (My Traceroute) from our server: repeated probes to every hop on the route, with packet loss, latency and jitter per router (IPv4 targets). | Guide |
| Internet Speed Test | Measure download, upload, ping, jitter and request loss. | Test your internet connection with real measurements: download and upload speed over parallel streams, latency, jitter and request loss, with a live gauge, charts, a connection-quality score and your recent results. | Guide |
| Network Jitter Test | Measure latency variation, failed probes and stability. | Test how stable a connection is: repeated round-trip measurements from your browser (HTTP) or from our server (ICMP), with jitter, latency, failed probes, live charts and a stability report. | Guide |
| Port Check | Check if a TCP port is open. | Check whether a specific TCP port on a host accepts connections from the internet. | Guide |
| Port Scanner & Firewall Test | Nmap scan of your own IP, a verified server or the demo host. | Test your router or firewall from the outside, or scan a server you own (verified by a DNS TXT record): open, closed and filtered ports, detected services and risky exposures, powered by Nmap. | Guide |
| ASN Lookup | Find out which company owns an Autonomous System Number. | Use this tool to determine which company owns the specified Autonomous System Number (ASN), with registry, country and allocation details. | Guide |
Which tool should I use?
| Problem | Start with | Then |
|---|---|---|
| Is a server reachable at all? | Ping — guide | Port Check on the service port if ICMP is blocked — guide |
| A host is reachable from some places but not others | Traceroute — guide | MTR with TCP to see where probes stop — guide |
| Intermittent timeouts or packet loss to a server | MTR — guide | ASN Lookup for the network where loss begins — guide |
| My internet feels slow | Internet Speed Test — guide | Repeat on cable and compare in the history |
| Video calls or games stutter | Network Jitter Test — guide | Speed test for upload and request loss |
| Port forwarding does not work | Port Check — guide | Port Scanner & Firewall Test on your own IP — guide |
| What does my router expose to the internet? | Port Scanner & Firewall Test — guide | Close unexpected ports and rescan |
| Which company runs this network or hop? | ASN Lookup — guide | IP Lookup for a specific address — guide |
A rule of thumb for interpreting all path tools: judge by the destination and by patterns that carry forward. Loss or high latency at a single intermediate router is usually that router answering probes slowly, not a problem for traffic passing through it.
Typical workflows
"The website is down" report
- Run Ping on the host. If replies come back, the host is up at the IP level.
- If ping fails, run Port Check on 443. Open means the host is up and simply ignores ICMP.
- If the port is open, check the application with Is It Down? or the HTTP Status Checker, and the certificate with the SSL Certificate Checker.
- If the port is filtered, run Traceroute to see where the path ends.
Intermittent slowness to a remote server
- Run MTR with 30 to 60 probes, first ICMP, then TCP to the service port.
- Look for loss or a latency step that starts at one hop and continues to the destination.
- Identify the network at that hop with ASN Lookup or IP Lookup.
- Export the report and send it to the provider, ideally with a test in the opposite direction from the remote side.
Poor call quality at home
- Run the Network Jitter Test in browser mode for 60 seconds on Wi-Fi, then on cable.
- Run the Internet Speed Test on both connections and compare upload, jitter and request loss.
- If jitter rises only while uploads or streaming run, the router queue (bufferbloat) is a likely cause; if only on Wi-Fi, look at the wireless setup.
Securing a new server or router
- Run the Port Scanner & Firewall Test with the Common services profile — on your own IP for a home or office router, or on the server after verifying its domain with the TXT record.
- Close or restrict every open port that should not be public, especially databases, RDP and SMB.
- Verify single changes with Port Check and rescan.
Related guides
Tool guides in this category:
- Ping guide
- Traceroute guide
- MTR guide
- Internet speed test guide
- Network jitter test guide
- Port check guide
- Port scanner & firewall test guide
- ASN lookup guide
Neighboring categories:
- Security testing tools — website security assessment, password tools and exposure checks.
- IP and network tools — IP lookup, geolocation, subnets and MAC addresses.
- DNS and domain tools — DNS lookups, propagation, reverse DNS and WHOIS.
- My info and identity tools — your public IP and browser details.
Frequently asked questions
Which network test should I run first?
Start with the symptom. For "is it reachable?" run ping and, if ICMP is blocked, a port check on the service port; for slowness or drops on the path, run MTR; for your own connection's speed or call quality, run the speed test and the jitter test from your browser.
Do these tests run from my computer or from your server?
It depends on the tool. Ping, traceroute, MTR, port check, the port scanner and the server ICMP mode of the jitter test run from the NetTools.tech server in Latvia. The speed test and the browser mode of the jitter test run in your browser and measure your own connection.
Why can't I test private IP addresses?
All server-side probes refuse private, loopback, link-local and reserved addresses, including hostnames that resolve to them. This protects internal networks, including ours, from being probed through a public tool.
Do the diagnostics support IPv6?
Not yet for server-side probes: the probe server has no IPv6 connectivity, so IPv6 targets are refused. The browser-based speed test reports whether your own connection used IPv4 or IPv6.
What is the difference between MTR and traceroute?
Traceroute makes one pass over the path with three probes per hop. MTR repeats the probing for up to 120 seconds and reports loss, latency and variation per hop, with ICMP, UDP or TCP probes.
Can I scan any server for open ports?
No. Port Check tests one TCP port per request on any public host, with per-target limits. The Port Scanner only scans your own public IP, a domain you verify with a DNS TXT record, or the Nmap demo host.
Why do results differ from tests I run myself?
Server-side tests start from our network in Latvia and follow its routes; your tests start from your network. Both views are useful, and comparing them often shows whether a problem is on your side or the remote side.