Изначально я пилил инструмент совершенно под другие задачи - закрывать админки и внутренние сервисы от ботов и посторонних глаз. Но в процессе работы над архитектурой меня осенило. Встроенный механизм переопределения DNS (DNS Override) можно применить для тестирования миграции сайтов. И главное - это закрывает постоянную "головную боль". Как дать протестировать новый сервер нетехническим людям (клиентам, маркетологам, контент-менеджерам) без танцев с бубном вокруг их компьютеров.
В чём обычно проблема с проверкой перед переездом
Сценарий классический, сайт скопирован на новый сервер, база перенесена, конфиги настроены. Прежде чем менять DNS-записи и пускать живых пользователей, нужно убедиться, что всё работает. На бумаге легко, а на практике начинается выбор между неудобным и рискованным.
Если прописывать новый IP в /etc/hosts, то всё честно. Домен настоящий, SSL валиден, абсолютные ссылки не ломаются. Но попробуйте объяснить клиенту или контент-менеджеру, как открыть «Блокнот» от имени администратора на Windows или подправить файл через терминал на Mac, а потом ещё сбросить кэш DNS. На мобильных устройствах это вообще практически невозможно без рут-прав.
Альтернатива - временный поддомен вроде new.example.com. Но тут мы тестируем совсем не то, что поедет в прод. Лезут проблемы с абсолютными ссылками, отваливаются OAuth-авторизации, а CMS вроде WordPress или Bitrix могут начать выдавать редиректы и mixed content.
Можно ещё поднять локальный DNS в офисе, настроить прокси вроде Charles или переключать Origin в CDN, но всё это упирается либо в сложность настройки для обычного пользователя, либо в риск задеть живой трафик. Ни один привычный метод не даёт одновременно боевой домен, простую передачу доступа всей команде и полную безопасность для прода.
Как сработала идея с DNS Override
Архитектура нашего сервиса устроена просто. Шлюз с встроенным DNS-резолвером и компактное браузерное расширение у пользователей. Расширение перенаправляет трафик указанных доменов через шлюз (используя стандартные API браузеров), а весь остальной интернет пускает напрямую.
Идея оказалась простой, если в настройках шлюза указать «для домена example.com использовать IP нового сервера», мы получаем идеальный изолированный стенд.
При этом домен остаётся настоящим, SSL-сертификат работает, CMS не путается в адресах, а обычные посетители сайта продолжают спокойно ходить на старый сервер. Более того, расширение выключается в один клик. Можно буквально за секунду переключаться между старой и новой версией, сравнивая вёрстку и поведение (даже F5 нажимать не нужно, страница автоматически перегружается).
Главный профит тут достаётся именно нетехническим участникам процесса. Разработчику больше не нужно проводить созвоны, объясняя клиенту, QA или маркетологу, как подменить IP в системе или поставить корневой сертификат. Человеку просто передаётся короткий токен. Он вставляет его в расширение - и в его браузере боевой домен мгновенно начинает открываться с нового сервера.
Итог
Иногда вспомогательные функции дают функционал, заслуживающий отдельного самостоятельного юзкейса. Мы сделали резолвер для доступа к внутренним сервисам, а получили удобный «тумблер реальности» для миграций, который не пугает клиентов и нетехнарей.
Проверить, насколько это удобно, вы можете на нашей демо-странице - без регистрации, достаточно просто установить расширение из стора Chrome/Firefox и ввести демо-токен.
Комментарии (13)
aol-nnov
07.08.2026 16:58https://staging.example.net, но тогда не получится пропиарить “эл семь админ гард” в конце статьи, да и статьи-то не получится… сплошные минусы! ))
AVX
07.08.2026 16:58А что насчёт линуксовых машин? Мне казалось, что преобразование имя-айпи выполняет системный резолвер, а он может быть разным на разных дистрибутивах или даже просто один и тот же дистр по-разному настроен. Расширение браузера забирает эти функции на себя? Браузер перестаёт использовать системные библиотеки для этих целей? Кэширование разрешения имён не влияет тут?
Naves
07.08.2026 16:58По умолчанию в Linux браузер Mozilla Firefox может игнорировать настройки из /etc/resolv.conf из-за включенной функции DNS через HTTPS (DoH / TRR). В режимах защиты по умолчанию браузер часто отправляет запросы через внешние защищенные серверы (например, Cloudflare), минуя локальный системный резолвер.
AVX
07.08.2026 16:58А это поведение как-то можно контролировать? Выглядит небезопасно, когда браузер разрешает имена в стороннем сервисе.
JBFW
07.08.2026 16:58Скорее наоборот, браузер разрешает имена там где они реально работают, а не где местный админ понакрутил...
AVX
07.08.2026 16:58Может это для обычных юзеров и норм, но для корпоративного применения - ровно наоборот, нужно чтобы всё было под контролем, а не так, чтобы браузер лез на хз какие сервера днс, кроме заданных админом.
zapimir Автор
07.08.2026 16:58Расширение браузера забирает эти функции на себя?
Расширение работает по сути, как менеджер прокси. Указывает, что для указанного в конфиге сайта нужно использовать такой-то прокси. Используются механизмы PAC (Proxy Auto-Configuration). Браузер видит, что к
example.comнужно подключиться черезgateway.comи отравляет туда запросCONNECT example.com. Шлюз получает запрос и проверяет по своим конфигам, может ли юзер подключаться к указанному хосту, далее смотрит не указан ли в конфиге DNS Override (если указан, то соединяет с указанным IP), если нет то идет в1.1.1.1/8.8.8.8и получает IP. И делает туннель к данному IP, после чего в тупую перекидывает байты из одного сокета в другой, только считая их.
Поэтому в данном случае безразлично какая у юзера система, так как механизм работает на уровне браузера, и к системному резолверу браузер не обращается.
Сам же прокси написан на Go, и заточен исключительно на создание туннеля и перекидывание байтов из сокета в сокет. При этом работает только по HTTPS.
Изначально использовал готовые прокси-серверы, но основная проблема, что они не умеют без танцев с бубном делать whitelist доменов для каждого юзера (по сути нужно свои внешние плагины-костыли писать), кроме того любое изменение конфига это рестарт сервера. В моём же случаи конфиги меняются инкрементально (т.е. если изменился один юзер, то приходят изменения только по этому юзеру) без каких-либо рестартов. К примеру, если юзер качает дамп базы, и у него заканчивается трафик, админ может из панели управления добавить, к примеру 500 МБ, и через доли секунды лимит трафика будет увеличен, без обрыва активной сессии. Тот же сертификат обновляется без рестарта, просто новые коннекты начинают ходить с новым сертом. Ну и за счет того, что выкинут всякий MITM, размер шлюза всего 8 МБ, без единой зависимости, его можно поставить на "голую" Debian 13 просто скачав один файл и добавив его в сервисы.
JBFW
07.08.2026 16:58Эту задачу можно решить на уровне nginx на сервере:
Задаем два апстрима, один рабочий, а другой новая версия:
upstream backend_real { server10.1.0.1:8080; } upstream backend_test { server10.1.0.2:8080; }Мапим юзеров по их адресу (remote_addr):
Для всех - рабочий сервер, для контрольной группы (или конкретных IP) - тестовая версияmap $remote_addr $backend { default backend_real; 192.168.1.0/24 backend_test; }И потом просто отправляем кого куда:
server { ... ... location / { proxy_path http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-HTTPS 0; proxy_set_header Referer $http_referer; } }Всё, контрольная группа тестирует, если все ОК - переключаем апстрим на новый, старый можно сохранить на случай срочного отката, потом убрать.
zapimir Автор
07.08.2026 16:58Можно, но с оговорками. И основная проблема сейчас "Мапим юзеров по их адресу". Так как статический IP сейчас проблема.
Мне собственно из-за этого и пришла в голову идея с легковесным прокси, так как это даёт статический IP, а юзеры могут хоть через WiFi кафешки заходить, хоть из отеля в командировке, хоть из аэропорта.
Как в вашем случае дать доступ внешнему юзеру, предварительно подключить его в свой VPN?
The_KOPACb
07.08.2026 16:58Хм.
Есть миллион способов сделать это , не заставляя клиента
Как минимум:
-
Правила на реверс прокси:
маршрутизация по ip
Прости маршрутизация
Маршрутизация по куке
Другой домен
Зонирование днс-ответов
Split-horizon, который упоминался в статье
zapimir Автор
07.08.2026 16:58Какой из этих вариантов позволяет юзеру самому быстро переключаться с нового на старый сайт, чтобы иметь возможность сравнить, как раньше было?
В случае с расширением получилась такая фича, что когда выключаете расширение, то сайт перегружается со старого сервера, причем даже позиция прокрутки сохраняется.
-
ky0
Ну и наркомания - заставлять ставить сомнительный плагин в браузер ради таких вещей.
Если уж настолько хочется показать с того же IP и домена - ну, не знаю, куку какую-нибудь секретную добавьте, отдаваемую по определённому урлу, с которой потом будет открываться тестовая версия сайта.
zapimir Автор
А чем сомнительный, он прошел модерацию в обоих официальных сторах и Chrome, и Firefox, а там такого плана плагины проверяются весьма основательно и вручную.
Да и плагин всего 38 КБ включая иконки, использует стандартные средства браузеров PAC для Chrome, и Proxy API для Firefox. В самом плагине даже не используется обфускация и минификация JS, т.е. скачав расширение из стора можно спокойно прочитать исходник, даже комменты в коде оставлены. Кроме того шлюзы работают, без MITM, т.е. сохраняется End-to-end шифрование и они не могут видеть трафик.