desktest.net
guide

Network Test Guide

A reference for the desktest.net Network Test. This is a reachability check, not a speedtest. It confirms the browser is online, that DNS resolves, that public HTTPS endpoints answer, and that a WebSocket upgrade is allowed through the local egress path. Use it to triage "page won't load" tickets before you blame the app.

Open the Network Test ->

What does the Network Test check?

The tool does not measure throughput. It answers a narrower question: can this browser, on this workstation, on this network, actually get out? Three steps run in order:

  1. Browser-reported connectivity. Reads navigator.onLine for the basic up/down signal, plus the Network Information API (navigator.connection) for effective type, downlink Mbps, and RTT hint. Chromium browsers expose the connection API; Firefox and Safari do not.
  2. DNS and HTTPS reachability. Probes five public endpoints in parallel, each with a 5 second timeout: no-cors GETs to cloudflare.com, google.com, 1.1.1.1 (a raw IP, so it still works when DNS is down), and microsoft.com, plus a real DNS-over-HTTPS query to dns.google whose JSON answer is actually read. Spreading across providers reduces the odds that one allow-list covers them all. Per-target RTT is captured via the Performance API. Separately, a readable check against the site's own Cloudflare Worker (echo.desktest.net) confirms genuine reachability (a captive portal or TLS-intercepting proxy block page cannot forge its JSON reply) and reports the egress IP and Cloudflare edge.
  3. WebSocket upgrade. Opens a single wss:// connection to echo.desktest.net, sends a token, waits for the echo, 8 second timeout. Many corporate firewalls allow HTTPS but drop the WebSocket upgrade frame. Slack, Teams, Zendesk, and most remote-deposit pages all need this to work.

When should I run this?

Reading the results

Each step renders a row with a status badge: Pending (grey), Running (yellow), Pass (green), or Fail (red). Step 2 also shows a per-target table with host, status, and RTT in milliseconds as each probe lands.

The verdict panel at the top summarises the run with a likely cause and a recommended next step. It reflects the common real-world reason for each failure. If the verdict does not fit your case, the expanded fix block under the failing row covers the rest.

Copy Diagnostic Report copies a plain-text report: timestamps, user agent, connection-API readout, every probe target with its RTT or error, the WebSocket open and echo timings, and the overall verdict. Paste it into a ticket or an email to the network team.

Common failures and fixes

Each failure path produces a specific named diagnosis. Each diagnosis maps to a concrete fix. They are listed below in the order they appear in the run.

offline: navigator.onLine is false

The browser reports no network. The workstation is not on Wi-Fi or ethernet, or it is in airplane mode. Step 2 and 3 will almost certainly fail too, so the run stops here.

  1. Look at the Wi-Fi or ethernet icon in the system tray (Windows) or menu bar (macOS). It should not show a disconnect or warning glyph.
  2. Toggle airplane mode off if it is on.
  3. Unplug and replug the ethernet cable. For Wi-Fi, forget the network and re-join.
  4. If still offline, reset the network adapter from an admin command prompt: ipconfig /release then ipconfig /renew. Flush the resolver cache too: ipconfig /flushdns.
  5. Re-run the Network Test once the tray icon shows connected.

slow-connection: effective type is 2g or slow-2g

The Network Information API reports the link is measurably slow (cellular 2G class). Reachability below may pass, but normal web apps will feel unusable. This warning fires when effectiveType is 2g or slow-2g.

  1. Move closer to the access point, or switch from Wi-Fi to wired.
  2. Check if a tethered phone or weak hotspot is the active connection.
  3. If this is the only connection available, expect timeouts on heavier apps. There is no fix at the browser layer.

dns-failure: zero of 5 targets responded

None of the five public endpoints answered. Either DNS resolution is failing entirely, or every outbound HTTPS request is being blocked. Both look identical from inside the browser.

  1. From a command prompt: nslookup cloudflare.com. If that fails too, DNS is the problem. Try setting the workstation's DNS to 1.1.1.1 or 8.8.8.8 temporarily.
  2. Flush the DNS cache: ipconfig /flushdns.
  3. Open https://www.cloudflare.com in a regular tab. If it errors, the workstation has no working HTTPS egress at all.
  4. On corporate Wi-Fi, check for a captive portal that has not been signed in to. Open any plain HTTP site to trigger the redirect.
  5. If a VPN is connected (Cisco AnyConnect, GlobalProtect, Zscaler ZIA tunnel), disconnect and re-test. A half-up VPN often kills all egress.
  6. Check antivirus or endpoint protection logs (Sophos, CrowdStrike, SentinelOne) for blocked HTTPS connections.

