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

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

Уточните, где именно сработал localhost

Ответ изнутри контейнера, ответ на Docker-хосте и ответ в браузере другого компьютера — три наблюдения. Для каждого запишите место проверки, адрес и ожидаемого участника. Фраза «на localhost работает» без этого не описывает маршрут.

В обзоре сетей Docker loopback относится к сетевому пространству контейнера в описанном сценарии. Если прокси работает отдельно, его localhost нельзя автоматически считать адресом приложения или хоста. Сначала установите фактическую схему сети.

Далее рассматривается обычная схема с bridge и публикацией порта. Для другого сетевого режима правила нужно сверять отдельно. Не переносите выводы о такой публикации на любую конфигурацию Docker по одному похожему номеру порта.

Сначала задайте разрешённый путь посетителя

Условная схема: внешний запрос принимает HTTPS-прокси, а приложение доступно только ему. Тогда прямой внешний вход на внутренний порт не обязан работать. Недоступность такого входа может быть правильным результатом, а ошибку нужно искать в разрешённом пути.

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

Матрица наблюдений для своей среды

Таблица — предлагаемый протокол приёмки, не результаты проверки реального сервера. Заполните ожидаемый результат заранее, чтобы случайный прямой доступ не был принят за успех всей настройки.

EXPOSE и публикация не взаимозаменяемы

В объяснении Docker о публикации EXPOSE сообщает о порте приложения, но сам по себе не публикует его. Сопоставление порта хоста и контейнера — отдельная конфигурация. Номер на внешней стороне может отличаться от номера внутри.

Проверяйте действующий контейнер, а не только Dockerfile. Если конфигурацию запуска поменяли, убедитесь, что рассматриваемый экземпляр получил эти настройки. Сохранённый файл не подтверждает автоматически состояние ранее созданного контейнера.

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

Привязка хоста — самостоятельная граница

В документации port publishing описана публикация на определённый адрес хоста, в том числе loopback. Публикация без указанного host IP по умолчанию может сделать порт доступным на всех интерфейсах. Это изменение области доступа, а не безобидный способ проверить гипотезу.

Docker отдельно предупреждает: в выпусках до 28.0.0 порты, опубликованные на localhost, могли быть доступны другим узлам того же L2-сегмента. Поэтому одну запись с 127.0.0.1 нельзя выдавать за безусловное доказательство изоляции любой версии и среды.

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

Когда приложение отвечает, а прокси нет

Проверьте фактическое назначение upstream из среды самого прокси. Затем свяжите входной запрос с выбранным маршрутом. Так можно отделить недоступность внутреннего адреса от неправильного выбора приложения по внешнему имени.

Не используйте один локальный успешный запрос как доказательство всей цепочки. И наоборот, один отказ извне не объясняет автоматически публикацию: в пути могут быть отдельные правила допуска. Уточните, какой участок не получил запрос или вернул иной ответ.

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

Как принимать исправление

1. Установите сетевой режим и место каждого участника.
2. Запишите разрешённый внешний путь и запрещённые прямые входы.
3. Проверьте адрес слушателя приложения и действующую публикацию.
4. Сопоставьте внутреннее назначение с точки зрения прокси.
5. Найдите первый подтверждённый разрыв разрешённого маршрута.
6. В отдельной безопасной среде измените только нужную причину.
7. Подтвердите функцию извне и сохранение ограничений служебных портов.

Для доработки развёртывания закрепите эту карту вместе с конфигурацией запуска. Исправление должно пережить следующий выпуск. Удачная ручная публикация, которой нет в согласованной схеме, оставляет проблему для следующего перезапуска.