CDN:Guia de solução de problemas de otimização de desempenho

Problemas de desempenho sofrem influência de diversos fatores. Antes de iniciar a solução de problemas, confirme se a requisição realmente passa pela CDN e estabeleça grupos de controle para restringir a causa raiz.

Colete o efeito de acesso

Uma solução de problemas reprodutível deve registrar pelo menos as seguintes informações:

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

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

• Resultado DNS, IP do nó realmente conectado;

• 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;

• DNS, TCP, TLS, TTFB, baixe e duração total;

• Resultados comparativos da mesma requisição para primeiro GET via CDN, GET repetido, GET em nó especificado 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>"

Qualidade de rede ruim entre cliente e nó ou anomalia de agendamento

Sintoma: ping para o domínio acelerado mostra alta latência ou perda de pacotes; usuários em uma região específica ou de um ISP específico estão lentos; usuários são direcionados 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 only", usuários no exterior são direcionados para nós na china continental; quando definida como "Global (excluding Mainland China)", usuários da china continental são direcionados 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").

• Domínio não concluiu o registro ICP: Domínios sem registro só podem selecionar "Global (excluding Mainland China)". Quando usuários da china continental acessam através de nós no exterior, o link é mais longo e a velocidade pode ser insatisfatória. Para fornecer aceleração a 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 acessando 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 direcionado para um nó nos EUA em vez de um nó próximo. Oriente o usuário a mudar 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 para confirmar o segmento específico do link onde ocorre a latência; teste vinculando o IP do nó que a requisição do usuário alcança para confirmar se o próprio nó responde normalmente, depois combine o status de acerto de cache e o tamanho do recurso para análise adicional.

Baixa taxa de acerto de cache ou recuperação frequente de origem causando acesso lento

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

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

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

• Tráfego baixo e popularidade de arquivo insuficiente: O cache do nó remove itens menos populares com base na popularidade; 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 pré-busca para manter a popularidade.

• Configuração de cache inadequada:

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

  • Sem regras de cache configuradas, a política de cache padrão é usada, com tempo máximo de cache não excedendo 3600 segundos, o que leva facilmente a expirações frequentes e recuperações 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 conteúdo não será armazenado 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 da CDN.

• URL carrega parâmetros variáveis: Quando URLs com parâmetros diferentes acessam o mesmo arquivo, a CDN as trata como recursos distintos e busca da origem separadamente. Ative o recurso de ignorar parâmetros; veja Ignore parameters.

• Arquivos grandes demoram para recuperar da origem: Para cenários de arquivos grandes, recomendamos ativar a recuperação de origem Range para otimizar a eficiência da recuperação; veja Configure range origin fetch.

• Atualização frequente de cache: Atualizações frequentes de cache de URL ou diretório fazem com que o cache do nó permaneça inválido e reduzem 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 hosts ao IP da origem e acesse diretamente, depois compare o tempo de carregamento com o acesso via CDN para verificar o efeito de aceleração e confirmar se o gargalo está na recuperação de origem ou no link de distribuição. Para mais estratégias de otimização de taxa de acerto, veja 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 geral carrega lentamente.

Causa: A CDN não consegue armazenar em cache conteúdo dinâmico que muda em tempo real. Requisições dinâmicas são encaminhadas ao servidor de origem todas as vezes, portanto a aceleração de cache da CDN não tem efeito sobre elas. Se a própria origem for lenta, as requisições dinâmicas ficarão lentas sincronizadamente.

Solução:

• Separe conteúdo estático e dinâmico na origem: use um domínio acelerado por 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 através de otimização de rota, otimização de transporte e outras tecnologias para encurtar a cadeia de origem. Note que a aceleração dinâmica é uma otimização de link; se o servidor de origem em si for lento, a origem ainda precisará ser otimizada.

Recuperação de origem entre países ou fronteiras é lenta

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

Causa: A recuperação de origem transfronteiriça sofre impacto da capacidade de cabos submarinos e congestionamento da rede pública entre países.

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

Home page do site carrega lentamente

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

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

Solução: Primeiro confirme através dos cabeçalhos de resposta se a home page atingiu o cache (veja Como identificar a direção de problemas de acesso lento); se houver falha, solucione problemas de configuração de cache conforme Baixa taxa de acerto de cache ou recuperação frequente de origem causando acesso lento; se a resposta da origem for lenta, otimize o desempenho da origem ou adote separação estática/dinâmica.

Recursos grandes carregam lentamente

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

Solução: Ative recursos de otimização de desempenho (compressão inteligente, otimização de página, etc.) para reduzir o tamanho dos arquivos e melhorar a velocidade de carregamento; veja Performance optimization. A compressã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.

Compressão Gzip não funciona após recuperação de origem

Sintoma: A origem (como Nginx) tem compressã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 de requisição contendo Accept-Encoding: gzip, deflate, o cabeçalho de resposta retorna apenas Content-Length, e o conteúdo não está comprimido.

Causa: As requisições de recuperação de origem da CDN carregam o cabeçalho de requisição Via para identificar 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 compressão está ativada para requisições de proxy. O valor padrão dessa configuração é off, então requisições de recuperação de origem da CDN não retornam conteúdo comprimido.

