CDN:Origin fetch troubleshooting

Um nó do CDN, atuando como gateway, retorna um erro 502 (Bad Gateway) quando não consegue obter uma resposta válida do servidor de origem. Falhas em qualquer uma das seguintes etapas no caminho de origin fetch podem retornar um erro 502:

• O servidor de origem não suporta HTTPS (escuta apenas na porta 80), mas o CDN está configurado para realizar o origin fetch via HTTPS.

• A porta de origem não corresponde à porta na qual o servidor de origem realmente escuta.

• O servidor de origem depende do SNI para selecionar o certificado, mas o CDN não carrega um valor SNI ou carrega um valor incorreto.

• O certificado SSL do servidor de origem expirou, é inválido ou não corresponde ao nome de domínio.

• O servidor de origem usa um certificado autoassinado ou emitido por uma CA interna, e a validação TLS durante o origin fetch falha.

Etapas de solução de problemas:

• Verifique se o servidor de origem suporta o protocolo de origin fetch atual: Execute curl -Iv https://origin-domain para verificar o servidor de origem diretamente. Se a conexão for recusada ou atingir o tempo limite, o servidor não suporta HTTPS. Altere o protocolo de origem para HTTP. Se o servidor suportar HTTPS e o certificado for válido, escolha o origin fetch HTTPS ou o protocolo Follow.

• Verifique se a porta de origem corresponde à porta de escuta do servidor: A porta de origem padrão é 443 para HTTPS e 80 para HTTP. Se o servidor usar uma porta personalizada (1 a 65535), especifique a porta correspondente na configuração do protocolo de origem.

• Verifique a configuração de SNI de origem: Quando o servidor de origem hospeda vários sites HTTPS no mesmo endereço IP, ele depende do campo SNI (Server Name Indication) no handshake TLS para selecionar o certificado SSL correspondente. Se o origin fetch do CDN não carregar um valor SNI ou se o valor estiver incorreto, o servidor não conseguirá corresponder ao certificado correto, o handshake TLS falhará e um erro 502 será retornado.

  Etapas da solução: Faça logon no console do CDN, escolha Domain Management, selecione o nome de domínio de destino, acesse Origin Settings e ative origin SNI. Insira o nome de domínio que o servidor de origem realmente usa para fornecer services (geralmente o mesmo Common Name do certificado de origem). Defina também o host de origem como o nome de domínio de origem.

  Durante o origin fetch, o CDN valida o valor SNI em relação ao Common Name no certificado do servidor de origem. Se os dois valores realmente não puderem corresponder (por exemplo, o servidor usa um certificado em uma camada de acesso unificada), adicione o Common Name do certificado à Common Name whitelist.

  Nota

  O SNI de origem seleciona o certificado durante o handshake TLS, enquanto o host de origem faz o roteamento de host virtual na camada HTTP. Ambos têm propósitos diferentes, mas geralmente são definidos com o mesmo nome de domínio de origem.

• Verifique a validade do certificado SSL no servidor de origem: Confirme se o certificado não expirou nem foi revogado, e se os nomes de domínio no certificado incluem o nome de domínio de origem. Execute curl -Iv https://origin-domain 2>&1 | grep -E "expire|subject|issuer" para visualizar o período de validade, o emissor e os nomes de domínio vinculados. Se o certificado tiver expirado ou não corresponder ao domínio, atualize-o no servidor de origem. Se o servidor usar um certificado autoassinado ou emitido por uma CA interna, substitua-o por um certificado emitido por uma CA publicamente confiável ou altere o protocolo de origem para HTTP.

Solução: Altere o protocolo de origem com base na configuração real do servidor de origem: se suportar apenas HTTP → selecione HTTP (porta 80 por padrão); se suportar HTTPS e o certificado for válido → selecione HTTPS (porta 443 ou personalizada); se suportar ambos e o certificado for bem mantido → selecione o protocolo Follow. Para etapas detalhadas, consulte Configure the origin protocol policy.

