Как GitHub Actions превратили в генератор VPN-конфигов без единого сервера

Есть разработчики, которые решают инфраструктурные задачи не потому, что им нужен сервер, а потому что им не нужен сервер. Репозиторий byJoey/warp-masque-actions — ровно такой случай: он берёт бесплатные раннеры GitHub Actions и заставляет их делать то, для чего обычно поднимают отдельную машину — генерировать конфигурацию Cloudflare WARP по протоколу MASQUE.

Суть проекта простая до банальности в описании: форкаешь репозиторий, включаешь Actions (по умолчанию они выключены у форков, и это единственный лишний клик), запускаешь workflow «Генерация WARP MASQUE конфига» и через минуту забираешь из Artifacts три файла. Один — warp-masque.yaml, готовый конфиг mihomo с 41 узлом, который сразу импортируется в Clash Verge или ClashMi. Второй — warp-masque-shadowrocket.txt, набор ссылок вида masque:// для тех, кто сидит на Shadowrocket. Третий — usque-config.json, сырые ключи для тех, кто хочет собрать что-то своё поверх.

Никакой установки Python, никакого Docker на своей машине, никакого VPS, который надо арендовать и настраивать. Вся тяжёлая работа — генерация ключей аккаунта WARP и сборка конфигурации — происходит на чужих раннерах, а пользователю остаётся забрать результат.

Что на самом деле означают 41 узел

Здесь автор README прямо предупреждает от завышенных ожиданий: 41 узел — это не 41 страна выхода в интернет. Это один и тот же аккаунт WARP, у которого просто много разных точек подключения, и выходной IP у всех одинаковый. Смысл множественности — не в географии, а в отказоустойчивости: если один адрес блокируется провайдером или файрволом, клиент автоматически переключается на другой. Из этих узлов двадцать — IPv6, и если у пользователя нет IPv6-подключения, они просто не будут работать, но клиент их тихо пропустит, не мешая остальным. Кто хочет реально выбирать страну выхода, тому нужен WARP+ или ZeroTrust — этот репозиторий такую задачу не решает, и авторы это не скрывают.

Alpha-ядро как единственное настоящее условие

Весь проект держится на одном техническом нюансе, который в README вынесен в отдельный раздел с капслоком: протокол MASQUE поддерживается только в Alpha-ветке ядра mihomo, стабильная версия просто не знает такого типа прокси и выдаёт ошибку unsupport proxy type: masque. Это не баг конкретного клиента, а общее ограничение самого ядра, и разработчик отдельно проговаривает, что обновление приложения (например, Clash Verge Rev) до последней версии само по себе не переключает ядро на Alpha — это два разных действия, и переключаться нужно вручную в настройках. Для Android нужен именно prerelease-alpha тег ClashMetaForAndroid, обычный релиз не подойдёт. На iOS всё проще — ClashMi несёт mihomo-ядро внутри себя, и yaml можно закинуть напрямую. А вот Surge, Quantumult X и Karing работают на других ядрах и MASQUE в принципе не понимают — тут и пытаться незачем.

Два пайплайна и Worker в довесок

В репозитории на самом деле не один сценарий, а три. Основной — чистый WARP с сорока одним узлом, о нём и речь выше. Второй, названный автором «套娃» (буквально — «матрёшка»), накладывает поверх WARP ещё один слой Opera VPN, чтобы получить другую страну выхода — то есть решает как раз ту задачу, которую чистый WARP не решает. Третий вариант живёт в папке worker/ — это версия того же матрёшечного пайплайна, но развёрнутая как Cloudflare Worker, который сам обновляет себя каждые четыре часа и показывает статус-страницу. То есть один и тот же принцип — генерация конфигурации без выделенного сервера — реализован сразу в двух средах исполнения: GitHub Actions для разового запуска и Worker для того, кому нужна постоянно свежая конфигурация без ручного нажатия кнопки.

Хрупкость как часть дизайна

Автор не прячет ограничения формата. Артефакты GitHub Actions живут по умолчанию семь дней и, если репозиторий публичный, доступны для скачивания кому угодно — значит, приватность здесь обеспечивается не системой, а выбором пользователя сделать форк приватным. Ключ private-key в конфиге приравнивается к паролю от аккаунта, и его просят не выкладывать наружу. А ещё в README отдельно предупреждают не ставить workflow на частый запуск по расписанию — WARP реагирует на такое риск-контролем и банит аккаунт. Каждый прогон workflow создаёт полностью новый аккаунт WARP, так что перегенерация ключей — это буквально повторный запуск того же action, а не отдельная процедура.

В итоге получается любопытный пример того, как CI-инфраструктура, придуманная для сборки и тестирования кода, используется как одноразовый генератор конфигураций — без сервера, без окружения, с ровно одним требованием к клиенту: убедиться, что ядро переключено на Alpha, прежде чем импортировать файл.