Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Informationen zur Behandlung von Problemen, bei denen der Fehler "HTTP-Fehler 503. Der Dienst ist nicht verfügbar." beim Zugriff auf Ihre Clouddienstanwendung.
Ursprüngliche Produktversion: API Management Service
Ursprüngliche KB-Nummer: 4464854
Hinweis
Lesen Sie den Artikel zur Azure Cloud Service-Problembehandlungsreihe. Dies ist das fünfte Szenario des Labs. Stellen Sie sicher, dass Sie die Anweisungen zum Einrichten des Labs für die Super Convertor-Anwendung wie folgt befolgt haben, um das Problem neu zu erstellen.
Symptome
Sie erhalten beim Durchsuchen ihrer Clouddienstanwendungs-URL (http://cloudservicelabs.cloudapp.net/) die Antwort HTTP-Fehler 503, obwohl sich Ihre Webrolle "SuperConvertor" im Ausführungszustand befindet. Ein Neustart oder reimaging der Rolle instance löst das Problem nicht.
Dienst nicht verfügbar (Service Unavailable)
HTTP-Fehler 503. Der Dienst ist nicht verfügbar.
Schritte zur Problembehandlung
Wenn Sie in Ihrer Anwendung 50-fache Fehler erhalten, bedeutet dies in der Regel, dass auf der Serverseite etwas beschädigt ist. 503 Service Unavailable Der Serverfehlerantwortcode gibt an, dass der Server nicht bereit ist, die Anforderung zu verarbeiten. Sie müssen darüber nachdenken, warum plötzlich eine neu bereitgestellte Clouddienstanwendung diesen Fehler auslöst. Stürzt die Anwendung ab? Erreicht die Anforderung den IIS-Server? Ist der Server unter hoher Auslastung?
Überprüfen Sie zunächst den lokalen IIS-Server. Sie können eine Verbindung mit der Webrolle instance mithilfe von RDP herstellen und die Anwendung lokal durchsuchen. Bevor Sie die Website lokal durchsuchen, überprüfen Sie die Anwendungs- und Systemereignisanzeigeprotokolle, um jegliche Möglichkeit eines IIS ApplicationPool-Absturzes oder anderer anwendungsbezogener Ausnahmen zu negieren.
Überprüfen Sie als Nächstes die IIS-Protokolle, die unter C:\Resources\directory\{Deployment ID}.SuperConvertor.DiagnosticStore\LogFiles\Web vorhanden sind, um zu überprüfen, ob Sie weitere Informationen zum HTTP 503-Fehler erhalten können, z. B. den Unterstatuscode, die für die Ausführung der Anforderung benötigte Zeit usw.
Wenn keine Protokolle generiert werden, bedeutet dies, dass die Anforderung überhaupt nicht an IIS gelangt. Gemäß der IIS-Architektur lauscht HTTP.sys auf HTTP-Anforderungen aus dem Netzwerk, übergibt die Anforderungen zur Verarbeitung an IIS und gibt dann verarbeitete Antworten an Clientbrowser zurück. Standardmäßig stellt IIS HTTP.sys bereit, da der Protokolllistener, der auf HTTP- und HTTPS-Anforderungen lauscht, und alle Fehler auf HTTP.sys Ebene in diesem Verzeichnis protokolliert werden: D:\Windows\System32\LogFiles\HTTPERR. Sehen wir uns also an, was wir im HTTPErr-Protokoll finden können:
#Software: Microsoft HTTP API 2.0
#Version: 1.0
#Date: 2018-08-13 03:12:38
#Fields: date time c-ip c-port s-ip s-port cs-version cs-method cs-uri streamid sc-status s-siteid s-reason s-queuename
2018-08-13 03:25:22 293.217.138.127 12052 10.1.2.5 80 HTTP/1.1 GET / - 503 - N/A -
2018-08-13 03:25:22 293.217.138.127 20463 10.1.2.5 80 HTTP/1.1 GET /favicon.ico - 503 - N/A -
Wenn das obige Protokoll angezeigt wird, wird HTTP 503 von HTTP.sys Ebene ausgelöst, und die Clientanforderung wird von dort selbst abgelehnt, ohne den IIS zu erreichen. Nun werden wir die Website lokal von IIS aus durchsuchen und sehen, was passiert. Möglicherweise erhalten Sie eine Fehlermeldung: Diese Seite kann nicht angezeigt werden. Eine Sache, die Sie möglicherweise bemerken, ist, dass die IIS-Website eine Bindung wie unten hatte. Dies bedeutet, dass Sie für den Zugriff auf diese spezielle Website über den benutzerdefinierten Domänennamen (www.cloudservicelabs.com) zugreifen müssen.
| IP-Adresse | Port | Hostheader |
|---|---|---|
| 10.1.2.5 | 80 | www.cloudservicelabs.com |
Auf Websites kann jeder Kunde über Bindungen zugreifen. Eine typische Bindung für Websites liegt in Form von IP:Port:HostHeader vor. Es handelt sich um einen Mechanismus, der dem Server mitteilt, wie dieser Standort erreicht werden kann. Die nächste Frage, die Ihnen einfällt, ist, dass von woher dieser benutzerdefinierte Hostname stammt.
ServiceDefinition.csdef ist der Ort, an dem Sie die Bindungen für Ihre Webrolle konfigurieren können. Hier sehen Sie möglicherweise folgendes für Ihre Anwendung:
<WebRole name="SuperConvertor" vmsize="Standard_D1_v2">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.cloudservicelabs.com"/></Bindings>
</Site>
</Sites>
In der Praxis muss für diesen Hostheader ein DNS konfiguriert sein, das der VIP des Clouddiensts entspricht, um über einen benutzerdefinierten Hostnamen auf Ihre Clouddienstanwendung zugreifen zu können. Vorerst können Sie das attribut hostHeader aus dem Binding-Element löschen und Ihre Clouddienstlösung erneut bereitstellen, um das Problem zu beheben.
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.