O que é rate limiting por IP?

Rate limiting por IP é um mecanismo que limita o número de requisições que um endereço IP pode enviar a um servidor durante um período determinado. Se você ultrapassar o limite, o servidor recusa temporariamente suas requisições, geralmente com um erro HTTP 429 ("Too Many Requests"). É uma das ferramentas mais comuns para proteger servidores contra abusos, ataques de negação de serviço e scraping automatizado.

Você provavelmente já encontrou isso sem perceber. Quando um site mostra "Muitas tentativas, tente novamente em 5 minutos" depois de vários logins falhos, isso é rate limiting. Quando uma API retorna erro depois de certo número de chamadas por minuto, isso é rate limiting. Quando um buscador bloqueia temporariamente suas consultas porque você pesquisou rápido demais, isso também é rate limiting.

Por que é necessário

Um servidor web tem recursos limitados: CPU, memória, largura de banda, conexões com banco de dados. Cada requisição consome uma parcela desses recursos. Sem nenhuma limitação, um único usuário (ou um script automatizado) poderia monopolizar o servidor enviando milhares de requisições por segundo, tornando o serviço inacessível para todos os outros.

O rate limiting protege contra vários tipos de ameaças:

Ataques DDoS e força bruta. Um ataque de negação de serviço distribuído (DDoS) inunda um servidor com requisições para torná-lo indisponível. O rate limiting sozinho não basta para bloquear um DDoS massivo (que vem de milhares de IPs diferentes), mas limita o dano que um único IP pode causar. Para ataques de força bruta (testar milhares de senhas), o rate limiting é a primeira linha de defesa: limitar a 5 ou 10 tentativas de login por minuto torna o ataque impraticável.

Scraping e crawling abusivo. Bots que extraem conteúdo de um site (preços, artigos, dados) enviam centenas de requisições por segundo. O rate limiting desacelera esses bots ao ponto de tornar a extração massiva economicamente inviável (muito lento, muito tempo de servidor necessário).

Abuso de API. APIs públicas (clima, geolocalização, IA, pagamentos) têm custo por requisição para o provedor. Sem rate limiting, um usuário poderia consumir recursos desproporcionais, seja por erro (um loop no código) ou intencionalmente. A maioria das APIs impõe limites por chave API e por endereço IP.

Equidade entre usuários. Mesmo sem intenção maliciosa, um usuário "guloso" (que atualiza uma página 50 vezes por minuto, ou um script mal escrito) pode degradar a experiência dos demais. O rate limiting garante compartilhamento justo dos recursos.

Como funciona tecnicamente

O princípio é simples: o servidor associa cada requisição a um endereço IP, conta o número de requisições recebidas desse IP em uma janela de tempo e recusa as requisições que ultrapassam o limite definido. Mas a implementação concreta varia conforme o algoritmo utilizado.

Janela fixa (Fixed Window). O tempo é dividido em intervalos fixos (por exemplo, janelas de um minuto). O servidor conta as requisições por IP em cada janela. Se você atinge 100 requisições na janela atual, as seguintes são recusadas até o início da próxima janela. É o algoritmo mais simples, mas tem um defeito: se você enviar 100 requisições no fim de uma janela e 100 no início da seguinte, enviou 200 requisições em poucos segundos, o dobro do limite previsto.

Janela deslizante (Sliding Window). Em vez de janelas fixas, o servidor olha os últimos N segundos a qualquer momento. Cada requisição é contada em um período deslizante. Isso suaviza a distribuição e elimina o problema da janela fixa, mas exige mais memória e processamento no servidor.

Token Bucket (balde de tokens). Cada IP dispõe de um "balde" contendo um número fixo de tokens. Cada requisição consome um token. Os tokens se regeneram a uma taxa constante (por exemplo, 10 por segundo). Se o balde está vazio, a requisição é recusada. Esse modelo permite rajadas curtas (burst): você pode enviar muitas requisições de uma vez se o balde está cheio, depois precisa esperar a regeneração. É o algoritmo mais usado em produção porque é flexível e previsível ao mesmo tempo.

