proxy_ssl_server_name в Nginx Ingress: Полное руководство по настройке и устранению ошибок

Что такое proxy_ssl_server_name в Nginx Ingress?

Директива proxy_ssl_server_name — критически важный параметр конфигурации Nginx Ingress Controller, управляющий передачей SNI (Server Name Indication) при проксировании TLS-трафика. Когда Ingress перенаправляет зашифрованные HTTPS-запросы к бэкенд-сервисам, эта директива определяет, будет ли имя сервера из оригинального запроса клиента включено в TLS-рукопожатие с целевым POD. По умолчанию отключена (off), что вызывает проблемы при работе с сертификатами для нескольких доменов.

Как работает SNI и зачем нужен proxy_ssl_server_name

SNI — расширение TLS-протокола, позволяющее серверу предъявлять корректный SSL-сертификат для разных доменов на одном IP-адресе. Без активации proxy_ssl_server_name:

• Nginx не передаёт доменное имя клиента бэкенду
• Серверы с мультидоменными сертификатами возвращают ошибки SSL
• Возникают сбои вида SSL_ERROR_NO_CYPHER_OVERLAP в браузерах

Активация директивы решает эти проблемы, добавляя заголовок Server Name в TLS-клиент бэкенда.

Пошаговая настройка proxy_ssl_server_name в Kubernetes

Для включения через ConfigMap Nginx Ingress Controller:

1. Создайте или отредактируйте ConfigMap:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: nginx-configuration
     namespace: ingress-nginx
   data:
     proxy-ssl-server-name: "on"

2. Примените изменения: kubectl apply -f configmap.yaml
3. Проверьте логи Ingress Controller: kubectl logs -n ingress-nginx [pod-name] | grep proxy_ssl_server_name

Для аннотации в конкретном Ingress-ресурсе:
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"

Типичные ошибки и решения

• Ошибка 502 Bad Gateway: Проверьте синтаксис ConfigMap и перезапустите POD
• Сертификат не соответствует домену: Убедитесь, что бэкенд поддерживает SNI
• Конфликт с proxy_ssl_name: Не используйте обе директивы одновременно
• Устаревшая версия Ingress Controller: Обновите до актуальной версии (v1.0+)

Оптимизация производительности и безопасности

При активации proxy_ssl_server_name:

• Добавьте proxy_ssl_verify on для проверки сертификатов бэкенда
• Настройте proxy_ssl_trusted_certificate с цепочкой CA
• Ограничьте TLS-версии: proxy_ssl_protocols TLSv1.2 TLSv1.3
• Мониторьте нагрузку CPU — SNI добавляет 5-7% overhead

FAQ: Часто задаваемые вопросы

Вопрос: Отличается ли proxy_ssl_server_name от proxy_ssl_name?
Ответ: Да. proxy_ssl_name жёстко задаёт домен в TLS-рукопожатии, тогда как proxy_ssl_server_name динамически передаёт имя из запроса клиента.

Вопрос: Работает ли с самоподписанными сертификатами?
Ответ: Да, но требуется добавить CA в proxy_ssl_trusted_certificate и включить proxy_ssl_verify.

Вопрос: Как проверить, что SNI передаётся корректно?
Ответ: Используйте openssl s_client -connect [адрес]:443 -servername example.com и проверьте поле SSL-Session: в выводе.

Вопрос: Обязательно ли включать директиву для HTTP/2?
Ответ: Да, HTTP/2 требует корректной работы SNI для мультидоменных конфигураций.

Вопрос: Влияет ли на скорость обработки запросов?
Ответ: Минимальное влияние (до 7% на TLS-рукопожатии), компенсируется кэшированием сессий через proxy_ssl_session_reuse.