anchor.diff:      "error":"dial tcp 10.0.32.15:60099: getsockopt: connection refused"}}
       </pre>
   - If the Gorouter successfully dials the endpoint but an error occurs:
  -    - Connection reset on read errors can occur when the application closes the connection. This will cause the Gorouter to retry the next endpoint.
  -    - TLS Handshake errors (this may not necessarily return a 502 but it's worth mentioning). These appear similar to the following in the `gorouter.log`:
  +    - `read: connection reset by peer` errors can occur when the application closes the connection abruptly with a TCP RST packet and not the expected FIN-ACK. This will cause the Gorouter to retry the next endpoint. Note, Gorouter does not currently retry on `write: connection reset by peer` failures.
  +    - TLS Handshake errors. When these errors occur, the Gorouter will retry up to three times and if it's still failing then a 502 may be returned. These errors appear similar to the following in the `gorouter.log` (and a 502 will be logged in the `access.log`):
       <pre class="terminal">
   		[2018-07-05 18:20:54+0000] {"log_level":3,"timestamp":1530814854.4359834,"message":"
       backend-endpoint-failed","source":"vcap.gorouter","data":{"route-endpoint":
       {"ApplicationId":"","Addr":"10.0.16.17:61002","Tags":null,"RouteServiceUrl":""},
       "error":"x509:certificate is valid for 53079ca3-c4fe-4910-78b9-c1a6, not xxx"}}
       </pre>
  -- If the Gorouter successfully dials the endpoint, but an error occurs while the request is in transport:
  -    - Prior to PCF 2.0, there was a bug that logged a 502 for requests canceled by clients before the server responded with headers. PCF 2.0 and beyond, if the same situation occurs, a 499 is returned.
  +    - If the Gorouter successfully connects to the endpoint, but an error occurs while the request is in transport (i.e. Gorouter has not received a response from the endpoint):
  +    - Prior to routing-release 0.166.0, there was a bug that logged a 502 for requests canceled by clients before the server responded with headers. Routing-release 0.166.0 and beyond, if the same situation occurs, a 499 is returned.
   
  -In an **Application**, 502's can occur in the following ways:
  +In an **Application**, 502's can occur in the following ways (Note: the Gorouter will not retry any error response that is returned by the application):
   
  -- If 502's are only occuring from a particular application instance(s) and not all of the applications on the PCF platform, then it is likely an application error (i.e. application is overloaded, unresponsive, etc.). If all applications are experiencing 502's, then it's likely a platform issue (possible misconfiguration).
  +- If 502's are only occuring from a particular application instance(s) and not all of the applications on the CF platform, then it is likely an application-related error (i.e. application is overloaded, unresponsive, can't connect to database, etc.).
  +- If all applications are experiencing 502's, then it could either be a platform issue (possible misconfiguration) or an application issue (i.e. all applications are unable to connect to an upstream database).
   
   ## <a id="debugging-steps"></a> General Debugging Steps
   
  
positive.code: 
  <strong><%= modified_date %></strong>
  
  This topic helps operators to better understand if 502's are a result of the PCF Platform or an application.
  
  ## <a id="points-of-failure"></a> Points of Failure
  
  
negative.code: 1. Infrastructure
      - Load Balancer
      - Network
  2. Platform - CF
      - Gorouter
      - Diego Cell(s)
  3. Application
  
  In the **Infrastructure**, 502's can occur in the following way:
  
  - From the Load Balancer, 502's can surface when the Gorouters are not receiving traffic at all.
      - This can be observed if the Load Balancer is logging 502's but the Gorouters are not.
  
  In the **Platform**, 502's can occur in the following ways:
  
  - If the Gorouter is unable to connect to the application container:
      - TCP dial issues (can't make an initial connection to the [backend](https://docs.cloudfoundry.org/concepts/http-routing.html#back-end)). The Gorouter will retry TCP dial errors up to three times, if it still fails then a 502 will be returned to the client and logged to the `access.log`. This may be due to:
  		- An application that is unresponsive (which indicates an issue with the application)
  		- The Gorouter has a stale route (which indicates an issue with the platform)
  		- The application container is corrupted (which indicates a problem with the platform)
  		- These types of errors may look like this within the `gorouter.log`:
      <pre class="terminal">
      [2018-07-05 17:59:10+0000] {"log_level":3,"timestamp":1530813550.92134,"message":
  