Um cliente escreve a dizer que a loja "não o deixa entrar". Viu uma página da Cloudflare com um código de quatro dígitos, desistiu e comprou noutro sítio. Os registos do servidor não mostram nada, porque o pedido nunca passou da Cloudflare. Acontece em lojas WooCommerce, em sites WordPress de captação de contactos, em frontends headless feitos em Astro ou Next.js e em qualquer aplicação à medida que esteja atrás do proxy da Cloudflare. A causa é quase sempre uma regra da sua própria zona, e a Cloudflare regista qual foi.
Este guia segue a ordem que funciona: obter o Ray ID, procurá-lo, ler que funcionalidade atuou e depois restringir essa funcionalidade para que deixe de apanhar compradores e notificações de pagamento. Todo o comportamento descrito abaixo vem da documentação para programadores da Cloudflare, tal como estava em outubro de 2026.
O que significam os erros 1015, 1020 e 1009 da Cloudflare
O código indica onde procurar. Uma publicação no r/CloudFlare de 21 de outubro de 2026 resumiu os códigos, e cada um corresponde às páginas de resolução de problemas da própria Cloudflare:
- 1015 (HTTP 429): foi acionada uma regra de limitação de pedidos. A Cloudflare aconselha a rever os limites e, se a regra contar durante um período muito curto, como um segundo, experimentar 10 segundos.
- 1020 (HTTP 403): uma regra de segurança com ação Block e sem resposta personalizada. A página do 1020 dá como exemplos a validação de esquema do API Shield e a validação de JWT, e afirma que as regras personalizadas e as regras geridas da WAF já não devolvem 1020. Mostram antes a página de bloqueio da WAF.
- 1009 (HTTP 403): uma proibição por país ou região definida nas IP Access rules. Aí, o bloqueio por país só existe no plano Enterprise; nos outros planos é uma regra personalizada, e essa mostra a página de bloqueio da WAF.
- 1010 (HTTP 403): o Browser Integrity Check rejeitou a assinatura do navegador.
- “Just a moment…” ou uma página de desafio: um Managed Challenge vindo de uma regra personalizada, de uma regra de limitação de pedidos, do Bot Fight Mode ou do Under Attack Mode.
O pormenor do 1020 poupa horas. Quem anda a vasculhar as regras personalizadas à procura da que devolveu 1020 está a procurar na lista errada.
Onde encontrar o Ray ID da Cloudflare
Peça ao cliente uma captura de ecrã da página de erro completa. Lá estão o código, o Ray ID e a hora em UTC. O autor do mesmo tópico acrescentou isto numa resposta:
o código é a parte fácil, o que as pessoas não veem é o ray id no mesmo ecrã. cola-o nos security events e aparece qual das tuas próprias regras disparou.
(u/Hot_Bee_5451, r/CloudFlare, 22 de outubro de 2026, tradução própria)
Cada pedido que passa pela Cloudflare recebe um Ray ID, que é enviado para a origem no cabeçalho cf-ray. A Cloudflare avisa que não há garantia de que os Ray IDs sejam únicos, por isso confirme também a hora e o IP. Se o cliente não conseguir enviar a captura, peça-lhe o endereço IP público, a hora aproximada e o país. Quando o problema é um desafio falhado há outro caminho, sugerido noutro tópico:
Bem, podes dar ao administrador do site o RayID que é criado quando esse teste corre, e ele consegue ver a razão exata por que falhaste.
(u/Logvin, r/CloudFlare, 21 de outubro de 2026, tradução própria)
Como pesquisar um Ray ID nos Security Events da Cloudflare
No painel, abra Security > Analytics e o separador Events. Acrescente um filtro por Ray ID, ou pelo IP do cliente, e escolha um intervalo de tempo que cubra a queixa. Converta antes a hora UTC da página de erro para o seu fuso horário; a página do 1020 da Cloudflare chama a atenção para isso.
A documentação do Security Events tem dois limites que pesam aqui. Os dados ficam guardados até 31 dias. E a lista usa registos por amostragem, pelo que numa zona com muito tráfego um pedido isolado pode não aparecer. Se a pesquisa pelo Ray ID não devolver nada, reduza a janela para poucos minutos e filtre por IP; uma janela mais pequena mostra mais eventos. Um só pedido também pode gerar vários eventos, se tiverem atuado várias funcionalidades sobre ele.
Que regra da Cloudflare bloqueou o visitante
Abra o evento. O campo Service indica a funcionalidade e, no caso das regras, aparece também o nome ou o ID da regra. O que cada uma costuma significar:
- Regras personalizadas: uma expressão sua. Os suspeitos habituais são bloqueios por país, bloqueios por ASN dirigidos a fornecedores de alojamento (que apanham também quem usa VPN) e regras de caminho demasiado largas em
/wp-login.phpou/checkout. - Regras geridas: uma assinatura da Cloudflare ou da OWASP encontrou algo no pedido. Pesquisas longas, campos de formulário com excertos de código e alguns dados enviados por construtores de páginas fazem-nas disparar.
- Regras de limitação de pedidos: o caso do 1015. Quando a regra conta por IP, os compradores que saem pelo mesmo IP de um escritório ou de um operador móvel partilham o mesmo contador.
- Bot Fight Mode ou Super Bot Fight Mode: os produtos contra bots. A documentação sobre bots da Cloudflare diz que ambos podem desafiar tráfego de APIs ou de aplicações móveis.
- Security Level ou Under Attack Mode: a página intermédia aplicada a toda a zona.
Uma regra apagada aparece como “Rule unavailable”. Consulte o registo de auditoria para ver quem a removeu ou alterou.
Como criar uma regra Skip na Cloudflare sem abrir o site todo
A correção é uma regra personalizada com a ação Skip, colocada acima da regra que bloqueou e limitada ao tráfego em que confia. As opções de Skip da Cloudflare permitem ignorar todas as regras personalizadas seguintes, todas as regras de limitação de pedidos, todas as regras geridas e todas as regras do Super Bot Fight Mode. Pela API também é possível ignorar o Browser Integrity Check, o Security Level, o User Agent Blocking, o Zone Lockdown e o Hotlink Protection. As regras personalizadas correm por ordem, por isso a posição conta.
Mantenha a expressão restrita. Para a extensão WooCommerce Stripe, que usa apenas /?wc-api=wc_stripe como endpoint de webhook:
(http.request.uri.query contains "wc-api=wc_stripe" and ip.src in $stripe_webhooks)Aqui, $stripe_webhooks é uma lista de IP criada a partir dos endereços IP de webhooks publicados pelo Stripe. Para uma integração da loja que chama a API REST do WooCommerce a partir de um servidor fixo:
(starts_with(http.request.uri.path, "/wp-json/wc/") and ip.src in $erp_servers)Quando o falso positivo atingiu compradores reais, muitas vezes é melhor alterar a regra original do que acrescentar uma exceção: aumentar o período da limitação de pedidos, restringir um bloqueio por país a /wp-login.php ou trocar um Block por um Managed Challenge. Deixe a opção Log matching requests ligada na regra Skip para ver que está a funcionar.
Porque é que a Cloudflare bloqueia webhooks do Stripe e a API REST do WooCommerce
As chamadas entre servidores não têm navegador, por isso não conseguem resolver um desafio em JavaScript. Qualquer funcionalidade que desafie em vez de bloquear continua a estragá-las. O dono de uma loja descreveu exatamente isto no r/CloudFlare:
Quando ligo o Under Attack Mode, o tráfego de Singapura desaparece do GA4. Mas o Under Attack Mode deixa o meu site lento, e as minhas chamadas de API entre servidores (WooCommerce REST API) recebem o desafio “Just a moment…” da Cloudflare, por isso falham.
(u/lastoneinbatumi, r/CloudFlare, 19 de outubro de 2026, tradução própria)
O prejuízo depende do fornecedor. O Stripe volta a tentar um webhook falhado com recuo exponencial durante até três dias em modo live, por isso as encomendas presas em “pagamento pendente” costumam recuperar depois de corrigida a regra. O Shopify tenta até oito vezes ao longo de quatro horas e depois remove a subscrição, o que importa se a sua aplicação ou o seu backend headless recebe webhooks do Shopify atrás da sua zona Cloudflare. Depois de qualquer alteração de segurança, verifique as entregas falhadas no painel de cada fornecedor.
O Under Attack Mode foi pensado como último recurso durante um ataque. A página do Security Level da Cloudflare indica que se deve usar uma regra de configuração para o ligar ou desligar na API ou em qualquer outra parte do domínio. Mantenha-o desligado em /wp-json/, nos caminhos dos webhooks e no anfitrião da API.
O mesmo tópico deixou uma segunda lição. Se o tráfego bloqueado continua a aparecer nas estatísticas, vale a pena perguntar se ele passa sequer pela Cloudflare:
O teu alojamento está configurado para só aceitar tráfego de e para a Cloudflare? Senão pode ser acedido diretamente pelo ip
(u/Wilbo007, r/CloudFlare, 19 de outubro de 2026, tradução própria)
A documentação sobre endereços IP da Cloudflare recomenda bloquear na origem o tráfego que não venha da Cloudflare nem dos seus parceiros de confiança. Autorize também nessa firewall da origem os endereços dos seus fornecedores de pagamento.
É possível contornar o Bot Fight Mode com uma regra WAF
Não. A página do Bot Fight Mode diz que não é possível contorná-lo nem ignorá-lo com regras personalizadas da WAF ou com Page Rules, porque não corre no Ruleset Engine, e por isso Skip, Bypass e Allow não têm efeito. A página das opções de Skip repete que só o Super Bot Fight Mode pode ser ignorado. Há uma exceção documentada: o Bot Fight Mode não é acionado se uma IP Access rule corresponder primeiro ao pedido.
Assim, no plano Free, se o Bot Fight Mode desafiar o seu fornecedor de pagamentos, o seu ERP ou o seu monitor de disponibilidade, restam três opções: uma IP Access rule de autorização para os endereços desse fornecedor, desligar o Bot Fight Mode ou passar para um plano pago, em que o Super Bot Fight Mode aceita regras Skip. O Super Bot Fight Mode tem ainda a definição Optimize for WordPress, que deixa passar os pedidos de loopback do WordPress e resolve os erros do Site Health sem regra personalizada.
Tabela de diagnóstico de bloqueios da Cloudflare
| O que o cliente ou o registo mostra | Regra provável | Correção |
|---|---|---|
| Erro 1015, HTTP 429 | Regra de limitação de pedidos | Período de contagem mais longo, limite mais alto, ou Skip da limitação para IP de confiança |
| Página de bloqueio da WAF, HTTP 403, sem código 1xxx | Regra personalizada ou regra gerida da WAF | Encontrar a regra pelo Ray ID; restringir a expressão ou acrescentar uma regra Skip acima dela |
| Erro 1020, HTTP 403 | Outro Block sem resposta personalizada (por exemplo, API Shield) | Procurar em Security Events, não nas regras personalizadas |
| Erro 1009 | Bloqueio por país nas IP Access rules | Autorizar o IP do visitante ou passar o bloqueio geográfico para uma regra personalizada limitada |
| Erro 1010 | Browser Integrity Check | Ignorá-lo no caminho afetado através da API, ou desligá-lo |
| Desafio em ciclo em todas as páginas | Under Attack Mode ou Security Level | Desligar, ou limitar com uma regra de configuração |
| Webhook ou API REST a falhar, sem pessoas envolvidas | Bot Fight Mode, Under Attack Mode ou uma regra de desafio | IP Access rule de autorização ou regra Skip do Super Bot Fight Mode; manter o UAM fora dos caminhos da API |
| Nada em Security Events | Amostragem, fuso horário errado, ou o pedido nunca chegou à Cloudflare | Janela de tempo mais curta, filtrar por IP; verificar o DNS e a firewall da origem |
Como monitorizar bloqueios da Cloudflare depois da correção
Não fique por um cliente. Em Security Events, filtre por Action igual a Block ou Managed Challenge e agrupe por caminho. Os pedidos para /checkout, /cart, /my-account, /wp-json/ ou para o endpoint do formulário de contacto são os que custam dinheiro. O URL com os filtros pode ser partilhado, para que um colega veja a mesma vista. É possível exportar até 500 eventos da amostra em JSON.
Depois, verifique o outro lado: entregas falhadas no Stripe, no PayPal ou no Shopify, encomendas WooCommerce presas em pendente e o número diário de envios do formulário de contacto. Uma quebra no dia a seguir a uma alteração de segurança aponta diretamente para a regra que acrescentou. O nosso serviço Cloudflare edge inclui auditorias de regras deste tipo, e a manutenção WooCommerce inclui esta monitorização para lojas WooCommerce.
Leituras relacionadas: se as definições de bots de IA da Cloudflare também travam os rastreadores dos motores de pesquisa está explicado em a Cloudflare bloqueia o Googlebot. Quanto do tráfego de um site pequeno é automatizado, e porque é que isso leva a regras de bots demasiado agressivas, está na nossa medição 72% do nosso tráfego não é um navegador. Para levar lógica para a rede de extremidade, veja Cloudflare Workers e WooCommerce.
