O site abre, mas bloqueia o verificador: porquê?

Se o site abre no navegador e recusa o verificador, sabemos que os dois pedidos tiveram resultados diferentes. Ainda não sabemos se a causa é uma proteção, uma sessão iniciada ou outra condição. Guarde a hora e compare exatamente o mesmo endereço antes de concluir que o site está em baixo.

Porque são os pedidos diferentes?

O navegador pode ter uma sessão iniciada ou já ter passado uma verificação de segurança. O pedido automático pode partir de outro IP ou rede e apresentar outra identificação. Por isso, abrir uma página no seu computador não demonstra que um serviço externo consiga fazer o mesmo.

Na ferramenta O site está em baixo?, o pedido parte de um servidor do nFerramentas na rede Cloudflare. Não leva os seus cookies, não inicia sessão e não executa o JavaScript da página. A indicação «Verificação bloqueada» descreve o acesso da ferramenta; não afirma que todos os visitantes estejam impedidos de entrar.

O que significam 403, 429 e CAPTCHA?

403: o acesso foi recusado

O servidor ou um intermediário compreendeu o pedido e recusou-o. Pode existir uma regra de segurança ou uma restrição de acesso. O código, sozinho, não identifica quem recusou nem qual foi a regra. Repetir o mesmo pedido sem mudar a causa pode dar a mesma resposta. Consulte a explicação do HTTP 403 na MDN.

429: há um limite de pedidos

Este código indica demasiados pedidos num período. O limite pode depender do IP, da conta ou do recurso consultado; não existe um prazo de espera igual para todos os sites. Numa rede partilhada, várias pessoas podem contribuir para um limite por IP. É uma possibilidade a investigar, não uma conclusão sobre o seu caso. Veja a referência do HTTP 429.

Se a resposta incluir Retry-After, respeite a espera indicada. O valor pode ser um número de segundos ou uma data HTTP, como explica a documentação desse cabeçalho. Distinga também um limite do site consultado de um aviso de excesso de consultas da própria ferramenta.

CAPTCHA ou «a verificar o navegador»

Uma página de desafio pode impedir o acesso ao conteúdo até o navegador completar uma verificação, por vezes com JavaScript ou uma interação. Um pedido automático simples pode ficar nessa etapa. A documentação da Cloudflare descreve este funcionamento. Nem todos os desafios usam CAPTCHA, nem todos os bloqueios são da Cloudflare.

Confirme também o conteúdo recebido: um HTTP 200 pode acompanhar uma página que não é a esperada. O verificador analisa uma amostra para reconhecer alguns desafios conhecidos; não identifica todos os erros ou proteções.

Sou visitante: o que posso fazer?

1. Confirme a página. Compare o URL completo e experimente a inicial. Uma página reservada pode exigir autenticação mesmo quando a inicial é pública.
2. Compare a sessão. Experimente uma janela privada e tenha em conta se está a iniciar sessão. Se só funciona com a sua conta, isso pode explicar a diferença para o verificador.
3. Compare outra rede, se puder. Teste o mesmo endereço nos dados móveis e no Wi-Fi. Anote qual funciona; não precisa de publicar o seu IP para fazer esta comparação.
4. Respeite a espera. Perante 429, evite recarregar repetidamente. Num desafio legítimo do próprio site, siga as instruções no navegador.
5. Contacte o responsável se persistir. Envie a mensagem, a hora e os resultados da comparação. Uma ferramenta externa não consegue corrigir as permissões do destino.

Para investigar falhas de ligação, siga O site está em baixo ou é a minha ligação?. Se a mensagem for «servidor não encontrado», o guia de WHOIS, DNS e IP ajuda a seguir outra pista.

O site é meu: como encontro a causa?

Faça uma verificação e anote o endereço, a hora com fuso horário e a resposta. Depois procure o pedido nos registos da proteção e do alojamento. Confirme se o resultado corresponde ao endereço original ou a um destino após redirecionamento.

Se usa Cloudflare

Em Security Events, selecione um intervalo próximo da tentativa e filtre pelo domínio e caminho. Abra o evento correspondente e veja a ação, o serviço e a regra identificados. «Managed Challenge» é uma ação que pode ser aplicada por vários serviços: o nome da ação não basta para escolher a definição a alterar.

