Todos os produtos
Search

Este produto

    Edge Security Acceleration:Elegibilidade de cache

    Central de documentação

    Edge Security Acceleration:Elegibilidade de cache

    Última atualização: Sep 15, 2026

    Para ignorar o cache do Edge Security Acceleration (ESA) em recursos correspondentes à default cache rule, crie uma regra para filtrar solicitações e defina a Cache Eligibility como Bypass Cache.

    Nota

    Se nenhuma regra ou configuração de cache estiver definida, o armazenamento em cache nos pontos de presença (POPs) do ESA segue a default cache rule.

    Cenários

    Caso seu servidor de origem possua recursos que não devam ser armazenados em cache nos POPs do ESA, como conteúdos dinâmicos que exigem a busca da versão mais recente na origem a cada solicitação, configure uma regra de bypass de cache para esses itens. Ignorar o cache para recursos dinâmicos melhora o desempenho de acesso.

    As regras de elegibilidade de cache determinam se os nós de borda do ESA armazenarão uma solicitação. Os casos de uso mais comuns incluem:

    • Cache de recursos estáticos — Melhore o desempenho armazenando imagens, CSS e arquivos JavaScript nos nós de borda.

    • Bypass de conteúdo dinâmico — Garanta que páginas de login, APIs e conteúdos personalizados não sejam armazenados em cache.

    • Separação entre dinâmico e estático — Armazene ativos estáticos em cache enquanto encaminha solicitações dinâmicas diretamente ao servidor de origem.

    • No-cache seletivo — Impeça o armazenamento em cache de arquivos ou caminhos específicos.

    Procedimento

    1. No console do ESA, escolha Websites. Na coluna Website, clique no site desejado.

    2. No painel de navegação à esquerda, escolha Rules > Cache Rules.

    3. Clique em Create Rule e insira um Rule Name.

    4. Na seção If requests match..., defina os atributos de correspondência da solicitação. Para mais informações sobre como configurar regras, consulte Composition of a rule expression.

    5. Na área de Cache Eligibility , selecione uma política de cache e clique em OK.

      image

      • Bypass Cache: Todas as solicitações ignoram o cache do POP e buscam dados diretamente na origem, permitindo visualizar os recursos mais recentes do servidor de origem em tempo real. Quando ativado, apenas a configuração de Browser Cache TTL é aplicada.

      • Eligible for Cache: Todas as solicitações elegíveis são atendidas pelos nós de cache do POP em vez da origem. Isso evita longos caminhos de busca na origem, reduz a latência e melhora o desempenho de acesso.

    Opções e limitações da elegibilidade de cache

    Bypass Cache

    Quando a opção Bypass Cache está selecionada:

    • O ESA encaminha as solicitações correspondentes diretamente ao servidor de origem sem armazená-las nos nós de borda.

    • Apenas a configuração Browser Cache TTL entra em vigor. Outros recursos relacionados a cache (como Cache Deception Defense e Serve Stale Content) ficam desativados para esta regra.

    • O ESA não suporta a configuração de comportamento no-cache baseada em cabeçalhos de resposta HTTP (como X-Fallback) ou marcadores de comentários HTML. Utilize condições de correspondência baseadas em cabeçalhos de solicitação ou URL.

    Comportamento padrão de cache

    Quando nenhuma regra de cache está configurada, ou quando nenhuma regra corresponde a uma solicitação, o ESA aplica o seguinte comportamento padrão:

    • As solicitações seguem a política de cache padrão do ESA.

    • Solicitações dinâmicas com URLs terminadas em / são encaminhadas ao servidor de origem por padrão.

    • Quando o servidor de origem retorna um cabeçalho de resposta no-cache, a resposta não é armazenada em cache.

    Recursos avançados de cache

    Os seguintes recursos vêm desativados por padrão e devem ser habilitados manualmente em uma regra de cache:

    • Cache Deception Defense: Protege contra ataques de enganação de cache.

    • Serve Stale Content: Permite que o ESA entregue conteúdo obsoleto do cache quando a origem estiver temporariamente indisponível.

    Exemplos comuns de configuração

    Os exemplos abaixo abrangem cenários frequentes para configuração de elegibilidade de cache.

    Exemplo 1: Ignorar cache para APIs dinâmicas

    Cenário: Impedir que endpoints de API dinâmicos sejam armazenados em cache nos nós de borda.

    Configuração:

    • Condição de correspondência: Caminho da URL contém /api, OU caminho da URL contém /prod-api/, OU extensão de arquivo é igual a php

    • Elegibilidade de cache: Bypass Cache

    Nota

    Ao especificar extensões de arquivo, não inclua o ponto. Insira php, e não .php.

    Exemplo 2: Ignorar cache para páginas administrativas e de login

    Cenário: Evitar que páginas de administração do WordPress, interfaces de gerenciamento de CMS ou endpoints de login sejam armazenados em cache.

    Configuração:

    • Condição de correspondência: Caminho da URL contém /wp-admin, OU caminho da URL contém /admin, OU caminho da URL contém /login

    • Elegibilidade de cache: Bypass Cache

    Importante

    Posicione esta regra no topo da lista para garantir que ela tenha prioridade sobre as regras gerais de cache de recursos estáticos.

    Exemplo 3: Armazenar em cache o caminho raiz de SPA

    Cenário: O ESA não armazena em cache URLs sem extensão (como /) por padrão. Para armazenar conteúdo text/html de aplicações de página única (SPAs):

    Configuração:

    • Condição de correspondência: Cabeçalho da solicitação Accept contém text/html

    • Elegibilidade de cache: Eligible for Cache

    • TTL de cache: Defina conforme a frequência de atualização da sua SPA.

    Exemplo 4: Ignorar cache para arquivos específicos

    Cenário: Impedir que arquivos específicos, como sitemap.xml, sejam armazenados em cache.

    Configuração:

    • Condição de correspondência: Caminho da URL contém sitemap (sem extensão de arquivo), OU extensão de arquivo é igual a xml (insira xml, e não .xml)

    • Elegibilidade de cache: Bypass Cache

    Exemplo 5: Separação entre dinâmico e estático

    Cenário: Armazenar ativos estáticos em cache garantindo que solicitações dinâmicas sejam encaminhadas à origem.

    Abordagem recomendada:

    1. Exclua quaisquer regras de cache de site completo existentes.

    2. Crie uma regra para armazenar recursos estáticos em cache. Por exemplo, configure a condição onde a extensão de arquivo é igual a uma das opções: jpg, png, css ou js.

    3. Crie uma regra separada para ignorar o cache em endpoints de API dinâmicos. Por exemplo, configure a condição onde o caminho da URL contém /api.

    Essa abordagem evita que solicitações dinâmicas sejam acidentalmente armazenadas em cache.

    Observações sobre configuração

    • Um TTL de cache por regra — Uma única regra de cache pode definir apenas um TTL. Se diferentes extensões de arquivo ou diretórios exigirem durações distintas, crie uma regra separada para cada caso.

    • Independência das regras — Desativar ou excluir uma regra específica não afeta o comportamento de cache dos demais recursos. O ESA continua avaliando as regras restantes em ordem.

    • Redução da carga na origem — Configure regras de bypass para conteúdo dinâmico e ative regras de cache para recursos estáticos, minimizando assim as solicitações encaminhadas ao servidor de origem.

    • Prioridade de aplicação de submódulos — No recurso @xref node="4727152" Cache Rules @/xref, a prioridade de aplicação dos submódulos, da maior para a menor, é: POST Cache > Bypass Cache > Outros submódulos. Quando o POST Cache está ativado, as solicitações passam pelo fluxo de trabalho de cache de recursos estáticos, tornando o recurso Bypass Cache ineficaz.

    Perguntas frequentes

    Por que minha regra de bypass de cache não está funcionando?

    Verifique os seguintes pontos:

    1. Condição de correspondência incorreta: Valide a expressão da regra. Erros comuns incluem:

      • Uma condição OR que acaba correspondendo involuntariamente a solicitações de outros domínios.

      • Valores de extensão de arquivo ou caminho formatados incorretamente. Por exemplo, usar .php em vez de php.

    2. Características da solicitação ausentes: Se a regra depender de um cabeçalho específico (como sec-fetch-site), confirme se as solicitações reais do cliente incluem esse cabeçalho.

    3. Prioridade insuficiente da regra: O ESA avalia as regras de cima para baixo. Se a regra de bypass estiver posicionada abaixo de uma regra de cache com TTL longo, a regra anterior poderá corresponder primeiro. Mova a regra de bypass para uma posição superior na lista.

    4. Cache não limpo após alteração da regra: Após modificar regras, limpe as URLs ou diretórios afetados no console do ESA. Atualizar o navegador não invalida o conteúdo armazenado nos nós de borda.

    5. Limitações do plano: A Edição Gratuita pode não garantir a aplicação consistente das regras. Considere atualizar para um plano pago.

    6. Método de verificação: Verifique o cabeçalho de resposta Server para confirmar se as solicitações estão sendo processadas pelos nós de borda do ESA. Use uma janela anônima do navegador para eliminar interferências do cache local.

    Por que não consigo fazer login ou por que as páginas redirecionam incorretamente após ativar o ESA?

    Causa: Isso geralmente ocorre quando uma regra de cache de site completo ou uma regra mal configurada faz com que cookies de login, dados de sessão ou respostas de API dinâmicas sejam armazenados em cache nos nós de borda do ESA.

    Resolução:

    1. Suspenda ou exclua quaisquer regras suspeitas de cache de site completo.

    2. Crie regras de Bypass Cache especificamente para páginas de login, endpoints de CAPTCHA e caminhos administrativos. Posicione essas regras no topo da lista para conceder-lhes a maior prioridade.

    3. No console do ESA, limpe o cache das URLs afetadas.

    4. Verifique a correção utilizando uma janela anônima do navegador.

    Se o problema persistir mesmo com a configuração correta: Verifique a lógica de negócios do seu servidor de origem. Por exemplo, confirme se a lógica de redirecionamento 302 identifica corretamente o estado de login. Caso o servidor de origem não esteja lidando adequadamente com o estado de autenticação, isso foge ao escopo do ESA.

    Qual a diferença entre "equals" e "contains" nas condições de correspondência?

    Tipo de correspondência

    Comportamento

    Equals

    Correspondência exata do caminho de URL especificado. Também corresponde automaticamente a todos os subcaminhos. Por exemplo, configurar /test/_nuxt/ com Equals também corresponde a recursos sob /test/_nuxt/chunk-abc.js.

    Contains

    Correspondência parcial. Qualquer URL que inclua a string especificada em qualquer posição será correspondida.

    Para correspondência de hostname, tanto Equals quanto Contains produzem resultados equivalentes e podem ser usados indistintamente.

    Por que ativar regras de cache faz o probing funcionar, mas desativá-las causa timeouts?

    Quando as regras de cache estão ativas, os nós de borda do ESA atendem às solicitações diretamente do cache, reduzindo a carga no servidor de origem.

    Ao desativar as regras de cache, todas as solicitações — incluindo volumes altos de requisições dinâmicas — vão diretamente ao servidor de origem em tempo real. Sob testes de carga de alta concorrência, isso pode sobrecarregar o servidor de origem e causar timeouts nas solicitações.

    Esse comportamento reflete um gargalo de desempenho no servidor de origem, e não um problema do ESA. Para resolver isso:

    • Configure regras de cache para reduzir o volume de solicitações encaminhadas à origem.

    • Ative o JS Challenge ou o Intelligent Rate Limiting para proteger o servidor de origem contra excesso de solicitações simultâneas.

    Documentação relacionada

    Os recursos relacionados a regras variam em prioridade efetiva, reentrância e granularidade de aplicação. Para detalhes, consulte Characteristics of rule-based features.