☰

AWS-Zielgruppe meldet Fehler, aber Anwendung ist fehlerfrei

tag-icon • tag-icon amazon-web-services amazon-elb
AWS-Zielgruppe meldet Fehler, aber Anwendung ist fehlerfrei

Ich habe eine IIS-Website, die in AWS auf einer EC2-Instanz läuft, die auf http://localhost:8088 läuft. Sie befindet sich hinter einem ELB, der den gesamten HTTPS-Verkehr an die Zielgruppe sendet, in der die EC2-Instanz läuft, sodass jede Anfrage an http://my-dns-name vom ELB an https://my-dns-name und dann an die Zielgruppe umgeleitet wird. Ich habe eine Integritätsprüfung für die Zielgruppe definiert, die den /healthcheckEndpunkt auf eine 200 OK-Antwort prüft, und der Endpunkt ist so konfiguriert, dass nicht authentifizierte Anfragen (auch bekannt als anonym) zugelassen werden.

Die Anwendung selbst läuft einwandfrei; AWS meldet die Zielgruppe jedoch als fehlerhaft, da es vom Integritätsprüfungsendpunkt einen Antwortcode von 302 erhält. Wenn ich den Endpunkt selbst direkt von meinem Desktop aus abfrage, z. B. über PowerShell, Invoke-WebRequesterhalte ich die erwartete 200 OKAntwort. Wenn ich mich remote in die EC2-Instanz einlogge und dieselbe Abfrage ausführe, wird auch die erwartete 200 OKAntwort zurückgegeben.

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

Wenn ich es jedoch so ändere, dass die lokale Adresse von verwendet wird http://localhost:8088, schlägt die Abfrage fehl:

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

Irgendwelche Ideen, warum die Zielgruppe eine 302-Weiterleitung erhält, bei einer direkten Abfrage aber 200 OK ist (es sei denn, ich verwende die lokale Adresse)?

Antwort1

Entschuldigung, das war ein Codierungsproblem mit der Anwendung. RequireHttpsTief im Startcode der Anwendung war ein Filter vergraben, der offensichtlich im Hintergrund eine Umleitung versuchte. AWS prüfte die Website per HTTP und erlebte daher die 302-Umleitung, aber als ich extern prüfte, nutzte ich HTTPS, wodurch die Umleitung nicht ausgelöst wurde.

Antwort2

Hier sind einige Dinge, die Sie überprüfen sollten:

  1. Läuft die Windows-Firewall und blockiert Port 8088?
  2. Hört IIS tatsächlich auf 8088?
  3. Ist Ihr AWS TG so eingerichtet, dass der Integritätscheck auf 8088 durchgeführt wird? Angesichts der 200-OK-Antwort auf https sieht es so aus, als würde es auf Port 443 ausgeführt.

verwandte Informationen