Troubleshooting areaReviewed 2026-08-13By HostWithShery technical editorial

Website Errors

Understand exact browser and Cloudflare errors, test your own domain on the same page and follow a repair path.

Start with evidence from your own domain before changing DNS, SSL or mail settings.

Check your own configuration

Complete Website Health Check

This page is preconfigured with the Complete Website Health Check that best matches this problem.

No accountPublic evidence only

On this page

Browse this section

Find the exact error message

Every important page in this area is linked here with a normal crawlable link, so you can choose by task instead of searching through a long generic list.

DNS & hostname errors

Cloudflare DNS_PROBE_FINISHED_NXDOMAINThe requested hostname does not currently resolve in public DNS.Open →Email Stopped Working After Moving DNS to CloudflareThe website can continue working while mail fails if MX and mail-authentication records were not copied to the new DNS zone.Open →DNS_PROBE_FINISHED_NXDOMAINThe browser could not obtain a DNS answer for the requested hostname.Open →ERR_NAME_NOT_RESOLVEDThe browser could not translate the hostname into a usable IP address.Open →NET::ERR_CERT_COMMON_NAME_INVALIDThe certificate does not cover the hostname the browser requested.Open →Server IP Address Could Not Be FoundPublic DNS did not return a usable address for the hostname.Open →NSURLErrorCannotFindHost (-1003)Apple networking could not resolve the hostname in the requested URL. The failure occurs before an HTTP response can be received, so start with the exact hostname and its DNS path.Open →EAI_NONAME / getaddrinfo Hostname ErrorThe operating-system name-resolution call could not translate the supplied node or hostname into an address. In Node.js this can surface through dns.lookup() or APIs that use the system getaddrinfo path.Open →NS_ERROR_UNKNOWN_HOSTFirefox networking reports NS_ERROR_UNKNOWN_HOST when lookup of the hostname fails. Treat it as a name-resolution symptom first, not as an SSL, redirect or application-response error.Open →JSSDK Unknown Host DomainMeta Facebook Login can show this message when the page hosting the JavaScript SDK is not included in the app configuration allowed for JavaScript SDK login. This is an application configuration error, not a generic DNS failure.Open →Host Validation Failed — See Logs for More DetailsThis message is application-specific. For the Homepage dashboard, current documentation says to read the logged host value and include that exact host in HOMEPAGE_ALLOWED_HOSTS; other products can use the same wording for different validation rules.Open →The Provided Host Name Is Not Valid for This Server (Drupal)Drupal returns this message when the HTTP Host header does not match the configured trusted host patterns. It is an application host-security check, so a domain can resolve correctly and still be rejected by Drupal.Open →

Connection, TLS & proxy errors

Cloudflare Error 520Cloudflare received an empty, unknown or unexpected response from the origin server.Open →Cloudflare Error 521Cloudflare reached the network but the origin refused the connection.Open →Cloudflare Error 522Cloudflare timed out while trying to communicate with the origin server.Open →Cloudflare Error 523Cloudflare cannot reach the configured origin network.Open →Cloudflare Error 524Cloudflare connected to the origin but the origin did not return a response before the proxy timeout.Open →Cloudflare Error 525The TLS handshake between Cloudflare and the origin failed.Open →Cloudflare Error 526Cloudflare could not validate the certificate presented by the origin while using strict certificate validation.Open →Cloudflare Too Many RedirectsThe browser is being redirected repeatedly, often because the edge and origin disagree about HTTPS behavior.Open →Cloudflare SSL Handshake FailedThe edge could not complete a TLS handshake with the origin server.Open →Cloudflare Origin IP MismatchCloudflare DNS points to a public IP that no longer serves the intended website.Open →ERR_TOO_MANY_REDIRECTSThe browser detected a redirect loop and stopped following the chain.Open →ERR_SSL_PROTOCOL_ERRORThe browser could not establish a valid TLS session with the server.Open →ERR_CONNECTION_TIMED_OUTThe connection attempt did not receive a response in time.Open →ERR_CONNECTION_REFUSEDThe destination actively refused the connection instead of serving the website.Open →This Site Cannot Provide a Secure ConnectionThe browser could not create a valid HTTPS connection for the hostname.Open →Your Connection Is Not PrivateThe browser does not trust the certificate or identity presented for the HTTPS site.Open →

Website Errors: what this section covers

Website Errors starts from the exact message a browser, Cloudflare edge or user sees, but does not treat the message itself as the root cause. Each error page maps the symptom to the DNS, connection, TLS, redirect or origin evidence that can confirm or eliminate common explanations.

Signals that matter for website errors

The pages here interpret origin reachability and HTTP availability evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.

Website errors — Verify website errors from the public Internet and compare it with the value the responsible provider says should be live.
Browser errors — Verify browser errors from the public Internet and compare it with the value the responsible provider says should be live.
Cloudflare errors — Verify cloudflare errors from the public Internet and compare it with the value the responsible provider says should be live.

Which Website Errors check to start with

Open the page matching the exact error string, run the embedded domain diagnostic and compare the resulting evidence with the cause table. Similar-looking errors such as connection refused, timeout, NXDOMAIN and certificate mismatch require different repairs and should not be collapsed into “the site is down.”

Diagnosis first, raw evidence second

The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For website errors, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.

What a repaired website errors problem should look like

Fix the smallest confirmed layer first. An NXDOMAIN result needs DNS/delegation work; a 525 needs origin TLS investigation; a 522 needs origin reachability evidence. The page links from diagnosis to the provider-specific repair path and back to the validating checker.

Validate the origin reachability and HTTP availability change

The redirect chain should terminate at one intended HTTPS URL without a loop or unnecessary hop, and the final response should be the expected application page. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.