Контейнер запущен, приложение недоступно: как проверить порт и адрес прослушивания в Docker

Если контейнер в Docker имеет статус Up, это еще не значит, что приложение доступно с хоста. На практике ошибка обычно лежит в одном из трех мест: процесс внутри контейнера жив, но слушает не тот порт; процесс слушает нужный порт, но только на 127.0.0.1 внутри контейнера; порт опубликован на хост неверно или опубликован шире, чем вам нужно для локальной проверки.

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

Почему статус контейнера не доказывает доступность сервиса

Команда docker ps показывает состояние основного процесса контейнера, а не готовность веб-приложения принимать подключения. Контейнер может быть запущен, если его стартовая команда все еще работает, даже когда само приложение внутри уже завершилось, зависло на инициализации или слушает не там, где вы ожидаете. Поэтому первый вопрос не «открывается ли страница», а «какой процесс сейчас живет в контейнере и что он пишет в журнал».

Для быстрой проверки обычно достаточно трех наблюдений: есть ли контейнер в списке, нет ли повторных перезапусков и есть ли в логах строка запуска сервиса. Для этого удобно последовательно посмотреть docker ps, затем docker logs --tail 50 ИМЯ_КОНТЕЙНЕРА. В логах вы ищете не общую фразу об успешном старте, а конкретику: номер порта, адрес привязки, сообщения об ошибке конфигурации, трассировки исключений. Если приложение пишет, что слушает 127.0.0.1, дальнейшая проверка уже становится гораздо короче.

Если логи молчат, полезно войти внутрь контейнера и проверить, какой процесс реально запущен. Это не решает проблему само по себе, но отделяет сетевую ошибку от ошибки старта. Когда контейнер запущен, а приложение нет, настройка порта на хосте уже не поможет.

Как понять, какой порт и какой адрес слушает приложение внутри контейнера

Нужно разделять две вещи: номер порта и адрес прослушивания. Порт отвечает на вопрос, по какому номеру сервис принимает соединения, а адрес — на каком сетевом интерфейсе он их принимает. Для контейнера это критично. Если приложение слушает 8000, но только на 127.0.0.1 внутри контейнера, запрос, пришедший через опубликованный порт Docker, обычно не дойдет до приложения: Docker перенаправляет трафик к сетевому интерфейсу контейнера, а не к его внутреннему loopback.

Поэтому недостаточно знать, что «у меня HTTP-сервер на 8000». Нужно выяснить, на чем именно он запущен: 127.0.0.1:8000 или 0.0.0.0:8000. Если приложение само пишет это в логах, используйте логи. Если нет, проверяйте изнутри контейнера: сначала локальный запрос на 127.0.0.1:ПОРТ, затем такой же запрос на IP-адрес контейнера. Когда первый запрос отвечает, а второй нет, это почти прямое доказательство, что сервис привязан только к loopback внутри контейнера.

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

Как сверить внутренний порт приложения и публикацию порта на хосте

После проверки самого сервиса нужно посмотреть, какой порт Docker действительно публикует наружу. Формат публикации читается слева направо: HOST_PORT:CONTAINER_PORT. В записи -p 8080:80 хост принимает трафик на 8080 и отправляет его на 80 внутри контейнера. Если приложение внутри слушает 8000, а опубликован контейнерный порт 80, браузер будет обращаться не туда, хотя контейнер останется в статусе Up.

Проверять это удобно двумя командами: docker ps и docker port ИМЯ_КОНТЕЙНЕРА. Они показывают фактическое сопоставление портов. Здесь важно не подменять реальную картину памятью о том, как контейнер запускался вчера. Если вы не указали порт хоста явно, Docker может выбрать временный свободный порт, и тогда сервис окажется не на 8080, а, например, на другом локальном номере. В таком случае искать проблему в приложении рано: сначала нужно узнать, куда именно опубликован контейнер.

Практический вывод простой: сначала найдите реальный контейнерный порт приложения, потом проверьте публикацию именно этого порта, и только после этого открывайте адрес на хосте. Иначе легко лечить не ту проблему: менять bind-адрес, когда на самом деле перепутан контейнерный порт.

Как проверить доступность локально и не открыть сервис всему интернету

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

Безопаснее задать адрес хоста явно и привязать публикацию к loopback: -p 127.0.0.1:8080:8000. Тогда приложение останется доступным только на этой машине через http://127.0.0.1:8080 или http://localhost:8080. Если вы используете Compose, логика та же: в списке ports указывают строку вида 127.0.0.1:8080:8000.

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

Учебный пример: контейнер запущен, но не отвечает с хоста

Учебный пример. Ниже условный сценарий для локального терминала с Docker. Мы запускаем простой HTTP-сервер Python в контейнере и специально создаем типичную ошибку: сервис слушает только 127.0.0.1 внутри контейнера, а порт на хост публикуется правильно и только локально.

docker run --name demo-app -d \
  -p 127.0.0.1:8080:8000 \
  python:3.12-slim \
  sh -c "mkdir -p /app && printf 'study ok\n' > /app/index.html && python -m http.server 8000 --bind 127.0.0.1 -d /app"

Проверяем внешнюю картину:

docker ps --filter name=demo-app
docker port demo-app
docker logs --tail 20 demo-app

Ожидаемая картина такая: контейнер в статусе Up, публикация показывает 127.0.0.1:8080->8000/tcp, но запрос с хоста на http://127.0.0.1:8080/ не дает содержимое страницы. Теперь нужно доказать, что проблема именно во внутреннем bind-адресе.

docker exec demo-app python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8000').status)"
docker exec demo-app sh -c "hostname -i"

Если первый запрос возвращает 200, сервис внутри контейнера жив. Вторая команда покажет IP контейнера. Подставьте этот адрес во второй запрос. Например, если вы увидели 172.17.0.2, проверка будет такой:

docker exec demo-app python -c "import urllib.request; print(urllib.request.urlopen('http://172.17.0.2:8000', timeout=2).status)"

Проверяем результат по смыслу, а не по точному тексту ошибки. Если запрос на 127.0.0.1:8000 изнутри контейнера отвечает, а запрос на IP контейнера завершается ошибкой соединения, сервис жив, но слушает только loopback внутри контейнера. Значит, порт на хосте опубликован не зря, просто Docker не может передать запрос приложению через сетевой интерфейс контейнера.

Исправление минимальное: пересоздать контейнер так, чтобы приложение слушало все адреса внутри контейнера, а на хосте оставить ограничение только на 127.0.0.1.

docker rm -f demo-app

docker run --name demo-app -d \
  -p 127.0.0.1:8080:8000 \
  python:3.12-slim \
  sh -c "mkdir -p /app && printf 'study ok\n' > /app/index.html && python -m http.server 8000 --bind 0.0.0.0 -d /app"

После этого учебный запрос на http://127.0.0.1:8080/ должен вернуть строку study ok. Проверяемый результат здесь двойной: приложение стало доступно с хоста, и при этом сервис не опубликован на все интерфейсы машины.

Если хотите отработать такие проверки не на одном примере, а в связке с журналами, процессами и сетями, в карточке каталога курса «Основы Docker + модели LLM» сохранены подтвержденные темы про сервис в контейнере, пробрасывание портов, устранение неполадок и сетевые ресурсы. По данным официальной страницы курса, там отдельно заявлены работа с процессами в контейнере, журналы и подробная информация о контейнере.