How LumaProbe tests your connection
LumaProbe uses ordinary HTTPS requests that a modern browser can make without an extension. This keeps the tools accessible, but it also creates limits that are important when interpreting a result.
The principle behind the tests
A browser can time transfers between the user’s device and the LumaProbe server. That path includes the device, browser, Wi-Fi or Ethernet connection, home router, access network, provider routing and the route to the server. The result describes that complete path at that moment. It is not a direct reading from the broadband modem and it is not guaranteed to match a provider’s controlled line test.
Results are most useful as comparisons. Use the same device and browser, pause large transfers and compare Wi-Fi with Ethernet or one room with another. Repeating a test under controlled conditions produces better evidence than treating one run as a definitive rating.
Latency and jitter method
The latency phase sends eight small HTTPS requests to LumaProbe’s ping endpoint. The browser records the elapsed time for each completed request. The displayed latency is the average round-trip time of successful samples. Jitter is calculated as the standard deviation of those sample times, which describes how much the measured response varied during the short run.
This is an HTTP-based browser measurement, not command-line ICMP ping. Browser scheduling, TLS and HTTP processing add overhead. The values are still useful for comparing the same setup before and after a change, but they should not be presented as a carrier-grade measurement of the underlying network.
Download and upload method
The download phase requests three six-mebibyte blocks of generated data, for roughly eighteen mebibytes in total. It measures the bytes received against elapsed browser time and converts the result to megabits per second. The upload phase sends a six-mebibyte block to the server and calculates the rate from the time taken to complete the request.
Short tests reduce data use and waiting time, but they may not fully ramp up a very fast connection. Device performance, browser memory, antivirus inspection, VPNs, server load and route distance can all affect the result. For an important fault report, repeat the measurement and compare it with the provider’s own test where available.
Failed requests and the packet-loss label
During the latency phase LumaProbe counts test requests that do not complete successfully. A failed request can be caused by local instability, a transient server or route issue, browser cancellation or another interruption. Persistent failures are worth investigating, especially if they remain when testing over Ethernet.
Browsers cannot send arbitrary raw ICMP packets. LumaProbe therefore describes this value as failed HTTPS requests or a browser-level stability estimate. It must not be treated as an exact packet-loss percentage for the broadband circuit. A network engineer may use longer ICMP, TCP or UDP tests when a formal packet-loss measurement is required.
DNS, IP and website checks
The DNS checker asks the LumaProbe server to retrieve public A and AAAA records for the hostname supplied. It reports the public addresses returned and the server-side lookup time. That confirms resolution from the server’s resolver, not from every resolver worldwide and not necessarily from the visitor’s home router.
The IP checker displays the public address associated with the request after considering common trusted-proxy headers. It also reports whether the request arrived securely and may show connection information exposed by the browser. The HTTP checker sends a HEAD request to a public HTTP or HTTPS address on a standard port. Private and reserved destinations are blocked, credentials in URLs are rejected and redirects are not followed.
Privacy, retention and reproducibility
The public application does not write speed results or displayed IP addresses to a central test-history database. When the visitor chooses to keep history, it is stored in that browser’s local storage and can be cleared there. The hosting platform, content-delivery network and security systems can still process request addresses and technical logs as part of delivering and protecting the site.
To reproduce a comparison, record the date, time, device, browser, connection type, test location and whether other traffic was paused. Run at least three tests rather than selecting only the best or worst. If investigating Wi-Fi, test beside the router and in the affected room; if possible, add an Ethernet control result.
What the tools cannot prove
A good result does not prove that every website or service is healthy, because a fault may exist beyond the route to LumaProbe. A poor result does not by itself prove that the provider is at fault, because the device, Wi-Fi, VPN, local traffic or test route may be responsible. The tools are diagnostic clues rather than contractual measurements or live outage feeds.
LumaProbe does not diagnose electrical faults, damaged provider infrastructure or account provisioning. Use the official provider checker for account and area information. If a fault persists across devices and an Ethernet control test, retain the evidence and contact the provider.
Questions or corrections
Send page-specific feedback through LumaContact. Please include the page address and the statement concerned.