Start by locating the failure
A browser needs to resolve a domain name, connect to a server, establish an HTTPS connection, and request a page. A failure at any stage can look like “the website is down,” but the remedy depends on where the process stopped. Start with the exact address that fails. The root domain, a www hostname, and a subdomain can have different DNS records, server settings, and certificates.
Write down the browser’s error message and whether you see a page from the site. “Server not found” or a name-resolution error points toward DNS. “Connection refused” or a timeout suggests the browser could not complete a connection. A certificate warning or TLS handshake error means the browser reached something, but could not establish a trusted HTTPS session. An HTTP error page, such as 404 or 503, usually means DNS and TLS worked well enough to deliver an HTTP response. These are clues, not final diagnoses.
Check whether DNS returns an address
Use a DNS lookup tool such as nslookup or dig to query the exact hostname. Check its A records for IPv4 addresses and AAAA records for IPv6 addresses. A hostname might instead point to another name through a CNAME record. If the lookup returns no usable address, investigate the DNS configuration before changing the web server. Check that the hostname exists in the active DNS zone and that the domain is using the nameservers where you made the change.
Pay attention to the kind of failure. An NXDOMAIN response indicates that the queried name does not exist according to the resolver’s answer. A timeout or other lookup error may indicate a resolver or DNS availability problem instead. If a recent record change appears on one network but not another, cached answers may explain the difference. Wait for caches to expire rather than repeatedly changing records without a clear reason. Also check both IPv4 and IPv6: if a hostname publishes an AAAA record that leads to a broken destination, some visitors may fail while others succeed.
If DNS works, test the connection and server response
A successful lookup tells you where a resolver thinks the site lives; it does not prove the server is reachable or serving the right website. Open the site using its normal hostname and note whether the connection times out, is refused, or produces an HTTP status. You can also use curl to inspect the response headers, for example with curl -I https://example.com. Replace the example hostname with your own and keep the hostname in the request so that the server can select the intended site.
A refusal suggests that nothing is accepting connections at that destination and port, or that access is being rejected. A timeout can have several causes, including network filtering or an unavailable server. An HTTP status such as 500 or 503 indicates that an HTTP service answered, but the site or an upstream component could not handle the request. If the response is an unexpected page, check that the DNS address, hosting configuration, and any proxy or content delivery service all refer to the intended site. A working homepage does not rule out a problem limited to one path.
Recognize TLS-specific failures
TLS is the security layer used by HTTPS. If the browser reports that a certificate is expired, untrusted, or issued for a different hostname, treat that as a TLS problem rather than a missing DNS record. Check the certificate presented for the exact hostname, including www or a subdomain where applicable. The server or proxy handling HTTPS needs a valid certificate for that name and must present it during the connection.
Other TLS errors may involve an incomplete certificate chain or incompatible connection settings. A command-line HTTPS request can provide a more specific error than the browser, but do not bypass certificate verification just to make the test pass. Disabling verification can conceal the issue you are trying to identify. If plain HTTP works while HTTPS fails, that comparison can help narrow the problem, but use HTTP only as a diagnostic where appropriate, not as a substitute for repairing HTTPS.
Compare results without losing the trail
Test from another device or network if you can. A failure on one device may involve a local DNS cache, browser setting, or network policy; a failure across several networks makes a site-side issue more plausible. Compare results for the same hostname and address each time. Record the lookup result, the connection or HTTP error, and any certificate message before making changes. If you recently updated DNS, remember that an old cached address may still send some visitors to the previous server.
Work in order: confirm the name resolves, confirm the destination accepts a connection, then inspect the HTTPS and HTTP results. That sequence helps you avoid replacing a certificate when the hostname does not resolve, or editing DNS when the application is returning a server error. When asking a hosting or DNS provider for help, share the hostname, error text, and relevant test results—but not passwords, private keys, session cookies, or account recovery details.