Como solucionar um erro 502 quando o protocolo de origem está definido como Follow?

Quando o protocolo de origem está definido como Follow, o CDN usa o mesmo protocolo da solicitação do cliente para o origin fetch: se o cliente usar HTTP, o CDN usará HTTP; se usar HTTPS, o CDN usará HTTPS. Se um cliente acessar o CDN via HTTPS, mas o servidor de origem não suportar HTTPS, o handshake TLS falhará e a solicitação de origin fetch também falhará. Este problema tem a mesma causa de "Como solucionar um erro 502 retornado durante o origin fetch?" e pode ser diagnosticado com as mesmas etapas.

Soluções:

• Método 1: Altere o protocolo de origem de Follow para HTTP para que o CDN sempre use HTTP no origin fetch.

• Método 2: Configure um certificado SSL no servidor de origem para que ele suporte acesso HTTPS. Para mais informações, consulte Configure the origin protocol policy.

Um erro 504 (Gateway Timeout) indica que um nó do CDN não conseguiu obter uma resposta do servidor de origem dentro do tempo especificado durante o origin fetch.

As causas comuns incluem:

• O servidor de origem responde lentamente ou o service está indisponível.

• Dispositivos de rede intermediários ou firewalls descartam solicitações de origin fetch (quando pacotes SYN são descartados, isso se manifesta como tempo limite de conexão).

• O protocolo ou a porta de origem está configurado incorretamente, impedindo o estabelecimento da conexão (isso geralmente gera um erro 502, mas se o firewall descartar pacotes silenciosamente em vez de recusá-los ativamente, também pode gerar um erro 504).

• O tempo limite de leitura de origem é muito curto para cobrir o tempo de resposta real do servidor de origem.

Os tempos limite de origin fetch dividem-se em duas fases, que indicam diferentes direções de solução de problemas:

• Tempo limite da fase de conexão: O tempo limite para um nó do CDN estabelecer uma conexão TCP com o servidor de origem é de 10 segundos. Um tempo limite nesta fase geralmente indica que o servidor não está escutando na porta de origem, um firewall ou grupo de segurança descarta pacotes SYN dos IPs de origin fetch do CDN, ou há perda severa de pacotes no caminho de rede.

• Tempo limite da fase de leitura: A conexão foi estabelecida, mas o servidor não retorna uma resposta completa dentro do tempo limite de leitura de origem (30 segundos por padrão). Isso geralmente indica processamento lento no servidor, devido a consultas lentas ao banco de dados, aplicativos de backend bloqueados ou alta carga.

Etapas de solução de problemas:

1. Verifique se o servidor de origem está acessível: Execute curl -I http(s)://origin-domain ou acesse o servidor em um navegador para verificar o tempo de resposta e o código de status. Se o próprio servidor responder lentamente ou estiver inacessível, corrija o problema de desempenho ou disponibilidade nele primeiro.

2. Identifique em qual fase o tempo é gasto: Execute o seguinte comando:

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s)://origin-domain/resource-path

   time_connect é o tempo necessário para estabelecer a conexão TCP, time_starttransfer é o tempo para receber o primeiro byte e time_total é o tempo total.

   • Se time_connect já for significativamente alto, solucione problemas de rede e firewall como uma questão da fase de conexão.

   • Se time_starttransfer for muito maior que time_connect, o processamento no servidor de origem está lento. Otimize o servidor.

   • Se time_total for muito maior que time_starttransfer, o corpo da resposta é muito grande ou a largura de banda de saída do servidor é insuficiente.

3. Verifique as configurações de protocolo e porta de origem: Certifique-se de que o protocolo e a porta configurados no CDN correspondam à escuta real do servidor de origem. Se a porta estiver incorreta ou o servidor não estiver escutando nela, o CDN retornará um erro 504 após o tempo limite.