partial-reach: 1 or 2 of 5 targets responded

Some endpoints reached, others did not. This is the signature of a corporate proxy or content filter with an inconsistent allow-list. It lets through what it knows about and drops the rest. Whatever the user was trying to open is probably on the blocked side.

  1. Note which targets passed and which failed from the per-target table. That list is the evidence you hand the network team.
  2. A TLS-intercepting proxy (Cisco Umbrella, Sophos, Fortinet, Zscaler, Netskope) may be rejecting unrecognised destinations on category grounds.
  3. Ask whoever runs the network for the egress allow-list and confirm whether the target app's hostnames are on it.
  4. Confirm whether the workstation is going through the corporate proxy at all. netsh winhttp show proxy on Windows shows the system-wide proxy setting.

websocket-blocked: WebSocket upgrade rejected

Step 2 passed (HTTPS works) but step 3 failed. The TCP and TLS handshake to echo.desktest.net completed, but the WebSocket upgrade either never finished or was dropped. Common on stricter Fortinet, Sophos, Palo Alto, and Netskope rulesets that do not pass HTTP upgrade frames by default.

  1. Have the network team allow wss:// upgrades on the egress rules used by this workstation segment.
  2. If a TLS-intercepting proxy is in the path, confirm it is configured to handle the WebSocket protocol rather than terminating at the first 101 response.
  3. Check endpoint protection for "deep packet inspection" on outbound 443 that may strip the upgrade.
  4. Disconnect any active VPN and retest. Some split-tunnel configs send 443 fine but route WebSocket through a slower inspection chain that times out.

high-latency: average RTT above 800 ms

Reachability is fine but the link is slow enough that normal web apps will feel sluggish. The threshold (800 ms average across the five passing targets) is well outside the expected range for a healthy wired or Wi-Fi connection.

  1. Switch from Wi-Fi to wired if possible.
  2. Move closer to the access point.
  3. If on a VPN, disconnect and retest. A satellite or trans-continental VPN egress easily adds 600 ms.
  4. If the wired link is also slow, contact the ISP or check for a saturated upstream.

aborted: run cancelled

The run was cancelled before completing, usually because the user clicked Reset or closed the tab. Not a real failure. Re-run the test.

For IT admins

The test page itself has to load through whatever corporate proxy sits between the user and the public internet. If the page does not load at all, allow desktest.net through the edge first. The page has no third-party scripts, no analytics, and no fonts loaded from a CDN, so there is nothing else to allow-list for it to render.

The diagnostic probes five fixed hosts. If your egress is strict allow-list, all five must be reachable for a clean pass:

To run an egress test from a specific workstation segment, open this page from a workstation in that segment. The per-target table shows exactly which hosts the segment's egress allows. The diagnostic report you can copy from the page is a paste-ready record for change tickets.

Known behaviours by product:

The Network Test does not require any extra CSP entries on your end. The page's own CSP already permits the probe targets, so it works behind a permissive proxy without complaint from the browser console.

Behind the scenes

The HTTP step uses fetch() with mode: 'no-cors'. That mode gives back an opaque response: the browser will not let JavaScript read the status code, headers, or body, but the fetch promise still resolves on a successful TCP and TLS handshake plus a valid HTTP response. Resolution is treated as "host answered." Each probe is wrapped in an AbortController with a 5 second timeout, and per-target timing is taken from performance.now() deltas around the fetch call.

The WebSocket step opens one wss:// connection, sends the literal string desktest-net-ping, and waits for an inbound message containing that exact token. The echo Worker sends back exactly what it receives; the token filter accepts the matching echo (and would still skip a connect-time greeting from any other echo backend). Open handshake time and end-to-end echo time are reported separately so you can tell a slow TLS open from a slow echo path.

No payload data leaves the browser except the literal ping token. There is no telemetry to desktest.net, no analytics beacon, and the target endpoints see only an opaque GET (for HTTP probes) or the ping string (for the WebSocket). View the page source to confirm the target list.