This will help if you are tracing the target or destination of the HTTP request: 77. The second item I have highlighted is what you can use to track the request on the target server, the X-ARR-LOG-ID. The first thing we can see in the failed request trace log is where the request was sent to in the ARR_SERVER_ROUTED event. We investigate this a bit further by enabling Failed Request Tracing on the IIS server. The win32 status 12002 maps to the same ERROR_WINHTTP_TIMEOUT error reported in the error page. The following is an excerpt from the IIS log entry for the 502.3 error, with most of the fields trimmed for readability: sc-status You can also find this information in the IIS logs for the associated website on the ARR controller. In this example, the error code maps to ERROR_WINHTTP_TIMEOUT.

You can decode the error code with a tool like err.exe. The error code in the screenshot above is significant because it contains the return code from WinHTTP, which is what ARR uses to proxy the request and identifies the reason for the failure. The root cause of the error will determine the actions you should take to resolve the issue. If you are able to reproduce the error by browsing the web farm from the controller, and detailed errors are enabled on the server, you may see an error similar to the following: This can happen for multiple reasons - for example: failure to connect to the server, no response from the server, or the server took too long to respond (time out). The 502.3 error means that - while acting as a proxy - ARR was unable to complete the request to the upstream server and send a response back to the client. When working with IIS Application Request Routing (ARR) deployments, one of the errors that you may see is 'HTTP 502 - Bad Gateway'. Microsoft makes no warranties, express or implied. This material is provided for informational purposes only. By Richard Marr Tools Used in this Troubleshooter:

Err 502 openoffice