Для разработчиков: практический гайд по Happ
Разработчику VPN нужен не просто как средство обхода блокировок — он нужен точечно: чтобы один сервис шёл через VPN, другой — напрямую, а Docker-контейнеры вели себя предсказуемо. Стандартные настройки Happ покрывают типовое использование, но для рабочих сценариев нужна тонкая настройка. На vpnmobile.biz мы разбираем конфигурацию Happ именно под задачи разработчика.
Раздельная маршрутизация трафика
Split tunneling — ключевая фича для разработчика. Идея: внешние API (GitHub, npm registry, Docker Hub) идут через VPN, а локальные сервисы, корпоративный VPN, российские CDN — напрямую. В Hiddify это настраивается в разделе «Routing Rules» через добавление доменов и CIDR-подсетей в нужные правила.
Пример конфига: добавьте github.com, npmjs.com, registry-1.docker.io в правило «Proxy» — они всегда пойдут через Happ. Добавьте 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 в правило «Direct» — локальные сети не будут маршрутизироваться через VPN, что важно для корпоративных инструментов.
В Clash Verge правила задаются в конфиг-файле YAML в секции rules. Формат: DOMAIN,github.com,PROXY — домен github.com через прокси; IP-CIDR,192.168.0.0/16,DIRECT — локальная сеть напрямую. Порядок правил важен: первое совпавшее правило применяется.
Для xray/sing-box разделение настраивается в секции routing JSON-конфига. Тип geosite предоставляет готовые наборы правил: geosite:geolocation-!cn — все нероссийские домены через proxy; geosite:cn — китайские (и можно добавить российские) через direct. Актуальные geosite-базы обновляются в репозитории v2fly/domain-list-community.
Использование Happ с Docker
Docker по умолчанию создаёт собственные виртуальные сети и не использует системный прокси хоста. Чтобы контейнеры видели VPN, есть два пути. Первый: запустить Happ в TUN-режиме — тогда сетевой адаптер tun0 становится доступен для всех процессов, включая Docker.
Второй путь: явно указать прокси для Docker daemon. В файле ~/.docker/config.json добавьте: {"proxies": {"default": {"httpProxy": "http://127.0.0.1:7890", "httpsProxy": "http://127.0.0.1:7890"}}}. После перезапуска Docker все pull и push операции пойдут через Happ.
Для docker-compose сервисов добавьте переменные окружения HTTP_PROXY и HTTPS_PROXY в секцию environment. Это даст прокси только конкретному сервису, не затрагивая остальные. Полезно, когда один контейнер должен идти через VPN, а другой — напрямую.
WSL2 имеет свой сетевой стек, отделённый от Windows. Для работы через Happ на Windows: в файле /etc/environment в WSL2 добавьте export http_proxy=http://$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):7890. Это динамически берёт IP шлюза WSL2 (который совпадает с IP хоста Windows) и использует порт Hiddify.
Проксирование отдельных инструментов разработки
Git не использует системный прокси автоматически. Настройте прокси для git: git config --global http.proxy http://127.0.0.1:7890. Для HTTPS-репозиториев это покроет все операции. Для SSH-репозиториев (git@github.com) настройте ProxyCommand в ~/.ssh/config: ProxyCommand nc -x 127.0.0.1:7890 %h %p.
npm и yarn читают переменные окружения. Установите npm config set proxy http://127.0.0.1:7890 и npm config set https-proxy http://127.0.0.1:7890. Или установите переменную HTTP_PROXY перед запуском npm install — это работает для одной команды без изменения глобального конфига.
curl и wget не используют системный прокси по умолчанию. Передавайте прокси через флаг: curl --proxy http://127.0.0.1:7890 https://api.github.com/. Чтобы не указывать флаг каждый раз, создайте алиас в ~/.bashrc или ~/.zshrc: alias curl='curl --proxy http://127.0.0.1:7890'.
Python-скрипты с requests: установите переменные окружения HTTPS_PROXY и HTTP_PROXY, или передайте proxies-словарь явно в requests.get(url, proxies={'http': 'http://127.0.0.1:7890', 'https': 'http://127.0.0.1:7890'}). Второй способ предпочтительней в production-коде для явности.
Отладка сети при активном VPN
Wireshark и tcpdump захватывают трафик на интерфейсе tun0 при активном Happ в TUN-режиме. Это позволяет видеть, что именно уходит через VPN. Для захвата: sudo tcpdump -i tun0 -w /tmp/vpn-capture.pcap. В Wireshark откройте файл и фильтруйте по IP назначения или протоколу.
Проблема с SSL-сертификатами при использовании MITM-прокси (Burp Suite, mitmproxy) совместно с Happ: цепочка доверия ломается. Решение: либо отключайте Happ при использовании MITM-прокси, либо настройте Happ так, чтобы целевые домены шли напрямую через правило Direct в маршрутизации.
Latency-профилирование API через VPN: используйте httpie или curl с опцией -v для вывода времени каждого этапа запроса. DNS lookup, TCP connect, TLS handshake — каждый этап отображается отдельно. Это помогает понять, где именно VPN добавляет задержку.
Для локальной разработки с webpack dev server или vite: добавьте localhost и 127.0.0.1 в правило Direct маршрутизации Happ. По умолчанию некоторые клиенты корректно обрабатывают loopback-адреса, но явное правило исключает неожиданности при тестировании локального API.
CI/CD и автоматизация с Happ
GitHub Actions, GitLab CI и другие системы иногда блокируются на корпоративных серверах или требуют доступа к заблокированным внешним сервисам. На Linux-агентах CI можно запустить sing-box или xray-core как фоновый процесс в шаге before_script, используя конфиг из зашифрованной переменной среды.
Конфиг VPN-ядра храните в CI secrets как base64-encoded JSON. В шаге before_script декодируйте его: echo $VPN_CONFIG_B64 | base64 -d > /tmp/config.json и запустите sing-box run -c /tmp/config.json &. После этого все шаги pipeline используют VPN через переменные HTTP_PROXY.
Не используйте GUI-клиенты в CI — они требуют рабочего стола и тяжелы. Xray-core и sing-box без GUI — единственный правильный выбор для автоматизированных сред. Бинарники весят 10–30 МБ, запускаются мгновенно и потребляют минимум ресурсов.
Мониторинг статуса VPN в скриптах: sing-box и xray-core предоставляют REST API для проверки состояния. Endpoint /proxies или /version отвечает HTTP 200, если ядро запущено и работает. Добавьте health-check в pipeline: curl --fail http://127.0.0.1:9090/version || exit 1 — и pipeline упадёт явно, если VPN не поднялся.
В pipeline на GitLab Runner с Docker executor VPN-контейнер поднимайте в service: image alpine, before_script монтирует конфиг sing-box как artifact. Шаги job получают HTTP_PROXY=172.17.0.1:7890 — адрес хоста runner изнутри контейнера. Health-check curl --fail http://127.0.0.1:9090/version внутри service-контейнера отлавливает ситуацию, когда ядро стартовало, но маршруты не применились.