Forwarding rules for domain and path matching - Server Load Balancer: Central de Documentação do Alibaba Cloud

Este tópico apresenta exemplos de configuração de regras de encaminhamento do ALB, abordando a correspondência de nome de domínio e caminho, reescrita e redirecionamento.

Exemplos de configuração

Cenário 1: Redirecionar HTTP para HTTPS

Redirecione solicitações HTTP para HTTPS e garanta a criptografia dos dados em trânsito. Adicione uma regra de encaminhamento ao listener HTTP (porta 80).

Parâmetro

Descrição

Add Condition

Defina Path como Exact Match and Wildcard e insira /*.

Action

Selecione Redirect to.

Protocol: Selecione HTTPS.
Domain Name: ${host}
Port: Insira a porta do listener HTTPS existente, como 443.
Path: ${path}
Search: ${query}
Status Code: Selecione 301.

Resultado: Ao acessar http://www.example.com/page, o navegador redireciona o usuário automaticamente para https://www.example.com/page.

Configure esta regra no listener HTTP (porta 80). Certifique-se também de criar um listener HTTPS (porta 443) e associá-lo a um certificado ssl válido. Para consultar os pré-requisitos e procedimentos completos, veja Use ALB to redirect HTTP requests to HTTPS .

Cenário 2: Roteamento de tráfego por caminho

Em um único domínio, encaminhe solicitações com caminhos diferentes para grupos de servidores distintos. Por exemplo, direcione solicitações de API e de ativos estáticos para backends separados.

Regra 1: Encaminhe solicitações para /api/* para o grupo de servidores de API.

Parâmetro	Descrição
Add Condition	Defina Path como Exact Match and Wildcard e insira `/api/*`.
Action	Selecione Forward to e escolha o grupo de servidores de API.

Regra 2: Encaminhe solicitações para /static/* para o grupo de servidores de ativos estáticos.

Parâmetro	Descrição
Add Condition	Defina Path como Exact Match and Wildcard e insira `/static/*`.
Action	Selecione Forward to e escolha o grupo de servidores de ativos estáticos.

O ALB avalia as regras de encaminhamento sequencialmente com base nos números de prioridade. Posicione as regras de caminho mais específicas (com números de prioridade menores) antes das mais amplas. Isso evita que uma regra com curinga as corresponda primeiro. Por exemplo, a regra para /api/v2/* deve ter um número de prioridade menor que a regra para /api/* .

Cenário 3: Encaminhar vários domínios

Hospede vários domínios em uma única instância do ALB e encaminhe as solicitações de cada domínio para o respectivo grupo de servidores de backend.

Regra 1: Encaminhe solicitações para www.example.com para o grupo de servidores web.

Parâmetro	Descrição
Add Condition	Defina Domain Name como Exact Match and Wildcard e insira `www.example.com`.
Action	Selecione Forward to e escolha o grupo de servidores web.

Regra 2: Encaminhe solicitações para api.example.com para o grupo de servidores de API.

Parâmetro	Descrição
Add Condition	Defina Domain Name como Exact Match and Wildcard e insira `api.example.com`.
Action	Selecione Forward to e escolha o grupo de servidores de API.

Cenário 4: Remover um prefixo de caminho antes do encaminhamento

Remova um prefixo específico do caminho de uma solicitação antes de encaminhá-la a um backend. Mantenha a captura de caminhos de vários níveis após o prefixo. Por exemplo, ao encaminhar solicitações para www.example.com/api/aaa/bbb/..., o ALB remove a parte /api do caminho, mas continua capturando os caminhos subsequentes de vários níveis, como /aaa/bbb/....

A reescrita (rewrite) substitui o caminho internamente no ALB. A url na barra de endereços do navegador do cliente permanece inalterada. Já o redirecionamento (redirect) retorna uma nova url ao cliente, e a barra de endereços do navegador é atualizada. Use a reescrita se apenas o backend precisar receber o caminho sem o prefixo. Use o redirecionamento se o cliente precisar notar a alteração da url.

Reescrita (Rewrite)

Parâmetro		Descrição
Add Condition	Domain Name	Defina como Exact Match and Wildcard e insira `www.example.com`.
Add Condition	Path	Defina como Regex Match \| Case-Insensitive e insira `^/api/(.*)`.
Action	Rewrite	Domain Name: `${host}` Path: `/${1}` Search: `${query}`
Action	Forward to	Selecione o grupo de servidores de destino.

Redirecionamento (Redirect)

Parâmetro		Descrição
Add Condition	Domain Name	Defina como Exact Match and Wildcard e insira `www.example.com`.
Add Condition	Path	Defina como Regex Match \| Case-Insensitive e insira `^/api/(.*)`.
Action	Redirect to	Protocol: `${protocol}` Domain Name: `${host}` Port: `${port}` Path: `/${1}` Search: `${query}` Status Code: Selecione `301`.

Resultado: Em uma solicitação para www.example.com/api/aaa/bbb/..., o servidor de backend recebe o caminho /aaa/bbb/....

Cenário 5: Redirecionar domínio raiz para www

Redirecione solicitações de um domínio raiz (como example.com) para www.example.com. Essa prática unifica o ponto de entrada, melhora o SEO e facilita o gerenciamento.

Parâmetro

Descrição

Add Condition

Defina Domain Name como Exact Match and Wildcard e insira example.com.

Action

Selecione Redirect to.

Protocol: ${protocol}
Domain Name: Insira www.example.com.
Port: ${port}
Path: ${path}
Search: ${query}
Status Code: Selecione 301.

Resultado: Ao acessar example.com, o navegador redireciona o usuário automaticamente para www.example.com. O protocolo e a porta permanecem inalterados.

Caso também precise redirecionar solicitações HTTP para HTTPS, combine esta configuração com o Cenário 1.

Cenário 6: Corresponder a um domínio com curinga

Use um domínio com curinga para abranger todos os subdomínios e encaminhar as solicitações ao mesmo grupo de servidores.

Parâmetro	Descrição
Add Condition	Defina Domain Name como Exact Match and Wildcard e insira `*.example.com`.
Action	Selecione Forward to e escolha o grupo de servidores de destino.

Resultado: O ALB encaminha as solicitações de todos os subdomínios correspondentes, como a.example.com, b.example.com e tenant1.example.com, para o mesmo grupo de servidores.

Para encaminhar um subdomínio específico a um grupo de servidores diferente, crie uma regra para esse domínio exato e atribua a ela um número de prioridade menor que o da regra com curinga. O ALB avalia as regras com base no número de prioridade, e não na especificidade da correspondência de domínio.

Cenário 7: Implantação canário por cabeçalho HTTP

Use um cabeçalho HTTP para implementar uma implantação canário. Essa configuração encaminha solicitações com um cabeçalho específico ao grupo de servidores da nova versão. As demais solicitações vão para o grupo de servidores da versão atual.

Regra 1 (Regra canário, prioridade mais alta): Encaminhe solicitações que contenham o cabeçalho X-Canary: true para o grupo de servidores da nova versão.

Parâmetro	Descrição
Add Condition	Selecione HTTP Header, defina a chave como `X-Canary` e defina o valor como `true`.
Action	Selecione Forward to e escolha o grupo de servidores da nova versão.

Regra 2 (Regra padrão, prioridade mais baixa): O ALB encaminha as solicitações sem o cabeçalho canário ao grupo de servidores da versão atual. Implemente isso usando a regra de encaminhamento padrão do listener.

Resultado: Se a solicitação do cliente incluir o cabeçalho X-Canary: true, o tráfego vai para o grupo de servidores da nova versão. As solicitações sem esse cabeçalho vão para o grupo de servidores da versão atual.

Para garantir a correspondência do tráfego canário em primeiro lugar, a regra canário deve ter um número de prioridade menor (o que indica prioridade mais alta) que a regra padrão. Para obter informações sobre métodos de implantação canário com base em cookies e pesos de grupos de servidores, consulte Use ALB to implement a canary release .

Correspondência de domínio nas regras de encaminhamento

O ALB avalia as regras de encaminhamento pelo número de prioridade, do menor para o maior, e para na primeira correspondência. O sistema não classifica as regras automaticamente pela especificidade do domínio. Esse comportamento difere do CLB, que prioriza as regras automaticamente com base na especificidade (por exemplo, exact match > narrower wildcard > broader wildcard).

Por exemplo, considere um listener com as duas regras a seguir:

Número de prioridade	Condição de correspondência
Regra 1 (Prioridade: 1)	Domínio = `*.example.com` → Encaminhar para o grupo de servidores A
Regra 2 (Prioridade: 2)	Domínio = `www.example.com` → Encaminhar para o grupo de servidores B

Uma solicitação para www.example.com corresponde à Regra 1 (a regra com curinga), e não à Regra 2 (a regra de correspondência exata), pois a Regra 1 tem um número de prioridade menor.

Melhor prática : Para garantir a avaliação de uma regra mais específica em primeiro lugar, atribua a ela um número de prioridade menor que o de uma regra menos específica. Por exemplo, defina a regra para www.example.com com Prioridade 1 e a regra para *.example.com com Prioridade 2.

Tipo de correspondência	Descrição
Correspondência exata e correspondência com curinga	Descrição da correspondência Correspondência exata: O nome de domínio solicitado deve ser idêntico ao definido na regra. Correspondência com curinga: O nome de domínio solicitado deve corresponder ao padrão com curinga definido na regra. Requisitos O nome de domínio deve ter de 3 a 256 caracteres e pode conter apenas letras, dígitos e os seguintes caracteres especiais: `.-?=~_+\^!$&\|()[]`. Use asteriscos () e pontos de interrogação (`?`) como curingas. Exemplo Nome de domínio solicitado: www.example.com Correspondência exata: Há correspondência se a regra estiver definida como `www.example.com`. Correspondência com curinga: Há correspondência se a regra estiver definida como `.example.com` ou `www.example.`.
Correspondência por expressão regular	Descrição da correspondência O nome de domínio solicitado deve corresponder à expressão regular definida na regra. Requisitos O nome de domínio deve ter de 3 a 256 caracteres e pode conter apenas letras, dígitos e os seguintes caracteres especiais: `.-?=~_+\^!$&\|()[]`. Exemplo* Nome de domínio solicitado: www.example.com Há correspondência se a regra estiver definida com a expressão regular `^www.example.com$`. Essa correspondência não diferencia maiúsculas de minúsculas.

Correspondência de caminho nas regras de encaminhamento

As regras de correspondência de caminho do ALB diferem das do Nginx. O ALB não oferece suporte ao princípio de correspondência de prefixo mais longo. Por exemplo, o Nginx usa o método de correspondência de prefixo mais longo para uma configuração comum como location /api. Para obter o mesmo efeito no ALB, use um curinga. Configure o caminho como /api/* (uma combinação de correspondência exata e curinga).

Se um listener tiver regras tanto para /api/* quanto para /api/v2/* , posicione a regra /api/v2/* antes da regra /api/* ao atribuir a ela um número de regra menor. Caso contrário, a regra /api/* corresponderá a todas as solicitações primeiro.

Tipo de correspondência	Descrição
Correspondência exata e com curinga	Descrição da correspondência Correspondência exata: O caminho solicitado deve ser idêntico ao caminho definido na regra. Correspondência com curinga: O caminho solicitado deve corresponder ao padrão com curinga definido na regra. Requisitos de entrada O caminho deve começar com uma barra (`/`) e deve conter apenas letras, dígitos e os seguintes caracteres especiais: `$-_.+/&~@:`. Asteriscos (``) e pontos de interrogação (`?`) atuam como curingas. Exemplo* Caminho da solicitação: /example/text Correspondência exata: Há correspondência se a regra estiver configurada com o caminho `/example/text`. Correspondência com curinga: Há correspondência se a regra estiver configurada com o caminho `/example/*`.
Correspondência por expressão regular	Descrição da correspondência O caminho solicitado deve corresponder à expressão regular definida na regra. Requisitos de entrada A expressão regular deve conter apenas letras, dígitos e os seguintes caracteres especiais: `.-_/=?~^$:()[]+\|`. Exemplo* Caminho da solicitação: `/api/v2/Users` Diferencia maiúsculas de minúsculas: Há correspondência se a expressão regular estiver definida como `^/api/(.)/Users$`. Não diferencia maiúsculas de minúsculas: Há correspondência se a expressão regular estiver definida como `^/api/(.)/users$`.

Nota

No modo de correspondência por expressão regular, uma barra no final (/) no caminho afeta o resultado. Por exemplo, a expressão regular ~^/ws/(.*) corresponde apenas a caminhos que começam com /ws/ (como /ws/ e /ws/abc), e não a /ws (sem a barra no final). Para abranger tanto /ws quanto caminhos que começam com /ws/, use a expressão regular ~^/ws(/.*)?$.

Configuração avançada de caminho para reescritas e redirecionamentos

Ao usar uma expressão regular para definir um caminho em uma condição de encaminhamento, você pode aplicar a substituição de expressão regular no caminho de uma ação de reescrita ou redirecionamento.

Observações
- A quantidade de grupos de captura, definidos por parênteses ( ), na expressão regular da condição de encaminhamento deve ser igual à quantidade de variáveis ${n} no caminho de reescrita ou redirecionamento da ação de encaminhamento.
- O caminho de reescrita ou redirecionamento na ação de encaminhamento deve incluir pelo menos uma das seguintes variáveis: ${1}, ${2} ou ${3}. Não substitua essas variáveis por outros caracteres.
- Em um caminho de reescrita ou redirecionamento, use o caractere $ apenas para referenciar as seguintes variáveis: ${host}, ${path}, ${port}, ${protocol} e variáveis de grupo de captura de expressão regular, como ${1}, ${2} e ${3}. O sistema não suporta outras variáveis.

Como funciona

Correspondência de caminho: Um cliente envia uma solicitação que corresponde à expressão regular de uma regra de encaminhamento.
Extração e substituição: O sistema extrai o conteúdo dos três primeiros grupos de captura, definidos por parênteses ( ), e o salva nas variáveis ${1}, ${2} e ${3}. Em seguida, o sistema usa essas variáveis para substituição no caminho de reescrita ou redirecionamento da ação de encaminhamento.
Construção do caminho: O sistema substitui as variáveis ${1}, ${2} e ${3} pelos valores capturados e constrói o caminho final para a reescrita ou redirecionamento.

Nº	Etapa	Exemplo
1	Configure a condição de encaminhamento e a ação de encaminhamento para uma regra de encaminhamento.	Caminho na condição de encaminhamento: `/app/(.)/(.)/settings` Caminho para a ação de reescrita ou redirecionamento: `/${1}/${2}`
2	Um cliente envia uma solicitação que corresponde ao caminho.	Caminho da solicitação do cliente: `/app/users/profile/settings` Caminho correspondente na condição de encaminhamento: `/app/(.)/(.)/settings`
3	Extraia e substitua os valores.	O sistema extrai `users` e `profile` dos dois grupos de captura `(.*)` no caminho da condição de encaminhamento e salva os valores nas variáveis ${1} e ${2} para a ação de encaminhamento. O sistema substitui `${1}` por `users`. O sistema substitui `${2}` por `profile`.
4	Construa o caminho.	Caminho recebido pelo servidor de backend: `/users/profile`

Exemplos de configuração

Ao adicionar regras de encaminhamento no console, siga as observações anteriores e a descrição do fluxo de trabalho.

Exemplo 1: Defina a ação de encaminhamento como Rewrite e Forward to

Este exemplo mostra como reescrever o caminho /app/users/profile/settings para /users/profile e encaminhar a solicitação a um servidor de backend. A expressão regular /app/(.*)/(.*)/settings usa dois grupos de captura para extrair users e profile. O caminho reescrito usa /${1}/${2} para construir o caminho final.

Parâmetro		Descrição
Add Condition	Path	Selecione Regex Match \| Case-Insensitive e insira a expressão regular `/app/(.)/(.)/settings`. Por exemplo, se um cliente solicitar o caminho `/app/users/profile/settings`, a regra corresponderá. Os grupos de captura extraem `users` e `profile`, e o sistema os salva nas variáveis `${1}` e `${2}`, respectivamente.
Action	Rewrite	Domain Name: `${host}` Path: `/${1}/${2}` Search: `${query}` O Search é a parte de uma url após o ponto de interrogação. Por exemplo, na url `www.example.com/test/test1?x=1`, o Search é `x=1`.
Action	Forward to	Selecione o grupo de servidores de destino na lista de grupos de servidores.

Exemplo 2: Defina a ação de encaminhamento como redirecionamento

O exemplo a seguir redireciona o caminho /app/users/profile/settings para /users/profile. Ao contrário do Exemplo 1, este redirecionamento retorna um código de status 301 e altera a url na barra de endereços do navegador.

Parâmetro

Descrição

Add Condition

Path

Selecione Regex Match | Case-Insensitive e insira a expressão regular /app/(.)/(.)/settings.

Por exemplo, se um cliente solicitar o caminho /app/users/profile/settings, a regra corresponderá. Os grupos de captura extraem users e profile, e o sistema os salva nas variáveis ${1} e ${2}, respectivamente.

Action

Redirect to

Protocol: ${protocol}
Domain Name: ${host}
Port: ${port}
Path: /${1}/${2}
Search: ${query}
Status Code: 301

Perguntas frequentes

Reescrever apenas um nome de domínio

Para reescrever o nome de domínio solicitado para outro e manter o caminho e a string de consulta inalterados, configure a regra da seguinte forma:

Add Condition: Defina o nome de domínio como o nome de domínio original, como old.example.com.
Action: selecione reescrita (rewrite). Defina o nome de domínio como o novo nome de domínio (como new.example.com), o caminho como ${path} e a consulta como ${query}. Configure também o Forward to e especifique um grupo de servidores.

Adicionar um prefixo a um caminho

Para adicionar um prefixo a um caminho (por exemplo, reescrever /users/list para /v2/users/list), configure a regra da seguinte forma:

Add Condition: Defina o caminho para corresponder à expressão regular ^/(.*).
Action: Selecione reescrita (rewrite) e defina o caminho como /v2/${1}. Configure também o Forward to e especifique um grupo de servidores.

Após a configuração da regra, o ALB reescreve uma solicitação para /users/list como /v2/users/list e a encaminha ao servidor de backend.

Remover um prefixo de caminho

Consulte Use case 4: Forward requests after stripping a path prefix neste tópico. Esse caso de uso fornece um exemplo de configuração completo para remover um prefixo, como /api/*, por meio de uma correspondência de expressão regular com uma ação de reescrita ou redirecionamento.

Solucionar problemas de correspondência e roteamento de regras de encaminhamento

Se as regras de encaminhamento não rotearem as solicitações conforme o esperado, siga estas etapas de solução de problemas:

verifique a prioridade da regra: O ALB avalia as regras em ordem crescente de número de prioridade e para na primeira correspondência. Se uma regra mais ampla tiver um número de prioridade menor (sendo avaliada primeiro), o sistema não corresponderá a uma regra mais específica com um número de prioridade maior.
verifique o tipo de correspondência: Certifique-se de usar o tipo de correspondência correto (exata, curinga ou expressão regular). Por exemplo, uma correspondência exata para /api não abrange /api/users. Para abranger ambos, use um curinga, como /api/*.
verifique múltiplas condições: Ao configurar várias condições para uma única regra de encaminhamento, o sistema combina condições de tipos diferentes com um operador AND. Já os vários valores para o mesmo tipo de condição são combinados com um operador OR. Para mais informações, consulte Configure listener forwarding rules.
verifique os logs de acesso: Use os campos host e request_uri no log de acesso do ALB para confirmar se os detalhes da solicitação recebidos pelo ALB correspondem às suas expectativas.

Reescrita versus redirecionamento

Item	Reescrita (Rewrite)	Redirecionamento (Redirect)
Barra de endereços do navegador	Inalterada (transparente para o usuário)	Altera para a nova url
Como funciona	O ALB reescreve o caminho da solicitação internamente e, em seguida, encaminha a solicitação para o servidor de backend. Todo o processo ocorre em uma única solicitação.	O ALB retorna um código de status 3xx, e o navegador inicia uma segunda solicitação para a nova url.
Casos de uso	Ajustes internos de caminho, como remover prefixos ou adicionar números de versão.	Redirecionamentos de HTTP para HTTPS, de domínio raiz para www e migrações de urls legadas.
Requer "Forward to"	Sim. Você deve configurar uma ação de reescrita com uma ação "Forward to" que especifique um grupo de servidores.	Não. Uma ação de redirecionamento é independente.

Documentos relacionados

Para obter instruções sobre a configuração de regras de encaminhamento de listener para um ALB, consulte Configure listener forwarding rules.