Server Load Balancer:CLB listener FAQ

Suporte a redirecionamento de porta no CLB

Sim.

O CLB oferece suporte a redirecionamento de porta. Para ver um exemplo, consulte Use CLB to redirect HTTP requests to HTTPS.

Suporte a intervalo de portas para listeners da Camada 4

Não. Para escutar em um intervalo de portas com um listener tcp ou udp, crie uma instância do Network Load Balancer (NLB) e ative o recurso All Ports para o listener. Para mais informações, consulte Use the NLB All Ports listener feature to forward traffic on multiple ports.

Considerações sobre a configuração da porta do listener

Algumas operadoras classificam portas como 25, 135, 139, 444, 445, 5800 e 5900 como de alto risco e as bloqueiam por padrão. Mesmo com a permissão dessas portas nas regras do grupo de segurança, usuários em regiões restritas podem não conseguir acessar seus serviços. Recomendamos usar outras portas sem classificação de alto risco.

• Para obter informações sobre as portas usadas por aplicações em sistemas Windows Server, consulte a Documentação da Microsoft Service overview and network port requirements for Windows Server.

• Para mais informações sobre portas comuns, consulte Common ports.

Configuração de listener para WebSocket

• Se os servidores de backend hospedam serviços WebSocket, configure um listener tcp ou um listener HTTP.

• Se os servidores de backend hospedam serviços WebSocket Secure, configure um listener tcp ou um listener https.

Efeito das alterações na configuração do listener

As alterações entram em vigor imediatamente e se aplicam apenas a novas requisições. As conexões existentes não são afetadas.

Caracteres especiais em regras de encaminhamento de URL

