# vLLM не открывается: localhost, контейнер и опубликованный порт

Почему vLLM недоступен по localhost: адрес процесса, сетевое пространство контейнера, публикация порта и последовательная локальная диагностика.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-localhost-container-port/
Language: ru

Если vLLM не открывается по localhost, сначала определите, где находится клиент и где работает сервер. Адрес 127.0.0.1 указывает на текущую сетевую среду: для браузера, контейнера и удалённой машины это могут быть разные места. Проверяйте готовность процесса, привязку интерфейса и публикацию порта отдельно от модели и GPU.

## Нарисуйте короткую схему соединения

Запишите цепочку словами: браузер на ноутбуке → локальный порт хоста → порт контейнера → процесс vLLM. Если клиент тоже в контейнере, добавьте его отдельным узлом. Такая схема часто сразу показывает, почему обращение к собственному localhost не достигает соседнего процесса.

Не начинайте с изменения всех сетевых правил. Сначала сохраните адрес запроса, место его выполнения и ожидаемый сервер. В [инструкции Docker vLLM](https://docs.vllm.ai/en/stable/deployment/docker/) показана публикация порта, а параметры интерфейса и порта перечислены в [справочнике serve](https://docs.vllm.ai/en/stable/cli/serve/).

## Убедитесь, что движок готов

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

После готовности обратитесь к HTTP-интерфейсу из ближайшей доступной среды. Затем получите `/v1/models` и выполните короткий запрос. Разница между живым процессом и работающей генерацией разобрана в [проверке готовности](/ru/journal/vllm-health-ready/). Сохраняйте точный тип ошибки: отказ соединения отличается от HTTP-ответа с ошибкой модели.

## Проверьте две стороны опубликованного порта

В записи `-p 127.0.0.1:8000:8000` первое значение порта относится к хосту, второе — к контейнеру. Если сервер внутри слушает другой порт, публикация должна соответствовать этому выбору. Номер снаружи не обязан совпадать с внутренним, но различие нужно явно записать.

Сервер внутри контейнера также должен слушать доступный контейнеру интерфейс. Привязка только к его внутреннему loopback способна помешать маршруту через опубликованный порт. Прежде чем менять привязку, проверьте реальную команду и журнал, а не предполагаемый конфигурационный файл.

## Разделите локальный доступ и внешнее подключение

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

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

Если меняете карту или движок, сохраните прежнюю сетевую схему как контроль. Связь сетевой доступности с производительностью разобрана в [пилотном чек-листе](/ru/journal/pilot-checklist/): каждую ступень полезно подтверждать своим результатом.

## Практические выводы

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

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