Solução:

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

2. Execute nginx -t para confirmar que a configuração está correta, depois execute nginx -s reload para recarregar a configuração.

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

Método de verificação: Use 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 é a mesma quando a compressão Brotli não funciona — confirme se a origem recusa retornar conteúdo comprimido para requisições de proxy devido ao cabeçalho de requisição Via ou configuração similar a gzip_proxied, e substitua a configuração relacionada a Gzip pela configuração Brotli correspondente.

Compensação com otimização de página: Se você também ativar a otimização de página, note que a compressão na origem e a otimização de página são mutuamente exclusivas; a CDN não consegue realizar otimização de página após a origem retornar conteúdo comprimido. Escolha entre compressão na origem (economizando largura de banda da origem) e otimização de página (reduzindo tamanho do HTML) com base na prioridade do negócio.

Otimização de página não funciona quando ambas otimização de página e compressão Gzip estão ativadas

Sintoma: A otimização de página está ativada. Quando curl é enviado sem o cabeçalho de requisição Accept-Encoding, o HTML retornado é otimizado; mas quando acessado de um navegador (que envia Accept-Encoding: gzip por padrão), o conteúdo retornado não tem otimização de página.

Causa:

• Origem retorna conteúdo comprimido com Gzip: Navegadores carregam o cabeçalho de requisição Accept-Encoding: gzip por padrão, e a CDN encaminha esse cabeçalho ao recuperar da origem. Quando a origem tem Gzip ativado, ela retorna conteúdo comprimido. Os nós CDN não descomprimem conteúdo já comprimido pela origem antes de realizar a otimização de página, logo a otimização não pode ter efeito quando a origem retorna conteúdo comprimido.

• Compressão inteligente da CDN não bloqueia otimização de página: A compressão inteligente da CDN executa 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 comprimido — a pré-compressão na origem impede a CDN de realizar otimização de página, e não tem relação com a compressão inteligente do lado da CDN.

Solução:

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

• Opção 2: Na configuração da CDN, remova Accept-Encoding do cabeçalho de requisição HTTP de origem para que a origem retorne conteúdo não comprimido e a CDN realize a otimização de página.

Nota: Após a origem parar de retornar conteúdo comprimido, a CDN pode comprimir a resposta ao cliente através do recurso de compressão inteligente, alcançando tanto otimização de página quanto compressão de transmissão.

Exceções de negócio após ativar ignorar parâmetros

Sintoma: Após ativar ignorar parâmetros, a autenticação falha, dados de usuário são misturados, conteúdo em cache errado é retornado ou o processamento de imagem torna-se inválido.

Causa: Depois que ignorar parâmetros é ativado, a 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 identidade do usuário (como UID, Token, Session ID): ignorá-los causa falha na autenticação ou mistura de dados de usuário.

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

• Diretivas de processamento da origem (como parâmetro de processamento de imagem 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 solução:

1. Exclua ou desative a configuração de ignorar parâmetros.

2. Realize atualização de cache (atualização de URL ou diretório) para limpar 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, veja Ignore parameters.

Configuração de ignorar parâmetros não efetiva após modificação

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

Causa: Após a modificação da configuração, 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 CDN, reabra a página de configuração de ignorar parâmetros e confirme se a configuração atual corresponde ao estado esperado.

2. Verifique conflito com Cache Key personalizada: A Cache Key personalizada substitui a configuração de ignorar parâmetros. Se a Cache Key personalizada estiver ativada, a configuração de ignorar parâmetros não terá efeito. Confirme se ambas não estão ativadas simultaneamente.

3. Realize atualização de cache: Na página Purge and prefetch resources, execute atualização de URL ou diretório. A nova configuração só terá 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 no processamento de imagem OSS ou captura de quadro de vídeo

Sintoma: Ao usar processamento de imagem OSS (como x-oss-process=image/resize,w_200) ou captura de quadro de vídeo, o acesso 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: Após ativar ignorar parâmetros para o domínio CDN, o link da imagem original e o link com parâmetros de processamento são armazenados em cache como o mesmo recurso, causando conteúdo incorreto.

Solução: Na configuração de ignorar parâmetros do console CDN, defina o parâmetro x-oss-process para o modo reter parâmetros especificados, para que 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 (veja Configuração de ignorar parâmetros não efetiva após modificação).

Status de acerto de cache inconsistente após ativar ignorar parâmetros

Sintoma: Ignorar parâmetros está ativado, mas o status de acerto de cache é inconsistente entre clientes; algumas requisições mostram X-Cache MISS.

Possíveis causas:

1. 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, então a CDN ainda as reconhece como recursos diferentes.

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

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

4. Conflito com Cache Key personalizada: A Cache Key personalizada substitui a configuração de ignorar parâmetros; quando ambas estão ativadas, ignorar parâmetros não tem 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 configuração de ignorar parâmetros está correta (ativada e parâmetros chave retidos), garanta estratégia consistente de cabeçalho de requisição do cliente e confirme que a Cache Key personalizada não está ativada simultaneamente.