anchor.diff:      "error":"x509:certificate is valid for 53079ca3-c4fe-4910-78b9-c1a6, not xxx"}}
       </pre>
       - If Gorouter successfully connects to the endpoint, but an error occurs while the request is in transport, such as if Gorouter has not received a response from the endpoint.
  -    - Prior to <%= vars.routing_version %>, Gorouter logged a 502 error for requests that clients canceled before the server responded with headers. If the same situation occurs in <%= vars.routing_version %> and beyond, Gorouter returns a 499 error.
  +    - If a clients cancels a request before the server responds with headers, Gorouter returns a 499 error.
   
   ## <a id="diagnose-stale-routes"></a> Diagnose Stale Routes in Gorouter
   
  -### <a id="stale-routes"></a> What is a stale route?
   A stale route occurs when Gorouter contains out-of-date route information for a
   backend app.
   In nearly all cases, stale routes are self-correcting.
  
positive.code: 
  - **Infrastructure**: issues with your load balancer or network can cause 502 errors.
  - **Platform**: issues with Gorouter or Diego Cells can cause 502 errors.
  - **App**: issues with an app's load or configuration can cause 502 errors.
  
  The following sections describe how to diagnose and debug router errors:
  
  - [General Debugging Steps](#debugging-steps)
  - [Diagnose Gorouter Errors](#gorouter-errors)
    - [Diagnose Stale Routes in Gorouter](#diagnose-stale-routes)
    - [Gorouter Error Classification Table](#gorouter-error-classification)
  - [Diagnose App Errors](#app-errors)
  
  ## <a id="debugging-steps"></a> General Debugging Steps
  
  Some general debugging steps for any issue resulting in 502 errors are as follows:
  
  - Gather the Gorouter logs and Diego Cell logs at the time of the incident. <%= vars.gather_routing_logs %>
  
  - Review the logs and consider the following:
      1. Which errors are the Gorouters returning?
      1. Is Gorouter's routing table accurate? Are the endpoints for the route as expected? For more information, see [Dynamic Routing Table](https://github.com/cloudfoundry/gorouter#dynamic-routing-table) in the Gorouter documentation on GitHub.
      1. Do the Diego Cell logs have anything interesting about unexpected app crashes or restarts?
      1. Is the app healthy and handling requests successfully? You can use request tracing headers to verify. For more information, see [HTTP Headers for Zipkin Tracing](../concepts/http-routing.html#zipkin-headers) in _HTTP Routing_.
  
  - If your load balancer logs 502 errors but Gorouter does not, traffic is not reaching Gorouter.
  
  - Was there a recent platform change or upgrade that caused an increase in 502 errors?
  
  - Are there any suspicious [metrics](<%= vars.gorouter_metrics_link %>) spiking? How is the CPU and memory utilization?
  
  
  ## <a id="gorouter"></a>Diagnose Gorouter Errors
  
  - If Gorouter is unable to connect to the app container:
      - If TCP cannot make an initial connection to the back end, Gorouter retries TCP dial errors up to three times. If it still fails, Gorouter returns a 502 to the client and writes to the `access.log`. This might be due to:
  
negative.code: SSL verification from Gorouter to backends is always on in <%= vars.app_runtime_abbr %> v2.4.0 and later.
  <% end %>
  
  ### <a id="stale-routes"></a> Causes of Stale Routes
  
  When a route is unmapped or when an app container is deleted because the app is deleted or moved, then deregister message is sent to Gorouter.
  This message tells Gorouter to delete the route mapping to that container.
  
  If Gorouter does not receive this deregister message, the route is now considered stale.
  Gorouter still attempts to send traffic to the app.
  
  You are more likely to have stale routes when the following are true:
  
  - SSL verification is not enabled.
  <% if vars.platform_code == 'CF' %>
  - You do not have Diego Release v2.34.0 or later deployed, which contains a fix that sends unregistration messages multiple times.
  <% else %>
  - You are on one of the versions of <%= vars.app_runtime_abbr %> that does not send unregistration messages multiple times.
  For the list of versions, see [Enabling TLS from the Gorouter to application instances results in bad routes in PAS 2.3+](https://community.pivotal.io/s/article/enabling-tls-from-the-gorouter-to-application-instances-results-in-bad-routes?language=en_US) in the Knowledge Base.
  <% end %>
  - You unmapped a route to an app, but traffic to that route is still being sent to the app.
  
  ### <a id="stale-route-triage"></a> How to Locate Stale Routes
  
  The following procedure helps you identify stale routes:
  
  1. Verify the state of the deployment.
  
      Run `cf routes` for all spaces and ensure the route is only mapped to the intended apps.
      Sometimes, there can be multiple routes using the same hostname and domain but with different paths.
      If the domain is shared, check all orgs as well.
  1. Examine the Gorouter routes table. It might be necessary to check multiple Gorouters, as it is possible that some received the proper deregister message and some did not.
    1. SSH to the VM where Gorouter is running.
    1. To print the entire Gorouter routes table, run:
     `/var/vcap/jobs/gorouter/bin/retreive-local-routes | jq .`
    1. Find the entry for the suspected stale route. Note the values for `address` and `private_instance_id`.
  1. Cross-reference the Gorouter routes table entry with actual Long-Running Processes (LRPs).
    1. SSH onto the Diego Cell where the IP address matches the IP address found on the routes table entry.
    1. To get information about all of the actual LRPs, run:
     `cfdot actual-lrps | jq .'`
    1. Look through the actual LRPs to find the instance ID that you noted from the routes table.
    If that instance ID exists and the port in the route table does not exist in the ports section, then there is likely a stale route.
    <p class="note"><strong>Note</strong>: You might be tempted to use the CAPI endpoint <code>GET /v3/processes/:guid/stats</code>
    to find out information about the host and ports the app is using.
    However, it is an app developer endpoint and does not provide complete information for operators.
    Use the <code>cfdot</code> CLI on the Diego Cell to view the actual LRPs directly and all at once.</p>
  
  ### <a id="stale-routes-fix"></a> How to Fix Stale Routes
  
  The following procedure helps you fix stale routes:
  
  1. Ensure that SSL verification is enabled.
  For more information, see [With TLS Enabled](../concepts/http-routing.html#with-tls) in _HTTP Routing_.
  
      Using TLS to verify app identity depends on SSL verification.
      If you disable SSL verification, there is no way to avoid misrouting.
  1. If there is a stale route, then restarting Gorouter fixes the immediate issue.
  If you restart all of the Gorouters and see the same issue for the exact same route, then the issue is not a stale route.
  1. If Gorouter is continually missing deregistration messages, it might be because either the NATS message bus or the Gorouters are overwhelmed.
  Look at the VM usage and consider scaling.
  
  ## <a id="gorouter-error-classification"></a> Gorouter Error Classification Table
  
  Error Type | Status Code | Source of Issue | Evidence
  ------------ | ------------- | ------------- | -------------
  Dial | 502 | App or Platform | Logs with error `dial tcp`
  AttemptedTLSWith<br/>NonTLSBackend | 525 | Platform* | Logs error: `tls: first record does not look like a TLS handshake`, `backend_tls_handshake_failed` metric increments
  HostnameMismatch | 503 | Platform | Logs with error `x509: certificate is valid for <x> not <y>`<br/>, `backend_invalid_id` metric increments
  UntrustedCert | 526 | Platform | Logs with error prefix `x509: certificate signed by unknown authority`<br/>, `backend_invalid_tls_cert` metric increments
  RemoteFailedCertCheck | 496 | Platform | Logs with error remote `error: tls: bad certificate`
  ContextCancelled | 499 | Client/App | Logs with error `context canceled` <p class="note"><strong>Note:</strong> This status code appears in logs only. It is never returned to clients as it occurs when the downstream client closes the connection before Gorouter responds.</p>
  RemoteHandshakeFailure | 525 | Platform | Logs with error remote `error: tls: handshake failure`,`backend_tls_handshake_failed` metric increments
  *Any platform issue could be the result of a misconfiguration.
  
  For each of the above errors, there is a `backend-endpoint-failure` log entry in `gorouter.log` and an error message in `gorouter.err.log`.
  Additionally, the `access.log` records the request status codes.
  For more information, see the [Gorouter documentation](https://github.com/cloudfoundry/gorouter#logs) on GitHub.
  
  ## <a id="app-errors"></a>Diagnose App Errors
  
  This section describes app-related 502 errors.
  
  If 502 errors only occur in specific app instances and not all app instances on the platform, it is likely an app-related error.
  The app might be overloaded, unresponsive, or unable to connect to the database.
  
  If all apps are experiencing 502 errors, then it could either be a platform issue, such as a misconfiguration, or an app issue, such as all apps being unable to connect to an upstream database.
  
  <p class='note'><strong>Note:</strong> Gorouter does not retry any error response returned by the app.</p>
  