4. Verifique o firewall ou grupo de segurança do servidor de origem: Se o servidor limitar ou bloquear faixas de IPs de origin fetch do CDN, algumas solicitações podem atingir o tempo limite. Políticas que descartam pacotes SYN silenciosamente se manifestam diretamente como tempos limite na fase de conexão. Adicione as faixas de IPs de origin fetch do CDN à lista de permissões do servidor (consulte What are the CDN origin fetch node IP addresses).

5. Verifique a qualidade do caminho de rede entre os nós do CDN e o servidor de origem: Podem existir instabilidade, perda de pacotes ou problemas de roteamento da operadora entre os nós e o servidor. Use ferramentas como MTR ou traceroute para analisar o caminho (entre em contato com o suporte técnico da Alibaba Cloud para iniciar diagnósticos do lado do nó do CDN).

6. Aumente o tempo limite de leitura de origem: Se o tempo de resposta do servidor estiver próximo do padrão de 30 segundos, aumente o origin HTTP request timeout no console do CDN para reduzir erros 504. O valor máximo configurável é 150 segundos, mas recomendamos não exceder 60 segundos. Use isso apenas como mitigação temporária. A solução definitiva é otimizar o desempenho de resposta do servidor.

Um erro 503 (Service Temporarily Unavailable) indica que o servidor de origem está temporariamente incapaz de processar solicitações. Um erro 503 recebido durante o origin fetch do CDN geralmente é causado pelo servidor de origem:

• O programa de service web no servidor de origem está anormal, não foi iniciado ou está reiniciando.

• A carga no servidor de origem está muito alta (CPU, memória ou conexões saturadas).

• Há um limite de taxa de solicitação por IP ou de conexões simultâneas configurado no servidor.

• Políticas de segurança, como software de segurança (Yunsuo ou SafeDog), WAF ou firewall no servidor, bloqueiam endereços IP de origin fetch do CDN.

• O servidor entrou em modo de manutenção ou está sendo implantado.

Etapas de solução de problemas:

1. Vincule o arquivo hosts para reproduzir o problema acessando o servidor diretamente: Modifique o arquivo hosts local para apontar o domínio acelerado para o IP do servidor de origem e acesse o domínio. Se o acesso direto também retornar 503, o problema está no servidor e o nó do CDN pode ser descartado.

2. Verifique se o service web no servidor está normal: Confirme se processos como NGINX, Apache ou IIS estão em execução e escutando na porta correspondente (80/443 ou personalizada). Se um processo estiver anormal ou parado, reinicie-o e verifique os logs para localizar a causa.

3. Verifique a carga e a configuração de limite de taxa do servidor: Alta carga de CPU, memória ou conexões, ou limites por IP (como os módulos limit_req ou limit_conn do NGINX), podem causar erro 503 no origin fetch. Avalie a necessidade de dimensionar recursos ou ajustar limites com base no volume de tráfego.

   Nota

   As solicitações de origin fetch do CDN chegam concentradas a partir de um conjunto limitado de IPs de nós e são facilmente confundidas com ataques de alta frequência quando o servidor limita por IP. Recomendamos definir um limite mais alto para as faixas de IPs de origin fetch do CDN ou isentá-las diretamente.

4. Verifique se políticas de segurança bloqueiam IPs de origin fetch do CDN: Grupos de segurança, firewalls, WAF ou softwares de segurança podem identificar IPs de origin fetch como tráfego anormal e bloqueá-los. Procure registros de IPs de nós do CDN nos logs de bloqueio e adicione as faixas de origin fetch à lista de permissões (para obtê-las, consulte What are the CDN origin fetch node IP addresses).

5. Atualize o cache do CDN: Se o erro 503 persistir após a recuperação do servidor, execute uma atualização de URL. Para códigos 500, 502, 503 e 504, a prioridade de cache do CDN é: não armazenar se o servidor retornar Set-Cookie → armazenar conforme o tempo de expiração configurado no console (se houver) → senão, armazenar conforme Pragma, Cache-Control e Expires do servidor → armazenar por 1 segundo por padrão. Portanto, por padrão, o erro 503 não causa impacto persistente. Porém, se um longo tempo de expiração para 5xx foi configurado no console, as respostas anormais continuam em cache até expirarem. Nesse caso, atualize manualmente ou defina o tempo de cache de 5xx como 0 (consulte Configure expiration for HTTP status codes).

Sintoma

Servidores de origem geralmente distinguem sites virtuais pelo cabeçalho Host. Se o host de origem configurado no CDN não corresponder ao domínio esperado pelo servidor, ele poderá retornar erros como 404, 403 ou 500.

Etapas de solução de problemas

1. Verifique se o host de origem corresponde à configuração de host virtual do servidor

   • NGINX: Verifique se server_name contém o domínio configurado como host de origem.

   • Apache: Verifique ServerName / ServerAlias em <VirtualHost>.

   • IIS: No IIS Manager, selecione o site de destino > Bindings e verifique se o campo "Host name" corresponde ao host de origem.

2. Atualize o cache do CDN

Após modificar o host de origem, execute uma atualização de URL para limpar respostas de erro que possam estar em cache.

Sintoma: O site retorna "Too many redirects" ou "ERR_TOO_MANY_REDIRECTS", ou recursos como imagens, CSS e JavaScript falham ao carregar.

Causa: O servidor de origem responde ativamente com um redirecionamento forçado de HTTP para HTTPS (comum em aaPanel, WAF e NGINX), mas o protocolo de origem do CDN está definido como HTTP. Isso cria um loop:

Cliente → CDN → CDN faz origin fetch via HTTP (porta 80) → Servidor retorna 301 para HTTPS → Se o seguimento de redirecionamento 301/302 não estiver configurado, o CDN retorna o 301 ao cliente → Navegador segue para HTTPS → Origin fetch via CDN sobre HTTP ocorre novamente → Servidor retorna outro 301 → ... o navegador redireciona repetidamente até reportar ERR_TOO_MANY_REDIRECTS. Se o seguimento de redirecionamento estiver ativado, os nós do CDN seguem os redirecionamentos repetidamente e retornam o 301 ao usuário após atingir o limite, o que também forma um loop. Para mais informações, consulte Configure 301/302 redirection.

Soluções (escolha uma):

• Solução A: Fazer o CDN usar HTTPS no origin fetch. Pré-requisito: o servidor deve ter certificado SSL válido e escutar na porta 443. Altere a porta de origem para 443 e o protocolo para HTTPS. Se o servidor escutar múltiplos domínios, defina também o SNI e o host de origem como o domínio acelerado ou o domínio de origem.

• Solução B: Desativar o redirecionamento forçado no servidor e manter HTTP. Faça logon no servidor e desative a regra de redirecionamento forçado. Mantenha o protocolo do CDN como HTTP e a porta como 80. A conexão entre clientes e CDN ainda pode usar HTTPS, desde que CDN e servidor concordem com o mesmo protocolo.

Operação adicional (recomendada em qualquer solução): Execute uma atualização de URL para limpar respostas de redirecionamento em cache e aplicar a nova configuração imediatamente. A distribuição da configuração para todos os nós leva alguns minutos. Durante esse período, alguns nós podem retornar a resposta antiga. Para políticas padrão de cache, consulte Configure expiration for HTTP status codes.

Esta entrada aplica-se apenas se o loop aparecer somente após configurar o host ou SNI de origem. Se o loop já existia antes, consulte a entrada anterior sobre redirecionamento forçado HTTP para HTTPS. A causa raiz continua sendo o servidor com redirecionamento forçado enquanto o CDN usa HTTP. Ao configurar o host ou SNI corretamente, o servidor identifica o site e aplica a regra de redirecionamento, iniciando o loop. Solucione assim:

• Desative o redirecionamento forçado de HTTPS no servidor: Acesse o console do servidor (ex: aaPanel), vá para configurações de HTTPS e desative "Force HTTPS" ou "HTTP to HTTPS redirect".

• Garanta consistência entre host e SNI de origem: Nas configurações de origem, defina ambos com o domínio correto (geralmente o domínio de origem) e mantenha-os iguais para atender às expectativas do servidor.

• Atualize o cache do CDN: Após ajustar a configuração, atualize o cache para limpar respostas de redirecionamento armazenadas.

Este erro indica que o bucket do OSS é privado e solicitações sem assinatura não podem ler objetos. Buckets privados exigem autenticação para evitar consumo indevido de tráfego. Não recomendamos tornar o bucket público apenas para resolver isso.

Solução: Ative o recurso Configure origin fetch from a private OSS bucket para o domínio acelerado. Assim, o CDN usa automaticamente a função AliyunCDNAccessingPrivateOSSRole para assinar o acesso ao bucket privado, sem exigir assinaturas dos usuários finais. Caminho: console do CDN > Domain Management > domínio alvo > Origin Settings > Origin fetch from private OSS buckets.

Se o bucket do OSS for criptografado com KMS, conceda permissões adicionais à função de origin fetch do CDN para usar a chave KMS. Sem isso, o CDN não descriptografa os arquivos e retorna This request is forbidden by kms..

Solução:

1. Faça logon no console do RAM. No painel esquerdo, escolha Identities > Roles.

2. Localize a função AliyunCDNAccessingPrivateOSSRole e clique em Grant Permission.

   Nota

   Se não encontrar a função, o origin fetch de buckets privados nunca foi ativado. Ative-o conforme descrito em Configure origin fetch from a private OSS bucket para criar a função automaticamente e retorne a esta etapa.

3. Em System Policy, pesquise e adicione AliyunKMSCryptoUserAccess e clique em Grant permissions.

4. Use o recurso Refresh and Prefetch e acesse o recurso novamente após a conclusão.

