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.
Limitação de pedidos da Cloudflare: que definições deixam de apanhar compradores
A página das regras de limitação de pedidos indica o que cada plano permite configurar, e esses valores determinam até que ponto a correção pode ser precisa:
| Plano | Campos na expressão da regra | Período de contagem | Tempo de mitigação | Contagem por |
|---|---|---|---|---|
| Free | Path, Verified Bot | 10 s | 10 s | IP |
| Pro | acrescenta Host, URI, Full URI, Query | até 1 min | até 1 h | IP |
| Business | acrescenta Method, Source IP, User Agent | até 10 min | até 1 dia | IP, IP com suporte de NAT |
| Enterprise com Advanced Rate Limiting | campos gerais do pedido e dos cabeçalhos | até 65535 s | até 1 dia | acrescenta cabeçalhos, cookies, ASN, país e mais |
A contagem por IP explica porque é que um escritório ou um operador móvel consegue acionar uma regra pensada para um único robô, porque todas as pessoas que saem pelo mesmo endereço partilham o mesmo contador. As boas práticas de limitação de pedidos da Cloudflare propõem três alterações que reduzem o problema:
- Excluir os parceiros conhecidos. O exemplo da Cloudflare permite 10 pedidos por minuto e por IP para
/status, exceto quando o endereço consta de uma lista de IP chamadapartner_ips, comnot ip.src in $partner_ipsna expressão. O IP de origem só está disponível nas expressões de limitação de pedidos a partir do plano Business; nos planos Free e Pro, coloque a lista de parceiros numa regra personalizada Skip que ignore todas as regras de limitação de pedidos, já que as regras personalizadas podem filtrar pelo IP de origem. - Contar apenas as falhas. A partir do plano Business há uma expressão de contagem personalizada, pelo que uma regra de início de sessão pode contar só os pedidos
POSTque devolveram 401 ou 403. Um cliente que entra à primeira nunca soma nada ao contador. - Indicar o caminho exato. A mesma página avisa que uma regra para
/validate/otpnão apanha/api/otp/validate. Confirme o caminho real nas estatísticas antes de escrever a regra e deixe/wp-json/e os pedidos AJAX do checkout fora das regras destinadas às páginas de início de sessão.
No plano Enterprise, o separador Request rate analysis do Security Analytics mostra a distribuição da taxa de pedidos dos 50 clientes mais ativos e pode preencher previamente uma regra de limitação de pedidos com a taxa selecionada. A Cloudflare recomenda pôr essa regra a funcionar primeiro com a ação Log.
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.
Excluir uma única regra gerida em vez de desligar a WAF no checkout
Quando o evento mostra uma regra gerida, não ignore todas as regras geridas no checkout. As exceções das regras geridas da Cloudflare podem ignorar todas as regras geridas seguintes, um ou mais conjuntos de regras geridas, ou uma ou mais regras individuais, e cada exceção tem a sua própria expressão. Copie o ID da regra a partir do evento, crie uma exceção só para essa regra e limite-a ao caminho e ao método que a acionaram, por exemplo os pedidos POST para o endpoint do formulário que transportava os dados.
O nível em que a exceção é criada também conta. Uma exceção definida ao nível da zona não impede uma correspondência de um conjunto de regras geridas aplicado ao nível da conta, porque os conjuntos de regras da conta correm primeiro em cada fase. Se gere várias lojas na mesma conta Cloudflare, confirme onde estão aplicadas as regras geridas antes de escrever a exceção.
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.
Atualização de . Deixar passar pela Cloudflare os webhooks do fornecedor de pagamentos não significa que o endpoint deva confiar em quem o chama. O relatório semanal de vulnerabilidades da Wordfence de 12 a 18 de outubro de 2026 lista plugins de pagamento que aceitavam chamadas forjadas: no Rede Itaú até 5.5.2, o webhook 3DS saltava a verificação junto da Rede quando o identificador de transação vinha vazio, e uma segunda falha no webhook de débito aceitava pedidos POST forjados; o Asaas Gateway antes da 2.7.8 comparava um token configurado vazio com um token vazio no pedido; o CamPay Shortcode Payment Gateway antes da 1.7 aceitava o estado do pagamento diretamente dos parâmetros GET do URL de retorno, sem consultar a API da CamPay nem validar uma assinatura. A Cloudflare não distingue um webhook forjado de um verdadeiro, por isso a verificação pertence à aplicação: defina o segredo do webhook nas definições do gateway, mantenha o plugin atualizado e confirme que as encomendas pagas têm transação no painel do fornecedor.
Como confirmar com curl se a Cloudflare ainda bloqueia um pedido
Uma captura de ecrã mostra o que aconteceu uma vez. Repetir o pedido mostra se continua a acontecer depois da correção. Num terminal, peça a página que o cliente não conseguiu abrir e leia os cabeçalhos:
curl -sI https://example.com/checkout/
curl -sI "https://example.com/?wc-api=wc_stripe"Há três cabeçalhos que interessam. server: cloudflare confirma que a resposta veio da rede de extremidade. cf-ray dá-lhe um Ray ID novo para procurar em Security Events. E um cabeçalho cf-mitigated: challenge significa que a resposta é uma página de desafio: o guia de deteção de desafios da Cloudflare diz que o cabeçalho é definido em todos os tipos de página de desafio, que challenge é o seu único valor e que o corpo é sempre text/html, seja qual for o recurso pedido.
Este último pormenor explica uma falha frequente nos sites headless. Um frontend em Astro ou Next.js que chama a sua própria API com fetch espera JSON, recebe um desafio em HTML e falha com um erro de leitura que parece um defeito do código. Verifique response.headers.get("cf-mitigated") antes de interpretar a resposta, registe o valor, e numa única publicação fica a saber se a causa é a Cloudflare. O seu IP e o seu navegador podem não acionar a mesma regra que os do cliente, por isso um resultado limpo no seu computador prova menos do que um resultado limpo em Security Events.
É 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 personalizar a página de bloqueio da Cloudflare para os clientes
A página de bloqueio predefinida não diz ao visitante nada sobre a sua loja, nem a quem deve pedir ajuda. Nos planos pagos há duas opções. As Custom Errors estão disponíveis nos planos Pro, Business e Enterprise, mas não no Free, e uma Error Page do tipo WAF block substitui a página mostrada em todos os bloqueios da WAF na zona. A partir do plano Pro, uma regra personalizada com a ação Block também pode devolver a sua própria resposta, com um código de estado entre 400 e 499 e um corpo em HTML, JSON ou texto simples.
Use essa página para pedir exatamente o que precisa para encontrar o evento: uma captura de ecrã com o Ray ID, a hora, e um endereço de email ou número de telefone que não esteja atrás da mesma zona, para que o cliente não fique bloqueado também no contacto. Num caminho de API, devolva JSON, para que as integrações registem um erro legível em vez de uma página HTML. Os exemplos de regras de erro personalizadas da Cloudflare incluem um para os erros 1020, que usa a expressão cf.response.1xxx_code eq 1020.
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.
Testar a próxima regra sem bloquear clientes
O guia das regras personalizadas da Cloudflare oferece a ação Log para validar uma regra antes de a aplicar, mas apenas nos planos Enterprise. Nos restantes planos sugere começar com Managed Challenge, rever em Security Events os pedidos que correspondem à regra e passar para Block quando essas correspondências parecerem corretas. Um cliente real consegue passar um Managed Challenge; um Block não lhe deixa nada para fazer.
Um visitante desafiado que passa o teste recebe um cookie cf_clearance. A definição Challenge Passage controla durante quanto tempo ele é válido: 30 minutos por omissão, com a Cloudflare a recomendar entre 15 e 45 minutos. Isto tem duas consequências nos pedidos de suporte. Um cliente que bloqueia cookies é desafiado de novo em cada página, o que ele descreve como “o site está sempre a verificar-me”. E o Challenge Passage não se aplica às regras de limitação de pedidos, por isso passar um desafio não anula um 1015.
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.
