What a successful DNS lookup does—and does not—prove
DNS helps a client find an address for a domain name. If a lookup returns an address, the client has information it can use to attempt a connection. That result does not prove that the address is the one you intended, that a web server is accepting connections, or that the server knows which website and page to serve.
An HTTP error is a different kind of clue. When you receive an HTTP 404 or 500 response, something along the request path has answered with an HTTP status. That responder might be the origin website, a reverse proxy, a hosting platform, or a content delivery service. The next task is to identify what answered and whether the request reached the intended website.
Reading a 404: a route or resource was not found
HTTP 404 means the responding system did not find a resource for the requested URL. It does not, by itself, mean that DNS is broken. A mistyped path, an outdated bookmark, a removed page, or a missing file can all produce a 404 even when the homepage works normally.
Start by checking the exact URL. Compare the hostname, path, capitalization, and any trailing slash with a known working link. Test the homepage and one other known public page on the same hostname. If those pages work but one path returns 404, the likely investigation is within the website: its links, files, routing rules, or publishing setup.
If every path returns 404, including the homepage, check whether the hostname is configured on the server or hosting service you reached. The apex domain and its www subdomain can have different DNS records and different website configurations. A server may receive your request but have no matching site or route for that hostname.
Reading a 500: the responder could not complete the request
HTTP 500 is a general server-error response. It usually indicates that the system handling the request encountered a problem while trying to produce the page. Possible areas to investigate include application errors, a failed connection to a dependency, or a server configuration problem. The status alone cannot identify the cause.
Notice whether the 500 appears on every page or only on a particular action or route. A failure limited to one page points toward code or content used by that page; a site-wide failure calls for a broader check of the application and its dependencies. If you administer the site, review logs for the corresponding request and time, taking care not to share entries containing personal data or secrets.
A branded error page can offer a clue about which component generated the response, but branding is not definitive. A proxy may display its own error after a problem communicating with the origin, while an application may return a 500 directly. Knowing which component responded helps you choose the right logs and configuration to inspect.
Confirm that you reached the intended website
Before treating a 404 or 500 as an application issue, verify the hostname you entered and the DNS answers you expected. A record can resolve successfully yet point to an old host or the wrong service. If both A and AAAA records exist, consider whether the website is configured at both the IPv4 and IPv6 destinations. Also check any CNAME used by the hostname and whether the destination matches the hosting setup.
Test the same public URL in a browser or a basic HTTP client, and note the final URL if a redirect occurs. A redirect can move the request to another hostname or path where the error actually happens. If you use a command-line client, be aware that a request for headers only may behave differently from a normal page request on some sites. Do not paste passwords, session cookies, authorization headers, or private query strings into a shared troubleshooting report.
DNS changes may be cached, so different devices can temporarily reach different destinations. Compare results from another network or device if that is practical, and record the hostname and status each sees. Differences are useful clues; they are not proof that one particular cache or server is at fault.
Choose the next check from the status and scope
For a single 404, verify the link and look for the page's current location. For widespread 404s, inspect hostname mapping, published files, and routing rules. For a 500, check the relevant server or application logs and test whether the failure affects all routes or only a specific operation. If you do not manage the website, report the affected public URL, the observed status, and the steps needed to reproduce it.
Keep the layers separate as you work: DNS finds a destination, a connection reaches a service, and HTTP describes the response to a particular request. A 404 or 500 narrows the problem, but neither status tells the whole story. Confirm the destination and the exact URL first, then investigate the component that returned the error.
