Cloudflare error 1013 identifies a mismatch between the hostname used during TLS negotiation and the HTTP request hostname. Compare the failing client or proxy with an ordinary request to the same address. If a browser succeeds while an integration fails, the integration’s request construction still needs investigation.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Compare the TLS SNI name with the HTTP Host
| Observed difference | Investigate | Evidence to supply |
|---|---|---|
| Only a custom client fails | Connection hostname and manually supplied Host value | Client type and intended destination |
| Only a managed network fails | Proxy handling of the secure request | Affected domain and failure time |
| All requests appear to fail | Exact error and hostname context | A reproducible public-page request |
| Browser works but integration fails | Original integration request | Its expected response, not only browser success |
Why one connection can fail while another works
Cloudflare’s documentation identifies client-side hostname handling and a network proxy handling SSL traffic as common causes. A proxy sits between the client and the website, so the request Cloudflare receives may differ from what someone assumes their browser sent.
For example, an integration might connect using one hostname while manually supplying another Host value. A normal browser visit to the public address can succeed, while that custom request fails. The successful browser test is useful because it narrows the investigation; it does not repair the integration’s request.
A managed office network is another context worth noting. If the failure occurs only there, the network administrator can review the secure proxy path. The error alone does not establish that the office network is responsible, but the difference between environments is evidence to investigate.
Keep the comparison small and specific
Hold the address constant. Record the failing URL, client, environment and time. Compare that same public page from an approved environment if permitted. Changing both the hostname and client makes it harder to determine which difference explains the mismatch.
Record the exact page address, failure time, complete error message, and the client used. Distinguish an ordinary browser request from a monitoring tool, API integration, or custom application. Those clients can be configured differently.
If a public page is involved and local policy permits it, compare an ordinary request from another approved environment. Keep the address the same. A different page on a different hostname introduces too many differences to say much about the mismatch.
Do not bypass certificate warnings or disable a managed network’s protections as a test. The useful task is to identify where the hostname changes, which the responsible administrator can inspect without weakening the connection.
Review the client or proxy that forms the request
For a custom client, the maintainer should compare the TLS destination name with any overridden HTTP hostname. For a managed network, the network team should inspect where the name is formed or changed. Keep certificate validation active while diagnosing the hostname relationship.
For a custom client, give the developer the connection hostname and intended HTTP hostname. The developer should review how the request is constructed and whether a manually overridden field differs from the destination selected for TLS.
For a managed proxy, provide the network team with the affected domain and error time. Ask it to review the request path and any hostname handling for that destination. Keep the investigation limited to the site and request involved rather than changing WordPress to accommodate an unexplained mismatch.
A certificate check for the public domain can provide supporting context, but a healthy public certificate does not show exactly what a particular client or proxy sent. Cloudflare’s support page recommends SNI testing and a HAR capture when escalating the issue.
Prepare useful evidence for support
A HAR capture records browser network activity and may include private request details. Reproduce a public-page failure where possible, follow the support team’s collection instructions, and review the capture before sharing it. Avoid including unrelated signed-in traffic.
Alongside the capture, describe which environments fail and which succeed. A brief report such as “the public article opens in an ordinary browser but the integration returns 1013” gives support a clear comparison without claiming a cause that has not been confirmed.
After the responsible maintainer adjusts the request construction or proxy configuration, retest the same client and address. A browser success alone is insufficient when the original failure belonged to an integration.
Confirm the expected content or application response as well as the disappearance of the error. If the corrected request reaches a different site, the hostname relationship still needs review.
Keep the final explanation in the integration or network notes. It should state which hostname the client is meant to use and why any custom override was removed or corrected. That small piece of context can prevent the same mismatch from returning during a later configuration change.
Reference: Cloudflare error 1013 documentation.
Retest the original client
After the responsible maintainer corrects request construction or proxy handling, use the original client and address. Confirm the expected site or application response. A healthy public certificate and a successful browser visit provide context, but neither alone proves the failing client now supplies matching names.