anchor.diff:  
   <strong><%= modified_date %></strong>
   
  -This topic helps operators to better understand if 502's are a result of the PCF Platform or an application.
  +This topic helps operators to better understand if 502's are a result of the Cloud Foundry Platform or an application.
   
   ## <a id="points-of-failure"></a> Points of Failure
   
  
positive.code: 1. Infrastructure
      - Load Balancer
      - Network
  2. Platform - PCF
      - Gorouter
      - Diego Cell(s)
  3. Applications
  
  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.
      - 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.pivotal.io/pivotalcf/2-1/concepts/http-routing.html#back-end)). This may be due to:
  		- An application that is unresponsive (which indicated an issue with the application)
  		- The Gorouter has a stale route (which indicateds an issue with the application)
  		- The application container is corrupted (which indicated 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":
  
negative.code:     "error":"dial tcp 10.0.32.15:60099: getsockopt: connection refused"}}
      </pre>
  - If the Gorouter successfully dials the endpoint but an error occurs:
      - `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 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 (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 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
  
  