É necessário codificar caracteres especiais em uma URL (URL-encode) para garantir o acesso adequado. Por exemplo, o caractere cerquilha (#) é codificado como %23, resultando na URL http://www.example.com/%23/. Para as regras completas de codificação, consulte a RFC 3986.

Gerencie servidores de backend para regras de encaminhamento

Na página Forwarding Rule, clique em nome do grupo de servidores virtuais de destino na coluna Virtual Server Group. Na página Edit Virtual Server Group, edite, adicione ou exclua servidores de backend e modifique as portas ou os pesos deles.

O CLB oferece suporte à definição de limites de tamanho para o corpo da requisição?

O CLB não oferece suporte ao parâmetro client_max_body_size. O limite de tamanho do corpo da requisição de 50 GB pertence ao Application Load Balancer (ALB), e não ao CLB.

Para controlar o tamanho do corpo da requisição, use um listener TCP da Camada 4 e configure client_max_body_size no servidor web da instância ECS de backend (como o Nginx):

http {
    client_max_body_size 100m;
}

Com um listener TCP, o CLB encaminha o tráfego da Camada 4 de forma transparente, e o limite de tamanho do corpo da requisição é aplicado pela instância ECS de backend.

Como a largura de banda é calculada para instâncias do CLB com largura de banda fixa?

As larguras de banda de entrada e de saída de uma instância do CLB com largura de banda fixa são calculadas de forma independente. Após defina o valor da largura de banda fixa, tanto a largura de banda de saída quanto a de entrada são limitadas individualmente ao valor configurado. Não é necessário somá-las. Por exemplo, se você defina a largura de banda fixa como 80 Mbps, a largura de banda máxima de saída será de 80 Mbps e a largura de banda máxima de entrada também será de 80 Mbps. Os dois valores são calculados de forma independente e não se afetam.

Visualize os dados de monitoramento em tempo real da largura de banda de saída e de entrada na página de monitoramento do console do CLB. Nas métricas de monitoramento, inBitsPS representa a largura de banda de entrada e outBitsPS representa a largura de banda de saída. Recomendamos o uso dos dados de monitoramento no nível de minuto no console como referência ao ajustar a largura de banda.

Queda de tráfego sem exceder o limite de largura de banda

Esse problema geralmente ocorre pelos seguintes motivos:

• O monitoramento de largura de banda da alibaba cloud usa médias de um minuto. Se um pico de tráfego instantâneo dentro de um segundo exceder o limite de largura de banda da instância, o sistema descartará o tráfego. Isso pode acontecer mesmo se a largura de banda média durante todo o minuto permanecer abaixo do limite configurado. Como resultado, o gráfico de monitoramento pode mostrar que o uso geral da largura de banda é inferior ao limite especificado.

• As instâncias do CLB são executadas em um cluster de servidores que distribui uniformemente as requisições recebidas entre seus servidores. A largura de banda de pico configurada também é distribuída entre os servidores do cluster. Se os dados que você baixe por uma única conexão de cliente excederem o limite de um servidor individual, o sistema descartará o tráfego. Para mais informações sobre como é calculado o tráfego máximo de download para uma única conexão, consulte Why can't a connection reach the peak bandwidth in certain scenarios?.

Tráfego monitorado excede o limite configurado

As instâncias do CLB usam um cluster de servidores para limitação de taxa distribuída. O limite de taxa de pico para um único nó é calculado como: Limite de taxa de pico para um único nó = Largura de banda total configurada / (N - 1), onde N é o número de nós no cluster. Como resultado, o limite de taxa efetivo total pode ser ligeiramente superior ao valor configurado.

A conexão não atinge a largura de banda de pico

• Cenário: Uma única conexão com uma instância pública do CLB que usa o método de faturamento por especificação (largura de banda fixa) pode não atingir a largura de banda de pico configurada. Esse problema costuma ocorrer durante testes de estresse de cliente único ou ao transferir um pacote de dados muito grande.

• Causa:

  As instâncias do CLB são executadas em um cluster de servidores. O cluster distribui uniformemente todas as requisições recebidas entre seus servidores.

  O tráfego máximo de download para uma única conexão é calculado da seguinte forma: Peak download traffic per connection = Total configured bandwidth / (N - 1), onde N é o número de servidores no cluster. N é 4 para um listener da Camada 4 e 8 para um listener da Camada 7. Por exemplo, ao definir o limite de largura de banda como 10 Mbps no console, a largura de banda total poderá atingir 10 Mbps com o uso de vários clientes simultaneamente. No entanto, o tráfego máximo que um único cliente pode baixar é de 10 / (4 - 1) = 3.33 Mbps.

• Solução:

  • Use o método de faturamento por tráfego para a instância pública do CLB.

  • Use uma instância NLB ou ALB com um EIP e largura de banda compartilhada. Essa configuração é mais elástica e evita essa limitação.

A instância do CLB não atinge o QPS de pico

• Cenário: Com o uso de um número pequeno de conexões persistentes, as conexões podem não ser distribuídas para todos os servidores no cluster de encaminhamento. Como resultado, a instância do CLB pode não atingir seu QPS de pico.

• Causa:

  As instâncias do CLB são implantadas em um cluster. O sistema distribui as requisições recebidas uniformemente entre os servidores do cluster. Portanto, o QPS de pico de uma instância do CLB também é distribuído entre esses servidores. O QPS máximo para um único servidor é calculado da seguinte forma: Peak QPS per server = Total instance QPS / (N - 1), onde N é o número de servidores no cluster de encaminhamento. Por exemplo, ao comprar uma instância do CLB da especificação slb.s1.small, que suporta 1.000 QPS, o QPS total poderá atingir 1.000 com o uso de vários clientes. No entanto, se o cluster tiver 8 servidores, o QPS máximo para um único servidor será de 1000 / (8 - 1) = 142 QPS.

  Nota

  Novas compras de instâncias do CLB com pagamento por especificação serão descontinuadas às 00:00:00 de 1 de junho de 2025 (UTC+8). Para mais informações, consulte End of sale for pay-by-specification CLB instances.

• Solução:

  • Use conexões de curta duração a partir de um único cliente para testes de estresse.

  • Reduza a reutilização de conexões com base nos requisitos reais do seu negócio.

  • Faça upgrade da especificação da instância do CLB. Para mais informações, consulte Upgrade or downgrade a pay-as-you-go (pay-by-specification) instance.

  • Use uma instância ALB. Esse tipo de instância oferece maior elasticidade.

A taxa de novas conexões não atinge o pico

• Cenário: Com o uso de uma instância do Classic Load Balancer (CLB) com pagamento por especificação, a taxa de novas conexões (CPS) pode não atingir o nível especificado, especialmente durante testes de estresse de cliente único ou quando o tráfego vem de uma única source.

  Nota

  Novas compras de instâncias do CLB com pagamento por especificação serão descontinuadas às 00:00:00 de 1 de junho de 2025 (UTC+8). Para mais informações, consulte End of sale for pay-by-specification CLB instances.

• Causa:

  O sistema de balanceamento de carga usa uma arquitetura de cluster para alta disponibilidade e escalabilidade. Ele distribui as requisições de conexão recebidas uniformemente entre os servidores do cluster. Portanto, o CPS de pico de uma instância do CLB também é distribuído entre esses servidores.

  O CPS de pico para um único servidor é calculado da seguinte forma: CPS de pico por servidor = CPS total da instância / (N - 1), onde N é o número de servidores no cluster de encaminhamento.

  Por exemplo, ao comprar uma instância do CLB da especificação slb.s1.small avaliada em 3.000 CPS, a instância poderá atingir os 3.000 CPS completos com requisições de vários clientes. No entanto, se o cluster tiver 4 servidores, o CPS máximo para um único servidor será de 3000 / (4 - 1) = 1.000 CPS.

• Solução:

  • Altere o método de faturamento da instância de pagamento por especificação para pagamento conforme o uso. Instâncias com pagamento conforme o uso não estão vinculadas a uma especificação de desempenho específica e oferecem limites mais altos, o que ajuda a evitar gargalos.

  • Faça upgrade para um Network Load Balancer (NLB) em cenários com alta concorrência e alta taxa de novas conexões. O NLB oferece desempenho e elasticidade superiores em comparação ao CLB. Uma única instância do NLB suporta 100 milhões de conexões simultâneas, sendo ideal para aplicações de grande escala e evitando as limitações de CPS da arquitetura de cluster do CLB.

Intervalos de tempo limite de conexão suportados

• Tempo limite de conexão do listener TCP: 10 a 900 segundos.

• Listener HTTP:

  • Tempo limite de ociosidade: 1 a 60 segundos.

  • Tempo limite de requisição: 1 a 180 segundos.

• Listener HTTPS:

  • Tempo limite de ociosidade: 1 a 60 segundos.

  • Tempo limite de requisição: 1 a 180 segundos.

Causas de tempos limite de conexão do CLB

Os seguintes problemas no lado do servidor podem causar tempos limite de conexão com o endereço de service do CLB:

• O endereço de service é bloqueado por medidas de segurança

  Isso inclui limpeza de tráfego, filtragem blackhole ou proteção WAF. O WAF, por exemplo, envia pacotes RST tanto para o cliente quanto para o cluster de servidores após estabelecer uma conexão.

• Portas de cliente insuficientes

  Esse problema é comum durante testes de estresse. A escassez de portas de cliente pode causar falhas de conexão. Por padrão, o CLB remove a opção de carimbo de data/hora das conexões TCP, impedindo a ativação do recurso tw_reuse do kernel Linux (reutilização de conexões no estado TIME_WAIT). Isso leva ao acúmulo de conexões no estado TIME_WAIT e à escassez de portas de cliente disponíveis.

  Solução: Use conexões persistentes em vez de conexões de curta duração. Encerre a conexão enviando um pacote RST ao definir a opção de socket SO_LINGER, em vez de enviar um pacote FIN.

• A fila de aceitação (accept queue) do servidor de backend está cheia

  Se a fila de aceitação de um servidor de backend estiver cheia, ele não enviará uma resposta SYN-ACK, causando um tempo limite no cliente.

  Solução: O valor padrão de net.core.somaxconn é 128. Avalie o volume de tráfego e ajuste esse valor para atender às suas necessidades. Em seguida, execute sysctl -w net.core.somaxconn=<new_value> para alterar o parâmetro e reinicie a aplicação no servidor de backend.

• Um servidor de backend da Camada 4 acessa o endereço de service do seu próprio balanceador de carga

  Os listeners da Camada 4 do CLB (TCP/UDP) não permitem que um servidor de backend atue como cliente e servidor ao mesmo tempo. Se um servidor de backend tentar acessar o endereço de service da instância do CLB à qual está anexado, a conexão falhará. Cenários comuns incluem uma aplicação de backend que redireciona para o endereço de service do CLB por meio da construção de uma URL e uma instância ECS em uma VPC que acessa o endereço de service de sua própria instância do CLB pela rede pública, causando um loopback de tráfego.

  Esse comportamento é causado pela forma como o CLB encaminha o tráfego na Camada 4 (LVS). Ao receber um pacote de uma instância ECS de backend, o CLB reescreve o endereço IP de destino e o encaminha para um servidor de backend. Caso o CLB encaminhe a requisição de volta para a mesma instância ECS de source, os endereços IP de source e de destino do pacote serão idênticos ao endereço IP dessa instância ECS. Consequentemente, a resposta é concluída localmente na instância ECS e não retorna pelo CLB, impossibilitando o estabelecimento da conexão.

  • Se a instância do CLB tiver apenas um servidor de backend, cada requisição desse servidor de backend será encaminhada de volta para ele mesmo, resultando em uma taxa de falha de conexão de 100%.

  • Se a instância do CLB tiver vários servidores de backend, por exemplo, dois servidores de backend com pesos iguais, o CLB encaminha cerca de 50% das requisições para o outro servidor de backend (a conexão é bem-sucedida). O CLB encaminha cerca de 50% das requisições de volta para o servidor de backend original (a conexão falha). A taxa de sucesso geral é de cerca de 50%.

  Solução:

  • Use um cliente diferente para acessar o endereço de service em vez do servidor de backend da Camada 4.

  • Migre para uma instância do Network Load Balancer (NLB) e desative a preservação do IP do cliente (client IP preservation) no grupo de servidores. Após desativar esse recurso, uma instância ECS no grupo de servidores pode atuar como servidor de backend e cliente da instância do NLB. Para obter o endereço IP de source do cliente, ative o Proxy Protocol. Para mais informações, consulte How can an ECS instance act as both a backend server and a client of an NLB instance?.

  • Use o Alibaba Cloud DNS PrivateZone para configurar a resolução de nome de domínio privado, para resolver o domínio do service para o endereço IP privado do servidor de backend. As requisições chegam ao servidor de backend diretamente pela rede interna, sem passar pela instância do CLB, eliminando a condição de loopback. Essa abordagem aplica-se a cenários em que um servidor de backend acessa o service da instância do CLB à qual está anexado por meio de um nome de domínio. Nesse caso, as requisições ignoram o CLB e não se beneficiam do balanceamento de carga nem das verificações de integridade. Use essa abordagem apenas para requisições iniciadas pelos próprios servidores de backend.

  • Modifique o arquivo hosts no servidor onde o cliente é executado para apontar o domínio do service para o endereço IP privado do servidor de backend. O efeito é o mesmo do PrivateZone, e essa abordagem é adequada para cenários que exigem a solução alternativa apenas em alguns servidores individuais. Como o arquivo hosts exige manutenção em cada servidor, prefira o PrivateZone para um grande número de servidores de backend.

• Tratamento inadequado de pacotes RST no tempo limite de conexão

  Se não houver atividade por 900 segundos após o estabelecimento de uma conexão TCP, o CLB envia pacotes RST tanto para o cliente quanto para o servidor e fecha a conexão. Algumas aplicações não lidam corretamente com o pacote RST e tentam enviar dados pela conexão fechada, causando um tempo limite na aplicação.

  Nota

  O tempo limite padrão é de 900 segundos, mas pode ser ajustado conforme necessário.

Tempos limite de conexão HTTP e HTTPS

• Uma conexão persistente HTTP suporta no máximo 100 requisições consecutivas. Após atingir esse limite, o CLB fecha a conexão.

• O tempo limite de ociosidade entre duas requisições HTTP ou HTTPS em uma conexão persistente é configurável de 1 a 60 segundos (com uma margem de erro de 1 a 2 segundos). A conexão TCP é fechada se esse tempo limite for excedido. Para aplicações que usam conexões persistentes, recomendamos o envio de uma requisição de heartbeat pelo menos a cada 13 segundos.

• O handshake de três vias TCP entre uma instância do CLB e uma instância ECS de backend expira após 5 segundos. Se o handshake expirar, o CLB tenta a próxima instância ECS. Identifique esse problema verificando o tempo de resposta upstream no log de acesso.

• O tempo limite da requisição (tempo de espera da instância do CLB por uma resposta de uma instância ECS) é configurável de 1 a 180 segundos. Caso esse tempo limite seja excedido, o CLB geralmente retorna um código de status 504 ou 408 para o cliente. Identifique esse problema verificando o tempo de resposta upstream no log de acesso.

• O tempo limite de reutilização de sessão HTTPS é de 300 segundos. Após esse período, o mesmo cliente precisa realizar um handshake SSL completo novamente.

O CLB repete requisições automaticamente após um tempo limite?

Não. Se uma requisição exceder o tempo limite configurado do listener (por exemplo, o padrão de 60 segundos), o CLB encerra a conexão e retorna um código de erro 504 ao cliente. O CLB não repete a requisição automaticamente. Para implementar repetições de requisição, implemente a lógica de repetição no lado do cliente.

Mecanismo de repetição implícita para listeners HTTPS da Camada 7 do CLB

Quando um servidor de backend não responde ou retorna um erro em um listener HTTPS da Camada 7 do CLB, o CLB aciona automaticamente um mecanismo de repetição implícita. O CLB tenta sequencialmente outros servidores de backend íntegros. A repetição é iniciada pelo próprio CLB e não depende do cliente. Em caso de tempo limite, o CLB registra um erro 504 e repete a tentativa em outro nó de backend. Apenas o resultado da tentativa final é retornado ao cliente.

Visualizar registros de repetição: O console do CLB não fornece uma interface dedicada para consultar logs de repetição. Visualize os registros de repetição nos logs de acesso do CLB. Vários valores no campo upstream_addr (separados por vírgulas) servem como evidência de uma repetição. Os vários valores em upstream_response_time correspondem aos tempos de resposta de cada tentativa. Por exemplo, upstream_addr: 10.0.0.1:80, 10.0.0.2:80 indica que o CLB tentou dois servidores de backend sequencialmente.

Comportamento do CLB em caso de desconexão antecipada do cliente

Não. O CLB não fecha a conexão com o servidor de backend durante operações de leitura e gravação.

Ativar conexões persistentes de backend para o CLB

As instâncias do CLB não suportam conexões persistentes de backend. Para usar esse recurso, crie uma instância ALB, configure um listener HTTP ou HTTPS e ative as conexões persistentes de backend para o grupo de servidores ALB correspondente. Para mais informações, consulte Create and manage a server group.

Solucionar problemas de alta latência do CLB

Acessar um service de backend por meio de uma instância do CLB introduz uma pequena quantidade de latência extra em comparação ao acesso direto ao servidor de backend. Isso é normal. Os listeners da Camada 7 do CLB usam uma arquitetura de proxy reverso (Tengine), adicionando um salto de rede extra e tempo de processamento de protocolo. A latência extra para os listeners da Camada 4, que usam LVS para encaminhamento, geralmente é menor.

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 CLB access logs e concentre-se nos seguintes campos:

   • request_time: O intervalo, em segundos, desde o recebimento do primeiro pacote de requisição pelo CLB até o retorno da resposta.

   • upstream_response_time: O intervalo, em segundos, desde o estabelecimento da conexão com um servidor de backend até a recepção total dos dados e o fechamento da conexão.

2. Identificar a source da latência:

   • Se upstream_response_time for alto: A latência provavelmente é causada pelo processamento lento no servidor de backend. Verifique o desempenho da aplicação de backend, a eficiência das consultas ao banco de dados e o uso de recursos (cpu/memória), ou adicione mais servidores de backend para distribuir a carga.

   • Se request_time for muito maior que upstream_response_time, a latência pode estar no link de rede do cliente até o CLB. Execute um teste contínuo de ping ou realize o rastreamento de rota MTR do cliente até o endereço de service do CLB para solucionar problemas no link de rede.

3. Acesso entre regiões: Se o cliente e a instância do CLB 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.

Solucionar erros 502, 503 ou 504

Ao acessar um service de backend por meio de uma instância do CLB, os códigos de erro 502, 503 ou 504 geralmente indicam que a requisição não foi processada corretamente pelo servidor de backend. Os códigos de erro significam o seguinte:

• 502 Bad Gateway: O CLB não conseguiu encaminhar a requisição para um servidor de backend ou receber uma resposta dele. As causas comuns incluem services de backend inacessíveis ou falha em todas as verificações de integridade.

• 503 Service Temporarily Unavailable: Geralmente causado por tráfego acima dos limites ou por um servidor de backend indisponível. Esse erro é retornado quando o tráfego instantâneo excede os limites da especificação da instância do CLB.

• 504 Gateway Timeout: O servidor de backend expirou. As causas comuns incluem tempos de processamento longos no backend ou um tempo limite ao estabelecer uma conexão com o servidor de backend.

Primeira etapa: Verificar os logs de acesso

Primeiro, ative CLB access logs e verifique os campos status (código de status retornado pelo CLB ao cliente) e upstream_status (código de status retornado pelo servidor de backend ao CLB) nos logs:

• Se status e upstream_status forem iguais, o CLB provavelmente passou o código de erro diretamente do servidor de backend. Investigue o motivo de o servidor de backend estar retornando esse erro.

• Se upstream_status for "-" ou diferente de status, o erro foi retornado pelo CLB. Consulte os pontos a seguir para solucionar o problema.

Solucionar erros 502

• Falha em todas as verificações de integridade do servidor de backend: Quando todos os servidores de backend associados a um listener falham nas verificações de integridade, o CLB não consegue encaminhar requisições e, em vez disso, retorna um erro 502. Verifique o status da verificação de integridade no console e solucione a causa da falha, como o bloqueio do bloco CIDR do sistema CLB 100.64.0.0/10 por iptables ou software de segurança de terceiros, um código de status de verificação de integridade incompatível ou um caminho de verificação de integridade inexistente. Para mais informações, consulte CLB Health Check FAQ.

• O backend retorna um código de erro que o CLB converte para 502: Se um servidor de backend retornar determinados códigos de erro (como 504 ou 444), o CLB poderá retornar um erro 502 ao cliente. Verifique o campo upstream_status no log de acesso para confirmar o código de status real retornado pelo backend e investigar a causa do erro no backend.

• Erros no service de backend: Alta carga, respostas malformadas ou fechamentos inesperados de conexão no servidor de backend também podem causar erros 502. Verifique os logs do servidor de backend e o uso de recursos, como cpu e memória.

Solucionar erros 503

• O tráfego excede os limites de especificação da instância: O CLB retorna um erro 503 se o QPS, a largura de banda ou a taxa de novas conexões do tráfego recebido excederem os limites da especificação atual da instância do CLB. Recupere essas métricas em cloud Monitor.

• O tráfego instantâneo excede os limites, mas não é mostrado no monitoramento: O cloud Monitor exibe dados com granularidade de nível de minuto e pode não mostrar picos de nível de segundo. Verifique a contagem de requisições de nível de segundo no log de acesso. Se o upstream_status for "-", indica que a requisição não foi enviada ao servidor de backend.

Solucionar erros 504

• Tempo limite de resposta do backend: Se o servidor de backend não responder dentro do período de tempo limite da requisição configurado para o listener, o CLB retorna um erro 504. Verifique o campo upstream_response_time no log de acesso para confirmar o tempo de resposta real do backend e ajuste o tempo limite da requisição do listener de acordo.

• Tempo limite de conexão do backend: O tempo limite para uma instância do CLB concluir um handshake de três vias TCP com uma instância ECS de backend é de 5 segundos. Se o upstream_response_time no log de acesso for muito longo, pode indicar um problema de conexão com o servidor de backend. Recomendamos a captura de pacotes para investigar a causa.

• Alta carga no backend: O alto uso de recursos (cpu, memória, etc.) no servidor de backend pode fazer com que os tempos de resposta excedam o período de tempo limite. Investigue e otimize o desempenho do service de backend, ou adicione mais servidores de backend para distribuir a carga.

Solucionar problemas de acesso ao CLB

Se você não conseguir acessar o seu service após configurar uma instância do CLB, siga estas etapas para solucionar o problema camada por camada:

1. Verificar a resolução do nome de domínio: Ao acessar o service usando um nome de domínio, certifique-se de que a resolução do nome de domínio aponte corretamente para o endereço de service da instância do CLB. Use os comandos nslookup ou dig para verificar a resolução. A resolução incorreta do nome de domínio é um motivo comum para falhas de acesso.

2. Verificar a configuração do listener: No console do CLB, verifique a criação do listener e confirme se a porta e o protocolo do listener estão configurados corretamente. Se um listener estiver ausente ou mal configurado, o CLB não consegue encaminhar requisições.

3. Verificar o status da verificação de integridade: No console do CLB, verifique o status da verificação de integridade dos servidores de backend. Se todos os servidores de backend falharem nas verificações de integridade, o CLB não consegue encaminhar requisições.

4. Verificar as configurações de firewall: Verifique se o iptables ou o software de segurança de terceiros no servidor de backend permite a porta do service de backend e o bloco CIDR do sistema CLB 100.64.0.0/10.

5. Verificar se o service de backend está em execução adequada: Acesse o servidor de backend diretamente e confirme se o próprio service de backend está respondendo executando telnet <private IP address of the backend server> <port> (Camada 4) ou curl -I http://<private IP address of the backend server> (Camada 7).

6. Solucionar problemas no link de rede: Teste o acesso ao endereço de service do CLB a partir de diferentes ambientes de rede. Se apenas a sua rede local for afetada, execute um teste contínuo de ping ou use o rastreamento de rota MTR para investigar mais a fundo.

Acesso por IP, mas não por nome de domínio

O motivo mais comum é que o nome de domínio não concluiu seu registro ICP (ICP filing).

De acordo com as regulamentações, quando um nome de domínio é usado para acesso público na China continental, ele deve ter um registro ICP válido. O acesso a domínios sem registro ICP é bloqueado, resultando em um código de status 403 ou em uma redefinição de conexão.

Recomendamos que você siga estas etapas para solucionar e resolver o problema:

1. Verificar o status do registro ICP: Acesse o Alibaba Cloud ICP Filing System para verificar se o seu nome de domínio concluiu o registro ICP. Caso contrário, conclua o processo primeiro. Para mais informações, consulte ICP filing process.

2. Verificar se é necessário transferir o seu registro ICP: Se o seu nome de domínio tiver um registro ICP com outro provedor de services de cloud, mas você estiver usando-o com a Alibaba Cloud pela primeira vez, também será necessário concluir um transfer ICP filing para associar as informações do registro à Alibaba Cloud. A não conclusão dessa transferência também pode resultar em acesso bloqueado.

3. Descartar outras causas: Se o nome de domínio tiver um registro ICP e a transferência do registro ICP também estiver concluída, verifique se a resolução do nome de domínio aponta corretamente para o endereço de service do CLB (use o comando nslookup ou dig para verificar) e se a porta e a configuração do protocolo do listener do CLB correspondem ao método de acesso do nome de domínio.

Impacto do controle de acesso no tráfego interno

Sim. O controle de acesso é aplicado no nível do listener e afeta tanto o tráfego interno quanto o público. Ao configurar uma lista de permissões que permita apenas endereços IP públicos específicos, as requisições de endereços IP internos que não estejam na lista de permissões serão bloqueadas. Para evitar a interrupção dos services internos, recomendamos a adição dos blocos CIDR internos relevantes à lista de permissões ou o uso do Cloud Firewall para restringir o acesso público ao EIP.

Solucionar tempos limite de requisição durante testes de estresse

Ao realizar testes de estresse em um CLB da Camada 7, ao receber códigos de status 504 ou tempos limite de requisição, e o upstream_response_time nos logs estiver agrupado em torno de 5 segundos, o problema geralmente é um tempo limite de conexão causado por uma falha no handshake de três vias TCP entre o CLB e o servidor de backend. Um motivo comum é a tabela de rastreamento de conexão (nf_conntrack) no servidor de backend estar cheia, fazendo com que o servidor descarte pacotes para novas conexões.

Acesse o servidor de backend e verifique o log /var/log/messages. Confirme o problema se a seguinte mensagem de erro aparecer:

nf_conntrack: table full, dropping packet

Solução: Ajuste os valores dos seguintes parâmetros nf_conntrack com base nos requisitos reais do seu service:

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Nota: O comando anterior tem efeito apenas temporário. As alterações são perdidas após a reinicialização da instância. Para tornar as alterações permanentes, grave os parâmetros em /etc/sysctl.conf.

Impacto de falhas de backend em listeners compartilhados

Cenário: Há vários sites, como um site estático www.example.com e um site dinâmico app.example.com, anexados ao mesmo listener do CLB. Quando o banco de dados de backend do site dinâmico falha, o site estático também se torna inacessível e retorna um erro HTTP 502.

Causa: Ambos os sites compartilham o mesmo listener, e o Health Check Domain Name do listener está configurado com o nome de domínio do site dinâmico. Quando o backend do site dinâmico falha, todos os servidores de backend falham em suas verificações de integridade. Como resultado, o CLB para de encaminhar tráfego para o backend, afetando todos os sites configurados sob esse listener.

Solução: Use instâncias separadas do CLB para fornecer balanceamento de carga para os sites dinâmicos e estáticos, a fim de alcançar o isolamento de negócios. Dessa forma, uma falha no site dinâmico não afeta o site estático.

Motivos para falha na persistência de sessão

• A persistência de sessão não está ativada: Verifique se a persistência de sessão está ativada na configuração do listener.

• Problemas no listener HTTP/HTTPS: Para um listener HTTP ou HTTPS, o CLB não pode inserir o cookie necessário para a persistência de sessão em uma resposta 4xx.

  Solução: Mude para um listener TCP, que usa o endereço IP de source do cliente para manter a persistência de sessão. Para maior confiabilidade, insira também um cookie na instância ECS de backend e adicione uma verificação de validação de cookie.

• Problemas de redirecionamento 302: Um redirecionamento 302 pode alterar a string SERVERID usada para a persistência de sessão.

  Se uma instância ECS de backend emitir um redirecionamento 302, isso pode alterar a string SERVERID no cookie injetado pelo CLB, quebrando a persistência de sessão.

  Como solucionar: Use as ferramentas de desenvolvedor do seu navegador ou um sniffer de pacotes para capturar requisições e respostas. Analise os pacotes para verificar se há respostas de redirecionamento 302 e compare as strings SERVERID nos cookies antes e depois do redirecionamento.

  Solução: Mude para um listener TCP, que usa o endereço IP de source do cliente para manter a persistência de sessão. Para maior confiabilidade, insira também um cookie na instância ECS de backend e adicione uma verificação de validação de cookie.

• O tempo limite de persistência de sessão é muito curto: Se o valor do tempo limite for muito baixo, a persistência de sessão poderá falhar.

Visualizar a string de persistência de sessão

Use as ferramentas de desenvolvedor do seu navegador (F12) para verificar se os cabeçalhos de resposta contêm a string SERVERID ou uma palavra-chave personalizada. Alternativamente, execute o comando curl www.example.com -c /tmp/cookie123 para salvar o cookie e, em seguida, execute curl www.example.com -b /tmp/cookie123 para enviar o cookie na próxima requisição.

Testar a persistência de sessão com curl

1. Crie uma página de teste.

   Em cada instância ECS de backend, crie uma página de teste que exiba o endereço IP privado da instância. Esse endereço identifica qual servidor está lidando com uma requisição. Se o endereço IP for consistente em várias requisições, a persistência de sessão está funcionando.

2. Execute o comando curl em um sistema Linux.

   Suponha que o endereço IP do service CLB seja 10.170.XX.XX e a URL da página de teste seja http://10.170.XX.XX/check.jsp.

   1. Acesse o servidor Linux que você usará para o teste.

   2. Execute o seguinte comando para recuperar o cookie do balanceador de carga.

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Nota

      Por padrão, o CLB usa injeção de cookie para persistência de sessão. No entanto, o curl não salva nem envia cookies por padrão. Salve e baixe o cookie antes de testar. Caso contrário, as requisições subsequentes do curl serão enviadas sem um cookie, levando a um roteamento aleatório, podendo levar à conclusão incorreta de que a persistência de sessão não está funcionando.

   3. Execute o seguinte comando para realizar testes contínuos.

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Nota

      Em a≤30, 30 é o número de testes repetidos e pode ser modificado conforme necessário. O comando grep '10.170.XX.XX' filtra as informações de IP exibidas. Altere 10.170.XX.XX para o endereço IP privado da instância ECS de backend.

   4. Observe os endereços IP retornados pelo teste. Se todas as respostas vierem do mesmo endereço IP privado do servidor de backend, a persistência de sessão está funcionando corretamente. Caso contrário, a persistência de sessão não está funcionando corretamente.

Configurar cookies de backend para o modo Rewrite Cookie**

Ao selecion o modo Rewrite Cookie para a persistência de sessão da Camada 7, configure um cookie com o mesmo nome em seus servidores de backend. O nome do cookie deve ser idêntico ao configurado no console do CLB. Os exemplos a seguir mostram como configurar isso em servidores web comuns:

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

Solucionar carga desigual entre servidores

Caso haja vários servidores de backend anexados a uma instância do CLB e um servidor tiver uma carga significativamente maior que os outros, siga estas etapas para solucionar o problema:

1. Verificar se a persistência de sessão está ativada: Os listeners HTTP/HTTPS do CLB suportam persistência de sessão por meio de injeção de cookie. Quando a persistência de sessão está ativada, todas as requisições do mesmo cliente são roteadas para o mesmo servidor de backend. A geração de um grande número de requisições por poucos clientes concentra o tráfego em servidores de backend específicos, levando a uma carga desigual.

2. Desativar a persistência de sessão para distribuição uniforme: Caso a aplicação não dependa do estado da sessão (como cookies ou estado de login), desative a persistência de sessão para o listener. Uma vez desativada, o CLB distribui as requisições uniformemente para todos os servidores de backend com base no algoritmo de agendamento configurado, como round-robin ponderado. Execute essa ação fora dos horários de pico e verifique imediatamente se a sua aplicação permanece disponível. A desativação da persistência de sessão afeta services com estado, como carrinhos de compras ou logins persistentes. Avalie a dependência da sua aplicação em relação à persistência de sessão antes de prosseguir.

3. Verificar a carga da aplicação nos servidores de backend: Mesmo que o CLB distribua o tráfego uniformemente, diferenças no uso de cpu, memória ou outros recursos nos próprios servidores de backend podem fazer com que alguns servidores experimentem uma carga maior. Acesse cada servidor de backend, compare o uso de recursos das suas aplicações e verifique se há gargalos de desempenho.

Falha ao carregar estilos por HTTPS

Sintoma:

Há um listener HTTP e um HTTPS, ambos usando os mesmos servidores de backend. Ao acessar o site por meio do listener HTTP, ele é exibido corretamente. No entanto, ao acessar por meio do listener HTTPS, o layout parece quebrado.

Causa:

Um balanceador de carga não bloqueia arquivos JavaScript (JS) por padrão. Esse problema pode ser causado pelo seguinte:

• O certificado não é compatível com o nível de segurança do navegador.

• O certificado é de um provedor de terceiros não confiável. Entre em contato com o emissor para resolver isso.

Solução:

1. Ao abrir o site, siga os avisos do navegador para carregar os scripts.

2. Adicione o certificado correspondente ao repositório de confiança do cliente.

Certificados de servidor de backend para redirecionamento de HTTP para HTTPS

Não. Basta configurar um certificado no listener HTTPS da instância do CLB. Para mais informações, consulte Configure an SSL certificate.

O navegador mostra a expiração antiga do certificado após a atualização

Isso geralmente ocorre se a instância do CLB estiver integrada de forma transparente ao WAF 2.0 e o certificado do WAF não tiver sido atualizado (atualize o certificado). O WAF sincroniza os certificados do CLB periodicamente. Para acionar uma sincronização imediata, desative e, em seguida, reative o redirecionamento de tráfego no console do WAF para forçar a atualização do certificado. Essa ação pode causar uma breve interrupção do service, com duração de 1 a 2 segundos.

Versão do protocolo HTTP para acesso ao servidor de backend

• Se uma requisição de cliente usar HTTP/1.1 ou HTTP/2.0, o listener da Camada 7 se comunica com o servidor de backend usando HTTP/1.1.

• Se uma requisição de cliente usar uma versão de protocolo diferente de HTTP/1.1 ou HTTP/2.0, o listener da Camada 7 se comunica com o servidor de backend usando HTTP/1.0.

Recuperar a versão do protocolo do cliente

Sim.

Limitação baseada em URL

O CLB não suporta limitação baseada em URL, apenas limitação de largura de banda no nível do listener.

O ALB suporta limitação baseada em URL. Configure uma configure a listener forwarding rule para aplicar limitação de QPS a um caminho específico. Esse recurso deve ser usado em conjunto com a ação "Forward to".

O campo Transfer-Encoding: chunked**

Transfer-Encoding: chunked é um campo de protocolo HTTP padrão que indica que o corpo da mensagem é enviado usando transferência fragmentada (chunked transfer). O CLB da Camada 7 é um proxy reverso construído no Tengine. Ao encaminhar requisições para um servidor de backend, ele usa a transferência fragmentada. Portanto, o servidor de backend recebe esse campo no cabeçalho da requisição. Esse é um comportamento normal para um proxy reverso e não afeta seus services. Um CLB da Camada 4 apenas encaminha tráfego e não adiciona esse campo.

Campos de cabeçalho de resposta removidos

Para implementar a persistência de sessão, o CLB remove campos como Date, Server, X-Pad e X-Accel-Redirect do cabeçalho de resposta. Para reter esses campos, adicione um prefixo aos seus cabeçalhos de resposta personalizados, como xl-server, ou mude para um listener TCP da Camada 4.

proxy_buffering e proxy_cache

Os recursos proxy_buffering e proxy_cache não estão ativados para o CLB. O CLB não armazena em buffer ou cache os dados de requisição ou resposta. Em vez disso, ele encaminha as requisições do cliente diretamente para os servidores de backend em um modo de encaminhamento transparente. Esse é o comportamento padrão do CLB e não requer configuração adicional.

O CLB suporta proxy direto (forward proxy)?

O CLB não suporta proxy direto. O CLB é um balanceador de carga de proxy reverso: ele distribui as requisições do cliente para os servidores de backend, mas não atua como proxy para o acesso de um cliente a recursos externos da forma como um proxy direto faz. Caso precise de recursos de proxy direto, crie seu próprio proxy direto usando um service como o Nginx.

Ativar a proteção do WAF para o CLB

Impacto da desativação da ENI pública

Se uma instância ECS tiver um IP público, desativar sua interface de rede elástica pública afeta o service de balanceador de carga.

Isso ocorre porque, se existir uma interface de rede elástica pública, a rota padrão direciona o tráfego pela rede pública. A desativação da interface impede o envio dos pacotes de resposta de volta, interrompendo o service de balanceador de carga. Recomendamos não desativar a interface de rede elástica pública. Caso precise desativá-la, altere a rota padrão para a rede privada para evitar a interrupção do service. No entanto, considere se os seus services dependem do acesso à rede pública, por exemplo, para acessar o rds.

Suporte para requisições de cliente com um campo TOA

Não. Um campo TCP Option Address (TOA) fornecido pelo cliente entra em conflito com o campo TOA usado pelo balanceador de carga para comunicação interna. Esse conflito impede que o servidor de backend obtenha o endereço IP real do cliente.