Error 1013: HTTP Hostname and TLS SNI Mismatch (Fix)

Problem

Cloudflare returns Error 1013: HTTP hostname and TLS SNI hostname mismatch. The connection to Cloudflare’s edge worked — TLS completed — but inside that connection the request disagreed with itself: the hostname the client announced during the TLS handshake (via SNI) is not the hostname it put in the HTTP Host header. Cloudflare uses both to figure out which site you’re asking for, and when they contradict each other it refuses to guess.

Symptoms

• The Cloudflare-branded error page shows Error 1013.
• A normal browser loads the site fine, but a script, a custom client, or curl with manual options gets 1013.
• It appears only from a specific network — one office, one VPN, one machine with security software — while everyone else is fine.
• It started right after you added a proxy, a TLS-inspecting appliance, or code that sets the Host header by hand.

What This Error Actually Means

Every HTTPS request to Cloudflare carries the target hostname twice, at two different layers. First, during the TLS handshake, the client sends SNI (Server Name Indication) — an unencrypted field that says “I want to speak TLS for example.com,” so the edge knows which certificate to present. Then, inside the now-encrypted HTTP request, the client sends the Host header — “I’m requesting a page from example.com.” On a healthy request these are identical, because both describe the same site.

Error 1013 means they weren’t identical. The SNI said one hostname, the Host header said another. Cloudflare treats that as a broken or tampered request and stops, because a mismatch between the two is either a misconfigured client or a sign that something in the middle rewrote the connection. This is not a certificate problem and not an origin problem — the origin was never contacted. It’s a contradiction inside the request itself, and that contradiction is created on the client side of Cloudflare, not on your server.

Top 3 Causes

1. A custom client or script setting SNI and Host to different values. You connect by IP or to one hostname for TLS but override the Host header to the real domain — curl --resolve, a hardcoded IP with a manual Host:, an HTTP library where the TLS server name and the Host header are configured independently. The TLS layer announces one name, the HTTP layer another. Browsers never do this, which is why it “works in Chrome but not in my code.”
2. A TLS-inspecting middlebox between the user and Cloudflare. A corporate proxy, a security appliance doing SSL inspection, or antivirus “HTTPS scanning” re-terminates TLS and rebuilds the connection outbound. If it sends its own SNI while forwarding the original Host header (or the reverse), Cloudflare sees a mismatch. The tell: it correlates with a network or a product, not with your site.
3. A stale or wrong SNI from an old integration or pinned config. A CDN-in-front-of-CDN setup, an API gateway, or a client with a hardcoded SNI value points TLS at one name while the request targets another. Common after a domain rename or a migration where one layer was updated and the other wasn’t.

Diagnose with DechoNet

• SSL Check inspects the TLS handshake and the certificate Cloudflare presents for your hostname, so you can confirm the edge is serving the right certificate for the name you intend — the baseline that proves the problem is a client/Host mismatch, not a certificate coverage gap.
• HTTP Check fetches the site with a normal, matching SNI and Host from the outside. If DechoNet’s check succeeds and 1013 only happens from your client or network, you’ve localized the fault to that client or a middlebox in its path — not to your domain or Cloudflare config.

Resolution Checklist

• Reproduce from a plain browser on a clean network. If it loads there, the fault is client-side or middlebox-side, not your Cloudflare setup.
• In any custom client or script, make the TLS server name (SNI) and the Host header carry the same hostname. Remove hardcoded IPs, stray --resolve, or manual Host: overrides that don’t match the SNI.
• If it only happens on one network, check for a proxy, SSL-inspection appliance, or antivirus HTTPS scanning between those users and the internet — fix or exclude your domain on that middlebox.
• For a CDN/gateway chain in front of Cloudflare, verify the SNI that layer sends upstream matches the Host it forwards; update whichever half is stale.
• Confirm with SSL Check that Cloudflare presents the correct certificate for the intended hostname, then re-test the request with matching SNI and Host.

When to Escalate

• If SNI and Host provably match on the client and 1013 still appears, capture the actual TLS ClientHello (SNI) and the HTTP Host header on the wire — a middlebox may be rewriting one of them invisibly, and the packet capture is what proves which.
• If the mismatch originates inside a managed proxy or corporate network you don’t control, escalate to whoever owns that appliance; the SNI/Host rewrite is a setting there, and no change to your domain or Cloudflare zone can fix a contradiction introduced downstream of you.