desktest.net
GitHub

Proxy & SSL Inspection Test Guide

A reference for the desktest.net Proxy Test. The tool answers one question: is there a corporate proxy or TLS-inspection appliance between this machine and the internet? It works by comparing what an edge reflector actually received to what this browser sent. Use it when apps throw certificate errors on a managed network, or when you need to prove to a vendor that traffic is being intercepted.

Open the Proxy Test ->

What does the Proxy Test check?

Nothing on this machine can see itself from the outside. So the test asks a server on the public internet to describe the connection it received, then compares that description to what the browser knows it sent. If the two disagree, something rewrote the traffic in between. Three steps run in order:

  1. Reach the edge reflector. A single GET to edge.desktest.net/whoami, a Cloudflare Worker that stores nothing. The reply must be HTTP 200 with a JSON body whose service field equals desktest-net-edge. That exact payload cannot be forged by a captive portal or a proxy block page, so a wrong or missing body counts as "not reached."
  2. Your egress identity. Informational. The reflector reports how the internet sees you: public IP, ASN and network organization, rough location, negotiated TLS version and cipher, HTTP version, the Cloudflare edge (colo) that served the request, and the measured TCP round-trip. None of this is pass/fail on its own; it is context for the ticket.
  3. Interception check. Three comparisons against the reflected request:
    • User-Agent rewrite. The User-Agent the edge received is compared (case-insensitive on the header name) to navigator.userAgent. If they differ, a proxy rewrote it.
    • Proxy / forwarding headers. The received headers are scanned for via, forwarded, x-forwarded-for, x-forwarded-host, x-forwarded-server, x-bluecoat-via, proxy-connection, x-cache, x-squid-error, and any header starting with x-zscaler or x-iws. Any hit means an intermediary is in the path. Cloudflare's own cf-* headers and x-forwarded-proto are normal and are ignored.
    • TLS downgrade. If the negotiated TLS version is present and is not TLSv1.3, that is noted as a possible downgrade. Some inspection proxies terminate at TLS 1.2. This alone is a hint, not proof.
The honest limit: the browser cannot read the TLS certificate issuer from JavaScript. Definitive proof of SSL inspection is checking the certificate under the browser's lock icon: if it was issued by a corporate CA (your company, Zscaler, Netskope) instead of the expected public CA, TLS is being inspected. This tool detects the proxy and hints at inspection; the lock icon confirms inspection.

When should I run this?

Reading the results

Each step renders a row with a status badge: Pending (grey), Running (yellow), Pass (green), Warn (yellow), or Fail (red). Step 2 shows an egress-identity grid. Step 3 shows a signal list where each row is tagged Clear, Signal (fired), or Hint.

The verdict panel at the top summarises the run with a likely cause and a recommended next step. There are four outcomes: reflector unreachable (fail), proxy detected (fail), TLS downgrade (warn), and direct connection (pass).

Copy Diagnostic Report copies a plain-text report: timestamps, the User-Agent this browser sent, the full egress identity, every detection signal with the exact header names and values, and the overall verdict. Send to your IT opens the same text in a pre-filled email. Paste either into a ticket.

Every result and its fix

The tool emits one named diagnosis per outcome. Each is listed below with what it means and what to do.

reflector-unreachable: could not reach the edge reflector

The one request the test needs did not complete, or a response came back that was not the reflector's JSON. Either outbound HTTPS to edge.desktest.net is blocked, or a captive portal / proxy block page is intercepting the request. The run stops here because there is nothing to compare against.

  1. Open https://edge.desktest.net/whoami in a normal browser tab. If it errors or shows a block page, outbound HTTPS to it is being blocked or intercepted.
  2. The network or a proxy is blocking outbound HTTPS. Try another network to compare; a phone hotspot is the quickest way to rule the local network in or out.
  3. On corporate Wi-Fi, check for a captive portal that has not been signed in to. Open any plain HTTP site to trigger the sign-in redirect.
  4. If a VPN or web filter is active (Zscaler, Netskope, Cisco Umbrella), the destination may be blocked by category. Ask for edge.desktest.net to be allowed, or test from off the corporate path.
  5. Re-run once the reflector loads cleanly in a normal tab.

direct: no proxy or TLS inspection detected

