Why a website doesn’t load, and how to fix it

What DNS failures, refused connections, 4xx and 5xx errors, timeouts, and bot checks mean when a website won’t load, and how to fix each.

Loading a website takes four steps: find the server’s address in DNS, connect to it, set up the secure connection, and get a page back. When a site doesn’t load, one of those steps failed.

SignalDNS’s “Does it load?” answer says which one. This page explains each answer and what to check first.

What SignalDNS checks

We request the address from one server, the way a browser asks for a page: a GET request with a Chrome user agent. We follow up to 10 redirects, including HTML meta refresh, and the whole check has 15 seconds. We don’t run JavaScript or keep cookies, so this is one server’s view, not a browser’s.

We only connect to public addresses on ports 80 and 443, checked again on every redirect. The report also tries the http:// version and the www or bare version of the address; see Redirects and HTTPS.

A timeout, a block aimed at our server, or an address we won’t contact is “Couldn’t check”, not a problem: it says nothing about what visitors see.

The name doesn’t resolve

Our server asked DNS for the hostname’s address and got none, so no request was sent. The name doesn’t exist, has no A or AAAA record, or is an alias (CNAME) to a name with no address. Visitors’ browsers fail the same way. This is a problem.

How to fix it:

  1. Check the records for the exact name people use, such as www.example.com as well as example.com. It needs an A record (IPv4), an AAAA record (IPv6), or a CNAME pointing to your web host.
  2. If it’s a CNAME, check its target still exists. See The alias leads nowhere.
  3. Check that the domain’s name servers belong to the DNS provider you’re editing, and that the domain hasn’t expired or been put on hold.
  4. If you just added the record, resolvers may still have the “doesn’t exist” answer saved. See The name doesn’t exist.

The connection failed

Our server found an address, but the connection was refused, reset, or couldn’t reach it, before any response arrived. This is a problem.

How to fix it:

  1. Compare the address in the report’s DNS answer with the one your host gives you. After a move to a new host, DNS can still point to the old server.
  2. On the server, check the web server is running and listening on ports 80 and 443. On Linux, sudo ss -tlnp lists the ports in use.
  3. Allow incoming TCP on ports 80 and 443 in the firewall and in your cloud provider’s security group.
  4. If a CDN or load balancer is in front, check that it can reach your server.

The secure connection failed

Our server connected, but the HTTPS handshake was rejected, with an error such as certificate has expired, so the page wasn’t requested. Browsers usually show a security warning, and apps refuse to connect. This is a problem.

How to fix it: the “Is the connection secure?” answer in the same report checks the certificate and says what’s wrong. SSL certificate errors explains each result.

  • If a redirect led to another hostname, that hostname’s certificate is the one that failed. Run the certificate inspector on it.
  • If the server only accepts TLS 1.0 or 1.1, browsers can’t connect either. See TLS versions.

One case is different. When the server leaves out its intermediate certificate, the answer is “Probably in browsers, but not in apps.” and counts as “Couldn’t check”. Most browsers work around it; our server, like most apps, doesn’t.

The site returns 404 or another 4xx error

The server answered with an error status from 400 to 499. 404 Not Found means there’s nothing at that address; 410 Gone means it was removed on purpose. If the address redirected first, the answer names the final address. This is a problem.

Visitors see an error page, and Google doesn’t index pages that return a 4xx status. 401, 403, and 429 mean something else; see It needs permission and It blocked our server.

How to fix it:

  • For the home page, check the site is deployed and the web server or app serves it. Some hosts answer 404 for a domain they have no site for, so check the domain is added in your host’s dashboard.
  • For a page, check the address is spelled correctly. If the page moved, redirect the old address to the new one with a 301.

The site returns a 5xx server error

The server answered with a status from 500 to 599: it received the request but couldn’t handle it. Every visitor gets the error while it lasts. This is a problem.

  • 500 Internal Server Error: the application hit an error.
  • 502 Bad Gateway: a proxy, CDN, or load balancer got an invalid response from the server behind it.
  • 503 Service Unavailable: the server is overloaded or down for maintenance.
  • 504 Gateway Timeout: the server behind a proxy didn’t answer in time.
  • 520 to 526: Cloudflare’s own codes for problems reaching your server.

How to fix it:

  1. Read the web server’s and application’s error logs for the time of the check.
  2. If a CDN or load balancer is in front, find out whether it or your server sent the error. The response headers, shown under the answer, often say.
  3. If the errors started after a deploy or config change, roll it back.

It needs permission (401 or 403)

401 Unauthorized means the page asks for a login. 403 Forbidden means the server refuses the request. This needs attention, not a problem, because some pages are meant to be private. If the page should be public, every visitor sees the error.

How to fix it: if the page should be public:

  • Turn off password protection, such as one left on from a staging site.
  • Check the web server can read the site’s files.
  • Check there’s an index file, such as index.html. nginx and Apache return 403 for a folder without one when folder listings are off.
  • Check firewall rules. A rule that blocks hosting providers or other countries can return 403 to our server while your visitors get through.

It blocked our server

The site answered 429 Too Many Requests, or an error status with a bot check from Cloudflare, Vercel, or AWS WAF. We recognise those from the headers they send: cf-mitigated: challenge, x-vercel-mitigated: challenge, and x-amzn-waf-action.

This is “Couldn’t check”, not a problem with the site. Our server doesn’t run JavaScript or solve challenges; people usually pass the same check in a browser.

How to fix it: usually there’s nothing to fix. To be sure, open the address in a private browser window. If visitors also report challenges or 429 errors, review your bot protection and rate-limiting rules.

No response in time

The site didn’t answer within the check’s 15 seconds. One server not getting an answer doesn’t prove the site is down, so this is “Couldn’t check”.

The usual causes are an overloaded server, a page that takes longer than that to generate, or a firewall that drops connections without refusing them. A refused connection fails at once; a dropped one waits until it times out.

How to fix it: run the check again, and open the site in a browser. If it’s slow there too, check the server’s load and the application’s slowest requests. If it’s fast, check that firewall rules allow incoming TCP on ports 80 and 443.

We didn’t request it

We only connect to public addresses, on ports 80 and 443. We don’t send a request when:

  • the name points to a private or reserved address, such as 10.0.0.5 or 127.0.0.1. If any of its addresses is private, we refuse the whole name;
  • the address uses another port, such as :8080;
  • the name is local-only, such as a single word, localhost, or a name ending in .local, .internal, .home.arpa, or .lan.

The same rules apply to every redirect, so our server can’t be used to reach private networks. This is “Couldn’t check”.

How to fix it: for an internal site, there’s nothing to fix. If the site should be public, a private address in public DNS fails for visitors too: their browsers look for the server on their own network. Change the A or AAAA record to the server’s public address.

Your provider’s guides

What we can’t tell from outside

We make one request from one server, in one region. A site can answer differently by country, network, or device, and a firewall can treat our server differently from a browser. A page that loads but then breaks in the browser looks fine here, since we don’t run JavaScript. And we can’t see your server’s logs.

Sources

Last reviewed .