A website that will not load can have a site-side fault, a DNS problem, a network-routing issue or a browser-specific problem. Try a second network and compare the exact error before changing settings. One successful or failed test narrows the possibilities; it does not establish what every visitor sees.
Start with the same device on home Wi-Fi and, if available, mobile data. Only use networks you have permission to use. If the site works on one path, investigate the difference rather than assuming you have proved a specific DNS or ISP fault.
Keep a simple record before changing anything
Note the hostname, approximate time, device, network, VPN state and exact error. Distinguish a page that will not connect from one that loads but cannot sign in or complete an action.
You can check the public address for the request to FindMyIP and the registered network shown by ISP Lookup. Neither is an outage detector. A warning or failed lookup can originate in this site or its data provider as well as your connection.
Compare one thing at a time
| Observation | Possible explanations | Next useful check |
|---|---|---|
| Works on mobile data but not home Wi-Fi | Different DNS, routing, filtering, VPN behavior or site treatment of the two networks | Compare VPN state and the error; test another device on home Wi-Fi |
| One device fails on the same network | Browser settings, cached state, local filtering or OS configuration | Try another browser or a private window on that device |
| Works in a private window | Different cookies, session state or extension behavior | Review the normal browser’s site data and enabled extensions |
| Fails on two networks | A broader site/DNS issue, or a condition shared by your tests | Check the provider’s status page and compare another device |
| Works only with the VPN on or off | Different route, exit, DNS or filtering | Check the VPN configuration; do not infer the exact cause from the toggle alone |
Private mode does not disable every extension in every browser and is not a complete reset. Its value is the comparison. Mozilla’s site-loading troubleshooting describes how browser, connection and individual-site failures can differ.
Check DNS without pretending to test every resolver
Look up the domain’s public DNS records. Enter the exact hostname; the root domain and www can have different records. An A record gives an IPv4 target, while AAAA gives an IPv6 target. Record values do not establish that the destination server is healthy.
FindMyIP queries through the site’s server resolver. It does not query the resolver configured on your own device, measure every geographic location or identify your browser’s DNS path. A different result on your device can therefore be worth investigating.
For a real comparison, use a DNS query tool that explicitly selects the resolver. Note which server returned each answer and when. If you temporarily change DNS settings on a device you control, record the original settings and restore them after the test. Managed work or school devices should follow their administrator’s process.
Read how to interpret DNS records if an answer is unfamiliar. If a domain recently changed, DNS propagation and caching explains why answers may differ. Do not edit a domain’s records unless you control it and have identified a configuration problem.
Interpret the error before deciding what to fix
| Error or behavior | What it suggests | What it does not prove |
|---|---|---|
| Server not found or NXDOMAIN | A name-resolution failure on that query path | That the domain is missing from every resolver |
| Timeout or connection refused | A route, filtering or service-listening problem | Which device or provider is responsible |
| Certificate warning | A certificate, clock, interception or host-configuration issue | That bypassing the warning is safe |
| HTTP 502 or 503 | A gateway or service reports a failure | That every region and user has the same fault |
| Page loads, but login fails | An application, account, session or API issue | That the entire website is offline |
Do not bypass a certificate warning merely to finish a test. Check the hostname and device clock, then use the site’s official support route if the warning persists.
Check the VPN and access path
A VPN toggle may change several things at once: the public exit, route and DNS configuration. If the outcome changes, what a VPN changes on your visible IP explains how to interpret the address comparison without calling it a complete leak test.
On a hotel or other captive network, complete its legitimate sign-in process before retrying. If the connection works but transfers are slow, that is a performance question rather than proof of an outage. Avoid repeatedly resetting the router or switching unrelated settings; you lose the useful baseline.
If FindMyIP itself fails, try other known sites. A failure here can involve this application, JavaScript, rate limiting or its upstream lookup provider. It does not establish that your device lacks a public connection. When many unrelated destinations fail, check Wi-Fi or mobile connectivity and the ISP’s status information.
When to contact support
If a failure persists across the paths available to you, send the site or network operator the hostname, time, error and comparisons you made. Share sensitive diagnostic details only through an appropriate private channel. A status page can help, but a clear status page does not rule out a regional or account-specific problem.
Your conclusion can stay narrow: “This hostname times out on home Wi-Fi but works on mobile data with the VPN off.” That observation is more useful than claiming you have proved a global outage or a broken ISP resolver.