---
title: "Discussion on \"Use SNI for routing https requests\" | Hashnode"
description: "Discussion on \"Use SNI for routing https requests\". The scenario is a proxy exposing https protocol. SNI, Server Name Indication, happens before ssl handshake negotiation.\nIf SNI is used for routing https request, the same port can be used for multiple domains\nThe problem is on passing the headers:\n\nX..."
url: "https://hashnode.com/posts/use-sni-for-routing-https-requests/693a89bceadaa8722c35bd49"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Use SNI for routing https requests](https://danielecr.hashnode.dev/use-sni-for-routing-https-requests?utm_source=hashnode&utm_medium=feed)

The scenario is a proxy exposing https protocol. SNI, Server Name Indication, happens before ssl handshake negotiation. If SNI is used for routing https request, the same port can be used for multiple domains The problem is on passing the headers: X...

Dec 11, 2025 · 6 min read · danielecr.hashnode.dev  
Read the article

-   [#nginx](https://hashnode.com/tag/nginx)
-   [#haproxy](https://hashnode.com/tag/haproxy)
-   [#http2](https://hashnode.com/tag/http2)
-   [#http3](https://hashnode.com/tag/http3)
-   [#rest-api](https://hashnode.com/tag/rest-api)

## Written by

[Daniele Cruciani](https://hashnode.com/@danielecr)

@danielecr

  
[View profile](https://hashnode.com/@danielecr)

DevOps, K8S, Docker

## Responses 1

Markdown supported · ⌘↵ to post

[Edge Ops](https://hashnode.com/@edgecacheops)

[Nov 5](https://hashnode.com/posts/use-sni-for-routing-https-requests/693a89bceadaa8722c35bd49/comment/6aec9fbd180e3e2272337844)

SNI-based routing only works if every TLS listener sees the ClientHello hostname before a default cert is chosen. Pin one certificate map (or per-Host secret) on the edge proxy, keep fallback certs for unknown names so misrouted names fail closed, and do not terminate TLS on both the outer load-balancer and the inner proxy unless SNI is forwarded intact. Route by exact Host first; wildcards hide stale backends until a canary Host proves the new pool.

Ops prove-out: open TLS to each Host and confirm the leaf CN/SAN matches the name you expect, then compare status codes and upstream timing against the pre-cut baseline. If only one Host fails handshake, check SNI passthrough and that the inner listener still receives the original name. If handshakes succeed but the wrong backend answers, verify Host-to-upstream maps and that DNS still points at the proxy that owns those certs — most SNI bugs are name mismatch or double termination, not the routing table shape.