I need to serve several applications over https using one external ip address.

The ssl certificates should not be managed on the reverse proxy. They are installed on the application servers.

Can a reverse proxy be configured to use SNI and pass ssl through for termination at the endpoint?

Is this possible using something like Nginx or Apache? What does the configuration look like?

4 Answers 4


This IS possible with Haproxy. You can setup a TCP proxy and extract the SNI and do routing based on the SNI. Here's an example:

backend be.app1
    mode tcp
    no option checkcache
    no option httpclose
    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }
    tcp-request content reject
    use-server server1 if { req.ssl_sni -m beg app1. }
    server server1 server1:8443 check id 1 weight 0

It is essential to delay the request until you get the SSL hello, otherwise haproxy will try to make a connection before receiving the SNI header.

I am using servers with weight 0 because, in my current configuration, I only have one server running for each SNI and I don't want them to receive random requests. You can probably find better ways to play with this.

I hope this helps.

  • Can you point me towards any documentation of this or a configuration snippet so I can accept the answer?
    – user319862
    Aug 31, 2014 at 23:17
  • 3
    @user319862 I found this nice tutorial which seems to be what's being discussed. Aug 31, 2014 at 23:21
  • 1
    Really? Why would someone downvote this answer? Sep 1, 2014 at 6:41
  • The problem with this is that the IP address of the client doesn't get forwarded, so the server only ever sees traffic coming from the proxy.
    – kyrofa
    Apr 28, 2017 at 18:48
  • @Kyle Of course. It is TCP proxy. The only thing you can do about this is if you configure and set haproxy as a router for the server and use tproxy. Apr 29, 2017 at 9:47

You can use sniproxy : https://github.com/dlundquist/sniproxy

An example configuration :

listener {
    protocol tls
    table TableHTTPS

listener {
    protocol http
    table TableHTTP

table TableHTTPS {
    domain1.com backend1:443
    domain2.org backend2:443

table TableHTTP {
    domain1.com backend1:80
    domain2.org backend2:80
  • Thanks for posting about that project. I was not aware of it
    – user319862
    Dec 7, 2015 at 4:07
  • @mick Hi mick when run SNI as a transparent proxy it break some sites wiht SSL errors. How to fix it ? May 8, 2017 at 9:38
  • Thanks for this recommendation. I choose to use sniproxy over nginx due to its comparatively simple config. Mar 10, 2021 at 3:41

This is certainly possible, even now in 2021 with more and more widespread TLS 1.3! Many web servers or specialized reverse proxies provide this functionality out of the box:

  • Nginx ≥ 1.11.5 (Debian ≥ buster or stretch-backports)
  • HAProxy ≥ 1.5 (Debian ≥ jessie)
  • Sniproxy (Debian ≥ buster)
  • etc.

This is an example configuration for Nginx, which is a very popular choice for setups that require a reverse proxy:

stream {
  map $ssl_preread_server_name $selected_upstream {
    example.org upstream_1;
    example.net upstream_2;
    example.com upstream_3;
    default upstream_4;
  upstream upstream_1 { server; }
  upstream upstream_2 { server; }
  upstream upstream_3 { server; }
  upstream upstream_4 { server; }
  server {
    proxy_pass $selected_upstream;
    ssl_preread on;

The relevant Nginx modules are stream_core and stream_ssl_preread. Manuals:


Be aware that if the target servers use the same certificate (which is not very unlikely when wildcard certificates are in use), then HTTP/2 can not be used. It will route your traffic to the wrong server.


  • a.example.com with certificate *.example.com
  • b.example.com with certificate *.example.com

If a.example.com and b.example.com are handled by the same reverse proxy then a single connection will be opened - and streamed to the server that is called for the first time. So if you call a.example.com, future requests to b.example.com may reach the wrong web server.

For reference, see

  • 1
    Thanks for this answer, helped me solve this exact issue - where I had a common IP with a shared SSL certificate proxying to separate upstream services. The easiest solution seems to be to configure the upstream server to return a 421 if it receives messages intended for an unexpected endpoint. For me this looked like: server { listen 443 ssl http2 proxy_protocol default_server; listen [::]:443 ssl http2 proxy_protocol default_server; server_name _; # may need ssl certs here return 421; }
    – Tyris
    Mar 19, 2021 at 5:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .