CDN:Performance optimization troubleshooting guide

Diversos fatores afetam o desempenho. Antes de iniciar a solução de problemas, confirme se a requisição realmente passa pelo CDN e estabeleça grupos de controle para restringir a causa raiz.

Colete as métricas de acesso

Uma solução de problemas reproduzível deve, no mínimo, registrar as seguintes informações:

• Hora UTC, região e ISP do cliente, IP do cliente mascarado <CLIENT_IP>, LocalDNS;

• URL da requisição, método da requisição, código de status, cadeia de redirecionamento;

• Resultado do DNS, IP do nó de conexão real;

• X-Cache, X-Swift-CacheTime, Age (se presente), Via;

• Cache-Control, Pragma, Expires, ETag, Last-Modified, Vary;

• Content-Type, Content-Length, Content-Encoding, Accept-Ranges, Content-Range;

• Durações de DNS, TCP, TLS, TTFB, download e total;

• Resultados da comparação da mesma requisição para: primeiro GET no CDN, GET repetido, GET em nó específico e GET direto na origem.

curl -sS -D /tmp/cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntime_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\nsize_download=%{size_download}\n' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<CDN_NODE_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<ORIGIN_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' \
  "https://<CDN_DOMAIN>/<LARGE_RESOURCE_PATH>"

curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"
curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

Má qualidade de rede entre cliente e nó ou anomalia de agendamento

Sintoma: o ping para o domínio acelerado mostra alta latência ou perda de pacotes; usuários em uma região ou ISP específico enfrentam lentidão; o agendamento direciona os usuários para nós distantes.

Possíveis causas e solução de problemas:

• Configuração incorreta da região de aceleração: Quando a região de aceleração está definida como "Mainland China", o sistema direciona usuários no exterior para nós da China Continental; quando definida como "Global (excluding Mainland China)", o sistema direciona usuários da China Continental para nós no exterior. Defina a região de aceleração para o escopo correto com base na distribuição dos usuários (por exemplo, "Global").

• O domínio não concluiu o registro ICP: Domínios sem registro: selecione a opção "Global (excluding Mainland China)". Quando usuários da China Continental acessam por meio de nós no exterior, a rota é mais longa e a velocidade pode ser insatisfatória. Para fornecer aceleração para usuários da China Continental, conclua o registro ICP primeiro; se o registro não for possível, considere usar Edge Security Acceleration (ESA) para reduzir a latência de usuários da China Continental que acessam sites no exterior.

• Configurações de DNS do cliente incorretas: Por exemplo, um usuário em Tóquio usando um DNS dos EUA pode ser roteado para um nó nos EUA em vez de um nó próximo. Oriente o usuário a alterar para um DNS correspondente à sua localização e ISP.

• Flutuação na rede do ISP regional: Quando a região de aceleração e o DNS estão corretos, mas o acesso continua lento, colete informações de traceroute e MTR. Isso ajuda a confirmar o trecho específico da rota onde ocorre a latência. Faça testes vinculando o IP do nó que a requisição do usuário alcança para confirmar se o próprio nó responde normalmente. Em seguida, correlacione o status de acerto de cache e o tamanho do recurso para uma análise mais aprofundada.

Baixa taxa de acerto de cache ou busca frequente na origem causando acesso lento

Sintoma: o cabeçalho de resposta X-Cache é MISS, X-Swift-CacheTime é 0; alta carga e alto tráfego na origem; o primeiro acesso é mais lento do que acessar a origem diretamente.

Causas comuns e soluções de otimização:

• O primeiro acesso não tem cache: O nó precisa buscar dados na origem na primeira resposta. Recomendamos usar o recurso de pré-busca de URL para buscar proativamente o conteúdo da origem para os nós do CDN; consulte Purge and prefetch resources.

• Tráfego baixo e popularidade do arquivo insuficiente: O cache do nó evicta os itens menos acessados; recursos com pouco tráfego são removidos mais cedo. Em cenários de baixo tráfego, estenda adequadamente o tempo de cache ou use a pré-busca para manter a popularidade.

• Configuração de cache inadequada:

  • Quando nenhuma regra de cache está configurada e os arquivos estáticos não retornam os cabeçalhos de resposta ETag e Last-Modified, o CDN não armazena o arquivo em cache. Adicione esses dois cabeçalhos de resposta na origem ou configure regras de cache no lado do CDN; consulte Configure CDN cache expiration.

  • Quando nenhuma regra de cache está configurada, o CDN usa a política de cache padrão, com um tempo máximo de cache não superior a 3600 segundos, o que causa expirações frequentes e buscas na origem. Defina um tempo de cache razoável com base no seu negócio.

  • Quando o cabeçalho de resposta da origem contém qualquer um entre s-maxage=0, max-age=0, no-cache, no-store, private ou Pragma: no-cache, o CDN não armazena o conteúdo em cache mesmo que regras de cache estejam configuradas. Modifique o cabeçalho de resposta da origem para um valor armazenável em cache (como public) ou ative Ignore Origin No-Cache Header na regra de cache do CDN.

• A URL carrega parâmetros variáveis: Quando URLs com parâmetros diferentes acessam o mesmo arquivo, o CDN os trata como recursos diferentes e faz buscas separadas na origem. Ative o recurso de ignorar parâmetros; consulte Ignore parameters.

• A busca de arquivos grandes na origem é lenta: Para cenários de arquivos grandes, recomendamos ativar a busca na origem com Range para otimizar a eficiência da busca; consulte Configure range origin fetch.

• Atualização frequente de cache: A atualização frequente de cache de URL ou diretório invalida continuamente o cache do nó e reduz a taxa de acerto. Atualize apenas os recursos afetados quando o conteúdo for modificado.

Método de verificação: Vincule o domínio do usuário no arquivo hosts ao IP de origem e acesse diretamente. Em seguida, compare o tempo de carregamento com o acesso via CDN para verificar o efeito de aceleração e confirmar se o gargalo está na busca na origem ou na rede de distribuição. Para mais estratégias de otimização da taxa de acerto, consulte Cache troubleshooting.

Requisições dinâmicas lentas

Sintoma: Conteúdo dinâmico, como interfaces de API, está lento; recursos estáticos são rápidos, mas a página como um todo carrega lentamente.

Causa: O CDN não consegue armazenar em cache conteúdo dinâmico que muda em tempo real. O CDN encaminha requisições dinâmicas para o servidor de origem todas as vezes, então a aceleração de cache do CDN não tem efeito sobre elas. Se a própria origem for lenta, as requisições dinâmicas também sofrerão lentidão.

Solução:

• Separe o conteúdo estático e dinâmico na origem: use um domínio acelerado pelo CDN para recursos estáticos e um domínio que resolva diretamente para a origem para requisições dinâmicas.

• Use Edge Security Acceleration (ESA) para acelerar requisições dinâmicas por meio de otimização de rota, otimização de transporte e outras tecnologias para encurtar a rota até a origem. Note que a aceleração dinâmica é uma otimização de enlace; se o próprio servidor de origem for lento, a origem ainda exige otimização.

Busca na origem entre países ou regiões é lenta

Sintoma: Quando a origem e os usuários principais estão em países ou regiões diferentes, a qualidade da busca na origem flutua, a busca na origem apresenta lentidão e alta taxa de falhas, afetando o cache e a distribuição de conteúdo.

Causa: A busca na origem transfronteiriça é afetada pela capacidade dos cabos submarinos e pelo congestionamento da rede pública entre países.

Solução: Use o Global Accelerator (GA) para fornecer aceleração direcionada para a origem no país correspondente e configure políticas de busca na origem específicas por região do CDN para melhorar a qualidade da busca em caso de cache miss. O GA suporta tipos de origem como ECS, ALB e OSS, e fornece soluções como Accelerate back-to-origin with GA and CDN.

A home do site carrega lentamente

Sintoma: A requisição da home permanece como Pending na aba Network por muito tempo; após o retorno da home, os recursos estáticos carregam rapidamente.

Causa: A home geralmente é um recurso dinâmico ou configurado como não armazenável em cache, fazendo com que cada visita retorne à origem. Quando a resposta da origem é lenta, a requisição da home fica bloqueada, e recursos subsequentes, como imagens, JS e CSS referenciados pelo HTML da home, não podem começar a carregar.

Solução: Primeiro, confirme por meio dos cabeçalhos de resposta se a home acerta o cache; em caso de miss, solucione problemas de configuração de cache de acordo com Baixa taxa de acerto de cache ou busca frequente na origem causando acesso lento; se a resposta da origem for lenta, otimize o desempenho da origem ou adote a separação de estático/dinâmico.

Recursos grandes carregam lentamente

Sintoma: Content Download representa uma grande proporção do Timing; os recursos da página têm um tamanho total elevado.

Solução: Ative os recursos de otimização de desempenho (compactação inteligente, otimização de página, etc.) para reduzir o tamanho do arquivo e melhorar a velocidade de carregamento; consulte Performance optimization. A compactação inteligente suporta os seguintes formatos: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, text/javascript, image/tiff, image/svg+xml, application/json, application/xml. Para testar, baixe o recurso diretamente.

Compactação Gzip não funciona após busca na origem

Sintoma: A origem (como o Nginx) tem a compactação Gzip ativada, e o cabeçalho de resposta retorna Content-Encoding: gzip quando o cliente acessa a origem diretamente; ao acessar via CDN com o cabeçalho da requisição incluindo Accept-Encoding: gzip, deflate, o cabeçalho de resposta retorna apenas Content-Length e o conteúdo permanece descompactado.

Causa: As requisições de busca na origem do CDN incluem o cabeçalho de requisição Via para indicar que a requisição vem de um servidor proxy. O módulo ngx_http_gzip_module do Nginx usa a configuração gzip_proxied para controlar se a compactação está ativada para requisições de proxy. O valor padrão dessa configuração é off, fazendo com que as requisições de busca na origem do CDN não retornem conteúdo compactado.

Solução:

1. Defina gzip_proxied any no arquivo de configuração do Nginx (bloco http, server ou location, o que for aplicável) para compactar todas as requisições de servidores proxy.

2. Execute nginx -t para confirmar se a configuração está correta e, em seguida, execute nginx -s reload para recarregar a configuração.

3. Acesse via CDN e confirme se o cabeçalho de resposta contém Content-Encoding: gzip.

Método de verificação: Use o curl para testar diretamente na origem — quando nenhum cabeçalho Via é enviado, ele retorna Content-Encoding: gzip; após adicionar -H 'Via:xxx' para simular uma requisição de proxy, ele retorna apenas Content-Length. Isso confirma que o problema é causado pela configuração gzip_proxied.

Nota: A abordagem de solução de problemas segue a mesma lógica quando a compactação Brotli não funciona — confirme se a origem se recusa a retornar conteúdo compactado para requisições de proxy devido ao cabeçalho de requisição Via ou configurações semelhantes ao gzip_proxied e substitua a configuração relacionada ao Gzip pela configuração Brotli correspondente.

Trade-off com a otimização de página: Se a otimização de página também estiver ativada, note que a compactação na origem e a otimização de página são mutuamente exclusivas; o CDN não consegue executar a otimização de página após a origem retornar conteúdo compactado. Escolha entre a compactação na origem (economizando largura de banda da origem) e a otimização de página (reduzindo o tamanho do HTML) com base na prioridade do negócio.

Otimização de página não funciona quando tanto a otimização de página quanto a compactação Gzip estão ativadas

Sintoma: A otimização de página está ativada. Ao usar o curl sem o cabeçalho de requisição Accept-Encoding, o HTML retornado é otimizado; porém, ao acessar a partir de um navegador (que envia Accept-Encoding: gzip por padrão), o conteúdo retornado não é otimizado.

Causa:

• A origem retorna conteúdo compactado com Gzip: Os navegadores incluem o cabeçalho de requisição Accept-Encoding: gzip por padrão, e o CDN encaminha esse cabeçalho ao buscar na origem. Quando a origem tem o Gzip ativado, ela retorna conteúdo compactado. Os nós do CDN não descompactam o conteúdo já compactado pela origem antes de executar a otimização de página, impedindo que a otimização de página surta efeito quando a origem retorna conteúdo compactado.

• A compactação inteligente do CDN não bloqueia a otimização de página: A compactação inteligente do CDN é executada após a otimização de página; as duas não entram em conflito. Este sintoma aparece apenas quando a origem já retornou conteúdo compactado — a pré-compactação na origem impede que o CDN execute a otimização de página e não tem relação com a compactação inteligente no lado do CDN.

Solução:

• Opção 1: Garanta que a origem não retorne conteúdo compactado com Gzip para requisições de busca na origem do CDN. Para origens Nginx, modifique o parâmetro gzip_proxied para impedir que requisições de servidores proxy retornem conteúdo compactado.

• Opção 2: Na configuração do CDN, remova o Accept-Encoding do cabeçalho de requisição HTTP da origem para forçar a origem a retornar conteúdo descompactado e o CDN execute a otimização de página.

Nota: Após a origem parar de retornar conteúdo compactado, o CDN poderá compactar a resposta para o cliente por meio do recurso de compactação inteligente, alcançando tanto a otimização de página quanto a compactação de transmissão.

Exceções de negócios após ativar a opção Ignorar Parâmetros

Sintoma: Após ativar a opção Ignorar Parâmetros, a autenticação falha, os dados do usuário são misturados, o CDN retorna conteúdo em cache incorreto ou o processamento de imagem se torna inválido.

Causa: Quando a opção Ignorar Parâmetros está ativada, o CDN trata requisições com parâmetros diferentes como o mesmo recurso para armazenamento em cache. Os seguintes tipos de parâmetros de URL não devem ser ignorados globalmente:

• Identificadores de usuário (como UID, Token, Session ID): ignorá-los causa falha na autenticação ou mistura de dados do usuário.

