NGINX поддерживает SNI или нет?

РЕДАКТИРОВАТЬ Новый вопрос: Может ли NGINX проверять запрос TLS для поиска SNI, как это делает HAProxy (и т. Д.)?

Согласно тому, что я читал (и я был сказал), NGINX не должен поддерживать SNI, и я должен выбрать HAProxy для SSL-прозрачного обратного прокси. Хорошо. Тем не мение, этот похоже, предполагает, что NGINX действительно поддерживает SNI, но я не могу найти ни единого клочка полезной документации. То есть все, что я смог найти, подразумевает, что мне все еще нужно было предоставить NGINX сертификаты, чтобы он мог соответствовать имени хоста запроса. Но разве это не та проблема, которую пытается решить SNI?

Теперь я начинаю запускать значительное количество разных сайтов HTTPS на одном IP-адресе, что сказывается на сохранении одного и того же фрагмента информации во многих разных конфигурациях, поэтому я хотел бы знать, лучше ли мне отказавшись от NGINX и изучив еще одно программное обеспечение (также известное как HAProxy), или если я действительно могу придерживаться NGINX - и как.

В идеале, я бы хотел, чтобы прокси-сервер предоставлял своего рода прозрачный туннель для зашифрованного трафика, и только клиент и внутренний сервер (скажем, Apache или любое другое приложение, которое я запускаю) должны иметь возможность его расшифровать. - это означает, что мне не придется хранить информацию о сертификатах в конфигурации обратного прокси. Это означает, что я могу уйти отсюда

server {
    listen 443 default ssl;

    server_name example.org;
    add_header X-Clacks-Overhead "GNU Terry Pratchett";

    ssl on;
    ssl_certificate         /etc/le_certs/example.org/live/example.org/fullchain.pem;
    ssl_certificate_key     /etc/le_certs/example.org/live/example.org/privkey.pem;

    location / {
        proxy_pass_header   Server;
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          https://exampleapp;
    }
}

сюда

server {
    listen 443 default ssl;

    server_name example.org;
    add_header X-Clacks-Overhead "GNU Terry Pratchett";

    location / {
        proxy_pass_header   Server;
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          https://exampleapp;
    }
}

с дополнительным преимуществом, заключающимся в том, что у прокси-контейнера вообще не будет доступа к сертификатам (поскольку это установка Docker, смонтировано очень много томов, что приводит к еще большему обслуживанию).