O grupo-alvo da AWS relata não íntegro, mas o aplicativo está íntegro

O grupo-alvo da AWS relata não íntegro, mas o aplicativo está íntegro

Eu tenho um site IIS rodando na AWS em uma instância EC2, rodando em http://localhost:8088. Ele está por trás de um ELB que envia todo o tráfego HTTPS para o grupo de destino em que a instância EC2 está sendo executada, portanto, qualquer solicitação para http://my-dns-name é redirecionada pelo ELB para https://my-dns-name e depois para o grupo-alvo. Eu tenho uma verificação de integridade definida no grupo de destino que verifica o /healthcheckendpoint em busca de uma resposta 200 OK, e o endpoint está configurado para permitir solicitações não autenticadas (também conhecidas como anônimas).

O aplicativo em si está funcionando bem; no entanto, a AWS está relatando que o grupo-alvo não está íntegro, pois está recebendo um código de resposta 302 do endpoint de verificação de integridade. Se eu consultar o endpoint diretamente da minha área de trabalho, por exemplo, por meio do PowerShell, Invoke-WebRequestobterei a 200 OKresposta esperada. Se eu acessar remotamente a instância do EC2 e executar a mesma consulta, ela também retornará a 200 OKresposta esperada.

$> Invoke-WebRequest -Uri https://my-dns-name/healthcheck -Method GET
StatusCode        : 200
StatusDescription : OK
Content           : {}
RawContent        : HTTP/1.1 200 OK

Mas se eu mudar para usar o endereço local de http://localhost:8088, a consulta falhará:

$> Invoke-WebRequest -Uri http://localhost:8088/healthcheck -Method GET
Invoke-WebRequest : Unable to connect to the remote server
At line:1 char:1
+ Invoke-WebRequest -Uri http://localhost:8088/healthcheck -Method GET

Alguma idéia de por que o grupo-alvo está recebendo um redirecionamento 302, mas se eu consultar diretamente, recebo 200 OK (a menos que eu use o endereço local)?

Responder1

Desculpe, este foi um problema de codificação do aplicativo; havia um RequireHttpsfiltro enterrado no código de inicialização do aplicativo, que obviamente tentava fazer um redirecionamento em segundo plano; A AWS estava verificando o site usando HTTP e, portanto, enfrentando o redirecionamento 302, mas quando eu estava verificando externamente, estava acessando HTTPS, o que não acionou o redirecionamento.

Responder2

Algumas coisas para verificar aqui:

  1. O firewall do Windows está em execução e bloqueando a porta 8088?
  2. O IIS está realmente escutando no 8088?
  3. O seu AWS TG está configurado para fazer a verificação de integridade no 8088? Parece que está sendo executado na porta 443, dada a resposta 200 OK em https.

informação relacionada