Server Load Balancer:ALB FAQ

Para obter mais largura de banda, adquira uma instância de Shared Bandwidth e adicione os EIPs associados à instância do ALB a ela.

• Para saber como adquirir uma instância de Shared Bandwidth, consulte Criar e gerenciar uma instância de Shared Bandwidth.

• Para saber como adicionar EIPs a uma instância de Shared Bandwidth, consulte Criar e gerenciar instâncias do ALB e Ajustar a largura de banda de pico de uma instância voltada para o público.

Apenas EIPs com pagamento conforme o uso podem ser associados a uma instância do ALB. A tabela a seguir descreve os tipos de EIPs compatíveis com uma instância do ALB.

Observe os pontos abaixo ao associar um EIP a uma instância do ALB:

• Os EIPs associados a todas as zonas de disponibilidade de uma instância do ALB devem ser do mesmo tipo.

• Antes de associar um EIP, verifique se ele já não foi adicionado a uma instância de Shared Bandwidth. Para utilizar o Shared Bandwidth, primeiro associe o EIP à instância do ALB e, em seguida, adicione-o a uma instância de Shared Bandwidth no console do Load Balancer. Ao adicionar um EIP a uma instância de Shared Bandwidth, garanta que o tipo de linha do EIP corresponda ao da instância de Shared Bandwidth. Tanto instâncias de Shared Bandwidth por assinatura quanto por pagamento conforme o uso são suportadas. Para mais informações, consulte Ajustar a largura de banda de pico de uma instância voltada para o público.

• Não é possível associar EIPs por assinatura ou EIPs por pagamento conforme o uso (pagamento por largura de banda).

• Ao atribuir um EIP a uma instância do ALB, selecione Purchase EIP ou Automatically Assign Public IP Address cria um EIP por pagamento conforme o uso (pagamento por transferência de dados) que utiliza o tipo de linha BGP (Multi-ISP) e oferece proteção padrão.

Para solicitações encaminhadas pelo ALB, o comprimento máximo da URI é de 32 KB e o comprimento máximo do cabeçalho é de 32 KB. Esses limites não podem ser ajustados. Para cabeçalhos personalizados nos logs de acesso, o comprimento máximo padrão é de 1 KB, que pode ser aumentado para 4 KB. Para solicitar um aumento, entre em contato com seu gerente de conta.

• Se o tamanho de uma solicitação do cliente exceder o limite, o ALB poderá retornar um código de status http 400 ou 414. Para mais informações, consulte Códigos de erro relacionados ao ALB.

• Para transmitir uma grande quantidade de dados, use uma solicitação POST. O tamanho máximo para o corpo de uma solicitação POST é de 50 GB.

Falha nas configurações cross-origin com erro de preflight

Se Allowed Request Headers estiver definido para nomes de cabeçalho específicos em vez de "", tente defini-lo como "" para teste. Se o problema for resolvido, verifique se o Access-Control-Request-Headers na solicitação preflight contém um nome de cabeçalho que não está incluído nas suas configurações. Isso pode causar falha na solicitação preflight.

Solicitações preflight e reais correspondem a regras diferentes

O ALB suporta vários métodos de correspondência para regras de encaminhamento. Em um cenário cross-origin, os cabeçalhos e o método de uma solicitação preflight podem diferir da solicitação real. Para cenários cross-origin, configure regras de encaminhamento com base em nomes de domínio. Isso garante que tanto a solicitação preflight quanto a solicitação real sejam roteadas para a mesma regra de encaminhamento, que possui as configurações cross-origin necessárias, e evita problemas inesperados.

Geração do cabeçalho Access-Control-Allow-Headers

1. Solicitação preflight

   Um navegador envia uma solicitação preflight usando o método OPTIONS quando uma solicitação cross-origin atende às seguintes condições:

   • O método da solicitação é OPTIONS.

   • A solicitação inclui o cabeçalho Access-Control-Request-Method.

   Nesse caso, o ALB retorna o cabeçalho de resposta Access-Control-Allow-Headers com base na regra de encaminhamento cross-origin configurada no console. O valor desse cabeçalho de resposta é uma lista dos campos de cabeçalho de solicitação permitidos especificados na regra. Exemplo:

   DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization

2. Solicitação cross-origin padrão

   Para solicitações não-OPTIONS ou solicitações simples que não exigem verificação preflight, o ALB não retorna o cabeçalho de resposta Access-Control-Allow-Headers.

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

Autenticação mútua de CA

Instâncias do ALB Basic Edition não suportam autenticação mútua de CA. Instâncias do ALB Standard Edition e WAF-enabled Edition suportam autenticação mútua de CA quando você adiciona um listener https. Se precisar usar o recurso de autenticação mútua de CA para uma instância do ALB Basic Edition, atualize a edição da instância.

Regras para certificados wildcard

Upload de certificados

Não.

O ALB utiliza certificados do Alibaba Cloud ssl Certificates service. Portanto, faça o upload dos certificados no console do ssl Certificate, e não no console do ALB. Para mais informações, consulte Fazer upload de um certificado ssl.

Data de expiração do certificado inalterada

Esse problema geralmente ocorre quando sua instância do ALB está integrada ao WAF 2.0 no modo de proxy transparente e o certificado no WAF não foi atualizado. O WAF sincroniza certificados do ALB periodicamente. Para acionar uma atualização imediata, desative e reative o desvio de tráfego para seu domínio no console do WAF. Essa ação força a atualização do certificado. Observe que essa operação causa uma breve interrupção de service de 1 a 2 segundos.

Modificar configuração de verificação de integridade

1. Faça login no console do Application Load Balancer (ALB).

2. No painel de navegação à esquerda, escolha ALB > Server Groups.

3. Na página Server Groups, localize o grupo de servidores desejado e clique em seu ID.

4. Na aba Details, na seção Health Check, clique em Modify Health Check.

5. Na caixa de diálogo Modify Health Check, clique em Edit ao lado de Health Check Settings, modifique as configurações de verificação de integridade e clique em Save.

   Para mais informações, consulte Verificação de integridade do ALB.

Erros 502 apesar de verificações de integridade bem-sucedidas

Isso geralmente ocorre porque a carga nos servidores de backend da instância do ALB está muito alta. Quando a carga nos servidores de backend da instância do ALB é excessiva, podem ocorrer inconsistências entre os resultados da verificação de integridade e os resultados das solicitações de acesso. Para saber como verificar a carga do servidor de backend, consulte Solução de problemas e tratamento de alta carga em instâncias Linux.

Encaminhamento de solicitações quando as verificações de integridade falham

A instância do ALB ainda encaminha solicitações com base no algoritmo de agendamento configurado para minimizar a interrupção do service. Se as solicitações não forem tratadas conforme o esperado, verifique seus logs em busca de erros no servidor de backend ou revise sua configuração de verificação de integridade para identificar problemas. Para mais informações, consulte Solucionar falhas na verificação de integridade do ALB.

service inacessível via ALB

Siga estas etapas para diagnosticar o problema:

1. Verificar a resolução do nome de domínio (CNAME): não é possível acessar diretamente uma nova instância do ALB usando seu nome DNS. Mapeie seu nome de domínio personalizado para o nome DNS da instância do ALB usando um registro CNAME. Use o comando nslookup ou dig para verificar a resolução. Para mais informações, consulte Nomes DNS da instância do ALB.

2. Verificar o tipo de rede da instância: uma instância do ALB de rede privada só pode ser acessada de dentro de sua Virtual Private Cloud (vpc). Para habilitar o acesso público, altere o tipo de rede da instância para público e associe um Elastic IP (EIP). Para mais informações, consulte Alterar o tipo de rede de uma instância do ALB.

3. Verificar o listener e as regras de encaminhamento: no console do ALB, verifique se um listener foi criado com a porta e o protocolo corretos. Confirme também se as regras de encaminhamento estão configuradas para corresponder ao nome de domínio e ao caminho das solicitações recebidas.

