В этом материале
Экспонирование порта даёт маршрут к процессу, но сам процесс, его bind-адрес и авторизация настраиваются отдельно.
HTTP-сервис в Runpod открывают через HTTP proxy, указав внутренний порт приложения в настройках Pod. Приложение должно работать и слушать доступный контейнеру интерфейс, обычно 0.0.0.0. URL прокси содержит ID Pod и внутренний порт; SSH-порт из Connect для этого адреса не используется.
Как устроен адрес прокси
Документация открытых портов описывает формат https://POD_ID-PORT.proxy.runpod.net. PORT здесь соответствует HTTP-порту сервиса внутри контейнера. Это отличается от прямого TCP, где панель выдаёт внешний сопоставленный порт.
Начните с записи трёх параметров: имя процесса, его внутренний порт и способ публикации. Такая карточка помогает коллеге понять, какой адрес проверять. Если в контейнере работают несколько интерфейсов, каждому нужен собственный понятный маршрут и отдельно настроенная защита.
Сначала проверьте само приложение
Откройте журнал запуска и убедитесь, что процесс завершил инициализацию. Затем выполните локальный HTTP-запрос внутри Pod к выбранному порту. Страница может быть недоступна из-за ошибки приложения, отсутствующего файла конфигурации или неверной команды запуска; изменение облачного порта этого не исправляет.
Если локальный ответ есть, проверьте bind-адрес. Процесс на 127.0.0.1 может быть доступен внутри контейнера, но не по внешнему маршруту прокси. Для публикации изменяют привязку осознанно. Для SSH-туннеля, напротив, loopback может быть именно желаемой настройкой.
Пример панели результатов эксперимента
Команда запускает небольшой веб-интерфейс для просмотра агрегированных метрик. Внутри Pod он использует порт 8080. После проверки локального ответа команда добавляет этот HTTP-порт в настройки и получает URL текущего Pod. При пересоздании ресурса адрес нужно сверить заново.
Проверка состоит из двух разных тестов: маршрут возвращает страницу и неавторизованный посетитель не видит закрытые данные. Рабочий HTTPS-адрес подтверждает транспортное соединение, но не показывает, что приложение правильно ограничивает доступ к результатам.
Отделите прокси от прямого TCP
| Способ | Что указывает клиент | Что настраивается внутри |
|---|---|---|
| HTTP proxy | URL с ID Pod и HTTP-портом | Работающий HTTP-сервис |
| Прямой TCP | IP и внешний сопоставленный порт | Сервис на внутреннем порту |
| SSH-туннель | Локальный адрес ноутбука | Доступ SSH и адрес назначения |
Руководство SSH полезно, если интерфейс нужен только одному администратору. Не публикуйте дополнительный порт исключительно потому, что первая попытка через другой способ подключения оказалась неудачной: сначала определите, какой путь нужен пользователю.
Для проверки маршрута удобно сначала поднять простой служебный ответ без рабочих данных. Он покажет, доходит ли запрос до процесса. После этого проверяют настоящее приложение, его обработку путей и авторизацию. Такой тест разделяет инфраструктурную проблему и ошибку сложного интерфейса.
Как оформить результат
Запишите команду запуска без секретов, внутренний порт, тип маршрута и способ аутентификации. Для долгих операций отдельно проверьте ограничения HTTP proxy и поведение клиента при разрыве соединения. Продолжительная задача должна сохранять состояние независимо от открытой вкладки браузера.
Если маршрут перестал работать после остановки, проверьте состояние Pod и процесса, затем актуальный URL. Для повторного запуска понадобятся сохранённая конфигурация и правильные пути к файлам.
Продолжите с доступа через SSH-туннель и сохранения результатов Jupyter.