Como reduzir de forma eficaz os banimentos de contas em serviços de relay de IA

Wokey Team · 2026-06-27

Os provedores de modelos fizeram recentemente uma onda enorme de banimentos de contas — tão ampla que até usuários individuais com uso legítimo foram pegos no fogo cruzado.

Se você opera um serviço de relay, ou está escolhendo um, vale a pena pensar nisso com seriedade: banimento é questão de sorte ou de arquitetura?

Minha resposta é a segunda. As taxas de banimento não são aleatórias — são determinadas pela arquitetura.

Vamos olhar o quadro geral. Quando os provedores decidem se uma conta está sendo compartilhada ou revendida, eles costumam observar estes sinais:

• Mudanças de IP e tipo de IP — suas requisições de repente pulam de um IP residencial para um IP de data center, ou passam por localizações geográficas diferentes.
• Anomalias de comportamento — frequência de chamadas, concorrência e distribuição de horários que claramente não parecem de uma única pessoa.
• Várias contas compartilhando uma saída — requisições de dezenas de contas afuniladas pelo mesmo lote de IPs.
• Anomalias na impressão digital do cliente — cabeçalhos de requisição, impressão digital TLS e características do dispositivo que não batem com um cliente normal.

Some esses sinais e o sistema de risco do provedor marca a sua conta.

Mas, se você perguntar qual sinal pesa mais e é mais fácil de detectar — eu diria que é o IP.

O motivo é simples: o IP é o critério de triagem mais externo e de menor custo. Uma requisição vinda de um IP residencial e outra vinda de um IP de data center representam níveis de risco totalmente diferentes aos olhos de um sistema de risco. ASN de data center + IP mudando + anomalia geográfica — quando esses três aparecem juntos, é praticamente dizer ao sistema de risco "este não é um usuário normal".

Sinceramente, a arquitetura dos serviços de relay convencionais pisa bem nessa mina: todas as requisições saem dos servidores do relay, com dezenas de contas compartilhando o mesmo lote de IPs de data center. Não importa como você balanceia a carga ou rotaciona seu pool de proxies, o ponto de saída é, no fundo, uma sala de servidores. Já olhei as soluções de outros operadores de relay — eles rotacionam proxies com dedicação, mas uma consulta rápida de ASN mostra que todos são provedores de nuvem. Máscara diferente, mesmo rosto.

É por isso que tem gente que troca entre três serviços de relay e é banida a cada duas semanas em cada um — não é azar, é que todos os serviços têm a mesma arquitetura.

Então, como manter o IP sem mudanças?

Se você é usuário individual, já existe uma abordagem bem estabelecida: instale um gateway unificado como New API ou One API em um NAS em casa, ou use ferramentas como sam-to-API, e passe todas as APIs dos provedores por ele. Seu celular, seu notebook, qualquer cliente que chame um modelo — nenhum deles acessa o provedor diretamente. Em vez disso, passam pelo seu dispositivo de casa, que encaminha para a API do provedor. Assim, não importa qual modelo você chame, o IP de saída que o provedor vê é sempre o IP da sua banda larga residencial — impossível de distinguir de você sentado em casa usando normalmente.

E quando você está fora? Use ferramentas de rede mesh como Tailscale ou WireGuard para levar o tráfego do celular ou do notebook primeiro até o NAS de casa e só então sair de lá. Seja num café, no escritório ou num trem, suas requisições continuam saindo pela banda larga de casa. O provedor nunca vê seu IP pular só porque você trocou de Wi-Fi ou ligou os dados móveis.

Essa abordagem é bem testada na comunidade do fnOS e no meio de self-hosting de IA, com muitos tutoriais e gente usando. Para usuários individuais, é hoje a solução mais confiável para fixar o IP.

Mas isso só resolve o problema de uma pessoa.

Um serviço de relay gerencia contas de dezenas ou centenas de Providers. Você não pode ir à casa de cada um instalar um NAS e configurar um gateway. Você precisa de uma solução sistemática que permita a cada Provider instalar um nó leve e se conectar à plataforma — as requisições continuam saindo pela rede do próprio Provider, mas a distribuição de pedidos e o roteamento do tráfego ficam centralizados na plataforma.

Essa arquitetura se chama saída pelo lado do Provider (provider-side exit) — as requisições saem pela rede do próprio Provider, não pelos servidores do relay.

Uma analogia: a abordagem do NAS é como ter sua própria loja de beira de estrada — você despacha de casa e cuida sozinho de abastecimento, seleção e pedidos. Um Provider Node é como entrar na franquia de uma plataforma — você continua despachando de casa, mas os pedidos são distribuídos a você pela plataforma. O endereço de envio não muda; o que muda é quem distribui os pedidos.

É isso que o Wokey Provider Node faz.

A instalação é simples — um único comando, com suporte a macOS, Linux, Windows e Docker. Depois de instalar, abra o console local, vincule sua conta da Wokey e importe as credenciais da sua assinatura local. Quando o nó inicia, ele mantém uma conexão WebSocket com a plataforma Wokey. A plataforma envia as requisições dos usuários e o nó faz a requisição à API do fornecedor localmente. Todo o processo sai pelo IP do próprio Provider — para o fornecedor, é idêntico ao Provider usando a própria assinatura normalmente.

Os fornecedores suportados atualmente incluem OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI e outros.

Depois de rodar essa arquitetura eu mesmo, a conclusão mais intuitiva é: ela não "briga" com os controles de risco — simplesmente nunca aciona as condições prévias para a detecção de risco. Do ponto de vista do fornecedor, é só um usuário normal em casa usando a própria assinatura, sem nada anômalo para explicar.

O projeto inteiro é open source sob Apache-2.0, com a lista de permissões de saída fixada no código-fonte. Não é seguro porque eu digo — é seguro porque cada linha de código pode ser auditada.

Claro, não vou afirmar que a saída pelo lado do Provider garante zero banimentos. O IP é só um fator — frequência de chamadas, padrões de concorrência e distribuição de horários também podem acionar os controles de risco. Nenhuma solução pode garantir taxa de banimento zero.

Mas a lógica é clara: se você não resolveu o maior sinal, qualquer outra otimização é construir sobre areia.

A chave para reduzir as taxas de banimento é tornar seu uso indistinguível do normal. Manter o IP sem mudanças é a peça mais crítica. Usuários individuais têm soluções individuais; serviços de relay precisam de uma abordagem sistemática de saída pelo lado do Provider.

Quando a competição entre relays chegar à fase final, não vai ser sobre quem tem mais modelos ou preços mais baixos — vai ser sobre qual arquitetura faz o provedor não conseguir perceber que você é um relay. O serviço que você usa agora — as requisições saem pela rede de quem?