If your website behind Deflect is facing 421, 403 or 400 HTTP errors, there’s a possibility you may be dealing with an SNI issue. This article aims to guide you in resolving this problem.
1. What is SNI? #
Server Name Indicator (SNI) is an extension to the Transport Layer Security (TLS) protocol that indicates which hostname the client is trying to connect to at the beginning of the handshaking process.
This allows a server to present multiple certificates on the same IP address and port number, and hence allows multiple secure HTTPS websites to be served off the same IP address without requiring all those sites to use the same certificate.
2. SNI and HTTP Host Header #
The HTTP host header is also used to indicate which site a client is trying to reach. But it’s not sent after SSL connection is established.
In other words, both SNI and the HTTP host header allow the client to specify which server name they’re trying to reach. However, SNI allows this information to be present earlier in the SSL setup process, which is crucial when multiple SSL websites are sharing a single IP address.
Not every web server requires the alignment of the SNI name and HTTP Host header. In instances where they do not match, the HTTP Host header generally takes precedence. However, some web servers, such as Apache, have recently begun requiring a match of the SNI and the HTTP host name, thus creating an SNI issue.
3. Identifying SNI Issue #
You may be dealing with an SNI connection issue, if your Deflect protected website is facing the following HTTP error:
- 421 Misdirected Request
Or you are seeing the following error in part or in full:
- 403 Forbidden
- 400 Bad Request
And one of the condition below apples to you:
- You’ve recently upgraded your origin web server
- You’ve recently updated your origin web server config
- You are using Apache as your origin server
- You are hosting multiple virtual hosts on one origin server
3.1. Inspect web server log #
Inspect your origin web server log for any error messages. For example, if you see the following message in your Apache error log, it indicates that you are facing an SNI issue.
AH02032: Hostname example.com provided via SNI and hostname www.example.net provided via HTTP are different
3.2. Connect to origin server directly #
Verify if you are encountering an SNI issue because your website is located behind Deflect Nginx reverse-proxy.
Bear in mind, there is no necessity to deactivate Deflect universally to perform this test. Instead, you can conveniently execute the following cURL command to compel DNS resolution to your origin server IP.
curl --resolve <domain name>:443:<origin server IP> -k "https://<domain name>"
If you are unable to execute the cURL command, you have the alternative of modifying your local /etc/hosts (or C:\Windows\System32\drivers\etc\hosts for Windows users). This allows you to manually compel a domain name to resolve to your origin server IP. Remember to revert the change after you are done testing.
3.3. Apache origin server #
On July 10, 2025, Apache released version 2.4.64, featuring specific security patches about the handling of SNI. Basically, this new update will reject a connection if the SNI name in the Secure Sockets Layer (SSL) handshake packet does not match the Host header within the HTTP packet of that particular SSL connection. See Apache changelog.
Websites utilizing Nginx as a reverse proxy and Apache as an origin server are affected by this upgrade. This is because in a reverse proxy setting, Nginx does not by default relay the SNI name to the origin server.
4. Resolving SNI Issue #
4.1. Check if SNI is enabled for your website #
Deflect automatically enables SNI for website signed up on or after late 2024. But it might be turned off manually by our support team. To verify whether this feature is enabled or not for your website, you can login to Deflect dashboard, and locate this settings under Settings -> Server Name Indication (SNI).
In most scenarios, it is advisable to keep these settings enabled, only under rare circumstances would you need to disable them. However, if the issue persists even after enabling SNI, you might want to consider disabling SSL session reuse.
4.2. Disable SSL session reuse #
By default, Deflect reuses the SSL session in the connection pool on the identical origin server for optimization. However, if your origin server hosts multiple virtual hosts with different domain names, disabling SSL session reuse may solve the SNI mismatch error.
In Deflect dashboard, you can locate this feature under Labs -> Disable SSL Session Reuse.
4.3. Multiple virtual hosts #
If you’re operating multiple virtual hosts on the same origin IP address under Deflect, it is advised to review the respective web server config, and to enable both SNI and the disabling of SSL session reuse across all these virtual hosts.
4.4. www domains #
If your website utilizes both the apex domain and the www domain, with the latter automatically added by Deflect and proxied to the same origin IP, consider adding the www domain name within your server name in your web server configuration.
4.5. Ensure origin certificate common name matches the hostname #
You may want to ensure SSL Certificate Common Name (CN) on your origin server matches the hostname requests by the visitor. You can verify this by connection directly to your origin server using cURL.
curl --resolve <domain name>:443:<origin server IP> -k "https://<domain name>" -v -I
Look for CN= in the output, for example:
* Added example.com:443:203.0.0.0 to DNS cache
* Hostname example.com was found in DNS cache
* Trying 203.0.0.0:443...
* Connected to example.com (203.0.0.0) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=example.com
...
If the common name doesn’t match the hostname, there are several options available:
- Generate and install a self-sign SSL certificate with the correct common name, as Deflect does not require a valid SSL certificate signed by trusted CA on your origin server.
- Request Deflect to sign an origin certificate in the dashboard under HTTPS / TLS -> Origin Certificates and install it on your server.
- Generate and install a valid SSL certificate using Lets Encrypt or other SSL provider.
4.6. Temporary Fix: HTTP origin #
Warning! This solution is not secure; it should only serve as a temporary measure until a permanent fix is implemented.
Should every solution outlined above prove unsuccessful, and a necessary debugging period is required, the SNI issue can be bypassed by compelling Deflect to connect to your origin server via HTTP.
To activate the bypass, you have to verify the availability of HTTP on your origin server by directly connecting to it via port 80.
curl --resolve <domain name>:80:<origin server IP> "http://<domain name>"
Ensure that the content is correctly served on port 80. Disable any 301 or 302 redirection to HTTPS in order to prevent redirection loop.
In Deflect dashboard, under HTTPS / TLS -> HTTPS/TLS Configuration, enable Flexible TLS encryption
Security Implications: Even though your website will remain accessible through HTTPS, secure connection will only cover the segment extending from the visitor’s browser to the Deflect edge. The data transmitted between the Deflect edge and your origin server will not be secured, posing potential risks.
4.7. Contact Deflect Support #
Please seek assistance from our Deflect support team if you require guidance throughout this process. Include server error messages, access logs and screenshots to help us resolve the issue faster.
