Как эффективно снизить число блокировок аккаунтов в AI-ретрансляторах

Wokey Team · 2026-06-27

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

Если вы держите ретранслятор (посредника, который перепродаёт доступ к API) или выбираете такой, об этом стоит задуматься всерьёз: блокировки — это вопрос везения или вопрос архитектуры?

Мой ответ — второе. Доля блокировок не случайна — её определяет архитектура.

Посмотрим на картину целиком. Решая, используется ли аккаунт совместно или перепродаётся, поставщики обычно смотрят на такие сигналы:

• Смена IP и тип IP — ваши запросы внезапно переезжают с резидентного IP на IP дата-центра или прыгают между разными геолокациями.
• Поведенческие аномалии — частота вызовов, параллельность и распределение по времени явно не похожи на одного человека.
• Несколько аккаунтов за одним выходом — запросы десятков аккаунтов идут через одну и ту же пачку IP.
• Аномалии отпечатка клиента — заголовки запросов, TLS-отпечаток и характеристики устройства не совпадают с обычным клиентом.

Сложите эти сигналы вместе — и антифрод-система поставщика пометит ваш аккаунт.

Но если спросить, какой сигнал весит больше всего и легче всего обнаруживается, — я бы сказал, что IP.

Причина проста: IP — самый внешний и самый дешёвый критерий отсева. Запрос с резидентного IP и запрос с IP дата-центра для антифрод-системы — это совершенно разные уровни риска. ASN дата-центра + скачки IP + географическая аномалия — как только эти три признака появляются вместе, это практически прямое сообщение антифрод-системе: «это не обычный пользователь».

Честно говоря, архитектура типичного ретранслятора наступает ровно на эту мину: все запросы выходят с серверов релея, а десятки аккаунтов сидят за одной и той же пачкой IP дата-центра. Как бы вы ни балансировали нагрузку и ни ротировали пул прокси, точкой выхода по сути остаётся серверная. Я смотрел решения других операторов релеев — прокси они ротируют усердно, но быстрая проверка ASN показывает, что всё это облачные провайдеры. Маска другая, лицо то же.

Поэтому некоторые люди меняют три ретранслятора и в каждом получают бан раз в две недели — дело не в невезении, а в том, что у всех сервисов одинаковая архитектура.

Так как же сохранить IP неизменным?

Если вы индивидуальный пользователь, для этого уже есть отработанный подход: разверните на домашнем NAS единый шлюз вроде New API или One API либо используйте инструменты вроде sam-to-API и пропускайте через него API всех поставщиков. Телефон, ноутбук, любой клиент, который обращается к модели, — никто из них не ходит к поставщику напрямую. Вместо этого запросы идут на ваше домашнее устройство, а оно пересылает их в API поставщика. Так, какую бы модель вы ни вызывали, выходной IP с точки зрения поставщика всегда остаётся IP вашего домашнего интернета — неотличимо от того, как если бы вы просто сидели дома и пользовались сервисом.

А если вы не дома? Используйте инструменты для mesh-сетей вроде Tailscale или WireGuard, чтобы сначала завернуть трафик телефона или ноутбука на домашний NAS, а уже оттуда выпускать его наружу. В кафе, в офисе или в поезде — ваши запросы всё равно выходят через домашний интернет. Поставщик никогда не увидит скачка вашего IP только из-за того, что вы сменили Wi-Fi или включили мобильный интернет.

Этот подход хорошо обкатан в сообществе fnOS и среди тех, кто самостоятельно хостит AI-инструменты: инструкций и практиков много. Для индивидуальных пользователей это сейчас самый надёжный способ закрепить IP.

Но так решается проблема только одного человека.

Ретранслятор управляет аккаунтами десятков или сотен провайдеров. Вы не можете приехать к каждому домой, поставить NAS и настроить шлюз. Нужно системное решение, при котором каждый провайдер ставит лёгкий узел и подключает его к платформе: запросы по-прежнему выходят из собственной сети провайдера, а распределение заказов и маршрутизацию трафика централизованно берёт на себя платформа.

Такая архитектура называется provider-side exit — выход на стороне провайдера: запросы выходят из собственной сети провайдера, а не с серверов релея.

Аналогия: подход с NAS — это как держать собственный магазинчик у дороги: вы отправляете товар из дома и сами занимаетесь закупкой, ассортиментом и заказами. Provider Node — это как вступить во франшизу платформы: вы по-прежнему отправляете товар из дома, но заказы вам распределяет платформа. Адрес отправки не меняется — меняется то, кто раздаёт заказы.

Именно это и делает Wokey Provider Node.

Установка простая — одна команда, поддерживаются macOS, Linux, Windows и Docker. После установки откройте локальную консоль, привяжите аккаунт Wokey и импортируйте локальные учётные данные подписки. После запуска узел держит WebSocket-соединение с платформой Wokey. Платформа передаёт ему запросы пользователей, а узел локально отправляет запрос в API поставщика. Весь процесс идёт с собственного IP провайдера — для поставщика это ничем не отличается от того, как провайдер обычно пользуется своей подпиской.

Сейчас поддерживаются поставщики OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI и другие.

Поработав с этой архитектурой сам, я сделал самый очевидный вывод: она не «борется» с антифродом — она просто никогда не создаёт предпосылок для срабатывания проверок. С точки зрения поставщика это обычный пользователь, который дома пользуется своей подпиской, и объяснять тут нечего.

Весь проект открыт под лицензией Apache-2.0, а белый список выходов зашит в исходный код. Он безопасен не потому, что я так говорю, — он безопасен потому, что каждую строку кода можно проверить.

Конечно, я не буду утверждать, что выход на стороне провайдера гарантирует нулевое число блокировок. IP — лишь один из факторов: частота вызовов, паттерны параллельности и распределение по времени тоже могут включить антифрод. Никакое решение не гарантирует нулевую долю блокировок.

Но логика ясна: если вы не устранили самый сильный сигнал, любая другая оптимизация — это строительство на песке.

Ключ к снижению доли блокировок — сделать ваше использование неотличимым от обычного. Неизменный IP — самая важная часть. У индивидуальных пользователей есть индивидуальные решения; ретрансляторам нужен системный подход с выходом на стороне провайдера.

Когда конкуренция релеев дойдёт до финала, решать будет не то, у кого больше моделей или ниже цены, а то, чья архитектура не позволит поставщику понять, что вы — ретранслятор. А сервис, которым вы пользуетесь прямо сейчас, — из чьей сети выходят его запросы?