Leaky Bucket (balde furado). As requisições entram em uma fila (o balde) e são processadas a uma taxa constante (a vazão do furo). Se o balde está cheio, novas requisições são rejeitadas. Diferente do Token Bucket, o Leaky Bucket impõe uma taxa de saída estritamente constante, sem rajadas. É útil quando se quer um fluxo de processamento perfeitamente regular.

Onde o rate limiting é aplicado

O rate limiting pode ser aplicado em diferentes níveis da infraestrutura de rede, e na prática frequentemente é: várias camadas se sobrepõem.

No nível do servidor web. Nginx, Apache e a maioria dos servidores web incluem módulos de rate limiting. O Nginx, por exemplo, usa o algoritmo Leaky Bucket com sua diretiva limit_req. Você define um número de requisições por segundo por IP, e o Nginx cuida do resto. É eficaz para proteção básica, mas o servidor ainda precisa receber e processar parcialmente cada requisição antes de rejeitá-la.

No nível do reverse proxy ou load balancer. Colocar o rate limiting na frente dos servidores de aplicação (em um reverse proxy como Nginx ou HAProxy, ou um load balancer) permite bloquear requisições antes que cheguem à aplicação. É mais eficiente em termos de recursos.

No nível do CDN ou firewall de aplicação (WAF). Serviços como Cloudflare, AWS WAF ou Akamai aplicam rate limiting na borda da rede (edge), antes mesmo da requisição atingir sua infraestrutura. É a camada mais eficaz contra ataques volumétricos, porque a requisição é bloqueada o mais perto possível da origem.

No nível da aplicação. A própria aplicação pode implementar rate limiting, frequentemente com mais granularidade: por usuário logado, por endpoint, por tipo de operação. Por exemplo, uma API pode autorizar 1.000 requisições GET por minuto mas apenas 10 requisições POST em um endpoint de criação de conta, porque tentativas abusivas de criação de conta são um vetor de ataque comum.

Cabeçalhos HTTP relacionados ao rate limiting

Quando um servidor aplica rate limiting, normalmente comunica as informações de limite via cabeçalhos HTTP na resposta. Não há um padrão universal, mas as convenções mais comuns são:

X-RateLimit-Limit: o número máximo de requisições permitidas na janela de tempo atual. X-RateLimit-Remaining: o número de requisições restantes antes de atingir o limite. X-RateLimit-Reset: o momento (em timestamp Unix ou segundos restantes) em que a janela reinicia e o contador volta a zero. Retry-After: um cabeçalho HTTP padrão que indica quanto tempo esperar antes de tentar novamente, retornado com a resposta 429.

Um rascunho IETF (RFC 6585 para o código 429 e propostas mais recentes) tenta padronizar esses cabeçalhos, mas na prática cada API usa sua própria convenção. Se você desenvolve uma aplicação que consome APIs, sempre leia a documentação da API para saber como ela comunica seus limites.

Por que o IP sozinho nem sempre basta

O rate limiting por IP tem um problema fundamental: um endereço IP nem sempre corresponde a um único usuário.

O CGNAT. Muitas operadoras móveis e alguns provedores usam CGNAT (Carrier-Grade NAT), que faz centenas ou milhares de usuários compartilharem um mesmo endereço IPv4 público. Se você limitar um IP a 100 requisições por minuto, na realidade está limitando todos os usuários atrás desse CGNAT a um total combinado de 100 requisições. Um único usuário normal pode esgotar a cota para todos os outros.

Redes corporativas e universitárias. Milhares de funcionários ou estudantes podem acessar a internet por um único endereço IP público (ou um pequeno número de endereços). O rate limiting por IP os penaliza coletivamente.

VPNs e proxies. Usuários de VPN frequentemente compartilham um endereço IP com centenas de outras pessoas. Um rate limiting rígido por IP pode bloquear usuários legítimos simplesmente porque usam o mesmo servidor VPN que um bot.

Endereços IP dinâmicos. Por outro lado, um atacante pode facilmente trocar de endereço IP (usando um pool de proxies, uma botnet, ou simplesmente ativando o modo avião no celular) e contornar o rate limiting por IP. Se o limite é por IP e o atacante tem acesso a 10.000 endereços, o limite efetivo é multiplicado por 10.000.