4. Verificar o status da verificação de integridade: no console do ALB, verifique o status da verificação de integridade dos seus servidores de backend. Uma instância do ALB não encaminhará solicitações para servidores de backend não íntegros.

5. Confirmar se o service de backend está em execução corretamente: faça login em um servidor de backend e execute o comando curl -I http://<backend_server_private_IP>:<port> para confirmar se o service de backend responde corretamente.

6. Verificar as configurações de controle de acesso e firewall: garanta que as configurações de controle de acesso ou as regras do grupo de segurança da instância do ALB permitam o intervalo de endereços IP de source do cliente. Confirme também se o iptables ou softwares de segurança de terceiros nas instâncias do Elastic Compute Service (ecs) de backend permitem o intervalo de endereços IP locais da instância do ALB.

Solucionar alta latência

O ALB opera na camada de aplicação, o que significa que as solicitações são encaminhadas para os servidores de backend. Esse processo introduz uma pequena latência adicional em comparação ao acesso direto aos servidores de backend. Esse comportamento é esperado.

Se você experimentar uma latência significativamente alta, siga estas etapas para solucionar o problema:

1. Ativar logs de acesso e analisar campos de latência: ative os Logs de Acesso do ALB e concentre-se nos seguintes campos:

   • request_time: o tempo em segundos desde quando o balanceador de carga recebe o primeiro pacote de solicitação até o momento em que envia a resposta.

   • upstream_response_time: o tempo em segundos desde quando o balanceador de carga começa a se conectar a um servidor de backend até receber todos os dados e fechar a conexão.

2. Identificar a source da latência:

   • Se upstream_response_time estiver alto, os servidores de backend provavelmente são a source da latência. Verifique o desempenho da sua aplicação de backend, a eficiência das consultas ao banco de dados e o uso de recursos como cpu e memória. Adicione mais servidores de backend para distribuir a carga.

   • Se request_time for muito maior que upstream_response_time, a latência provavelmente está no caminho de rede entre o cliente e a instância do ALB. A partir do cliente, execute testes contínuos de ping ou um rastreamento MTR para o endereço de service do ALB para diagnosticar problemas no link de rede.

3. Considerar cenários de acesso entre regiões: se o cliente e a instância do ALB estiverem em regiões diferentes, a latência de rede devido à distância física é inevitável. Recomendamos o uso do Global Accelerator (GA) para otimizar a experiência de acesso entre regiões.

service inacessível via nome de domínio

Após mapear seu nome de domínio personalizado para o nome DNS da instância do ALB com um registro CNAME, você ainda pode não conseguir acessar o service. Se receber um erro http 403 ou uma redefinição de conexão, a causa provável é um registro ICP incompleto para o seu nome de domínio.

Siga estas etapas para diagnosticar o problema:

1. Verificar a configuração do registro CNAME: use o comando nslookup ou dig para verificar se o seu nome de domínio está resolvido corretamente para o nome DNS da instância do ALB. Para mais informações, consulte Configurar um Registro CNAME.

2. Verificar o status do registro ICP do seu nome de domínio: de acordo com os regulamentos, nomes de domínio usados para acesso público na China continental devem ter um registro ICP válido. Caso contrário, o acesso será bloqueado. Faça login no sistema de Registro ICP da Alibaba Cloud para verificar o status do registro do seu nome de domínio. Se não estiver registrado, conclua o processo de registro ICP primeiro. Para mais informações, consulte Processo de Registro ICP.

3. Determinar se é necessária uma transferência de registro ICP: se o seu nome de domínio foi registrado por meio de outro provedor de services cloud e você o está usando com a Alibaba Cloud pela primeira vez, deve concluir uma transferência de registro ICP. Esse processo registra suas informações de registro na Alibaba Cloud. O acesso pode ser bloqueado se a transferência não estiver concluída.

500 (Internal Server Error)

O servidor de backend encontrou um erro interno e não pôde processar a solicitação.

