Por questão de simplicidade, digamos que eu tenha um servidor web rodando nginx servindo um único arquivo php (com uma mensagem "hello world") via php5-fpm.
Digamos que o servidor esteja por trás do cloudflare e que todas as solicitações ao meu servidor sejam recebidas por meio do cloudflare.
Sob quase a configuração padrão, todos os IPs relatados pelo nginx são ip do cloudflare, portanto usamos o realip_module e seguimos este link para definir o IP real do cloudflare.
Meu próximo passo é limitar as conexões e solicitações para este arquivo php para 1 requisição por segundo, por ip de usuário (mas permitir solicitações ilimitadas do próprio cloudflare).
De acordo com esta resposta , é seguro usar o $binary_remote_addr para impor limites, porque depois de usar o realip_module, o nginx irá reescrever o ip para qualquer ip que tenha sido fornecido no cabeçalho CF-Connecting-IP .
Então, eu começo essa configuração:
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=1r/s;
limit_conn conn_limit_per_ip 1;
limit_req zone=req_limit_per_ip burst=1 nodelay;
Significa que eu permito apenas 1 conexão http e 1 req / seg, com 1 pedido extra dentro desse segundo permitido (estou me sentindo generoso aqui).
Eu sei que $binary_remote_addr inclui o ip do usuário conforme relatado pelo cloudflare, mas as conexões e solicitações ainda estão chegando ao servidor via cloudflare (portanto, eu não posso usar o iptables para isso).
Meu entendimento de limit_conn e limit_req é que ele mostrará uma página de status 503 para qualquer usuário que exceda esses limites.
Caso 1:
Para simplificar, digamos que 300 usuários na mesma região e usando o mesmo ponto de presença do cloudflare acessem o site no mesmo segundo.
Como o cloudflare relata diferentes endereços IP para todos e todos fazem uma única solicitação, ninguém verá que 503 páginas de status e 300 solicitações serão permitidas via cloudflare.
Caso 2:
Digamos que 3 pessoas acessem minha página dentro desse segundo. Desses, 2 usuários fizeram 1 solicitação única enquanto o terceiro usuário está usando ab (benchmark do apache) para fazer 10 solicitações simultâneas.
Como o cloudflare relata diferentes endereços IP para todos, posso presumir que os 2 primeiros usuários verão minha página sem problemas, enquanto a 3ª pessoa solicitará duas vezes minha página com sucesso (porque estou usando burst + nodelay) e depois obterá um 503 página de status para o restante das solicitações nesse segundo. No segundo seguinte, ele repetirá o mesmo, limitando efetivamente suas solicitações a 2 req / seg.
Preocupações:
Como todas essas 503 solicitações ainda estão sendo veiculadas via cloudflare, outros usuários começarão a ver as mensagens do cloudflare dizendo que a origem não está disponível (clique aqui para tentar novamente um botão de versão ao vivo), porque as solicitações anteriores falharam?
Se o servidor estiver inoperante (sem rede), as mensagens do cloudflare serão exibidas para todos e levará alguns segundos para desaparecer, mesmo quando o servidor estiver ativo novamente.
Serão exibidas as mensagens "servidor off-line" do cloudflare para os usuários quando meu nginx começar a responder com o erro 503 a esse usuário ruim em particular?