Текст и данные · Инструкция
VS Code Remote SSH: проброс порта на localhost
VS Code Remote SSH: проброс порта на localhost нужен, когда веб-сервис работает на удалённой машине и не должен быть.
Короткий ответ
Подключитесь к серверу через Remote - SSH, откройте Ports view и выберите Forward a Port, затем укажите удалённый порт, например 3000. VS Code покажет локальный адрес; если локальный 3000 занят, он может выбрать другой свободный порт.
Что именно пробрасывает VS Code в Remote SSH
При удалённой разработке процесс приложения работает на сервере, поэтому `localhost:3000` в терминале сервера и `localhost:3000` в браузере вашего компьютера — это разные сетевые пространства. Port forwarding связывает локальный порт с портом удалённой машины через SSH-соединение. В результате сервис можно открыть локально, не публикуя его на внешнем интерфейсе удалённого хоста и не настраивая отдельный reverse proxy для временной разработки. Официальная документация VS Code показывает управление через Ports view и Command Palette. Если желаемый локальный порт занят, VS Code может сопоставить удалённый порт с другим локальным номером и сообщить итоговый адрес.
Совет: Сначала убедитесь, что сервис действительно отвечает на удалённой машине: туннель не исправляет приложение, которое не запустилось или слушает другой порт.
Временный forward и постоянный LocalForward
Для разовой сессии проще всего использовать кнопку Add Port или Forward a Port: туннель живёт вместе с подключением и подходит для тестового веб-сервера, базы или отладочного endpoint. Если один и тот же порт нужен при каждом подключении, документация Remote SSH предлагает либо включить восстановление forwarded ports, либо добавить директиву `LocalForward` в SSH config. Например, `LocalForward 127.0.0.1:3000 127.0.0.1:3000` фиксирует локальную и удалённую стороны. Такой вариант прозрачен и работает на уровне SSH, но при конфликте локального порта соединение может не поднять этот forward. Поэтому для командной разработки сначала решите, нужен ли автоматический постоянный tunnel или удобнее создавать его по требованию.
Важно: Привязывайте локальную сторону к 127.0.0.1, если сервис нужен только на вашем компьютере. Не расширяйте bind на внешние интерфейсы без явной необходимости.
Как пробросить удалённый порт через интерфейс VS Code
- Подключитесь по Remote - SSH: Откройте нужный host и убедитесь по индикатору удалённого окна, что workspace действительно выполняется на сервере.
- Запустите сервис на сервере: Например, приложение слушает порт 3000. Проверьте в удалённом терминале, что процесс запущен и порт соответствует конфигурации.
- Откройте Ports view: В нижней панели выберите Ports или выполните команду `Ports: Focus on Ports View` через Command Palette.
- Добавьте удалённый порт: Нажмите Forward a Port или Add Port и введите 3000. При необходимости задайте понятное имя, например `web-dev`.
- Откройте Local Address: VS Code покажет локальный адрес. Если 3000 свободен, это часто localhost:3000; при конфликте номер может отличаться.
- Закрепите при необходимости: Включите `Remote: Restore Forwarded Ports` для восстановления или добавьте LocalForward в SSH config, если tunnel должен создаваться стабильно при каждом соединении.
Предупреждение: Не путайте Remote SSH forwarding с функцией public dev tunnels. В Remote SSH сценарий обычно нужен для приватного доступа с вашего компьютера к порту удалённой машины.
Как выбрать способ проброса
[object Object]
Почему локальный адрес иногда не совпадает с удалённым портом
Если вы пробрасываете удалённый 3000, VS Code старается сделать удобный local mapping, но занятый локальный порт нельзя использовать одновременно вторым процессом. Тогда редактор может сообщить другой номер, например localhost:4123, при сохранении назначения на remote:3000. Это нормальная ситуация, а не признак того, что сервис сменил порт. Если приложение формирует абсолютные callback URL, OAuth redirect или cookie с жёстким портом, такой remap уже имеет значение — тогда освободите нужный локальный порт или измените Local Address Port через интерфейс. При проблемах проверяйте три точки отдельно: слушает ли сервис на сервере, существует ли forward в Ports view и доступен ли итоговый локальный адрес.
Безопасность временного порта при удалённой разработке
Главное преимущество local forwarding в том, что сервис может оставаться непубличным и быть доступным через уже аутентифицированное SSH-соединение. Но это не повод считать любой forwarded endpoint безопасным: веб-приложение всё равно может иметь уязвимости, а локальная машина — другие процессы и пользователей. Не меняйте bind на `0.0.0.0`, если достаточно localhost, и не используйте публичный туннель для административной панели без дополнительной аутентификации. Если проект обрабатывает секреты, следите также за тем, что именно приложение пишет в браузер и логи. Port forwarding решает сетевую достижимость, но не заменяет контроль доступа самого сервиса.
Как проверить туннель по слоям, если браузер не подключается
Не начинайте с переустановки Remote - SSH. Сначала на удалённой машине проверьте сам сервис: из remote terminal обратитесь к `127.0.0.1:<порт>` или к тому адресу, на котором приложение реально слушает. Если ответа нет, forwarding ни при чём — нужно чинить сервис или его bind address. Если удалённый endpoint отвечает, посмотрите Ports view и убедитесь, что нужный remote port присутствует и у него есть Forwarded Address. Затем откройте именно этот локальный адрес, а не автоматически тот же номер порта. При конфликте VS Code может выбрать другой localhost-порт, и это штатное поведение. Только после этих трёх проверок имеет смысл смотреть локальный firewall, proxy или конфликт `LocalForward` в SSH config. Разделение на remote service → SSH tunnel → local client экономит время и показывает, на каком слое соединение реально ломается.
Когда нужен LocalForward, а когда достаточно Restore Forwarded Ports
`Remote: Restore Forwarded Ports` удобно для обычной разработки внутри VS Code: редактор запоминает ранее проброшенные порты и пытается восстановить их при новой remote-сессии. `LocalForward` в SSH config полезнее, когда туннель должен быть частью самого SSH-подключения и работать независимо от конкретного workspace. Например, фиксированный callback на `127.0.0.1:3000` проще описать директивой SSH, если приложение ожидает именно этот адрес при каждом соединении. Но жёсткая привязка имеет цену: занятый локальный порт может помешать создать forward, тогда как временный Ports view способен выбрать свободный номер. Поэтому не дублируйте один и тот же туннель сразу несколькими механизмами без причины. Для разового сервиса используйте интерфейс VS Code; для постоянной инфраструктурной зависимости — явный LocalForward с понятным адресом и портом.
Если localhost не открывается после Forward a Port
- Удалённое приложение запущено и слушает тот порт, который вы пробрасываете.
- Remote - SSH соединение активно и не перезапущено после создания tunnel.
- В Ports view у порта есть Forwarded Address без ошибки.
- Вы открываете фактический локальный порт, а не автоматически предполагаете тот же номер.
- Локальный firewall или proxy не блокирует обращение к localhost.
- Если используется LocalForward, в SSH config нет дубликата или конфликта адреса.
Что учитывать
Если вы пробрасываете удалённый 3000, VS Code старается сделать удобный local mapping, но занятый локальный порт нельзя использовать одновременно вторым процессом. Тогда редактор может сообщить другой номер, например localhost:4123, при сохранении назначения на remote:3000. Это нормальная ситуация, а не признак того, что сервис сменил порт. Если приложение формирует абсолютные callback URL, OAuth redirect или cookie с жёстким портом, такой remap уже имеет значение — тогда освободите нужный…
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Remote Development using SSH). Пример и формулировки — редакция N1RO на 2026-09-20.