• O backend retorna 500 diretamente: verifique o log de acesso. Se upstream_status for 500, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• O servidor de backend fechou a conexão inesperadamente: o servidor de backend fechou a conexão antes de enviar uma resposta completa. Capture pacotes no servidor de backend para identificar a causa do fechamento inesperado da conexão.

502 (Bad Gateway)

Esse erro ocorre quando um listener http ou https recebe uma solicitação do cliente, mas o ALB falha ao encaminhar a solicitação para um servidor de backend ou ao receber uma resposta dele.

Abordagem de solução de problemas: primeiro, verifique o valor do campo upstream_status no log de acesso para determinar as próximas etapas.

• Se upstream_status = 502: o ALB repassou o código de status 502 do servidor de backend. O problema reside no próprio service de backend. Investigue seu service de backend. Por exemplo, verifique se uma camada de Nginx ou gateway de backend está tentando fazer reverse proxy para um upstream inacessível.

• Se upstream_status for outro valor (como 504, 444 ou 500): o status que o ALB retorna ao cliente difere de upstream_status, o que significa que o ALB alterou o código de status. Investigue por que o service de backend está retornando esse código de status específico verificando os logs do Nginx de backend, gateway ou aplicação.

• Se upstream_status for - ou estiver vazio: o ALB não recebeu nenhuma resposta do backend. Isso significa que a solicitação nunca chegou ao backend ou a conexão com o backend foi encerrada anormalmente antes que uma resposta fosse enviada. Verifique as seguintes causas em ordem:

  • A comunicação TCP entre o ALB e o servidor de backend está falhando. Verifique se o service de backend está em execução, se a porta de service está escutando corretamente e se nenhuma regra de iptables ou software de segurança de terceiros no ecs de backend está bloqueando o bloco CIDR do vSwitch onde a instância do ALB está localizada. O ALB se comunica com os servidores de backend usando um Local IP atribuído pelo vSwitch. Capture pacotes para verificar se o handshake TCP foi bem-sucedido.

  • O backlog do servidor de backend está cheio. Isso faz com que o servidor descarte novas solicitações de conexão. Execute netstat -s | grep -i listen no servidor de backend e verifique se há um contador de drop.

  • O servidor de backend falhou ao processar a solicitação a tempo. Verifique os logs do servidor de backend e revise o uso de cpu e memória para identificar gargalos de desempenho.

  • O tamanho do pacote da solicitação do cliente excede a MTU do servidor de backend. Isso pode fazer com que pacotes curtos (como verificações de integridade) tenham êxito, enquanto pacotes longos falham. Capture pacotes no servidor de backend para analisar se o comprimento do pacote está dentro dos limites necessários.

  • A resposta do servidor de backend tem um formato inválido ou contém cabeçalhos http inválidos. Capture pacotes no servidor de backend para analisar se o formato da resposta está em conformidade com o padrão.

503 (service Temporarily Unavailable)

O servidor está temporariamente indisponível, geralmente devido a tráfego excedendo limites ou um service de backend indisponível.

• O backend retorna 503 diretamente: verifique o log de acesso. Se upstream_status for 503, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• A solicitação do cliente aciona o limitador de taxa do ALB:

  • Em cloud Monitor, verifique a métrica Requests per second.

  • O cloud Monitor exibe dados no nível de minuto e pode não refletir picos no nível de segundo. Verifique o log de acesso. Se o campo upstream_status for -, a solicitação não chegou ao servidor de backend.

  • Verifique o cabeçalho do pacote de resposta. Se contiver o campo ALB-QPS-Limited:Limited, a solicitação acionou o limitador de taxa do ALB.

• Acesso direto por IP ou resolução DNS anormal: isso pode concentrar o tráfego em apenas alguns endereços IP e acionar o limitador de taxa. Acesse o ALB por meio do seu nome de domínio (consulte Configurar um CNAME para uma instância do ALB) e verifique se a resolução DNS funciona conforme o esperado.

• O listener não tem servidores de backend configurados, ou os servidores de backend configurados têm peso 0.

