What the tool sends and from where
The server runs the operating system's own ping command against the target: 2, 4 or 6 ICMP echo requests, each allowed about two seconds for a reply. The output is parsed line by line. A line with a measured time becomes a SUCCESS row with its byte count, round-trip time and TTL; a timeout becomes a TIMEOUT row; and messages such as Destination host unreachable become ERROR rows with the text preserved.
The probe source is the DNSfinder server, shown as This server in the header, not your browser. The numbers describe the path from that server to the target. If your own connection is slow, this test will not show it. It answers a different question, namely whether the target responds from the public internet and how quickly.
A hostname is resolved first and the test goes to the first address returned, which is printed next to the target. Private, loopback and reserved addresses are refused, as are names that resolve to one. You can paste a URL. The protocol and path are stripped before resolution.
When ICMP gets no answer: the TCP fallback
Many hosts and cloud networks drop ICMP entirely. If not one echo reply comes back, the tool switches method: it opens a TCP connection to port 443 the same number of times, about 100 ms apart, and times each handshake. The result is flagged with a warning box that states the reason, for example No ICMP echo replies (4 sent), and the table title changes to TCP connect responses.
A TCP round trip is a real measurement of the path, so the latency figures remain comparable, but two columns go blank: there is no TTL and no payload size for a handshake, and the tool shows a dash rather than inventing values. A refused connection (the host answered with a reset) still counts as a successful round trip, because the packet went there and back.
The fallback only triggers when ICMP got nothing at all. One lost packet out of four is reported as 25% loss under ICMP. If the fallback itself shows every row as TIMEOUT, the host is either down or has 443 closed off too. The port scanner will tell you which ports do answer.
Reading the four metrics
Average RTT is the mean of the successful probes, with the minimum and maximum underneath. Packet loss is the share of probes that got no reply, shown with the received-of-sent count. Jitter is the average difference between consecutive round trips, so it describes how steady the path is, and the standard deviation beside it measures spread around the mean.
The Connection State badge summarises loss: SUCCESS at zero loss, FILTERED for partial loss and TIMEOUT when nothing came back. Each row's time carries a colour, green up to 75 ms, amber up to 150 ms and red above that. The chart under the metrics plots every probe against the average line, which makes a single outlier easy to spot.
On an ICMP result the TTL column hints at distance: operating systems start at 64, 128 or 255 and each router subtracts one, so a TTL of 54 means roughly ten hops from a Linux host. For the actual route, run a traceroute to the same target.
Common patterns and what they usually mean
Four probes are a spot check rather than a measurement campaign, so read the shape of the result rather than a single number, and repeat the test a few times when something looks odd. The combinations below cover most of what the tool shows.
- Every probe answers with a steady time: a healthy path. Distance sets the floor, about 1 ms of round-trip time per 100 km of fibre.
- One or two timeouts, the rest fine: a router or the host is rate limiting ICMP, or the path is briefly congested. Repeat before concluding anything.
- Times swinging between tens and hundreds of milliseconds with high jitter: queueing or congestion somewhere on the path. Voice and video suffer first.
- 100% ICMP loss but the TCP fallback succeeds: the host is up and only ICMP is blocked. Not an outage.
- ERROR rows reading host unreachable or net unreachable: a router on the way has no route to the address. The problem is upstream of the target.
- Fallback rows all TIMEOUT: the host is down, the address is wrong, or every port is filtered from the internet.
What a server-side ping cannot tell you
It measures one path from one place. The DNSfinder server's route to a host may be shorter or longer than yours, so compare with ping from your own machine (ping example.com on Windows, macOS or Linux) before blaming either side. It also sends at most six packets, which is enough to confirm reachability and get a feel for latency, not to detect loss of one packet in a hundred.
Routers answer ICMP from their control plane at low priority, so a slow reply from an intermediate device is not the same as slow forwarding. Equally, a host that responds to ping may still have its web server down. A security scan checks the HTTP layer and the IP lookup tells you whose network you reached.
Requests are rate limited per visitor IP, with a 429 response and a wait time when the limit is hit. Results can be copied as JSON or downloaded as CSV with one line per probe, and nothing you test is stored. See the privacy policy.