Résolution des erreurs 502 dans ARR
Cet article vous aide à résoudre les problèmes liés aux erreurs 502 dans le routage des demandes d’application (ARR).
S’applique à : Internet Information Services
HTTP 502 - Vue d’ensemble
Lorsque vous utilisez des déploiements ARR (Application Request Routing) IIS, l’une des erreurs que vous pouvez voir est « HTTP 502 - Passerelle incorrecte ». L’erreur 502.3 signifie que lors de l’action en tant que proxy, ARR n’a pas pu terminer la demande sur le serveur en amont et renvoyer une réponse au client. Ce problème peut se produire pour plusieurs raisons. Par exemple, l’échec de la connexion au serveur, l’absence de réponse du serveur ou le serveur a pris trop de temps pour répondre (délai d’attente). Si vous êtes en mesure de reproduire l’erreur en parcourant la batterie de serveurs web à partir du contrôleur et si des erreurs détaillées sont activées sur le serveur, une erreur similaire au message d’erreur suivant peut s’afficher :
La cause racine de l’erreur détermine ce que vous devez faire pour résoudre le problème.
Erreurs de délai d’expiration 502.3
ARR utilise le code d’erreur dans la capture d’écran précédente pour proxyr la requête et déterminer la source de l’échec, car il contient le code de retour de WinHTTP.
Vous pouvez décoder le code d’erreur avec l’outil err.exe. Dans cet exemple, le code d’erreur correspond à ERROR_WINHTTP_TIMEOUT. Vous trouverez également ces informations dans les journaux IIS du site web associé sur le contrôleur ARR. Voici un extrait de l’entrée de journal IIS correspondant à l’erreur 502.3, dont la plupart des champs ont été supprimés pour des raisons de lisibilité :
| sc-status | sc-substatus | sc-win32-status | time-taken |
|---|---|---|---|
| 502 | 3 | 12002 | 29889 |
L’état win32 12002 correspond à la même erreur ERROR_WINHTTP_TIMEOUT signalée dans la page d’erreur.
Qu’est-ce qui a expiré exactement ?
Vous pouvez vérifier ce délai d’attente en activant le suivi des demandes ayant échoué sur le serveur IIS. Le premier point que vous pouvez voir, dans le journal de suivi des demandes ayant échoué et c’est là que la demande a été envoyée dans l’événement ARR_SERVER_ROUTED. Le deuxième point est le X-ARR-LOG-ID, que vous pouvez utiliser pour suivre la requête sur le serveur cible. Cela permet de tracer la cible ou la destination de la requête HTTP :
77. ARR_SERVER_ROUTED RoutingReason="LoadBalancing", Server="192.168.0.216", State="Active", TotalRequests="3", FailedRequests="2", CurrentRequests="1", BytesSent="648", BytesReceived="0", ResponseTime="15225" 16:50:21.033
78. GENERAL_SET_REQUEST_HEADER HeaderName="Max-Forwards", HeaderValue="10", Replace="true" 16:50:21.033
79. GENERAL_SET_REQUEST_HEADER HeaderName="X-Forwarded-For", HeaderValue="192.168.0.204:49247", Replace="true" 16:50:21.033
80. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-SSL", HeaderValue="", Replace="true" 16:50:21.033
81. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-ClientCert", HeaderValue="", Replace="true" 16:50:21.033
82. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-LOG-ID", HeaderValue="dbf06c50-adb0-4141-8c04-20bc2f193a61", Replace="true" 16:50:21.033
83. GENERAL_SET_REQUEST_HEADER HeaderName="Connection", HeaderValue="", Replace="true" 16:50:21.033
L’exemple suivant montre comment cela peut se présenter sur les journaux de suivi des demandes ayant échoué du serveur cible. Vous pouvez vérifier que vous avez trouvé la requête correcte en correspondant aux valeurs « X-ARR-LOG-ID » dans les deux traces.
185. GENERAL_REQUEST_HEADERS Headers="Connection: Keep-Alive Content-Length: 0 Accept: */* Accept-Encoding: gzip, deflate Accept-Language: en-US Host: test Max-Forwards: 10 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0) X-Original-URL: /time/ X-Forwarded-For: 192.168.0.204:49247 X-ARR-LOG-ID: dbf06c50-adb0-4141-8c04-20bc2f193a61
<multiple entries skipped for brevity>
345. GENERAL_FLUSH_RESPONSE_END BytesSent="0", ErrorCode="An operation was attempted on a nonexistent network connection. (0x800704cd)" 16:51:06.240
Dans l’exemple précédent, vous pouvez voir que le serveur ARR s’est déconnecté avant l’envoi de la réponse HTTP. L’horodateur de GENERAL_FLUSH_RESPONSE_END peut être utilisé comme guide approximatif pour rechercher l’entrée correspondante dans les journaux IIS sur le serveur de destination.
| date | time | s-ip | cs-method | cs-uri-stem | cs-uri-query | s-port | cs-username | sc-status | sc-substatus | sc-win32-status | time-taken |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011-07-18 | 16:51:06 | 192.168.0.216 | GET | /Heure/ | - | 80 | - | 200 | 0 | 64 | 45208 |
IIS sur le serveur de destination a enregistré un code d’état HTTP 200, indiquant que la demande s’est terminée correctement. En outre, le statut win32 a changé à 64, qui correspond à ERROR_NETNAME_DELETED. Ce code d’état indique généralement que le client (ARR étant le « client » dans ce cas) déconnecté avant la fin de la demande.
Cause
Le serveur ARR a signalé un délai d’expiration, c’est-à-dire où vous devez commencer par regarder.
Bien que le journal du serveur membre indique que la réponse a été envoyée en 45 secondes (45208 ms), l’entrée de journal IIS du serveur ARR indique que le délai nécessaire est très proche de 30 secondes. Cela indique que ARR expire la demande et que vous pouvez le confirmer en examinant le délai d’expiration du proxy dans les paramètres de proxy de la batterie de serveurs. Par défaut, il est défini sur 30 secondes.
Ainsi, dans ce cas, vous pouvez clairement voir que le délai d’expiration ARR était plus court que l’exécution de la demande. Par conséquent, vous souhaiterez peut-être vérifier si cette durée d’exécution était classique ou si vous deviez examiner pourquoi la demande prenait plus de temps que prévu. Si ce temps d’exécution était prévu et normal, l’augmentation du délai d’expiration ARR devrait résoudre l’erreur.
Voici d’autres raisons possibles pour ERROR_WINHTTP_TIMEOUT :
ResolveTimeout: se produit si la résolution de noms prend plus de temps que le délai d’expiration spécifié.ConnectTimeout: se produit s’il faut plus de temps que le délai d’expiration spécifié pour se connecter au serveur après la résolution du nom.SendTimeout: se produit si l’envoi d’une requête prend plus de temps que cette valeur de délai d’attente. L’opération d’envoi est annulée.ReceiveTimeout: se produit si une réponse prend plus de temps que cette valeur de délai d’attente. La demande est annulée.
Lorsque vous observez les deux premières raisons et ConnectTimeoutque ResolveTimeout la méthodologie de résolution des problèmes décrite précédemment ne fonctionnerait pas. Cela est dû au fait que vous ne voyiez aucun trafic sur le serveur cible et ne connaissait donc pas le code d’erreur. Par conséquent, dans ce cas ou ResolveTimeout ConnectTimeout vous souhaiterez peut-être capturer une trace WinHTTP pour obtenir des informations supplémentaires. Consultez la section suivi WinHTTP ou WEBIO, ainsi que dans les blogs suivants pour obtenir d’autres exemples sur la résolution des problèmes et le suivi :
- 502.3 Passerelle incorrecte « L’opération a expiré » avec Application Request Routing IIS (ARR)
- Options de suivi Winhttp pour la résolution des problèmes avec Application Request Routing
Erreurs d’arrêt de connexion 502.3
Les erreurs 502.3 sont également retournées lorsque la connexion entre ARR et le serveur membre est déconnectée du flux intermédiaire. Pour tester ce type de problème, créez une page .aspx qui appelle Response.Close(). Dans l’exemple suivant, il existe un répertoire appelé « time », qui est configuré avec une page .aspx comme document par défaut dans ce répertoire. Lorsque vous essayez d’accéder au répertoire, ARR affiche le message d’erreur suivant :
L’erreur 0x80072efe correspond à ERROR_INTERNET_CONNECTION_ABORTED. La requête peut être tracée sur le serveur qui l’a réellement traitée à l’aide des mêmes étapes que celles utilisées précédemment dans cet utilitaire de résolution des problèmes, à une exception près. Bien que le suivi des demandes ayant échoué sur le serveur de destination affiche la demande traitée sur le serveur, l’entrée de journal associée n’apparaît pas dans les journaux IIS. Au lieu de cela, cette requête est journalisée dans le journal HTTPERR comme suit :
HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool
Les journaux intégrés sur le serveur de destination ne fournissent pas d’informations supplémentaires sur le problème. L’étape suivante consiste donc à collecter une trace réseau à partir du serveur ARR. Dans l’exemple précédent, la page .aspx appelée Response.Close() sans retourner de données. L’affichage de ceci dans une trace réseau indique qu’un Connection: close en-tête HTTP provient du serveur de destination. Avec ces informations, vous pouvez commencer une enquête sur la raison pour laquelle l’en-tête Connection: close a été envoyé.
L’erreur suivante est un autre exemple de réponse non valide du serveur membre :
Dans cet exemple, ARR a commencé à recevoir des données du client, mais un problème s’est produit lors de la lecture du corps de l’entité de requête. Cela a entraîné le retour du code d’erreur 0x80072f78. Pour approfondir vos recherches, utilisez Network Monitor sur le serveur membre pour obtenir une trace réseau du problème. Cet exemple d’erreur particulier a été créé en appelant Response.Close() dans la page ASP.net après l’envoi d’une partie de la réponse, puis en appelant Response.Flush(). Si le trafic entre le serveur ARR et les serveurs membres se fait via SSL, le suivi WinHTTP sur Windows Server 2008 ou le suivi WebIO sur Windows Server 2008 R2 peut fournir des informations supplémentaires. Le suivi WebIO est décrit plus loin dans cet utilitaire de résolution des problèmes.
502.4 Aucun serveur approprié n’est trouvé pour acheminer la requête
L’erreur HTTP 502.4 avec un code d’erreur associé de 0x00000000 indique généralement que tous les membres de la batterie de serveurs sont hors connexion ou inaccessibles.
La première étape consiste à vérifier que les serveurs membres sont en ligne. Pour vérifier cela, accédez au nœud Serveurs sous la batterie de serveurs dans le Gestionnaire IIS.
Pour ramener les serveurs hors connexion, cliquez avec le bouton droit sur le nom du serveur, puis sélectionnez Ajouter à l’équilibrage de charge. Si vous ne pouvez pas remettre les serveurs en ligne, vérifiez si les serveurs membres sont accessibles à partir du serveur ARR. Consultez le volet Messages de suivi dans la page Serveurs pour rechercher des indices sur le problème. Si vous utilisez Web Farm Framework (WFF) 2.0, vous pouvez recevoir cette erreur lorsque le pool d’applications redémarre. Vous devez redémarrer le service de batterie de serveurs web pour récupérer.
Suivi WinHTTP ou WebIO
En règle générale, les outils de capture de paquets tels que WireShark vous fournissent les informations dont vous avez besoin pour identifier exactement le délai d’attente. Toutefois, il existe des heures (par exemple, quand le trafic est chiffré SSL) que vous devrez essayer une approche différente. À compter de Windows 7 et Windows Server 2008 R2, vous pouvez activer le suivi WinHTTP à l’aide de l’outil netsh en exécutant la commande suivante à partir d’une invite de commandes d’administration :
netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl
Ensuite, reproduisez le problème. Une fois le problème reproduit, arrêtez le suivi en exécutant la commande suivante :
netsh trace stop
La stop commande prend quelques secondes pour se terminer. Une fois terminé, vous trouverez un fichier net.etl et un fichier net.cab dans C:\temp. Vous devez vous assurer que le C:\temp dossier existe avant d’exécuter les commandes ci-dessus. Le fichier .cab contient des journaux d’événements et d’autres données qui peuvent s’avérer utiles pour analyser le fichier .etl.
Pour analyser le journal,
Ouvrez-le dans Netmon 3.4 ou version ultérieure.
Vérifiez que vous avez configuré votre profil d’analyseur. Pour ce faire, ouvrez le menu Options des outils>, sélectionnez le profil Windows de l’onglet >Profils de l’analyseur, puis sélectionnez le bouton Définir comme actif pour appliquer les modifications.
Faites défiler la trace jusqu’à ce que vous trouviez l’instance w3wp.exe où ARR est en cours d’exécution en corrélation avec la colonne de nom du processus UT.
Cliquez avec le bouton droit sur w3wp, puis sélectionnez Ajouter un nom de processus UT pour afficher le filtre. Cela définit le filtre d’affichage similaire à :
UTProcessName == "w3wp.exe (1432)"
Vous pouvez filtrer davantage les résultats en le remplaçant par les éléments suivants :
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
Vous devrez parcourir la sortie jusqu’à ce que vous trouviez l’erreur de délai d’expiration. Dans l’exemple suivant, une requête a expiré parce qu’il a fallu plus de 30 secondes (délai d’expiration par défaut d’ARR) pour s’exécuter.
336 2:32:22 PM 7/22/2011 32.6380453 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver starts in _INIT state
337 2:32:22 PM 7/22/2011 32.6380489 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::current thread is not impersonating
340 2:32:22 PM 7/22/2011 32.6380584 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver processing WebReceiveHttpResponse completion (error-cdoe = ? (0x5b4), overlapped = 003728F0)
341 2:32:22 PM 7/22/2011 32.6380606 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver failed to receive headers; error = ? (1460)
342 2:32:22 PM 7/22/2011 32.6380800 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::ERROR_WINHTTP_FROM_WIN32 mapped (?) 1460 to (ERROR_WINHTTP_TIMEOUT) 12002
343 2:32:22 PM 7/22/2011 32.6380829 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver returning ERROR_WINHTTP_TIMEOUT (12002) from RecvResponse()
344 2:32:22 PM 7/22/2011 32.6380862 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-req completes recv-headers inline (sync); error = ERROR_WINHTTP_TIMEOUT (12002)
Dans l’exemple suivant, le serveur de contenu était complètement hors connexion :
42 2:26:39 PM 7/22/2011 18.9279133 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::WinHttpReceiveResponse(0x11d23d0, 0x0) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
43 2:26:39 PM 7/22/2011 18.9279633 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver starts in _INIT state {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
44 2:26:39 PM 7/22/2011 18.9280469 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::current thread is not impersonating {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
45 2:26:39 PM 7/22/2011 18.9280776 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver processing WebReceiveHttpResponse completion (error-cdoe = WSAETIMEDOUT (0x274c), overlapped = 003728F0) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
46 2:26:39 PM 7/22/2011 18.9280802 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver failed to receive headers; error = WSAETIMEDOUT (10060) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
47 2:26:39 PM 7/22/2011 18.9280926 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::ERROR_WINHTTP_FROM_WIN32 mapped (WSAETIMEDOUT) 10060 to (ERROR_WINHTTP_TIMEOUT) 12002 {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
48 2:26:39 PM 7/22/2011 18.9280955 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver returning ERROR_WINHTTP_TIMEOUT (12002) from RecvResponse() {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
Autres ressources
- Outil de recherche d’erreurs
- Codes d’erreur Winhttp
- Suivi des demandes ayant échoué
- Suivi Winhttp
- Moniteur réseau
Exclusion de responsabilité de tiers
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.