Public Cloudflare evidence we can test
Cloudflare is relevant here for DNS, proxying, SSL modes, redirect rules and origin connectivity. The scanner does not sign in to the account; it compares the public-facing configuration associated with proxy status, SSL/TLS mode, DNS records, email records, 52x errors so a provider dashboard and the Internet-visible result can be checked against one another.
- Proxy status — Record the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
- SSL/TLS mode — Test the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
- DNS records — Verify DNS records from the public Internet and compare it with the value the responsible provider says should be live.
- Email records — Verify email records from the public Internet and compare it with the value the responsible provider says should be live.
- 52x errors — Verify 52x errors from the public Internet and compare it with the value the responsible provider says should be live.
Where Cloudflare changes normally belong
Cloudflare DNS > Records for DNS changes, and SSL/TLS or Rules only when the diagnosis specifically points to those layers. Before editing that area, verify that Cloudflare actually controls the failing layer; a domain may use a different company for authoritative DNS, mail or the origin application.
How to interpret Cloudflare detection
proxy status and SSL/TLS mode can support a Cloudflare identification, but signatures are confidence-weighted. If the visible address belongs to a CDN/reverse proxy, the edge provider is reported as the edge and the hidden origin is not guessed. Mail-provider signatures likewise identify public routing, not private account ownership.
Common Cloudflare change points
DNS, proxying, SSL modes, redirect rules and origin connectivity most often breaks after a domain connection, nameserver move, website migration, certificate/HTTPS change or mail-DNS edit. For this provider, compare proxy status, SSL/TLS mode, DNS records with the value expected for the exact domain and account before replacing a working setting elsewhere.
Repair Cloudflare without widening the incident
Save the current public value, change only the setting tied to the diagnosis, and preserve unrelated working records. If DNS is not authoritative at Cloudflare, make the DNS edit at the provider named by the active nameservers. If Cloudflare owns only hosting or mail, leave the other service layers where they are.
Verify the Cloudflare repair
The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. The verification should use the exact hostname/service repaired and should no longer depend on a control-panel “connected” indicator once the public check is available.
What a public scan cannot see inside Cloudflare
Billing state, private support actions, unpublished incidents, private origin addresses and authenticated account settings are outside a public diagnostic. HostWithShery reports those areas as unknown or a next support step instead of manufacturing certainty from a weak Cloudflare signature.
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.