Руководство по HTTP-порту: веб-трафик на порту 80

HTTP — это протокол запросов и ответов, используемый браузерами, API, веб-перехватчиками, проверками работоспособности и многими внутренними службами. Через порт 80 клиент подключается через TCP, отправляет HTTP-запрос и получает заголовки и тело ответа без предварительного подтверждения TLS.

Поскольку трафик не шифруется, любой, кто может наблюдать за сетевым путем, может видеть URL-адреса, файлы cookie, заголовки, данные форм и содержимое ответов, если приложение не добавит собственную защиту. Для общедоступных веб-сайтов и приложений, прошедших проверку подлинности, порт 80 обычно должен перенаправляться на HTTPS, а не напрямую обслуживать частный контент.

Порт 80 — это обычный HTTP. Порт 443 — это HTTPS, что означает, что HTTP передается внутри сеанса, зашифрованного TLS. Пользовательский интерфейс может выглядеть аналогично в браузере, но модель безопасности другая: HTTPS проверяет сертификат сервера и шифрует передаваемый трафик.

Большинство производственных площадок используют оба порта одновременно. Порт 80 принимает старые ссылки, запросы сертификатов и первые запросы браузера, а затем отправляет перенаправление 301 или 308 на URL-адрес HTTPS на 443. После этого HSTS может автоматически указать браузерам предпочитать HTTPS.

Держите порт 80 открытым, когда вам нужны перенаправления HTTP-to-HTTPS, задачи Let’s Encrypt HTTP-01, проверки работоспособности балансировщика нагрузки, проверки происхождения CDN, простые конечные точки внутреннего состояния или совместимость со старыми системами, которые не могут запускаться напрямую по HTTPS.

Закройте или ограничьте порт 80, если служба является частной, когда все клиенты контролируются и могут использовать HTTPS напрямую, или когда простой HTTP создает ненужную уязвимость. Если вы оставляете его открытым, сохраняйте узкое и предсказуемое поведение: перенаправление, запрос или проверка работоспособности, а не полный доступ к приложению.

Прежде чем открывать TCP 80, убедитесь, что предполагаемый веб-сервер, обратный прокси-сервер, входящий контроллер, источник CDN или балансировщик нагрузки прослушивают правильный интерфейс. Решите, должен ли порт 80 обслуживать контент, перенаправляться на 443, отвечать на проверки работоспособности или отвечать только на пути проверки сертификата.

Средство проверки портов подтверждает доступность сети, но не сообщает, правильна ли ваша цепочка перенаправления, заголовки кэша, маршрутизация виртуального хоста или автоматизация сертификатов. Проверьте путь TCP и поведение HTTP с помощью журналов браузера, Curl и сервера.

На Windows Server запустите IIS, Nginx, Apache, Caddy или другой веб-сервер, привяжите сайт к TCP 80 и разрешите входящий HTTP-трафик в брандмауэре Защитника Windows. Облачным серверам также необходимы соответствующие правила облачного брандмауэра или группы безопасности.

В Linux настройте Nginx, Apache, Caddy, публикацию порта контейнера или входной контроллер для прослушивания 80, затем разрешите TCP 80 в ufw, firewalld, nftables, iptables или брандмауэре провайдера. Контейнеры и службы Kubernetes должны публиковать или маршрутизировать порт на хосте, балансировщике нагрузки или входном уровне.

В macOS порт 80 чаще всего используется для локальной разработки или лабораторных служб. Привилегированные порты могут требовать повышенных разрешений, а правила локального брандмауэра или маршрутизатора по-прежнему определяют, могут ли другие машины получить доступ к службе.

Начните с проверки внешнего порта по общедоступному имени хоста или IP-адресу и порту 80. Если результат открыт, удаленные клиенты могут установить TCP-соединение. Затем запустите Curl -I http://example.com, чтобы проверить коды состояния, перенаправления, заголовки сервера и поведение кэша.

На сервере проверьте прослушиватели с помощью ss -tlnp, netstat, lsof или PowerShell. Для обратных прокси-серверов и развертываний в облаке сравните правила брандмауэра узла, группы безопасности облака, прослушиватели балансировщика нагрузки, сопоставления портов контейнера и журналы приложений, поскольку любой уровень может блокировать или неправильно маршрутизировать HTTP.

Если порт 80 отображается закрытым, возможно, веб-сервер остановлен, прослушивает только локальный хост, использует другой порт или заблокирован брандмауэром хоста. Если время ожидания истекло, пакеты могут быть отброшены облачным брандмауэром, правилом NAT маршрутизатора, фильтром интернет-провайдера, настройкой CDN или политикой безопасности восходящего потока.

Если порт 80 открыт, но страница неверна, проверьте порядок виртуальных хостов, маршрутизацию заголовка хоста, блоки серверов по умолчанию, восходящие прокси-серверы, сопоставления контейнеров и записи DNS. Если происходит цикл перенаправления, сравните виртуальные хосты HTTP и HTTPS и убедитесь, что прокси-сервер правильно передает исходную схему.

Используйте порт 80 намеренно. Перенаправляйте трафик приложений на HTTPS, избегайте использования учетных данных и конфиденциальных данных по простому HTTP и оставляйте только те конечные точки, которые должны оставаться доступными. Для общедоступных сайтов свяжите перенаправление с действительными сертификатами на 443 и HSTS после того, как вы убедитесь, что HTTPS стабилен.

Регистрируйте запросы на порт 80, отслеживайте неожиданные пути и удаляйте устаревшие конечные точки, которым больше не нужен простой HTTP. Если порт 80 предназначен только для ACME или проверок работоспособности, ограничьте ответы этими путями, чтобы облегчить анализ и мониторинг службы.