curl localhost:8001. This is the admin interface of every sidecar. To see a list of all available resources, run curl localhost:8001/help.curl localhost:8001/config_dump from within the sidecar. This is the full configuration of the sidecar, which can be used for comparison with the mesh configuration you expect to have been applied.502 or a 503 error, it's likely an issue with JWT filter configuration or with SPIRE.502 or 503 error in a web browser, the problem is likely with either ingress to the edge service, or a failure in the filter chain, such as the JWT filter./services/fibonacci). With this error, it is likely you won't see this request at all. If this is the case, then check for logs indicating a filter chain failure, this would appear as something like:no healthy upstream error, check the edge logs and grep for your path (e.g. /services/fibonacci). You may see a log that looks like this:"-", which means it is not known. If this is the case, you can follow more specific steps to verify discovery and ultimately go back through the deploy a service guide and make sure to create all of the necessary mesh objects from steps 2 and 3.upstream connect error error, check the edge logs and grep for your path - (e.g. /services/fibonacci). You may see a log that looks like this:10.42.1.8:10808, we can see that this is not a discovery issue from edge to sidecar. To rule out discovery as the problem, next check the service's sidecar logs.503 log that looks like the following:{UPSTREAM-HOST} value. If the value is "-", there is a discovery issue from sidecar to service. You will likely need to hard code the address for this in the local cluster. If the value is something like [::1]:9080, the instance that you configured in this step of deploying a service (the local cluster) could be wrong, or the service may have other security requirements that don't allow the sidecar to make requests to it as configured.curl localhost:8001/clusters./services/fibonacci and you see the following in the edge logs:503, but you don't see any indication of this request in the sidecar's logs, this is likely an mTLS problem.curl localhost:8001/stats | grep ssl. You will see something like the following:curl localhost:8001/logging?level=debug -XPOST. Then, make the failing request again. Because of the high volume of logs, it may be best to run curl localhost:8001/logging?level=info -XPOST immediately afterwards to turn off debug logging while you inspect the output.TLS error or OPENSSL. The errors that come up here may also indicate more specifically what the problem is./logging/logging?level=<log-level>level.error, warn, info, debug.