HTTPS Origin Host and SNI Mismatch: Explanation and Troubleshooting Guide

When HTTPS is used to connect to an origin server, the origin may observe that the Origin Host and TLS SNI values are different. This is expected behavior when this CDN product delivers services through Cloudflare Custom Hostnames. It does not mean that the request has been modified incorrectly or that the origin configuration has failed.

All domains and IP addresses in this document are examples. Replace them with your actual configuration where appropriate.

1. Origin Settings in the Control Panel

The following parameters can be configured when editing an origin:

• Origin protocol: The protocol used by CDN edge nodes to connect to the origin.
• HTTP: CDN edge nodes connect to the origin over HTTP.
• HTTPS: CDN edge nodes establish an encrypted TLS connection to the origin.
• Origin address: The IP address or hostname of the origin, such as 192.0.2.10.
• Origin port: The port on which the origin listens, such as 80 for HTTP or 443 for HTTPS.
• Origin Host: The value sent in the HTTP Host request header, such as cdn.example.com.

Important: Origin Host controls only the HTTP Host header. It does not change the TLS SNI used for an HTTPS origin connection.

2. Why Origin Host and SNI Are Different

An HTTPS request has two separate stages: the TLS handshake and the HTTP request.

Client accesses the CDN
        ↓
Cloudflare establishes a TLS connection to the origin
SNI: cdn.example.com.fallback.gnamess.com
        ↓
Cloudflare sends the HTTP request after TLS is established
Host: cdn.example.com

The two values serve different purposes:

This CDN product provides a managed layer on top of Cloudflare Custom Hostnames. To allow multiple customer domains to connect through a stable and centrally managed origin endpoint, HTTPS origin connections use an SNI value assigned by the platform. The Origin Host configured in the control panel is sent separately as the HTTP Host request header.

The origin may therefore receive the following values:

SNI  = cdn.example.com.fallback.gnamess.com
Host = cdn.example.com

This is the expected result.

Why Customers Cannot Change the SNI

SNI is sent by Cloudflare when the TLS handshake begins. The origin server receiving the connection cannot modify an SNI value that has already been sent.

In this CDN product, the Cloudflare account, origin rules, and shared origin hostnames are managed by the platform. To maintain certificate validation, shared-origin compatibility, and platform security policies, the origin SNI is configured centrally and is not exposed as a customer-editable setting.

For customers using this product:

• The origin protocol, address, port, and Origin Host can be changed.
• The SNI used by Cloudflare for the origin TLS connection cannot be changed.
• A difference between Origin Host and SNI is expected behavior.

3. Why NGINX Normally Works

By default, NGINX does not require the TLS SNI and HTTP Host values to be identical.

NGINX generally processes an HTTPS request as follows:

1. It uses the listening address, port, and SNI to select an SSL server and complete the TLS handshake.
2. After TLS has been established, it reads the HTTP Host header.
3. It uses the Host value to select a website or route the request to an upstream application.

If the SNI does not match a specific server_name, NGINX generally uses the default_server for that address and port. If no explicit default_server is configured, it uses the first matching server configuration for that listening address. Consequently, different SNI and Host values do not automatically produce an error.

Example configuration:

server {
    listen 443 ssl default_server;

    # Shared origin SNI assigned by the platform
    server_name cdn.example.com.fallback.gnamess.com;

    ssl_certificate     /etc/nginx/ssl/cdn.example.com.fallback.gnamess.com.crt;
    ssl_certificate_key /etc/nginx/ssl/cdn.example.com.fallback.gnamess.com.key;

    location / {
        # Preserve the original application Host header
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto https;

        proxy_pass http://127.0.0.1:8080;
    }
}

To record both SNI and Host in the NGINX access log, define a log format inside the http {} block:

log_format sni_host '$remote_addr sni="$ssl_server_name" host="$http_host" '
                    'request="$request" status=$status';

Enable it in the website's server {} block:

access_log /var/log/nginx/sni_host.log sni_host;

4. Why Apache May Return HTTP 421

Apache mod_ssl generally performs stricter SSL virtual-host checks than NGINX.

During the TLS handshake, Apache selects an SSL virtual host according to the SNI. After TLS has been established, it uses the HTTP Host header to select the virtual host that should process the request. If SNI and Host select different HTTPS virtual hosts whose SSL configurations are incompatible, Apache may return:

