☰

Целевая группа AWS сообщает о нездоровье, но приложение работоспособно

tag-icon • tag-icon amazon-web-services amazon-elb
Целевая группа AWS сообщает о нездоровье, но приложение работоспособно

У меня есть веб-сайт IIS, работающий в AWS на экземпляре EC2, работающем на http://localhost:8088. Он находится за ELB, который отправляет весь трафик HTTPS в целевую группу, в которой запущен экземпляр EC2, поэтому любой запрос к http://my-dns-name перенаправляется ELB на https://my-dns-name, а затем в целевую группу. У меня есть проверка работоспособности, определенная в целевой группе, которая проверяет /healthcheckконечную точку на наличие ответа 200 OK, и конечная точка настроена на разрешение неаутентифицированных запросов (т. е. анонимных).

Само приложение работает нормально; однако AWS сообщает о целевой группе как о нездоровой, поскольку получает код ответа 302 от конечной точки проверки работоспособности. Если я сам запрашиваю конечную точку напрямую со своего рабочего стола, например, через PowerShell, Invoke-WebRequestто получаю ожидаемый 200 OKответ. Если я удаленно подключаюсь к экземпляру EC2 и запускаю тот же запрос, то он также возвращает ожидаемый 200 OKответ.

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

Но если я изменю его на локальный адрес http://localhost:8088, то запрос не будет выполнен:

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

Есть идеи, почему целевая группа получает перенаправление 302, но если я делаю запрос напрямую, то получаю 200 OK (если только я не использую локальный адрес)?

решение1

Извините, это была проблема с кодировкой приложения; RequireHttpsв коде запуска приложения был заложен фильтр, который, очевидно, пытался выполнить перенаправление в фоновом режиме; AWS проверял веб-сайт с использованием HTTP и, таким образом, сталкивался с перенаправлением 302, но когда я выполнял внешнюю проверку, я использовал HTTPS, что не приводило к перенаправлению.

решение2

Вот несколько вещей, которые следует здесь проверить:

  1. Работает ли брандмауэр Windows и блокирует ли он порт 8088?
  2. Действительно ли IIS прослушивает 8088?
  3. Настроен ли ваш AWS TG на выполнение проверки работоспособности на порту 8088? Похоже, он работает на порту 443, судя по ответу 200 OK на https.

Связанный контент