Se a página de bloqueio apresentar um Ray ID, guarde-o para ajudar a localizar o pedido. Não confunda o IP do seu computador com o do verificador: a consulta externa parte de um servidor. A ferramenta de IP mostra a sua ligação, não o IP desse servidor.

Os registos podem ser uma amostra: a ausência de um evento não prova a ausência de bloqueio. Reduza o intervalo e consulte também os registos do alojamento ou da aplicação. Estas limitações estão descritas na documentação dos eventos de segurança.

Ajuste a causa identificada

Se uma regra sua estiver a atingir tráfego legítimo, reveja a condição e restrinja a alteração ao acesso necessário. Confirme quais as proteções abrangidas por uma exceção antes de a guardar. Desativar toda a proteção dificulta perceber a causa e pode deixar outros pedidos sem controlo.

Há uma particularidade no Bot Fight Mode: não é possível ignorá-lo com regras personalizadas de WAF ou Page Rules. As ações Skip, Bypass e Allow dessas regras não criam essa exceção. O Super Bot Fight Mode tem funcionamento diferente e admite regras Skip; a disponibilidade depende do plano. Consulte os limites oficiais do Bot Fight Mode antes de escolher uma solução.

Depois do ajuste, repita a tentativa original e confirme o acesso normal de um visitante. Se gere uma loja ou uma área reservada, confirme também as funções afetadas: abrir a inicial não testa o início de sessão nem o pagamento.

Um exemplo de diagnóstico

Exemplo fictício: a inicial abre no navegador, mas uma consulta externa recebe 403. Nos registos, o proprietário encontra um desafio aplicado ao pedido, à mesma hora e no mesmo caminho. Há evidência de uma proteção a intervir; ainda é preciso perceber se essa política deve permitir aquele serviço. Se não encontrar correspondência, deve continuar a investigar em vez de atribuir o resultado a uma regra por suposição.

E se o bloqueio afetar o Google ou o Bing?

Confirme primeiro a identidade do robô. O texto Googlebot ou bingbot no User-Agent pode ser imitado; não crie uma permissão baseada apenas nesse nome ou numa rede inteira. A Google documenta a verificação por intervalos de IP publicados ou por DNS inverso seguido de confirmação direta. Para outros serviços, use a verificação oficial correspondente.

Um verificador de disponibilidade, uma inspeção de URL e um robô de pesquisa são serviços diferentes. Depois de corrigir um bloqueio confirmado, volte a testar no serviço afetado. Conseguir obter uma página não significa que ela esteja indexada. A Google distingue rastreio, indexação e apresentação nos resultados; a entrada no índice não é garantida. Um relatório sem erros técnicos também não equivale a aprovação no AdSense.

O que enviar num pedido de ajuda?

Use esta lista para o responsável conseguir comparar a ocorrência com os registos:

• Endereço: domínio e caminho, retirando tokens e dados confidenciais.
• Quando: data, hora e fuso horário.
• O que aparece: mensagem e código HTTP, se disponível.
• Comparação: navegador, sessão iniciada ou não, Wi-Fi e dados móveis.
• Consulta externa: ferramenta utilizada, hora e resultado.
• Identificador: Ray ID ou equivalente, se a página o apresentar.

Não envie palavras-passe, cookies de sessão ou cabeçalhos de autenticação. Numa captura de ecrã, oculte dados de conta e ligações privadas. Partilhe os detalhes técnicos apenas com o suporte responsável.

Um 403 prova que o site está em baixo?

Não. Prova que aquele pedido recebeu uma recusa de acesso. O site pode permitir outros pedidos. Compare o endereço, a sessão e a rede, e use os registos para investigar a causa.

Devo continuar a carregar em verificar quando aparece 429?

Não. Aguarde o prazo indicado pelo serviço, quando existir. Repetir muitas vezes pode manter a limitação e tornar o diagnóstico menos claro.

É necessário desligar a proteção contra robôs?

Comece por identificar o serviço e a condição que atingem o pedido. A solução depende da proteção e do acesso pretendido. Um verificador bloqueado, por si só, não justifica retirar a proteção geral.