Порт 443 закрыт: что делать

Что означает «порт 443 закрыт»

Порт 443 — стандартный порт HTTPS. Когда он «закрыт», браузер не может установить защищённое соединение, и пользователь видит одну из классических ошибок: «Не удаётся получить доступ к сайту», «Сайт не отвечает», «ERR_CONNECTION_REFUSED», «ERR_CONNECTION_TIMED_OUT», «ERR_SSL_PROTOCOL_ERROR». Само сообщение редко указывает на настоящую причину: за одной и той же надписью стоят и файрвол, и остановленный веб-сервер, и неправильно настроенный прокси, и блокировка на стороне хостера.

Важно понимать: «порт 443 закрыт» — это не диагноз, а симптом. За ним скрываются минимум четыре разных состояния сети, и лечатся они по-разному. Прежде чем что-то менять, нужно понять, какое именно из них ваше. Быстрый способ — внешняя проверка порта 443: она покажет, открыт ли порт снаружи, и это сразу отсекает половину гипотез.

Четыре разных состояния: «закрыт», «отказ», «таймаут», «фильтр»

Ошибка «порт 443 закрыт» может означать четыре принципиально разные вещи. Различить их критично: от этого зависит, идти ли настраивать файрвол или проверять веб-сервер.

Разница между refused и timed out — ключевая. Connection refused означает, что сеть до сервера работает и кто-то активно отклонил соединение. Timed out означает, что пакеты уходят в пустоту: их кто-то молча выбрасывает. Первое чаще указывает на веб-сервер, второе — на файрвол и хостинг.

Быстрая диагностика: nc, telnet, curl с разбором вывода

Начните с самой простой проверки — отвечает ли порт вообще, без всякого HTTPS.

Проверка порта через nc

nc -vz example.com 443

Разбор флагов и вывода:

• -v — подробный режим, покажет результат попытки;
• -z — zero-I/O: только проверить соединение, ничего не передавать;
• успех выглядит так: Connection to example.com 443 port [tcp/https] succeeded!;
• отказ: nc: connect to example.com port 443 (tcp) failed: Connection refused — порт закрыт явно, RST;
• зависание без ответа и сообщение о таймауте (или подвисание до срабатывания -w) — трафик фильтруется.

Полезно ограничить ожидание, чтобы не ждать минуты:

nc -vz -w 5 example.com 443

Флаг -w 5 задаёт таймаут 5 секунд. Если команда упирается в таймаут — с порта нет ответа вовсе, это почерк DROP-правила или блокировки у провайдера.

Проверка через telnet

telnet example.com 443

Разбор: telnet пытается открыть TCP-соединение на указанный порт.

• Connected to example.com. — порт открыт, TCP-соединение проходит;
• Connection refused — порт закрыт, сервер активно отказал;
• Connection timed out — пакеты отбрасываются;
• Could not resolve host — проблема не в порте, а в DNS; проверьте записи в проверке DNS;
• пустой экран после Connected to ... — нормально: вы соединились с HTTPS-портом «голым» telnet, но TLS-рукопожатие не выполнили, поэтому сервер молчит.

Если telnet на вашей машине не установлен, nc полностью его заменяет.

Проверка «как браузер» через curl

curl -vI https://example.com/ 2>&1 | head -30

Разбор строк вывода:

• Trying 203.0.113.10:443... — клиент начал TCP-соединение, здесь виден IP, который реально отвечает (важно: если IP не ваш, где-то висит прокси или старая DNS-запись);
• Connected to example.com (203.0.113.10) port 443 — TCP прошёл, порт открыт;
• connection timed out на этом месте — порт не отвечает, дальше идти некуда;
• Connection refused — RST, никто не слушает на 443;
• TLS handshake, Client hello и далее SSL certificate problem или error:1408F10B — порт открыт, но TLS не настроен;
• строка subject: и issuer: — сертификат получен, соединение работает;
• < HTTP/1.1 200 OK — сервер ответил, HTTPS работает.

Полезно разделить проверку соединения и проверку TLS:

curl -sS -o /dev/null -w "connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n" https://example.com/

• если команда падает с ошибкой соединения — проблема на уровне TCP/фильтра;
• если соединение есть, а time_appconnect равен нулю или команда падает на TLS — проблема в сертификате или конфиге HTTPS;
• если всё заполнено и code=200 — порт и HTTPS работают, причина «недоступности» была в другом.

Отдельная проверка самого TLS-слоя:

openssl s_client -connect example.com:443 -servername example.com </dev/null

Разбор: -servername передаёт SNI — критично, если на одном IP несколько сайтов. В выводе смотрите строку Verify return code: 0 (ok) — цепочка валидна, любое другое значение указывает на проблему с сертификатом, которую стоит разобрать в проверке SSL-сертификата. Флаг </dev/null нужен, чтобы команда завершилась, а не ждала ввода.

Диагностика файрвола: откуда берётся «закрытый» порт

Если nc даёт таймаут или отказ, а веб-сервер по конфигу должен слушать 443, проверяем сначала сам процесс, затем файрвол.

Проверить, слушает ли кто-то 443-й порт:

sudo ss -tlnp | grep ':443'

Пояснение: -t — только TCP, -l — слушающие сокеты, -n — не разворачивать номера в имена, -p — показать процесс. Нормальный вывод содержит строку вроде LISTEN 0 511 0.0.0.0:443 users:(("nginx",pid=1234,fd=6)). Если строки нет вообще — проблема не в файрволе, а в том, что веб-сервер не слушает 443. Обратите внимание на адрес: 127.0.0.1:443 означает, что сервер слушает только локально и снаружи недоступен — классическая причина «порт закрыт».

Если процесс есть, но снаружи порт недоступен, смотрим правила.