• Regra de encaminhamento padrão do ALB Ingress causa 503: ao instalar o controlador ALB Ingress no ACK, o controlador cria automaticamente uma regra de encaminhamento padrão e um grupo de servidores padrão associado na instância do ALB. O grupo de servidores padrão está inicialmente vazio. Quando o tráfego recebido não corresponde a nenhuma das regras de encaminhamento de Ingress configuradas, o ALB roteia a solicitação para a regra de encaminhamento padrão. Como o grupo de servidores padrão está vazio, o ALB retorna um erro 503. Esse comportamento é esperado. Não é necessário excluir manualmente a regra de encaminhamento padrão. Para resolver esse problema, configure as regras de encaminhamento baseadas em domínio corretas para rotear o tráfego para os grupos de servidores de backend correspondentes.

  Nota

  Um erro 503 indica que nenhum servidor de backend está disponível para processar a solicitação (o grupo de servidores está vazio), o que é diferente de um erro 502, onde existem servidores de backend, mas estão indisponíveis.

504 (Gateway Time-out)

O ALB atingiu o tempo limite enquanto aguardava uma resposta do servidor de backend.

• O backend retorna 504 diretamente: verifique o log de acesso. Se upstream_status for 504, o ALB provavelmente repassou o código de status do backend. Investigue o service de backend.

• A tentativa de conexão do ALB com o servidor de backend atinge o tempo limite: esse tempo limite é de 5 segundos por padrão e não pode ser alterado. Capture pacotes para identificar por que o servidor de backend não está respondendo a tempo.

• Tempo limite de resposta do backend: o tempo limite de solicitação de conexão é de 60 segundos por padrão. Verifique a métrica UpstreamResponseTime no cloud Monitor e o campo upstream_response_time no log de acesso para determinar se a resposta do servidor de backend atingiu o tempo limite.

Integração transparente WAF 2.0 vs. integração baseada em service WAF 3.0

Para mais informações, consulte Comparação entre WAF 3.0 e WAF 2.0.

Integração entre ALB e WAF

• Recomendamos que você ative a proteção do WAF 3.0 para uma instância do ALB usando a integração baseada em service WAF 3.0. Isso significa usar uma instância do ALB aprimorada com WAF.

  • Regiões suportadas:

    Area	Region
    China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), and China (Heyuan)
    Asia-Pacific	Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), and South Korea (Seoul)
    Europe and Americas	Germany (Frankfurt), US (Silicon Valley), US (Virginia), and Mexico
    Middle East	SAU (Riyadh - Partner Region) and UAE (Dubai)

  • Instâncias do ALB habilitadas para WAF usam o modelo de integração sdk do WAF 3.0. Se você tiver uma instância do WAF 2.0 em sua conta, primeiro libere a instância do WAF 2.0 ou migra-a para o WAF 3.0.

    Por padrão, o ALB não adiciona o cabeçalho X-Forwarded-Proto às solicitações. Após liberar uma instância do WAF 2.0, acessar a instância do ALB diretamente pode causar problemas de service, como redirecionamentos infinitos, porque os servidores de backend não conseguem identificar o protocolo original (http ou https). Para evitar esse problema, ative manualmente o cabeçalho de solicitação X-Forwarded-Proto na configuração do listener do ALB.

  • Instâncias do ALB habilitadas para WAF não suportam o recurso de prevenção de vazamento de dados do WAF.

• Se quiser usar uma instância existente do WAF 2.0, instâncias do ALB Basic e Standard voltadas para a Internet suportam integração transparente WAF 2.0 nas seguintes regiões: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing) e China (Zhangjiakou). Instâncias do ALB voltadas para rede interna não suportam integração transparente WAF 2.0.

Suporte à integração com WAF para CLB e ALB

Problemas na integração transparente WAF 2.0

Em uma integração transparente WAF 2.0, as solicitações do cliente passam pelo WAF para inspeção antes de serem enviadas para uma instância do ALB ou CLB. Esse caminho de dois gateways exige que você sincronize várias configurações entre o WAF e o balanceador de carga. Alterações em tempos limite e certificados são especialmente propensas a atrasos na sincronização de configurações.