A Website Will Not Open: Browser, DNS, and Site-Access Checks
A Website Will Not Open: Browser, DNS, and Site-Access Checks
If most of the internet works but one site does not, the network itself may be healthy. The cause may be the website, a saved browser session, DNS name resolution, a proxy or content policy, or a certificate/date problem. Use the checks below without weakening security controls.
Define the failure
Copy the exact address and error message. Common clues include server not found, name not resolved, connection timed out, access denied, a sign-in loop, or a certificate/privacy warning. Confirm that the address is spelled correctly and uses the organization’s official domain. Do not follow a replacement link from an unexpected email or advertisement.
Try a second trusted website. If nothing opens, follow the no-internet procedure. If only one site fails, ask a coworker or check the site owner’s published status page. A service outage cannot be repaired by resetting your router.
Test the browser safely
- Reload the page once.
- Open a private or incognito window and enter the known address manually. This tests without most existing cookies, but it does not make browsing anonymous.
- Try another organization-approved browser. If it works there, the first browser’s cache, cookies, extension, or profile may be involved.
- Close and reopen the browser, then restart the computer if necessary.
- Check that the computer’s date, time, and time zone are correct. Incorrect time can cause valid HTTPS certificates to appear untrusted.
Clear data only for the affected site first. Clearing all cookies signs you out of many services and may remove useful preferences. Do not disable certificate checks, endpoint filtering, the firewall, or browser security. Never proceed through a certificate warning on a banking, identity, healthcare, or work sign-in page; capture it and contact support.
Understand DNS without changing it
DNS translates a name such as example.com into a network address. A DNS error can affect one name while other sites continue to work. Windows and macOS normally receive approved DNS settings automatically from the network or VPN.
Changing to a public DNS provider may bypass company filtering, internal names, split-DNS VPN design, or compliance controls. Do not change DNS, proxy, “secure DNS,” hosts-file, or TCP/IP settings on a managed device unless IT instructs you. Likewise, do not run downloaded “DNS repair” utilities.
Safe checks include reconnecting Wi-Fi, reconnecting the approved VPN, and restarting the device. On Windows, the built-in network troubleshooter may identify a resolver problem. On a Mac, review the connected network and VPN status, but leave DNS and proxy values unchanged. Support may ask you to run nslookup or another diagnostic; share the result through an approved channel because internal names can be sensitive.
Consider access policy and accounts
An access denied page often means the site is blocked by organizational policy, geography, licensing, or account permissions, not that DNS is broken. Do not attempt to evade a block with a personal VPN, alternate DNS service, web proxy, or browser extension. Submit the business reason and exact URL to the appropriate approval process.
For a sign-in loop, sign out from the service, close related tabs, and retry in a private window. Confirm you selected the correct work account. If MFA prompts arrive when you are not signing in, deny them and report the event.
What support needs
Send the exact URL (without passwords or secret tokens), screenshot or full error text, browser name, device, network/VPN status, and time of failure. State whether the site works in a private window, another approved browser, another device, or another approved network. This quickly separates a site outage, account issue, browser problem, policy block, and DNS failure.