Для nftables:

sudo nft list ruleset | grep -A5 -E 'chain (input|INPUT)'

Для старого iptables:

sudo iptables -L INPUT -n --line-numbers

Для ufw:

sudo ufw status verbose

Разбор: ищите правило DROP или REJECT без исключения для порта 443, а также политику по умолчанию (policy DROP). Для ufw наличие строки 443/tcp ALLOW означает, что порт разрешён; отсутствие строки при включённом ufw (Status: active) — вероятная причина проблемы. Разрешить порт можно так:

sudo ufw allow 443/tcp

Для firewalld:

sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Дополнительно проверьте, не блокирует ли трафик fail2ban или похожий механизм защиты: он может занести ваш IP в блокировку после серии неудачных попыток, и тогда «порт закрыт» будет только для вас. Репутацию адреса стоит проверить отдельно, чтобы исключить блокировку именно вашего IP.

Диагностика на стороне хостинга и облака

Очень частая история: на сервере всё настроено, ss показывает слушающий 443, локальный curl работает, а снаружи — таймаут. Значит, блокировка находится не на вашем сервере, а на уровне инфраструктуры, до него.

Что проверять по порядку:

1. Правила облачного firewall / security group. У облачных провайдеров порт может быть закрыт на уровне виртуальной сети, независимо от правил внутри ВМ. Проверьте inbound-правила для TCP 443 и адрес источника (0.0.0.0/0, если сайт должен быть публичным).
2. Файрвол в панели управления хостингом. Многие панели имеют свой отдельный «сетевой экран» с собственным набором правил, который перекрывает серверный.
3. Прокси и CDN перед сервером. Если трафик идёт через промежуточный слой, порт 443 может быть открыт на прокси, но закрыт до бэкенда, либо наоборот. Проверьте, какой IP отдаёт DNS, и совпадает ли он с вашим сервером: если нет, проблема в конфигурации прокси.
4. Блокировка у провайдера. Бывает, что хостер приостанавливает сервис (например, из-за жалобы или неоплаты) и фильтрует порты. Признак — сайт не отвечает из всех внешних точек, включая независимые проверки.
5. Блокировка на стороне клиента или его провайдера. Если порт открыт для всех, кроме вас, дело в вашей сети, корпоративном прокси или региональной фильтрации. Сравните с внешней проверкой: она покажет картину «снаружи».
6. Порты в конфигурации приложения. Обратный прокси может слушать 443, а приложение — другой порт, и падать при передаче. Проверьте, что upstream в конфиге указан верно.
7. Домен и DNS. Если A-запись указывает на старый или чужой IP, вы будете стучаться «не туда» и получать отказ. Сверьте записи в DNS и проверьте, на какой адрес указывает домен.

Полезный приём для локализации: проверьте порт изнутри сервера на локальный адрес, затем на внешний IP, затем с внешней точки. Это даёт три разных ответа и сразу указывает слой:

curl -sS -o /dev/null -w "local  %{http_code}\n" https://127.0.0.1/ -k --resolve example.com:443:127.0.0.1
curl -sS -o /dev/null -w "public %{http_code}\n" https://example.com/ || echo "public: не отвечает"

Пояснение: первый вызов идёт напрямую на локальный адрес и минует сеть — если он успешен, значит, веб-сервер и TLS живы, а проблема во внешнем доступе. Второй обращается к публичному имени, как обычный пользователь. Разница между «local 200» и «public: не отвечает» с высокой вероятностью означает файрвол, security group или блокировку у провайдера.

Таблица «симптом → причина → решение»

Отдельно про HTTP: если у вас «закрыт» 80-й порт, логика диагностики та же, но контекст другой — разбор в статье Порт 80 закрыт: что делать.

Частные случаи: Nginx, Apache, Docker, IPv6

Nginx

Убедитесь, что есть блок server с listen 443 ssl; и корректно указаны ssl_certificate и ssl_certificate_key. Частая ошибка — listen 443 без ssl, из-за чего на порту служит HTTP-сервер, а браузер ждёт TLS и получает ошибку. Проверить конфиг до перезапуска:

sudo nginx -t
sudo systemctl reload nginx

Apache

Порт 443 обслуживается модулем SSL. Проверьте, включён ли он, и что виртуальный хост с SSLEngine on существует:

sudo apachectl configtest
sudo a2enmod ssl

Docker и контейнеры

Если приложение в контейнере, проверьте публикацию порта: -p 443:443. Без неё порт слушает только внутри контейнера, и снаружи он «закрыт», хотя сервис работает. Проверьте проброс:

docker ps --format '{{.Names}} {{.Ports}}'

IPv6

Если у домена есть AAAA-запись, но IPv6 на сервере не настроен или не слушается, часть пользователей будет получать «недоступно», тогда как остальные видят нормальную работу. Уберите лишнюю AAAA-запись или настройте прослушивание IPv6 — проверьте записи в проверке DNS.

Что проверить после восстановления

Порт открылся — не заканчивайте на этом. Пройдите короткий чек-лист:

1. HTTPS отвечает с кодом 200 из внешней точки, а не только с вашей машины;
2. сертификат валиден, цепочка полная, срок не истекает на днях;
3. редирект с HTTP на HTTPS работает;
4. сайт одинаково доступен по IPv4 и IPv6;
5. таймауты и ошибки не повторяются — это стоит подтвердить наблюдением, а не разовым замером.

Для регулярного контроля доступности портов и сервисов удобно опираться на внешние проверки: они видят ровно то, что видят ваши пользователи. Начните с проверки порта, а SSL, DNS и общий статус сайта держите под наблюдением в UptimeChecker, чтобы узнавать о закрытом порте из своих метрик, а не из жалоб клиентов.