The edge received the same User-Agent the browser sent, no forwarding or proxy headers were present, and TLS negotiated at 1.3. Nothing points to an intermediary rewriting traffic. This is the expected result on a home connection or any network without an egress proxy.

  1. No action needed. If an app is still failing, the cause is not a proxy in the path; look at DNS (try the Network Test), the app itself, or local firewall/antivirus.
  2. Remember the honest limit: a well-behaved inspection proxy that preserves the User-Agent, adds no forwarding headers, and negotiates TLS 1.3 to your browser would still show as direct here. Confirm with the certificate issuer under the lock icon if you have any reason to suspect inspection.

proxy-detected: a proxy is in the path

A proxy is in the path between you and the internet. This fires when the edge received forwarding/proxy headers (such as via, x-forwarded-for, x-bluecoat-via, x-zscaler-*) OR the User-Agent the edge saw does not match what this browser sent. The verdict names exactly which signals fired. On a managed or corporate network this is normal and not itself a fault.

  1. Confirm this is expected. On a corporate network, an egress proxy in the path is by design.
  2. If apps are failing with certificate errors ("connection is not private", NET::ERR_CERT_AUTHORITY_INVALID, a pinned-cert failure), that is TLS inspection re-signing certificates with a corporate CA. The proxy is decrypting and re-encrypting the traffic.
  3. For the failing app, IT must either allowlist it (bypass inspection for that app's hostnames) or install the inspection CA into the trust store the app actually uses. Browsers usually trust the corporate CA already via the OS store; standalone apps, Java, Node, Python, and Electron apps often ship their own store and need the CA added there.
  4. To prove inspection: open the failing site, click the lock icon, view the certificate, and read the issuer. A corporate CA name (your company, Zscaler, Netskope, Forcepoint) instead of a public CA (DigiCert, Let's Encrypt, Google Trust Services) confirms TLS is being inspected.
  5. Hand IT the copied report. It names the exact forwarding headers, which points at which product is in the path.

tls-downgrade: TLS negotiated below 1.3

No proxy headers were present and the User-Agent matched, but TLS negotiated below 1.3 (for example TLSv1.2). That could be an old client or browser, or an inspection proxy that terminates the connection at TLS 1.2. On its own this is a hint, not proof, so the result is a warning rather than a failure.

  1. Update the browser to the current version. Modern browsers negotiate TLS 1.3 by default, so a current browser landing on 1.2 is itself suspicious.
  2. If the browser is current and TLS is still 1.2, an intermediary may be terminating the connection and re-originating it at 1.2. That is consistent with an inspection proxy.
  3. Check the certificate issuer under the lock icon on any normal HTTPS site. A corporate CA issuer confirms inspection even when no forwarding headers were added.
  4. If the browser is genuinely old (a locked-down kiosk or legacy image), the downgrade may just be the client, with no proxy involved.

For IT admins

This tool is a quick, self-service way for a user to show you whether their traffic is being proxied, and to hand you the forwarding headers as evidence. It has no third-party scripts, no analytics, and contacts only edge.desktest.net over HTTPS on port 443. If the page will not load at all, allow desktest.net and edge.desktest.net through the edge first.

SSL / TLS inspection products

Most enterprise egress runs through an inspection proxy that terminates TLS, decrypts, inspects, and re-signs with an internal CA. The tool detects the proxy hop; the re-signed certificate is what breaks apps.

Allowlisting and the inspection CA

Behind the scenes

The reflector is edge.desktest.net, a Cloudflare Worker. GET /whoami returns JSON describing the request as Cloudflare saw it: ip, asn, asOrganization, colo, country, city, region, tlsVersion, tlsCipher, httpProtocol, clientTcpRttMs, and a requestHeaders object containing the headers that arrived at the edge. It stores nothing and sends access-control-allow-origin: * so the browser can read the body cross-origin.

The fetch uses cache: 'no-store' and credentials: 'omit', wrapped in an AbortController with an 8 second timeout. The pass condition is strict: HTTP 200 plus service === "desktest-net-edge". Anything else (a block page, a redirect to a portal, a rewritten body) fails the reach step, because a forged reply is exactly what a hostile intermediary would send.

The interception logic is a pure comparison in the browser: the reflected user-agent versus navigator.userAgent, a scan of the reflected header names against the proxy-header list and the x-zscaler / x-iws prefixes, and a check of tlsVersion against TLSv1.3. Cloudflare's cf-* headers and x-forwarded-proto are excluded because Cloudflare itself sets them and they are not evidence of a corporate proxy. No payload data leaves the browser beyond the plain GET; there is no telemetry to desktest.net. View the page source to confirm.

Elsewhere on the web: