Proxy queimado

SintomasCopy Anchor Link

• Várias sessões do mesmo endereço caem juntas (coluna proxy em Clientes → Conexões).
• Pareamentos novos nesse endereço não completam.
• A sonda do endereço falha, ou o tipo/registro detectado mudou.
• O endereço venceu (Compras mostra validade) e as sessões voltaram de outro lugar.

ConfirmarCopy Anchor Link

API=https://api.superdinda.com
AUTH="Authorization: Bearer <ADMIN_ACCESS_TOKEN>"
curl -s "$API/admin/proxies" -H "$AUTH"                         # status e ocupação
curl -s "$API/admin/proxies/<proxy-uid>/bindings" -H "$AUTH"    # quem está nele
curl -s -X POST "$API/admin/proxies/probe" -H "$AUTH" -H "Content-Type: application/json" \
  -d '{"server":"<host:porta>","protocol":"socks5","username":"<usuário>","password":"<senha>"}'

Lendo a sonda:

As credenciais nunca saem das nossas rotas: pegue-as no painel do fornecedor.

PassosCopy Anchor Link

1. Na dúvida, drene. Backoffice → Infraestrutura → Proxies → Drenar, ou PATCH /admin/proxies/<proxy-uid> com {"status":"draining"}. Ninguém novo entra; quem está fica. É reversível.

2. Garanta vaga em outro endereço antes de queimar. Sem vaga, o novo pareamento dá NO_PROXY_CAPACITY. Compre (Compras: cotar → comprar → adotar) ou registre um endereço com POST /admin/proxies.

3. Queime. No backoffice, o diálogo mostra o impacto (quem está no endereço), avisa que não dá para desfazer e pede para digitar o nome do endereço antes de Queimar endereço. Pela rota:

   Copy Text

   curl -s -X PATCH "$API/admin/proxies/<proxy-uid>" -H "$AUTH" \
     -H "Content-Type: application/json" -d '{"status":"burned"}'

   A resposta traz burned: { pairingsEnded, accountsRequeued }.

4. Pare a renovação do pedido desse endereço (veja o "Em aberto" abaixo).

5. Acompanhe as famílias voltando a parear em Conexões.

O que o sistema faz sozinho ao queimarCopy Anchor Link

• O status vira burned antes da cascata: o alocador só escolhe active, então ninguém cai de volta no endereço enquanto ela roda.
• Cada pareamento no endereço termina disconnected com motivo proxy_burned, e a sessão é apagada no WAHA.
• Os bindings são liberados (released_reason = proxy_burned).
• Responsáveis e a própria pessoa recebem pairing.reconnect_required, uma vez por pareamento.
• As contas voltam à fila de ingest com prioridade de reconexão, na frente de quem nunca foi protegido.

O que não é automático: perceber que o endereço queimou. A decisão é do operador.

Quando escalarCopy Anchor Link

• Mais de um endereço do mesmo fornecedor queimando em pouco tempo → reveja o fornecedor e a capacidade por IP (Proxies).
• Saldo insuficiente para repor (shortfall em Compras) → recarga no painel do fornecedor; não existe recarga por API.

FontesCopy Anchor Link

• backend/src/http/routes/admin/{proxies,probe,proxy-supply}.route.ts, backend/src/http/routes/admin/schemas.ts
• backend/src/domains/channels/use-cases/burn-address.ts, backend/src/domains/proxies/use-cases/{allocate,probe,supply-orders}.ts, entities/proxy-supply.entity.ts
• backend/src/domains/notifications/use-cases/dispatch.ts, backend/src/config/env.ts
• apps/backoffice/src/components/proxies/{burn-proxy-dialog,proxy-actions}.tsx
• Vault: problems/2026-09-29-sonda-de-proxy-dois-bugs, research/2026-09-11-proxies-residenciais-br (adendo 2026-09-29)