☰

El grupo objetivo de AWS informa que no está en buen estado, pero la aplicación está en buen estado

tag-icon • tag-icon amazon-web-services amazon-elb
El grupo objetivo de AWS informa que no está en buen estado, pero la aplicación está en buen estado

Tengo un sitio web de IIS ejecutándose en AWS en una instancia EC2, ejecutándose en http://localhost:8088. Está detrás de un ELB que envía todo el tráfico HTTPS al grupo objetivo en el que se ejecuta la instancia EC2, por lo que el ELB redirige cualquier solicitud a http://my-dns-name a https://my-dns-name. y luego al grupo objetivo. Tengo una verificación de estado definida en el grupo objetivo que verifica que el /healthcheckpunto final tenga una respuesta 200 OK, y el punto final está configurado para permitir solicitudes no autenticadas (también conocidas como anónimas).

La aplicación en sí funciona bien; sin embargo, AWS informa que el grupo objetivo no está en buen estado, ya que recibe un código de respuesta 302 del punto final de verificación de estado. Si consulto el punto final directamente desde mi escritorio, por ejemplo, a través de PowerShell, Invoke-WebRequestobtengo la 200 OKrespuesta esperada. Si entro de forma remota a la instancia EC2 y ejecuto la misma consulta, también devuelve la 200 OKrespuesta esperada.

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

Pero si lo cambio para usar la dirección local de http://localhost:8088, la consulta falla:

$> 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

¿Alguna idea de por qué el grupo objetivo recibe una redirección 302, pero si hago una consulta directamente, obtengo 200 OK (a menos que use la dirección local)?

Respuesta1

Lo sentimos, esto fue un problema de codificación con la aplicación; había un RequireHttpsfiltro enterrado profundamente en el código de inicio de la aplicación, que obviamente intentaba realizar una redirección en segundo plano; AWS estaba revisando el sitio web usando HTTP y, por lo tanto, experimentó la redirección 302, pero cuando estaba revisando externamente estaba usando HTTPS, lo que no activó la redirección.

Respuesta2

Algunas cosas para comprobar aquí:

  1. ¿Se está ejecutando el firewall de Windows y bloqueando el puerto 8088?
  2. ¿IIS realmente escucha en 8088?
  3. ¿Su AWS TG está configurado para realizar la verificación de estado en 8088? Parece que se está ejecutando en el puerto 443 dada la respuesta 200 OK en https.

información relacionada