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, tout en agissant en tant que proxy, ARR n’a pas pu effectuer la requête au serveur 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 la réponse du serveur a pris trop de temps (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 que des erreurs détaillées sont activées sur le serveur, vous pouvez voir une erreur similaire au message d’erreur suivant :

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 de la capture d’écran précédente pour proxyer la demande 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 est mappé à 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 pour l’erreur 502.3, avec la plupart des champs supprimés pour plus de lisibilité :

sc-status	sc-substatus	sc-win32-status	temps pris
502	3	12002	29889

Win32 status 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 case activée 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 suivre 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 à quoi cela peut ressembler dans les journaux de suivi des demandes ayant échoué du serveur cible. Vous pouvez vérifier que vous avez trouvé la requête correcte en faisant correspondre les 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’horodatage 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	Temps	s-ip	cs-method	cs-uri-stem	cs-uri-query	s-port	cs-username	sc-status	sc-substatus	sc-win32-status	temps pris
2011-07-18	16:51:06	192.168.0.216	GET	/Temps/	-	80	-	200	0	64	45208

IIS sur le serveur de destination a enregistré un code status HTTP 200, indiquant que la requête s’est terminée avec succès. En outre, le status win32 est passé à 64, qui correspond à ERROR_NETNAME_DELETED. Ce code status indique généralement que le client (ARR étant le « client » dans ce cas) s’est déconnecté avant la fin de la requête.

Cause

Le serveur ARR a signalé un délai d’expiration, qui est l’endroit où vous devez d’abord rechercher.

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 temps nécessaire est très proche de 30 secondes. Cela indique qu’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 requête. Par conséquent, vous pouvez case activée pour voir si cette durée d’exécution était classique ou si vous avez besoin d’examiner la raison pour laquelle la demande prenait plus de temps que prévu. Si cette durée d’exécution était attendue et normale, 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 si la connexion au serveur après la résolution du nom prend plus de temps que le délai d’expiration spécifié.
• 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, ResolveTimeout et ConnectTimeout, la méthodologie de résolution des problèmes décrite précédemment ne fonctionne pas. Cela est dû au fait que vous ne voyez pas de trafic sur le serveur cible et que vous ne connaissez donc pas le code d’erreur. Par conséquent, dans ce cas de ResolveTimeout ou ConnectTimeout , vous souhaiterez peut-être capturer une trace WinHTTP pour obtenir des informations supplémentaires. Consultez la section suivi WinHTTP ou WEBIO et 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 le routage des demandes d’application IIS (ARR)
• Winhttp Tracing Options for Troubleshooting with Application Request Routing

502.3 Erreurs d’arrêt de connexion

Les erreurs 502.3 sont également retournées lorsque la connexion entre ARR et le serveur membre est déconnectée à mi-flux. 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 :

Le 0x80072efe d’erreur correspond à ERROR_INTERNET_CONNECTION_ABORTED. La requête peut être tracée vers le serveur qui l’a réellement traitée en suivant les mêmes étapes que celles utilisées précédemment dans cet utilitaire de résolution des problèmes, à une exception près. Alors 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 consigné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 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 demande. Cela a entraîné le retour du code d’erreur 0x80072f78. Pour plus d’informations, utilisez le Moniteur réseau 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 avoir envoyé une partie de la réponse, puis en appelant Response.Flush(). Si le trafic entre le serveur ARR et les serveurs membres est sur 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’a été trouvé pour acheminer la demande

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 case activée cela, accédez au nœud Serveurs sous la batterie dans le Gestionnaire des services Internet.

Pour rétablir 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. Vérifiez 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 comme WireShark vous fournissent les informations dont vous avez besoin pour identifier exactement ce qui expire. Toutefois, il existe des moments (par exemple, lorsque le trafic est chiffré SSL) que vous devez 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. Lorsque vous avez 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 des événements et d’autres données qui peuvent s’avérer utiles pour analyser le fichier .etl.

Pour analyser le journal,

1. Ouvrez-le dans Netmon 3.4 ou version ultérieure.

2. Vérifiez que vous avez configuré votre profil d’analyseur. Pour ce faire, ouvrez le menuOptionsDes outils>, sélectionnez l’onglet >Profils d’analyseur Profil Windows, puis sélectionnez le bouton Définir comme actif pour appliquer les modifications.

3. Faites défiler la trace jusqu’à ce que vous trouviez lew3wp.exeinstance où ARR s’exécute en corrélant avec la colonne nom du processus UT.

4. Cliquez avec le bouton droit sur w3wp et sélectionnez Ajouter un nom de processus UT pour afficher le filtre. Cela définit le filtre d’affichage comme suit :

   UTProcessName == "w3wp.exe (1432)"
   

Vous pouvez filtrer davantage les résultats en les remplaçant par ce qui suit :

UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"

Vous devez faire défiler la sortie jusqu’à trouver l’erreur de délai d’expiration. Dans l’exemple suivant, une requête a expiré, car son exécution a pris plus de 30 secondes (délai d’expiration par défaut d’ARR).

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’erreur
• Codes d’erreur Winhttp
• Suivi des demandes ayant échoué
• Winhttp Tracing
• 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.