Isso ocorre quando três condições são atendidas: bucket privado, hospedagem de site estático ativada e Configure origin fetch from a private OSS bucket ativado. Ao acessar a raiz (ex: https://example.com/), recebe-se 403 com x-tengine-error: You are forbidden to list buckets.

Causa: Conflito entre o origin fetch de buckets privados e a página inicial padrão da hospedagem estática.

Soluções:

• Solução 1: Se não precisar da hospedagem estática, desative-a. Veja Static website hosting.

• Solução 2: Se precisar manter a hospedagem estática, configure reescrita de URI no CDN para evitar origin fetch na raiz: defina Path to Be Rewritten como ^/$, Target Path como /index.html e Flag como Redirect. Assim, o CDN retorna 302 para /index.html. Detalhes em Rewrite access URLs.

Sintoma: O servidor usa 302 para servir interfaces conforme o dispositivo. Com o CDN, a resposta 302 do primeiro usuário fica em cache. Outros dispositivos acessando a mesma URL recebem a página errada, quebrando a adaptação.

Solução A (recomendada): Não armazenar o 302 em cache. Configure o CDN para não cachear a URL inicial, mas sim a página pós-redirecionamento. Configure o servidor para não cachear a página inicial (no-cache tem alta prioridade). A página não será armazenada se contiver:

• Cache-control:no-cache, no-store

• Cache-control:max-age=0

• pragma:no-cache

• Cache-control:private

Solução B: Configurar o CDN para não cachear a URL inicial. Se não puder alterar cabeçalhos no servidor, combine regras de cache de diretórios e extensões no CDN para definir tempo 0 na URL de redirecionamento inicial.

Solução C: Usar chave de cache personalizada por dispositivo. Para manter o cache, configure uma chave que inclua o tipo de dispositivo, separando caches de PC e mobile. Veja Custom cache key.

Possível causa: o servidor depende de parâmetros de URL ou cabeçalho Host específico, e o comportamento padrão do CDN pode perder parâmetros ou alterar o Host. Solucione assim:

1. Verifique parâmetros de URL nas regras de cache: Se o servidor usa parâmetros para lógica/redirecionamento, atente-se ao "Ignore Parameters". Ele afeta apenas a chave de cache. O origin fetch ainda leva os parâmetros completos. O problema não é "servidor não processa por falta de parâmetro", mas "requisições diferentes batem no mesmo cache". Desative Ignore Parameters ou retenha parâmetros críticos (veja Ignore parameters).

2. Defina o host de origem como o domínio esperado pelo servidor: Garante identificação correta do Host e processamento da lógica.

3. Execute atualização de diretório ou URL: Aplique a nova configuração executando uma tarefa de atualização.

Sintoma: Downloads param, retomada falha ou busca em vídeo dá erro/reinicia.

Causa: Com origin fetch Range ativado, o CDN envia solicitações com cabeçalho Range. Se o servidor não suportar Range (ignora o cabeçalho e retorna 200 completo) ou retornar Content-Range incompatível, ocorrem falhas.

Etapas de solução:

1. Verifique suporte a Range: Execute curl -I -H "Range: bytes=0-1023" http(s)://origin-domain/resource-path. Se retornar 206 Partial Content com Content-Range correto, suporta Range. Se retornar 200 OK completo, ignora Range.

2. Ajuste a configuração conforme o suporte do servidor: Se não suportar, modifique o servidor para responder 206 ou desative o origin fetch Range no CDN. Caminho: console do CDN > Domain Management > domínio > Video Settings > Range Origin Fetch. Desativado por padrão. Veja Configure range origin fetch.

3. Verifique estabilidade dos cabeçalhos: O origin fetch Range exige Content-Length, ETag e Last-Modified estáveis. Conteúdo dinâmico sem esses cabeçalhos torna o Range não confiável.

4. Verifique limpeza de fatias em cache: Se o servidor retornar status não-206, o CDN exclui fatias em cache. Respostas 5xx intermitentes limpam fatias repetidamente, causando interrupções e alto tráfego. Veja Configure expiration for HTTP status codes.

Sintoma

Página corrompida via CDN ou falha de decodificação no navegador (ERR_CONTENT_DECODING_FAILED).

Causa

• Servidor retornou conteúdo compactado (gzip/br) sem Content-Encoding. O CDN compacta novamente, causando erro.

• Content-Encoding declarado não corresponde à codificação real.

Etapas de solução

1. Compare cabeçalhos do servidor e do CDN

# Direct access to the origin server
curl -I -H "Accept-Encoding: gzip" https://<origin-domain>/<resource-path>

# Access through CDN
curl -I -H "Accept-Encoding: gzip" https://<accelerated-domain>/<resource-path>

Verifique consistência de Content-Encoding, Content-Length e Content-Type.

2. Verifique a compressão inteligente do CDN

Se o servidor já retorna conteúdo compactado (com Content-Encoding: gzip), o CDN não deve compactar novamente. Se houver compressão dupla, verifique a "Intelligent Compression" no console ou desative a compressão no CDN.

3. Corrija os cabeçalhos do servidor

Garanta que o servidor sempre defina Content-Encoding correto ao retornar conteúdo compactado.

Sintoma

Usuários recebem sessões de outros (login trocado) ou login expira imediatamente.

Causa

Servidor retorna Set-Cookie em página dinâmica. Se o CDN cachear essa resposta, outros usuários recebem Cookies alheios.

Solução

1. Configure o servidor para não cachear respostas com Set-Cookie

Adicione Cache-Control: no-store ou Cache-Control: private em páginas dinâmicas.

2. Configure regras de cache no CDN

No console do CDN, crie regra "Do Not Cache" para páginas dinâmicas (ex: .php, .jsp, /api/) para forçar origin fetch.

3. Use Modify Inbound Response Headers para remover o cabeçalho

Se Set-Cookie for irrelevante para cache (ex: tracking), use Modify Inbound Response Headers no CDN para removê-lo antes de cachear. Garanta que isso não afete a lógica de negócios.