Erreur lors de la navigation sur votre site web via l’URL de domaine de service cloud par défaut : erreur HTTP 503. Le service n’est pas disponible

Cet article fournit des informations sur la résolution des problèmes dans lesquels vous obtenez une erreur « Erreur HTTP 503. Le service n’est pas disponible. » lors de l’accès à votre application de service cloud.

Version du produit d’origine : service Gestion des API
Numéro de base de connaissances d’origine : 4464854

Note

Reportez-vous à l’article sur la série de résolution des problèmes du service cloud Azure, il s’agit du cinquième scénario du labo. Vérifiez que vous avez suivi les instructions de configuration du laboratoire pour l’application Super Convertor en fonction de cela, pour recréer le problème.

Symptômes

Vous obtenez une réponse HTTP Error 503 lors de la navigation dans l’URL de votre application de service cloud (http://cloudservicelabs.cloudapp.net/), bien que votre rôle web « SuperConvertor » soit en cours d’exécution. Le redémarrage ou la réinitialisation de l’instance de rôle ne résout pas le problème.

Service indisponible

Erreur HTTP 503. Le service n’est pas disponible.

Étapes de dépannage

Lorsque vous obtenez des erreurs 50 fois dans votre application, cela signifie généralement que quelque chose est rompu côté serveur. 503 Service Unavailable le code de réponse d’erreur du serveur indique que le serveur n’est pas prêt à gérer la demande. Vous devez penser pourquoi soudainement une application de service cloud nouvellement déployée a soudainement commencé à lever cette erreur. L’application se bloque-t-elle ? La requête atteint-elle le serveur IIS ? Le serveur est-il sous une charge élevée ?

Tout d’abord, vérifiez le serveur IIS local. Vous pouvez vous connecter à l’instance de rôle web à l’aide du protocole RDP et parcourir l’application localement. Avant de parcourir le site localement, vérifiez les journaux d’activité de l’observateur d’événements Application and System pour négation de toute possibilité d’incident IIS ApplicationPool ou toute autre exception liée à l’application.

Ensuite, vérifiez les journaux IIS présents sous C:\Resources\directory\{Deployment ID}.SuperConvertor.DiagnosticStore\LogFiles\Web pour vérifier si vous pouvez obtenir plus d’informations sur l’erreur HTTP 503, comme le code de sous-état, le temps nécessaire pour exécuter la requête, etc.

S’il n’y a pas de journaux générés, cela signifie que la requête n’est pas atteinte à IIS du tout. Conformément à l’architecture IIS, HTTP.sys écoute les requêtes HTTP à partir du réseau, transmet les requêtes à IIS pour traitement, puis retourne des réponses traitées aux navigateurs clients. Par défaut, IIS fournit HTTP.sys en tant qu’écouteur de protocole qui écoute les requêtes HTTP et HTTPS et toute erreur au niveau HTTP.sys est consignée dans ce répertoire . D:\Windows\System32\LogFiles\HTTPERR Voyons donc ce que nous pouvons trouver dans le journal HTTPErr :

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

Si vous voyez le journal ci-dessus, HTTP 503 est levée à partir de HTTP.sys niveau et la demande cliente est rejetée à partir de là-même sans atteindre IIS. Maintenant, nous allons parcourir le site localement à partir d’IIS et voir ce qui se passe - Vous risquez d’obtenir une erreur - Cette page ne peut pas être affichée. Une chose que vous remarquerez peut-être est que le site web IIS avait une liaison comme ci-dessous, ce qui signifie que pour accéder à ce site web particulier, vous devez accéder sur le nom de domaine personnalisé (www.cloudservicelabs.com)

Adresse IP	Port	En-tête de l'hôte
10.1.2.5	80	www.cloudservicelabs.com

Les sites web sont accessibles par chaque client à l’aide de liaisons. Une liaison classique pour les sites web se présente sous la forme d’IP :Port :HostHeader. Il s’agit d’un mécanisme qui indique au serveur comment ce site peut être atteint. La question suivante qui viendra à votre esprit est que d’où vient ce nom d’hôte personnalisé.

ServiceDefinition.csdef est l’endroit où vous pouvez configurer les liaisons pour votre rôle web, et voici ce que vous pouvez voir pour votre application :

<WebRole name="SuperConvertor" vmsize="Standard_D1_v2">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.cloudservicelabs.com"/></Bindings>
</Site>
</Sites>

Dans un scénario réel, afin d’accéder à votre application de service cloud sur un nom d’hôte personnalisé, vous devez disposer d’un DNS configuré pour cet en-tête d’hôte correspondant à l’adresse IP virtuelle du service cloud. Pour l’instant, vous pouvez supprimer l’attribut hostHeader de l’élément Binding et redéployer votre solution de service cloud pour résoudre le problème.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.