Por isso os sistemas de rate limiting modernos geralmente combinam o IP com outros identificadores: chave API, token de autenticação, impressão digital do navegador, cookie de sessão. O IP continua sendo um critério útil, mas raramente suficiente sozinho.

O que acontece quando você é limitado

A resposta mais comum é um código HTTP 429 (Too Many Requests). O servidor também pode retornar um 503 (Service Unavailable) se a limitação é devida a sobrecarga geral e não a ultrapassagem individual.

Alguns serviços não bloqueiam completamente o acesso, mas degradam o serviço: desaceleram as respostas (throttling), reduzem a qualidade dos resultados ou adicionam um CAPTCHA para verificar que você é humano.

Outros serviços bloqueiam silenciosamente sem retornar erro explícito. Continuam respondendo com código 200 (OK) mas retornam dados vazios ou resultados degradados. Esse "rate limiting silencioso" (shadow banning) é comum em redes sociais e alguns buscadores, e é projetado para ser difícil de detectar por bots.

Como os desenvolvedores lidam com o rate limiting

Se você desenvolve uma aplicação que consome uma API, precisa lidar com o rate limiting adequadamente. O método padrão é o "exponential backoff": quando recebe uma resposta 429, espera um tempo determinado antes de tentar novamente e dobra esse tempo a cada falha sucessiva. Por exemplo: primeira tentativa após 1 segundo, segunda após 2 segundos, terceira após 4 segundos, etc.

Boas práticas incluem:

Ler os cabeçalhos Retry-After e X-RateLimit-Reset para saber exatamente quando tentar novamente, em vez de adivinhar. Implementar cache para evitar refazer as mesmas requisições. Agrupar requisições (batching) quando a API permite. Distribuir requisições ao longo do tempo em vez de enviá-las em rajada. Prever um circuit breaker que pare de chamar a API por um período se os erros 429 se acumulam, para não agravar a situação.

Rate limiting e privacidade

O rate limiting por IP implica que o servidor identifica e rastreia requisições por endereço IP. É uma forma de tratamento de dados pessoais (o endereço IP é considerado dado pessoal em muitas jurisdições, especialmente sob a LGPD no Brasil e o RGPD na Europa). Empresas que implementam rate limiting deveriam em teoria mencionar esse tratamento em sua política de privacidade.

Do ponto de vista do usuário, o rate limiting por IP também significa que sua atividade está sendo contabilizada. Se você usa VPN ou proxy por razões de privacidade, o rate limiting pode paradoxalmente penalizá-lo: você compartilha um IP com outros usuários e a cota comum se esgota mais rápido.

Contornar o rate limiting

Trocar de endereço IP (via VPN, proxy rotativo ou modo avião no celular) permite contornar um rate limiting baseado somente no IP. Serviços de scraping comerciais usam pools de milhares de endereços IP residenciais para distribuir requisições e ficar abaixo dos limites por IP.

Mas os sistemas de proteção modernos não se limitam ao IP. Combinam análise de impressão digital do navegador, comportamento de navegação (ritmo de cliques, movimentos do mouse, tempo nas páginas), CAPTCHAs e análise de padrões de requisições para distinguir humanos de bots, mesmo quando o IP muda a cada requisição.

A corrida entre sistemas de rate limiting e técnicas de contorno é permanente. Métodos que funcionam hoje podem ser detectados amanhã. Se você está do lado do servidor, a melhor estratégia é combinar várias camadas de proteção em vez de depender do IP sozinho.

Exemplos de limites comuns

Esses limites variam enormemente conforme o serviço, o plano tarifário e o contexto. Uma API paga geralmente oferece limites muito mais altos que um plano gratuito. Um endpoint sensível (login, pagamento, criação de conta) tem limites muito mais baixos que um endpoint de leitura de dados.

O rate limiting por IP é uma proteção essencial para qualquer servidor exposto à internet. Impede abusos, protege recursos e garante acesso equitativo. Mas o endereço IP sozinho é um identificador cada vez menos confiável com o CGNAT, VPNs e proxies. Sistemas modernos combinam o IP com outros sinais para distinguir tráfego legítimo de tráfego abusivo, e é essa combinação que faz a diferença entre uma proteção eficaz e um simples filtro fácil de contornar.