Как проверить доступность SNI: диагностика DNS, TCP, TLS и HTTPS

Если IP отвечает, а HTTPS-сайт не открывается, полезно проверить соединение с правильным именем сервера — SNI. Это помогает отделить сбой DNS, недоступный TCP-порт, ошибку TLS и ответ самого сайта. Проверка требует пары «домен + IP», а вывод относится к конкретной сети и моменту времени.

Ниже — последовательность для Windows и Linux, примеры curl и OpenSSL и таблица интерпретации. Одиночный таймаут не позволяет уверенно объявить адрес заблокированным ТСПУ: похожий результат дают сервер, маршрут, межсетевой экран и ошибка конфигурации.

Что такое SNI и почему недостаточно открыть IP

SNI — расширение TLS, через которое клиент передаёт имя сервера при установлении защищённого соединения. На одном IP могут работать разные HTTPS-сайты. Имя помогает серверу выбрать нужный сертификат и конфигурацию. Это поведение описано в разделе Server Name Indication RFC 6066.

Когда вы открываете HTTPS по голому IP, сервер может показать другой сертификат, отклонить запрос или вернуть служебную страницу. Такой результат не доказывает, что сайт по своему домену недоступен. HTTP-заголовок Host тоже не заменяет SNI: HTTP начинается уже после установления TLS.

У SNI нет отдельного «адреса» или порта. Проверяется TLS-соединение к IP и порту с определённым именем. Для обычного HTTPS чаще используется TCP 443. Другой сервис может работать на другом порту, который нужно указать явно.

Подготовьте домен, IP и условия проверки

1. Возьмите точный домен без протокола и пути. Для международного домена используйте ASCII-форму punycode, которую понимает выбранный инструмент.
2. Узнайте A- и AAAA-записи. Если адресов несколько, сохраняйте каждый результат отдельно: разные узлы CDN могут вести себя по-разному.
3. Запишите время, провайдера и способ подключения. Домашний интернет, мобильная сеть и удалённый сервер — разные точки наблюдения.
4. Учитывайте VPN, системный прокси и правила роутера. Отключение прокси в curl не отключает туннель или маршрутизацию всей сети.
5. Проверьте часы устройства. Неверное время может вызвать ошибку сертификата при исправном соединении.

Для быстрого дополнительного наблюдения можно использовать сервис проверки сайта или IP на блокировку. Его результат характеризует доступные точки проверки. Отсутствие ответа от одной из них оставляет неопределённость, а успешный ответ удалённого узла не гарантирует доступность у вашего провайдера.

Проверка DNS и TCP в Windows

Откройте PowerShell. Первая команда попросит домен, затем будут показаны его адреса:

$TargetDomain = Read-Host 'Введите домен без https:// и пути'
Resolve-DnsName -Name $TargetDomain -Type A
Resolve-DnsName -Name $TargetDomain -Type AAAA
Test-NetConnection -ComputerName $TargetDomain -Port 443

Отсутствие AAAA не является неисправностью для сайта, который работает только по IPv4. Если не получена A-запись, сначала разбирайтесь с DNS или проверяйте, не является ли сервис IPv6-only. В Test-NetConnection смотрите RemoteAddress и TcpTestSucceeded: так понятно, к какому адресу реально обращался тест.

Проверка TCP не отправляет полноценный HTTPS-запрос с нужным SNI. Значение True означает, что удалось установить TCP-соединение на выбранный порт. Значение False ещё не объясняет причину сбоя. ICMP/ping в этой ситуации — отдельное наблюдение: сервер может не отвечать на ping и нормально обслуживать HTTPS.

Проверка HTTPS с нужным SNI через curl

В PowerShell выберите один IPv4 из DNS-ответа. Используйте именно curl.exe, чтобы команда запускала curl, а не одноимённый псевдоним старых версий PowerShell:

$TargetIp = Read-Host 'Введите один IPv4 из DNS-ответа'
curl.exe --noproxy "*" --http1.1 --resolve "${TargetDomain}:443:${TargetIp}" --connect-timeout 5 --max-time 15 -v -o NUL "https://${TargetDomain}/"
$LASTEXITCODE

Параметр --resolve направляет соединение на выбранный IP, сохраняя домен в URL, TLS SNI, проверке сертификата и HTTP Host. Значение --http1.1 делает этот тест предсказуемым для сравнения; он проверяет HTTPS поверх TCP, а не QUIC. --noproxy исключает прокси, известный самому curl, но не меняет маршруты операционной системы.

Для Linux с установленными curl и dig последовательность такая:

read -r -p 'Домен без https:// и пути: ' DOMAIN
dig +short A "$DOMAIN"
dig +short AAAA "$DOMAIN"
read -r -p 'Один IPv4 из ответа: ' IP
curl --noproxy '*' --http1.1 --resolve "$DOMAIN:443:$IP" --connect-timeout 5 --max-time 15 -v -o /dev/null "https://$DOMAIN/"
echo "curl exit code: $?"

Не добавляйте -k для основной проверки: этот параметр отключает проверку сертификата и скрывает важную часть результата. Возможности --resolve, таймаутов и кодов завершения описаны в официальном руководстве curl; принцип проверки сертификатов — в документации TLS curl.

Проверка TLS отдельно от HTTP через OpenSSL

Если нужно увидеть именно результат TLS-рукопожатия, в Linux используйте установленный OpenSSL. Переменные DOMAIN и IP остаются из предыдущего блока. Утилита timeout ограничивает ожидание всей команды:

timeout 15s openssl s_client -connect "$IP:443" -servername "$DOMAIN" -verify_hostname "$DOMAIN" -verify_return_error -brief < /dev/null

-servername передаёт SNI, -verify_hostname проверяет имя в сертификате, а -verify_return_error заставляет завершить проверку ошибкой при проблеме доверия. Одного успешного открытия сокета недостаточно. На системе должно быть корректное хранилище доверенных корневых сертификатов. Команда предназначена для Linux с GNU timeout; OpenSSL в Windows может потребовать отдельной установки и настройки доверенных CA.

Параметры и поведение s_client приведены в документации OpenSSL. Такой тест не проверяет загрузку страницы целиком: после TLS ещё остаются HTTP, редиректы, авторизация и ресурсы сайта.

Как читать результат без поспешных выводов

curl без --fail может завершиться кодом 0 даже при HTTP 403: он успешно выполнил передачу. Поэтому смотрите и код процесса, и HTTP-строку. Не принимайте загруженную заглушку за нужную страницу — проверяйте содержание и адрес редиректа.

Чтобы обсудить возможную фильтрацию, нужны повторяемые различия между сетями при одинаковых IP, домене и протоколе. Даже такое различие требует исключить ограничения сервера по географии или адресу клиента. Общий механизм сетевой фильтрации разобран в материале о работе ТСПУ, а отдельная проверка адреса — в руководстве по диагностике IP.

Что сохранить для сравнения и обращения в поддержку

Сохраните домен, выбранный IP, порт, время, сеть, версии curl/OpenSSL, этап сбоя и несколько строк ошибки. Повторите тест с другим адресом того же домена, затем с другой сети. Для IPv6 нужен отдельный тест с его адресом и правильным синтаксисом --resolve; вывод IPv4 нельзя автоматически переносить на IPv6.

В подробном выводе могут оказаться токены, cookies и другие данные запроса. Перед передачей лога уберите их. Для публичной страницы достаточно запросить корень сайта без авторизации.

Практическая последовательность остаётся одной: DNS, выбранный IP, TCP, TLS с правильным SNI и проверкой сертификата, затем HTTP. Если отмечать каждый этап отдельно, становится понятно, что действительно сломалось и какое измерение ещё нужно. Это гораздо полезнее единственного вердикта «IP работает» или «SNI заблокирован».