421 Misdirected Request

The client needs a new connection for this request as the requested host
name does not match the Server Name Indication (SNI) in use for this connection.

A typical request flow looks like this:

TLS SNI: cdn.example.com.fallback.gnamess.com
    → Apache selects virtual host A

HTTP Host: cdn.example.com
    → Apache attempts to use virtual host B

The SSL configurations of virtual hosts A and B are incompatible
    → Apache returns 421 Misdirected Request

Common incompatibilities include:

• Different TLS certificates or certificate policies.
• Different TLS protocol or cipher-suite settings.
• Different client-certificate verification requirements.
• Other incompatible mod_ssl settings.
• HTTP/2 connection reuse for a Host that is not valid for the current TLS connection.

5. Resolving the Apache Error

Option 1: Route the SNI and Host to the Same VirtualHost

When only a small number of application domains are involved, configure the shared origin hostname and the application hostname in the same HTTPS virtual host:

<VirtualHost *:443>
    ServerName cdn.example.com.fallback.gnamess.com
    ServerAlias cdn.example.com

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/cdn.example.com.fallback.gnamess.com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/cdn.example.com.fallback.gnamess.com.key

    DocumentRoot /var/www/example
</VirtualHost>

After changing the configuration, inspect Apache's virtual-host mapping:

apachectl -S

Ensure that the platform SNI and application Host do not resolve to two <VirtualHost *:443> definitions with incompatible SSL configurations.

Option 2: Make the SSL Configurations Compatible

If multiple HTTPS virtual hosts must be retained, make sure the relevant virtual hosts use compatible SSL settings. Review at least the following directives:

• SSLCertificateFile
• SSLCertificateKeyFile
• SSLProtocol
• SSLCipherSuite
• SSLVerifyClient
• Other TLS-handshake or client-authentication settings

Changing only SSLStrictSNIVHostCheck usually does not fully resolve the problem. The 421 response may be caused by Apache's compatibility check between the TLS connection and the SSL configuration of the requested virtual host.

Option 3: Use NGINX as the Shared HTTPS Entry Point

If the service handles many customer custom hostnames, maintaining an Apache ServerAlias for every domain may not be practical. In that case, use NGINX to terminate TLS and forward requests to Apache:

Cloudflare
SNI: platform-managed shared origin hostname
Host: customer application hostname
        ↓
NGINX terminates TLS
        ↓
HTTP or HTTPS with a fixed backend SNI
        ↓
Apache / application

Forwarding to Apache over local HTTP is generally preferred because it prevents Apache from performing another SNI-versus-Host SSL virtual-host check:

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
}

Option 4: Use a Shared Default HTTPS VirtualHost in Apache

If the origin is dedicated to this CDN product, Apache can use a shared default HTTPS virtual host for platform origin connections. The application can then route requests according to the HTTP Host header.

This approach must be combined with appropriate origin-access controls, such as:

• Allowing only Cloudflare origin IP ranges to access the origin port.
• Enabling Cloudflare Authenticated Origin Pulls.
• Preventing untrusted clients from connecting directly to the origin HTTPS port.
• Not relying only on spoofable HTTP headers to determine whether a request came from Cloudflare.

6. Configuration Recommendations

• HTTP origin connections do not use TLS SNI; the origin only needs to process the Origin Host.
• For HTTPS origin connections, ensure that the certificate and TLS configuration accept the platform-assigned SNI.
• Do not require the SNI to be identical to the HTTP Host at the origin.
• NGINX users generally do not need special handling for different SNI and Host values.
• If Apache returns 421, run apachectl -S first and identify which virtual hosts are selected by the SNI and Host.
• For a large number of custom hostnames, use NGINX as the shared TLS termination layer in front of Apache or the application.

7. Summary

For HTTPS origin connections in this CDN product, SNI is managed centrally by the platform, while the Origin Host setting controls the HTTP Host request header. Different SNI and Host values are a normal result of the Cloudflare Custom Hostnames architecture.

Customers cannot change the SNI through the control panel because it is a platform-level origin parameter. NGINX normally accepts different SNI and Host values and can process the request successfully. Apache may return HTTP 421 when the two names select virtual hosts with incompatible SSL configurations. This can be resolved by using one compatible VirtualHost, aligning the SSL settings, or placing NGINX in front of Apache as the shared TLS termination layer.