• Diferenciação de conteúdo dinâmico (como versão ?v=1, número da página ?page=2): ignorá-los faz o CDN retornar o conteúdo em cache errado.

• Diretivas de processamento da origem (como o parâmetro de processamento de imagem do OSS x-oss-process): ignorá-lo invalida o parâmetro de processamento e retorna o recurso original não processado.

Solução de problemas e correção:

1. exclua ou desative a opção Ignorar Parâmetros.

2. Atualize o cache (por URL ou diretório) para limpar o cache obsoleto nos nós de borda.

3. Se alguns parâmetros precisarem ser retidos, use o modo Reter Parâmetros Especificados e defina parâmetros-chave (como x-oss-process, token) como retidos. Para detalhes sobre o recurso de ignorar parâmetros, consulte Ignore parameters.

A opção Ignorar Parâmetros não surte efeito após modificação

Sintoma: Após modificar a opção Ignorar Parâmetros, o acesso continua anormal ou o tráfego de origem não diminuiu.

Causa: Após a modificação, os arquivos já armazenados em cache nos nós de borda não são atualizados automaticamente; o cache antigo ainda responde de acordo com a política antiga.

Etapas de solução de problemas:

1. Confirme se a configuração foi salva: Faça login no console do CDN, reabra a página da opção Ignorar Parâmetros e confirme se a configuração atual corresponde ao estado esperado.

2. Verifique se há conflito com a Cache Key personalizada: A Cache Key personalizada substitui a opção Ignorar Parâmetros. Se a Cache Key personalizada estiver ativada, a opção Ignorar Parâmetros não surtirá efeito. Confirme se ambas não estão ativadas ao mesmo tempo.

3. Execute a atualização de cache: Na página Purge and prefetch resources, execute a atualização de URL ou diretório. A nova configuração só surte efeito total após a limpeza do cache antigo.

4. Verifique o efeito da configuração: Execute curl -I "full URL" e verifique o cabeçalho de resposta X-Cache para confirmar se o status de acerto de cache atende às expectativas.

Conteúdo incorreto de processamento de imagem ou captura de quadro de vídeo do OSS

Sintoma: Ao usar o processamento de imagem do OSS (como x-oss-process=image/resize,w_200) ou captura de quadro de vídeo, o CDN retorna a imagem ou vídeo original não processado, ou requisições com parâmetros de processamento diferentes retornam o mesmo conteúdo.

Causa: Quando a opção Ignorar Parâmetros está ativada para o domínio do CDN, o CDN armazena o link da imagem original e o link com parâmetros de processamento em cache como o mesmo recurso, causando conteúdo incorreto.

Solução: Na opção Ignorar Parâmetros do console do CDN, defina o parâmetro x-oss-process para o modo Reter Parâmetros Especificados, para que as URLs com parâmetros de processamento de imagem sejam armazenadas em cache separadamente e não entrem em conflito com o cache da imagem original. Após modificar a configuração, atualize o cache (consulte A opção Ignorar Parâmetros não surte efeito após modificação).

Status de acerto de cache inconsistente após ativar a opção Ignorar Parâmetros

Sintoma: A opção Ignorar Parâmetros está ativada, mas o status de acerto de cache é inconsistente entre os clientes; algumas requisições mostram X-Cache MISS.

Possíveis causas:

1. A URL carrega parâmetros de autenticação dinâmica não ignorados: Por exemplo, a URL tem auth_key e outros parâmetros de autenticação definidos como retidos. Cada requisição tem um valor de autenticação diferente, fazendo com que o CDN ainda os reconheça como recursos diferentes.

2. O primeiro acesso não tem cache no nó: O recurso ainda não foi armazenado em cache naquele nó de borda, e o primeiro acesso inevitavelmente mostrará MISS.

3. Diferenças no cabeçalho de requisição do cliente: Por exemplo, diferentes Accept-Encoding podem acionar o cache de múltiplas cópias (versões Gzip e não-Gzip armazenadas separadamente). Se a origem retornar Vary: User-Agent, o CDN armazena requisições de UAs diferentes separadamente.

4. Conflito com a Cache Key personalizada: A Cache Key personalizada substitui a opção Ignorar Parâmetros; quando ambas estão ativadas, a opção Ignorar Parâmetros não surte efeito.

Método de solução de problemas: No cliente, execute curl -I "full URL" e compare os cabeçalhos de resposta X-Cache e X-Swift-CacheTime para confirmar o status do cache. Solução: Confirme se a opção Ignorar Parâmetros está correta (ativada e parâmetros-chave retidos), garanta uma estratégia consistente de cabeçalho de requisição do cliente e confirme se a Cache Key personalizada não está ativada ao mesmo tempo.