Quando uma requisição a um recurso acelerado por CDN retorna um erro 403, ou o domínio apresenta anomalias de tráfego ou suspeita de roubo malicioso de tráfego, use as categorias de sintomas neste tópico para identificar a causa e resolvê-la. Este tópico abrange apenas a solução de problemas. Para dúvidas sobre configuração e consulta, consulte FAQ about access control.
Referência rápida de sintomas
Use curl -v ou as ferramentas de desenvolvedor do navegador para verifique o campo X-Tengine-Error nos cabeçalhos de resposta e identifique a causa com base na tabela a seguir:
Observação: Se o campo X-Tengine-Error existir nos cabeçalhos de resposta, mas seu valor não constar na tabela anterior, ou se a autenticação remota estiver ativa para o domínio, consulte Erros 403 causados por autenticação remota.
Como determinar se o erro 403 é retornado pelo CDN ou pelo servidor de origem?
Quando uma requisição a um recurso acelerado retorna um erro 403, primeiro determine a origem do erro e, em seguida, solucione o problema com base na família de sintomas correspondente:
Se os cabeçalhos de resposta não contiverem o campo X-Tengine-Error, modifique o arquivo hosts local para mapear o domínio acelerado ao endereço IP do servidor de origem e acesse o servidor de origem diretamente para verifique. Se o servidor de origem também retornar um erro 403, a política de controle de acesso do próprio servidor de origem bloqueou a requisição. Consulte Erros 403 retornados pelo servidor de origem. Para métodos gerais de solução de problemas no servidor de origem, consulte Troubleshooting guide about origin fetch.
Erros 403 causados por autenticação de URL
Após ativar a autenticação de URL, o CDN retorna um erro 403 se uma requisição não carregar o parâmetro de assinatura ou se o parâmetro for inválido. Use a mensagem X-Tengine-Error: denied by req auth nos cabeçalhos de resposta para determinar a causa específica.
Observação: A autenticação de URL controla apenas as permissões de acesso; o resultado da autenticação não afeta o comportamento de cache do CDN. Após a autenticação ser aprovada, o nó do CDN remove o parâmetro de assinatura (como auth_key) da URL e usa a URL original como chave de cache, de modo que diferentes URLs assinadas geradas por diferentes usuários para o mesmo recurso acessam o mesmo conteúdo em cache. Uma autenticação expirada apenas faz com que novas requisições subsequentes sejam bloqueadas com um erro 403 e não invalida recursos que já estão em cache.
Error denied by req auth: no url arg auth_key (no signing parameter is carried)
Causa: A autenticação de URL está ativa no CDN, mas a URL efetivamente acessada não carrega o parâmetro de assinatura.
Solução: Se o recurso de autenticação for necessário, siga Configure URL signing para gerar e incluir o parâmetro de assinatura correto nas requisições. Caso contrário, acesse o console do CDN e desative a autenticação de URL para o domínio.
Error denied by req auth: expired timestamp (the signing has expired)
Causa: A URL carrega o parâmetro de assinatura, mas o timestamp nesse parâmetro expirou. O período de validade de uma URL assinada é determinado pela duração de validade configurada. A assinatura deixa de ser válida após esse período expirar.
Solução: Consulte Configure URL signing para regenerar a URL assinada. Se as páginas da sua aplicação levam muito tempo para carregar, aumente adequadamente a duração de validade da assinatura.
Error denied by req auth: invalid md5hash (authentication calculation error)
Causa: O valor MD5 do parâmetro de assinatura foi calculado incorretamente. Isso geralmente ocorre por uma incompatibilidade entre o algoritmo de assinatura do seu código e os requisitos do método de autenticação do CDN.
Solução: Recomendamos que você primeiro use o gerador de URL no console do CDN para criar uma URL assinada, compare-a campo a campo com a URL gerada pelo seu próprio código de assinatura e localize a diferença. Para o algoritmo de assinatura de cada método de autenticação, consulte Type A signing. Para exemplos de código de assinatura, consulte URL signing examples.
Erros 403 causados pela lista de bloqueios/permissões de Referer
Após configure uma lista de bloqueios/permissões de Referer, o CDN retorna um erro 403 se o Referer de uma requisição não corresponder às regras. A mensagem de erro nos cabeçalhos de resposta é X-Tengine-Error: denied by Referer ACL. Execute o comando curl -e "<Referer value>" <accelerated resource URL> para simular uma requisição com um Referer específico e verifique o comportamento.
A request that carries a Referer is blocked (denied by Referer ACL)
Causa: O Referer da requisição não está na lista de permissões ou corresponde à lista de bloqueios. Isso ocorre com frequência quando a lista de permissões omite o domínio do site que realmente referencia os recursos.
Diagnóstico: No console do CDN, verifique a configuração da lista de bloqueios/permissões de Referer do domínio acelerado e determine se o Referer da requisição bloqueada corresponde às regras. Você também pode baixe os logs do CDN para encontrar o cabeçalho Referer do registro de acesso correspondente.
Solução: Adicione o Referer bloqueado à lista de permissões (ou remova-o da lista de bloqueios). Para o método de configuração, consulte Configure a Referer blacklist or whitelist.
A request with an empty Referer is blocked (accessing the URL directly returns a 403 error)
Causa: Requisições nos seguintes cenários não carregam um Referer (Referer vazio): acesso direto a uma URL de recurso pela barra de endereços do navegador; construção de requisições em aplicativos ou programas cliente sem defina o cabeçalho Referer; uma página https referenciando recursos http, caso em que o navegador não envia o Referer com base na Referrer-Policy padrão; a página definindo explicitamente Referrer-Policy: no-referrer; e uso de ferramentas de linha de comando como curl ou wget, que não carregam um Referer por padrão. Se a opção Allow direct access to resource URLs from the browser address bar não estiver selecione na configuração da lista de bloqueios/permissões de Referer, requisições com Referer vazio são bloqueadas.
Solução: Se a sua aplicação precisar permitir acesso com Referer vazio, selecione Allow direct access to resource URLs from the browser address bar na configuração da lista de bloqueios/permissões de Referer. Se você bloqueia intencionalmente requisições com Referer vazio para evitar roubo de tráfego, não as permita e consulte Anomalias de tráfego e roubo malicioso de tráfego para configure políticas de mitigação mais granulares. Para o método de configuração, consulte Configure a Referer blacklist or whitelist.
Erros 403 causados por outros recursos de controle de acesso do CDN
403 errors caused by the IP blacklist/whitelist
Após configure uma lista de bloqueios/permissões de IP, o nó do CDN rejeita a requisição e retorna um erro 403 se o endereço IP do cliente corresponder à lista de bloqueios ou não estiver na lista de permissões. O cabeçalho de resposta X-Tengine-Error: denied by IP ACL = blacklist indica que o endereço IP corresponde à lista de bloqueios de IP, e X-Tengine-Error: denied by IP ACL = not in whitelist indica que o endereço IP não está na lista de permissões de IP.
Diagnóstico: Confirme primeiro o endereço IP público real do cliente (consulte-o executando curl ifconfig.me ou curl myip.ipip.net). Se as requisições passam por um proxy ou balanceador de carga, o endereço IP do cliente obtido pelo CDN pode ser o IP do proxy, e não o IP do usuário final; confirme o endereço IP realmente identificado pelo nó do CDN. No console do CDN, verifique a configuração da lista de bloqueios/permissões de IP do domínio e confirme se o endereço IP corresponde às regras.
Solução: Confirme primeiro se o bloqueio é intencional. Para permitir o endereço IP, na página Domain Names no console do CDN, clique em Manage para o domínio de destino. No painel de navegação à esquerda, clique em Access Control e ajuste as regras na seção IP Blacklist/Whitelist. Para o método de configuração, consulte Configure an IP blacklist or whitelist. Se um endereço IP na lista de bloqueios ainda consegue acessar os recursos, consulte Why can an IP address in the blacklist still access my resources?.
403 errors caused by the UA blacklist/whitelist
Após configure uma lista de bloqueios/permissões de UA, o nó do CDN rejeita a requisição e retorna um erro 403 se o User-Agent no cabeçalho da requisição corresponder à lista de bloqueios de UA ou não estiver na lista de permissões de UA. O cabeçalho de resposta X-Tengine-Error: black ua indica que o User-Agent corresponde à lista de bloqueios de UA, e X-Tengine-Error: not in white ua indica que o User-Agent não está na lista de permissões de UA.
Diagnóstico: Execute curl -v <accelerated resource URL> para verifique o valor de User-Agent que a requisição realmente envia, ou verifique os cabeçalhos da requisição nas ferramentas de desenvolvedor do navegador. No console do CDN, verifique as regras da lista de bloqueios/permissões de UA do domínio e confirme se o User-Agent corresponde. Observe que a lista de bloqueios/permissões de UA suporta correspondência por curinga; verifique se o User-Agent não está sendo correspondido inesperadamente por uma regra de curinga.
Solução: Confirme primeiro se o bloqueio é intencional. Para permitir a requisição, na página Domain Names no console do CDN, clique em Manage para o domínio de destino. No painel de navegação à esquerda, clique em Access Control e ajuste as regras na aba UA Blacklist/Whitelist. Para o método de configuração, consulte Configure a User-Agent blacklist or whitelist.
403 errors caused by remote authentication
Após ativar a autenticação remota, o nó do CDN encaminha as requisições ao servidor de autenticação especificado para verificação. As requisições são bloqueadas e um erro 403 é retornado nos dois casos a seguir:
O servidor de autenticação retorna o Authentication Failure Status Code defina na configuração (por exemplo, 403). O CDN determina que a autenticação falhou e rejeita a requisição.
A autenticação expira por timeout (a interação entre o nó do CDN e o servidor de autenticação não é concluída dentro do período de timeout configurado) e Action After Authentication Timeout está defina como Reject.
Diagnóstico: Se o erro 403 não se enquadrar em nenhuma das categorias de autenticação de URL, Referer, IP ACL ou UA ACL descritas acima (o valor de X-Tengine-Error nos cabeçalhos de resposta não corresponde a nenhuma delas) e a autenticação remota estiver ativa para o domínio, investigue a autenticação remota primeiro. No console do CDN, verifique Authentication Failure Status Code, Authentication Timeout Settings e Action After Authentication Timeout na configuração de autenticação remota do domínio e, em seguida, verifique os logs de acesso do servidor de autenticação para confirme o código de status realmente retornado e se ocorreram timeouts.
Solução: Se o bloqueio não for intencional, ajuste a lógica de verificação do servidor de autenticação ou a configuração do código de status de falha de autenticação. Se os timeouts de autenticação ocorrerem com frequência, investigue o desempenho do servidor de autenticação (o período de timeout pode ser defina em no máximo 3.000 milissegundos) ou defina Action After Authentication Timeout como Allow com base na avaliação de risco da sua aplicação. Para o método de configuração, consulte Configure remote authentication.
Erros 403 retornados pelo servidor de origem
Se os cabeçalhos de resposta não contiverem o campo X-Tengine-Error e X-Cache for MISS, o cache do CDN não teve correspondência e o servidor de origem retornou um erro 403 após a busca na origem. Nesse caso, investigue as políticas de controle de acesso do próprio servidor de origem.
403 errors when the origin server is OSS (AccessDenied and other errors)
O erro 403 é retornado pelo servidor de origem OSS. Há três mensagens de erro comuns:
O erro You have no right to access this object because of bucket acl: O bucket tem permissões de leitura privadas e a requisição de busca na origem do CDN não passa pela autenticação do OSS. Recomendamos ativar a autorização de busca na origem para buckets OSS privados no console do CDN. Para o método de configuração, consulte Configure origin fetch from a private OSS bucket.
O erro You are denied by bucket referer policy: Uma lista de bloqueios/permissões de Referer está configurada para o bucket, e o Referer da requisição de busca na origem do CDN não corresponde às regras do bucket. Verifique as configurações da lista de bloqueios/permissões de Referer do bucket no console do OSS e permita o acesso das requisições de busca na origem do CDN (por exemplo, permita Referer vazio ou adicione o Referer das requisições de busca na origem do CDN à lista de permissões).
O erro You are forbidden to list buckets: A autorização de busca na origem de bucket privado do CDN e a hospedagem de site estático do OSS estão ativas ao mesmo tempo, e os dois recursos entram em conflito. Desative um deles: desative a autorização de busca na origem para buckets privados do CDN ou desative o recurso de hospedagem de site estático do OSS. Para a descrição do conflito, consulte What can I do if errors arise after I enable access to private OSS buckets and static website hosting?.
403 errors caused by the origin host or other origin server policies
Causa: Quando o CDN realiza uma busca na origem, o origin host determina qual site no endereço IP do servidor de origem a requisição acessa. Se o origin host estiver configurado incorretamente, a requisição pode ser direcionada a um site que não fornece serviços ou que tem restrições de acesso no servidor de origem, e o servidor de origem retorna um erro 403. Além disso, as regras de firewall, as políticas de WAF ou o controle de acesso na camada de aplicação do próprio servidor de origem também podem bloquear as requisições de busca na origem do CDN.
Diagnóstico: Mapeie o domínio acelerado ao endereço IP do servidor de origem no arquivo hosts, acesse o servidor de origem diretamente e verifique se ele também retorna um erro 403. Verifique a configuração do origin host no console do CDN e confirme se ele aponta para o site que realmente fornece serviços no servidor de origem.
Solução: Corrija a configuração do origin host para garantir que ele aponte para o site que realmente fornece serviços no servidor de origem. Se o firewall ou o WAF do servidor de origem bloquear as requisições de busca na origem do CDN, adicione os intervalos de endereços IP de busca na origem do CDN à lista de permissões do servidor de origem. Para métodos gerais de solução de problemas no servidor de origem, consulte Troubleshooting guide about origin fetch.
Anomalias de tráfego e roubo malicioso de tráfego
Quando um domínio sofre um ataque ou tem seu tráfego roubado de forma maliciosa, picos súbitos de largura de banda ou tráfego intenso são gerados, o que traz principalmente dois riscos:
O domínio é movido para um sandbox: O Alibaba Cloud CDN é um service de aceleração público e não oferece capacidades anti-ataque por padrão. Quando um domínio sofre um ataque, o CDN tem o direito de movê-lo para um sandbox com base na situação da aplicação e na gravidade do impacto do ataque, para evitar afetar os serviços de aceleração de outros usuários. Se os ataques forem severos, outros domínios na mesma conta também podem ser movidos para um sandbox, e o cadastro de novos domínios na conta fica restrito. Após um domínio entrar no sandbox, o CDN não garante mais a qualidade do service. Para mais informações sobre o sandbox, consulte Sandbox overview.
Acesso malicioso gera cobranças inesperadamente altas: Ataques e roubos de tráfego consomem de fato os recursos de largura de banda do CDN. Os custos de largura de banda resultantes são de sua responsabilidade, o que pode facilmente levar a cobranças inesperadamente altas e até mesmo causar a suspensão da conta por pagamentos em atraso. Para mais informações sobre proteção contra suspensão de service e controle de custos, consulte High bill risk warning.
How do I confirm whether the domain name is suffering from traffic theft or attacks?
Confirme preliminarmente das seguintes maneiras:
Acesse o console do CDN e verifique as tendências de largura de banda e tráfego do domínio em Monitoring Reports. Verifique se ocorrem picos anormais fora do horário comercial.
Baixe os logs de acesso do CDN do domínio, analise a distribuição de endereços IP, distribuição de Referer e distribuição de User-Agent das fontes de acesso e identifique intervalos de IP com frequência anormalmente alta, fontes de Referer suspeitas ou User-Agents com comportamento de crawler.
Verifique no CloudMonitor se alertas de largura de banda ou tráfego foram disparados.
How do I protect against and handle it?
Recomendamos que você adote medidas de proteção preventivamente: configure regras de alerta para pico de largura de banda e tráfego downstream por meio do recurso de configuração de alarmes, para ser notificado prontamente quando os limiares forem atingidos; configure políticas de controle de acesso como lista de bloqueios de IP, lista de bloqueios de Referer, lista de bloqueios de UA ou autenticação de URL com base nas características do ataque para bloqueá-lo. Para soluções de bloqueio em cenários de roubo de tráfego, consulte Prevent traffic abuse.
Se o domínio foi movido para um sandbox, aguarde o tráfego do ataque diminuir e envie um ticket solicitando a remoção do sandbox. Para evitar reincidência, configure as políticas de controle de acesso antes da remoção.