User guide
How do I get started?
- Start with “Your network” to compare observations from your browser with the connection seen by the edge server.
- Enter a domain or full URL, such as example.com, and select “Run diagnostics”.
- Review DNS, certificate records, redirects, and response headers. Compare browser reachability with server-side results to narrow down the problem.
Share links include the target URL and rerun the checks when opened. Copied results (JSON) contain the data available at the time of copying.
What can I check?
- DNS and IP ownership
- Query records through Cloudflare’s public DNS resolver, then inspect IP ownership and known CDN ranges. These results may differ from your local DNS cache or ISP resolver.
- Certificate records
- Look up public certificate transparency records from crt.sh to review issuers, domain names, and validity dates. These are historical issuance records and may not match the TLS certificate currently served by the target.
- Redirects and response headers
- The server follows redirects and reads security headers, compression, and CDN / WAF indicators. These results describe the server’s connection to the target.
- Network connection information
- Compare browser capabilities, WebRTC / STUN candidate addresses, and edge connection information to inspect possible proxy signals. Reachability checks run in your browser; port probes run on the server.
How should I interpret the results?
Can this prove whether I use a proxy or VPN?
No. Proxy detection uses indirect signals that can be affected by privacy settings, extensions, NAT, and network conditions. A match does not prove proxy use, and no match does not rule it out.
Does “reachable” mean a website is working?
Not necessarily. The browser’s cross-origin check can only tell whether a request received a response; it cannot read the status code or body. It does not imply HTTP 200 or confirm that the application works. Server-side probes may also take a different network path from your browser.
Why are some checks unavailable?
Your browser may not support every network API, privacy settings may restrict WebRTC, and third-party queries may time out or be rate-limited. Port probing depends on server capabilities. Use the other checks when one fails; a single failure does not establish that the target is down.
Where are queries sent?
Your browser queries Cloudflare DNS-over-HTTPS, ipwho.is, and crt.sh. WebRTC attempts to gather network candidate addresses using Cloudflare STUN. The target URL is sent to this site’s server for redirect, response-header, and port checks.
Avoid entering URLs that contain passwords, tokens, or other private parameters. Share links also include the target URL, so review them before sharing.