Порт открыт, а сайт всё равно не работает — почему?

Открытый порт означает только то, что операционная система принимает TCP-соединение на этом порту. Сам факт открытого порта ничего не говорит о том, работает ли веб-сервер за ним корректно — это две разные вещи, и путать их не стоит.

Что проверить в первую очередь

Если порт 80 или 443 отвечает, а браузер выдаёт ошибку или бесконечную загрузку, порядок диагностики такой:

  • Проверьте, слушает ли на этом порту именно нужный процесс: netstat -tulpn | grep :80 или ss -tulpn. Порт может быть занят другим сервисом.
  • Проверьте, что веб-сервер (nginx, Apache) запущен и без ошибок в конфиге: systemctl status nginx, nginx -t.
  • Посмотрите логи сервера — error.log часто сразу показывает причину: неверный root, отсутствующий SSL-сертификат, ошибка в location-блоке.
  • Проверьте локально, до внешней проверки: curl -v http://localhost на самом сервере. Если это не отвечает, проблема не в сети, а в конфигурации сервера или приложения.

Порт открыт снаружи, но локально сайт не отвечает

Это значит, что сетевой уровень (файрвол, роутер, порт-форвардинг) настроен верно, но сам сервис за портом не обрабатывает запросы. Частые причины:

  • Веб-сервер упал или завис — процесс есть в списке, но не отвечает на запросы (зависший воркер, исчерпание лимита соединений).
  • Неверный server_name или виртуальный хост — сервер отвечает, но не тому домену, который вы проверяете.
  • Бэкенд (PHP-FPM, приложение на Node/Python) недоступен, и веб-сервер отдаёт 502/504 вместо страницы.
  • SSL-сертификат просрочен или не соответствует домену — порт 443 открыт, но handshake обрывается.

Порт открыт, но сайт недоступен только снаружи

Если локально (с самого сервера) сайт открывается, а извне — нет, дело в сети:

  • Файрвол на уровне провайдера или облачной платформы (security group в AWS, firewall в VPS-панели) блокирует внешние подключения отдельно от локального iptables.
  • NAT/порт-форвардинг на роутере настроен для одного порта, а сервис слушает другой (например, проброшен 8080, а nginx слушает 80).
  • DNS-запись указывает не на тот IP-адрес, где реально открыт порт.

Быстрая проверка снаружи

Чтобы отделить сетевую проблему от проблемы приложения, используйте curl с подробным выводом: curl -v -I https://example.com. Если соединение устанавливается (виден TCP handshake), но ответ приходит с ошибкой 4xx/5xx или обрывается на TLS — проблема на уровне сервера или сертификата, а не сети. Если соединение зависает или таймаутит — дело в файрволе, маршрутизации или NAT.

Открытый порт — необходимое, но не достаточное условие работы сайта. Прежде чем чинить сеть, убедитесь, что сам процесс сервера жив и отвечает на localhost.

Понравилась статья? Поделиться с друзьями: