Todos os produtos
Search

Este produto

    Edge Security Acceleration:Request redirects

    Central de documentação

    Edge Security Acceleration:Request redirects

    Última atualização: Jun 29, 2026

    Se os caminhos dos recursos de source mudarem, mas as URLs das requisições permanecerem inalteradas, configure regras de redirecionamento nos POPs do Edge Security Acceleration (ESA) para encaminhar os clientes ao destino correto. Essa prática reduz as requisições de volta à origem e melhora o desempenho de acesso.

    Como funciona

    image

    O processo de redirecionamento:

    1. Um cliente solicita um recurso.

    2. O POP do ESA compara a requisição com as regras de redirecionamento. Em caso de correspondência, retorna um código de status de redirecionamento (por exemplo, 301 ou 302) com a URL de destino no cabeçalho de resposta Location.

    3. O cliente segue o cabeçalho Location e solicita o recurso na nova URL.

    Códigos de status e cenários

    Código de status

    Significado

    Tratamento de método

    Cenários comuns

    301

    Movido Permanentemente

    Requisições GET permanecem inalteradas. Outros métodos podem ser convertidos para GET.

    O recurso foi movido permanentemente para uma nova URL. Os mecanismos de busca atualizam seus índices.

    302

    Encontrado

    Requisições GET permanecem inalteradas. Outros métodos podem ser convertidos para GET.

    O recurso está temporariamente em uma URL diferente. Os mecanismos de busca mantêm o link original.

    303

    Ver Outro

    Requisições GET permanecem inalteradas. Outros métodos são forçados para GET e o corpo da requisição é descartado.

    Redirecionamento após PUT ou POST para evitar envios duplicados ao atualizar a página.

    307

    Redirecionamento Temporário

    O método e o corpo da requisição permanecem inalterados.

    Redirecionamento temporário. Prefira este código em vez do 302 quando seu site utilizar métodos diferentes de GET.

    308

    Redirecionamento Permanente

    O método e o corpo da requisição permanecem inalterados.

    Redirecionamento permanente que preserva o método HTTP e o corpo da requisição. Utilize para migrações de API ou refatoração de sites que exigem consistência de método.
    Importante

    Para redirecionar chamadas de API ou requisições que não sejam GET (como POST ou PUT) preservando o método e o corpo da requisição, utilize o código de status 307 (temporário) ou 308 (permanente). Os códigos de status 301 e 302 podem converter requisições não-GET em GET, resultando em perda de dados.

    Evite configurar redirecionamentos em caminhos de upload com alto tráfego (como /api/upload). Para esses caminhos, considere separá-los em um domínio dedicado ou interceptar as requisições via WAF para evitar tráfego anormal de volta à origem causado pelos redirecionamentos.

    Criar uma regra de redirecionamento

    O ESA avalia as regras em ordem de prioridade e aplica a primeira correspondência encontrada.

    1. No console do ESA, escolha Site Management. Na coluna Website, clique em Website no site desejado.

    2. No painel de navegação à esquerda, escolha Rules > Redirect Rules. Clique em Create Rule.

    3. Na página Add Redirect Rule, defina as configurações abaixo e clique em OK:

      • Insira um Rule Name.

      • Na seção If requests match..., defina as condições de correspondência da requisição. Para mais informações, consulte Componentes de uma expressão de regra.

      • URL Redirect:

        Single Redirect configuration

        Parâmetro

        Tipo

        Descrição

        Redirect Type

        Static

        Redireciona para uma URL fixa. Por exemplo, defina URL como https://test.example.com/image/1.jpg?test=123.

        Dynamic

        Construa a URL de destino dinamicamente com uma expressão. Por exemplo, para substituir o nome do host na URL da requisição mantendo o caminho original, defina Expression como concat("https://www.example.com", http.request.uri.path). Utilize uma expressão válida construída com funções suportadas. Inserir diretamente uma string simples contendo variáveis causará falha ao salvar.

        Padrões comuns de expressões dinâmicas:

        • Preservar o caminho original (de non-www para www, de HTTP para HTTPS) — Utilize concat("https://target-domain.com", http.request.uri.path) para concatenar o domínio de destino com o caminho da requisição original. Use este padrão quando precisar manter o caminho durante o redirecionamento.

        • Remover ou substituir um prefixo de caminho — Utilize concat("https://img.example.com", regex_replace(http.request.uri.path, "^/data", "")) para remover o prefixo /data do caminho original e redirecionar para o novo domínio. Combine regex_replace com concat para transformar o caminho.

        Status Code

        Código de status HTTP retornado para o redirecionamento. Valores válidos: 301 (padrão), 302, 303, 307 e 308. Para detalhes, consulte Códigos de status e cenários.

        Retain Query String

        Define se a string de consulta da requisição original deve ser levada para a URL de destino. Desativado por padrão (a string de consulta original é descartada).

        Quando Retain Query String está ativado:

        • Se a requisição original possuir uma string de consulta, ela substituirá a string de consulta da URL de redirecionamento.

        • Se a requisição original não possuir string de consulta, a string de consulta da URL de redirecionamento será preservada.

        Para exemplos de configuração, consulte Exemplos de configuração.

    Exemplos de configuração

    Exemplos de redirecionamento estático

    Cenário 1: A requisição não possui string de consulta, a URL de redirecionamento possui

    • A requisição contém string de consulta: Não

    • A URL de redirecionamento configurada contém string de consulta: Sim

    • Preservar string de consulta: Ativado ou desativado

    • URL de requisição de exemplo: http://test.example.com/1.jpg

    • URL de redirecionamento configurada: http://test.example.com/image/1.jpg?test=123

    • Location de redirecionamento real: http://test.example.com/image/1.jpg?test=123

    • Observações: Como não há string de consulta na requisição original, a string de consulta da URL configurada é utilizada independentemente da configuração de preservação de string de consulta.

    Cenário 2: Ambas as URLs possuem strings de consulta, preservação de string de consulta ativada

    • A requisição contém string de consulta: Sim

    • A URL de redirecionamento configurada contém string de consulta: Sim

    • Preservar string de consulta: Ativado

    • URL de requisição de exemplo: http://test.example.com/1.jpg?test=321

    • URL de redirecionamento configurada: http://test.example.com/image/1.jpg?test=123

    • Location de redirecionamento real: http://test.example.com/image/1.jpg?test=321

    • Observações: Com a preservação de string de consulta ativada, apenas a string de consulta da requisição original é mantida; os parâmetros de consulta da URL configurada são descartados.

    Cenário 3: Ambas as URLs possuem strings de consulta, preservação de string de consulta desativada

    • A requisição contém string de consulta: Sim

    • A URL de redirecionamento configurada contém string de consulta: Sim

    • Preservar string de consulta: Desativado

    • URL de requisição de exemplo: http://test.example.com/1.jpg?test=321

    • URL de redirecionamento configurada: http://test.example.com/image/1.jpg?test=123

    • Location de redirecionamento real: http://test.example.com/image/1.jpg?test=123

    • Observações: Com a preservação de string de consulta desativada, apenas a string de consulta da URL configurada é mantida; os parâmetros de consulta da requisição original são descartados.

    Cenário 4: A requisição possui string de consulta, a URL de redirecionamento não, preservação de string de consulta ativada

    • A requisição contém string de consulta: Sim

    • A URL de redirecionamento configurada contém string de consulta: Não

    • Preservar string de consulta: Ativado

    • URL de requisição de exemplo: http://test.example.com/1.jpg?test=321

    • URL de redirecionamento configurada: http://test.example.com/image/1.jpg

    • Location de redirecionamento real: http://test.example.com/image/1.jpg?test=321

    • Observações: Com a preservação de string de consulta ativada, a string de consulta original é anexada à URL configurada mesmo que esta não possua parâmetros de consulta.

    Cenário 5: A requisição possui string de consulta, a URL de redirecionamento não, preservação de string de consulta desativada

    • A requisição contém string de consulta: Sim

    • A URL de redirecionamento configurada contém string de consulta: Não

    • Preservar string de consulta: Desativado

    • URL de requisição de exemplo: http://test.example.com/1.jpg?test=321

    • URL de redirecionamento configurada: http://test.example.com/image/1.jpg

    • Location de redirecionamento real: http://test.example.com/image/1.jpg

    • Observações: Com a preservação de string de consulta desativada, a string de consulta original é descartada e apenas a URL configurada é retornada.

    Exemplos de redirecionamento dinâmico

    Cenário 1: Preservação de string de consulta desativada

    • Preservar string de consulta: Desativado

    • URL de requisição de exemplo: https://test.example.com/image/1.jpg?test=123

    • Expressão: concat("https://www.example.com", http.request.uri.path)

    • Location de redirecionamento real: https://www.example.com/image/1.jpg

    • Observações:

      • Com a preservação de string de consulta desativada, o caminho (/image/1.jpg) é mantido e a string de consulta (?test=123) é descartada.

      • A expressão concatena apenas nome do host e caminho; os parâmetros de consulta não são tratados.

    Cenário 2: Preservação de string de consulta ativada

    • Preservar string de consulta: Ativado

    • URL de requisição de exemplo: https://test.example.com/image/1.jpg?test=123

    • Expressão: concat("https://www.example.com", http.request.uri.path)

    • Location de redirecionamento real: https://www.example.com/image/1.jpg?test=123

    • Observações:

      • Com a preservação de string de consulta ativada, a string de consulta original é anexada à URL gerada mesmo que a expressão não trate parâmetros de consulta.

      • A expressão trata apenas a concatenação do caminho; o sistema anexa a string de consulta conforme a configuração.

    Cenário 3: Função wildcard_replace, preservação de string de consulta ativada

    • Preservar string de consulta: Ativado

    • URL de requisição de exemplo: https://www.example.com/image-flower-20250816-1.html?src=cdn

    • Expressão: wildcard_replace(http.request.full_uri, "https://www.example.com/image-*", "https://www.example.com/${1}")

    • Location de redirecionamento real: https://www.example.com/flower-20250816-1.html?src=cdn

    • Observações:

      • Com a preservação de string de consulta ativada, o sistema anexa a string de consulta original (ex.: ?src=cdn) à URL de destino.

      • A expressão trata apenas a reescrita do caminho; o sistema repassa a string de consulta conforme a configuração.

    Cenário 4: Função wildcard_replace, preservação de string de consulta desativada

    • Preservar string de consulta: Desativado

    • URL de requisição de exemplo: https://www.example.com/index.html?place=garden&date=20250816

    • Expressão: wildcard_replace(http.request.full_uri, "https://www.example.com/index.html?place=garden&date=*", "https://www.example.com/flower-${1}-1.html")

    • Location de redirecionamento real: https://www.example.com/flower-20250816-1.html

    • Observações:

      • Com a preservação de string de consulta desativada, a URL de destino é construída inteiramente pela expressão. Os parâmetros originais (ex.: place=garden) são usados apenas para correspondência; * captura o valor após date e o substitui como ${1}.

      • A URL final exclui os parâmetros de consulta originais.

    Perguntas frequentes

    Como redirecionar entre um domínio raiz (domínio simples) e um domínio www?

    A abordagem depende da sua configuração de DNS:

    1. Usando o ESA para redirecionamento: Tanto o domínio raiz quanto o domínio www devem estar conectados ao ESA via registros CNAME ou NS. Mesmo que você configure uma regra de redirecionamento, o domínio de source deve manter seu registro CNAME para que o ESA reconheça o tráfego recebido. Após conectar ambos os domínios ao ESA, configure a regra de redirecionamento de hostname correspondente nas regras de redirecionamento do ESA.

    2. O domínio raiz possui registros MX e não pode usar CNAME (conflito de DNS): Utilize o recurso de encaminhamento de URL fornecido pelo seu provedor de DNS. Observe que o encaminhamento de URL via DNS suporta apenas HTTP e o tráfego não passa pelo ESA.

    3. Importante: Se você configurou anteriormente um registro de encaminhamento de URL nas suas configurações de DNS, deverá excluir esse registro e adicionar o CNAME do ESA antes de usar as regras de redirecionamento do ESA. Caso contrário, as regras de redirecionamento do ESA não entrarão em vigor.

    O que fazer se uma regra de redirecionamento não entrar em vigor ou redirecionar para a URL errada?

    Verifique os itens a seguir nesta ordem:

    1. Confirme se a condição de correspondência cobre precisamente o domínio alvo: Por exemplo, se você configurou uma regra apenas para o domínio www, mas os usuários acessam o domínio raiz, adicione uma regra para o domínio raiz ou use um curinga para cobrir ambos.

    2. Verifique se o DNS está corretamente conectado ao ESA: Se estiver usando o redirecionamento do ESA, o domínio deve estar conectado ao ESA via registros CNAME ou NS. Depender exclusivamente da configuração de redirecionamento do servidor de source ou do encaminhamento de URL via DNS não funcionará.

    3. Verifique se há regras de prioridade maior sobrescrevendo a regra de redirecionamento: Revise a ordem de prioridade das regras e garanta que nenhuma regra anterior esteja interceptando ou modificando a requisição antes que a regra de redirecionamento seja avaliada.

    4. Valide a sintaxe da expressão dinâmica: A concatenação de URLs requer a função concat. Inserir uma string bruta com variáveis falhará. Utilize funções de expressão válidas como concat, regex_replace ou wildcard_replace.

    O que fazer se os redirecionamentos causarem um loop infinito ou tornarem o site inacessível?

    Siga estas etapas de solução de problemas:

    1. Verifique se há uma configuração de redirecionamento circular: Confirme se o servidor de source do domínio www aponta para o domínio raiz enquanto você também configurou um redirecionamento de raiz para www, criando um loop. Restaure a source para o endereço IP real ou para o endereço de source upstream original.

    2. Redirecionamento de HTTP para HTTPS: Utilize o recurso Force HTTPS no console do ESA em vez de configurar regras de redirecionamento manualmente. Regras manuais podem entrar em conflito entre si e criar loops de redirecionamento.

    3. Limpe o cache de redirecionamento: Se uma resposta de redirecionamento antiga persistir devido ao cache, limpe o cache no console do ESA e teste novamente o comportamento de redirecionamento.

    4. Verifique se há regras incompatíveis: Confirme se as regras de redirecionamento não estão correspondendo inadvertidamente a endpoints de verificação de integridade ou caminhos internos especiais, o que poderia causar falhas de acesso.

    Como configurar redirecionamentos condicionais baseados no tipo de dispositivo (como móvel) ou características da requisição?

    Utilize cabeçalhos de requisição como User-Agent nas condições de correspondência da requisição recebida:

    1. Método de correspondência: Utilize Contains em vez de Equals para correspondência de User-Agent, pois as strings de User-Agent costumam ser longas e variam entre dispositivos.

    2. Exemplo de redirecionamento móvel: Defina a condição de correspondência como User-Agent Contains Mobile ou use palavras-chave como Android ou iPhone, e configure a ação como um redirecionamento 302 para o domínio móvel.

    3. Controle avançado: Combine caminho, parâmetros de consulta e outras condições para um controle granular do redirecionamento. Por exemplo, redirecione usuários móveis que acessam / para m.example.com, enquanto usuários desktop continuam no domínio padrão.

    Por que a URL do navegador não muda após eu configurar uma regra de redirecionamento?

    Se a URL do navegador não mudar, você pode estar usando reescrita de URL em vez de redirecionamento de requisição:

    1. O redirecionamento de requisição do ESA envia uma resposta 3xx ao cliente, fazendo com que o navegador navegue para a nova URL e atualize a barra de endereços.

    2. A reescrita de URL modifica apenas o caminho da requisição de source de forma transparente (proxy no lado do servidor) e não altera a URL do navegador. Se você precisa manter a URL do navegador inalterada enquanto modifica o caminho enviado à source, utilize o recurso URL Rewrite em vez de regras de redirecionamento.

    3. Observação sobre a região de aceleração: Se a região de aceleração não incluir a China continental, os usuários na China continental podem não experimentar aceleração ao acessar o alvo do redirecionamento.

    Suporte por plano

    Recurso

    Entrance

    Pro

    Premium

    Enterprise

    Número de regras

    10

    25

    50

    125

    Documentação relacionada

    Os recursos relacionados a regras variam em prioridade efetiva, reentrância e granularidade efetiva. Para detalhes, consulte Propriedades de Recursos Relacionados a Regras.