VPN включён, а localhost не работает: имя, прокси или привязка?

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

Когда localhost разрешается в корпоративную зону

Проверьте, во что разрешается имя, пока туннель поднят, затем выполните тот же запрос с опущенным туннелем и сравните два ответа. Признак — адрес в корпоративном диапазоне там, где вы ожидали 127.0.0.1. Запись вроде localhost.mycompany.corp побеждает запись loopback, как только клиент добавляет этот суффикс в список поиска, и запрос уходит на частный хост, где на этом порту ничего не слушает. Читайте список поиска, а не угадывайте его, потому что клиент может добавить больше одного домена, и порядок решает, какой кандидат проверяется первым:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

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

Настройки прокси, которые перехватывают loopback

Системный прокси, применяемый при поднятии туннеля, примет запрос к 127.0.0.1 и передаст его удалённому прокси, который понятия не имеет, что вы имели в виду. Пустой список исключений превращает локальный запрос в удалённый, и сообщение об ошибке редко об этом говорит. Добавьте loopback-адреса в список исключений на всю сессию, а не на одну команду, затем подтвердите, что инструмент это соблюдает, прежде чем делать выводы о сети.

Фреймворки приложений читают собственные переменные окружения, а иногда и свой конфигурационный файл, поэтому исключение, работающее для одного инструмента, ничего не доказывает для следующего. Браузеры добавляют нюанс: браузеры на Chromium неявно обходят прокси для loopback, и токен исключения может убрать это поведение. Проверяйте фактическое решение прокси, а не предполагайте, что настройка операционной системы — это вся история. Две команды решают это для всего, что запускается из оболочки:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Адрес привязки решает, кто может подключиться

Сервер, запущенный на 127.0.0.1, принимает подключения только с этой машины, что обычно и есть правильное значение по умолчанию для разработки. Сервер на 0.0.0.0 отвечает на каждом интерфейсе, включая адаптер VPN, а это больше открытости, чем имеют в виду большинство людей. Когда буквальный loopback-адрес не работает, сначала проверьте привязку.

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

Где инструмент отладки ожидает LAN

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

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

Остановитесь на первом сбойном этапе

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

Замените фиксированную паузу ограниченной проверкой готовности, которая ждёт маршрут, и оставьте сбойный этап в журнале, чтобы следующий человек видел, где всё остановилось. Инструмент, который восстанавливается сам, не исправлен, ему просто повезло, а удача заканчивается на чужой машине. Меняйте туннель последним и только для того этапа, который действительно сбойнул. Этот порядок — ещё и кратчайший путь назад к работающей сборке, потому что не даёт переделывать компонент, который никогда не участвовал.