Что реально лежит на GitHub под запрос «github обход белых списков»
Поиск приводит к трём разным категориям проектов — их полезно не путать, потому что делают они разное:
- Ядра протоколов —
XTLS/Xray-core,SagerNet/sing-box. Движки, реализующие VLESS, VMess, Trojan, Shadowsocks, Reality и транспорты gRPC, WebSocket, XHTTP. Именно они шифруют и маскируют трафик. - Клиенты — v2rayNG, NekoBox/Nekoray, Hiddify, Streisand, Happ, sing-box-приложения. Оболочки над ядром: импорт подписки, роутинг, переключение серверов.
- Серверные панели — 3x-ui, Marzban, Marzneshin, Remnawave. Поднимают серверную часть, выдают ссылки-подписки, управляют пользователями и ключами.
Всё это живой, регулярно обновляемый опенсорс, и обход белых списков опенсорс-средствами вполне реален. Но код отвечает за то, *как* передаётся трафик, а не за то, *откуда* он выходит наружу. Именно на этой границе ломаются ожидания.
Почему один только код не обходит белый список
Главная ошибка запроса «обход белых списков код» — надежда, что есть репозиторий, который «включил и работает» даже при веерном отключении мобильного интернета.
Механику самих белых списков подробно разбираем в отдельной статье об обходе белых списков — здесь важен практический вывод. При жёстком режиме оператор оставляет доступ к ограниченному набору ресурсов; трафик проходит, только если точка, к которой подключается клиент, *сама* попадает в разрешённый список — по IP-диапазону или по домену CDN.
Ни Xray, ни sing-box этого не дают: они подключатся к любому адресу, который вы укажете в поле address. Если это обычный IP дата-центра — при отключении он будет недоступен, каким бы совершенным ни был Reality или XHTTP поверх него. Протокол маскирует содержимое соединения, но не меняет его адрес назначения.
Иначе говоря: опенсорс даёт транспорт и маскировку, но не даёт «белую» точку выхода. Её нужно построить отдельно.
Чего именно не хватает в репозитории: whitelisted-фронт
Клиентский конфиг из GitHub — это обычно строка вида vless://uuid@host:443?type=xhttp&security=reality.... Работоспособность при белых списках определяет host, и вот чего в самом репозитории нет:
- Сервер на whitelisted-адресе. Либо IP из диапазона, который у операторов не режется, — но такие диапазоны нужно проверять по каждой подсети /24, и они меняются от недели к неделе. Либо, надёжнее, фронт через легальный CDN-домен.
- CDN-домен как фронт. Клиент обращается к домену CDN, который у операторов часто остаётся доступным; CDN проксирует соединение на ваш реальный сервер. Снаружи это выглядит как обычное обращение к «белому» ресурсу.
- Корректный транспорт под CDN. Многие CDN не пропускают произвольные протоколы и не принимают POST — только GET. Для связки через такой CDN обычно нужен XHTTP в режиме packet-up, явно заданном в конфиге. Именно из-за этой тонкости один и тот же ключ «в одном приложении работает, в другом нет».
Всего этого в репозитории быть не может — это инфраструктура на стороне оператора сервиса, а не часть клиентского кода.
Риски чужих конфигов и «случайных» ключей из репозиториев
Соблазн понятен: в интернете и в некоторых репозиториях выкладывают готовые подписки «просто работает». Риски здесь конкретные:
- Владелец сервера видит метаданные. Вы не контролируете точку выхода — оператор чужого сервера видит, к каким доменам, в каком объёме и в какое время вы ходите, даже если содержимое зашифровано TLS.
- Ханипоты и логирование. Публичный бесплатный ключ может быть выложен именно для сбора статистики или деанонимизации.
- Общие ключи умирают первыми. Публичные подписки перегружены, их адреса примелькались и блокируются раньше остальных.
- Подменённый клиент. Скачивайте бинарники только из официальных релизов проекта, сверяйте контрольные суммы (
sha256sum). Форк с «улучшенным обходом» может содержать закладку. - Ключ в открытом репо = скомпрометированный ключ. Если он лежит в публичном репозитории, считайте его известным всем по определению.
Вывод простой: опенсорс-клиенту доверять можно — код открыт и проверяем. Чужому серверу за найденным ключом — нет.
Как выглядит рабочая сборка на практике
Схема, которая действительно обходит белые списки, состоит из трёх слоёв — и только первый берётся с GitHub «как есть»:
- Клиент (GitHub). v2rayNG / NekoBox / Hiddify / sing-box — импортируете свою подписку, ничего не изобретая.
- Свой сервер (панель с GitHub). 3x-ui / Marzban / Remnawave на вашей VPS. Здесь вы владелец ключей и логов, генерируете конфиги под свои протоколы.
- Whitelisted-фронт (инфраструктура, не код). CDN-домен или проверенный whitelist-диапазон перед сервером. Самый сложный и дефицитный слой — именно его отсутствие ломает «готовые» решения.
Без третьего слоя первые два дают обычный VPN, который на веерном отключении просто не поднимется. С ним трафик выходит через ресурс, который оператор считает «белым».
Операторам и энтузиастам, которым не хочется в одиночку решать задачу whitelisted-фронта, существует подход whitelist-CDN: сервис отдаёт легальный CDN-домен-фронт, за которым стоит ваша инфраструктура на тех же опенсорс-ядрах. Это закрывает ровно тот третий слой, которого в репозитории нет.
Чек-лист перед запуском
- Клиент — только официальный релиз с GitHub, контрольная сумма сверена.
- Ядро — актуальная версия Xray-core или sing-box; старые сборки хуже маскируются и первыми детектируются.
- Ключи — свои, сгенерированные на своём сервере; чужие «готовые» подписки не берём за основу.
- Точка выхода — проверьте, что адрес или домен реально доступен в вашей сети при ограничениях, а не только в обычном режиме.
- Транспорт под CDN — если фронт идёт через CDN, убедитесь, что задан режим, совместимый с GET (XHTTP packet-up), иначе соединение молча не встанет.
- Whitelist меняется — то, что работало на прошлой неделе, могло отвалиться; тестируйте на реальном ограничении, а не в теории.
- Резервный канал — держите второй фронт (другой CDN или домен) на случай, если первый перестанет считаться «белым».