Debug codes

Learn the meaning of the debug strings
In Transparent Edge, every response is logged with a TCDN-Debug code, that helps us to check what happened with a request in a glance. You can see it in the analytics section of the dashboard
Every code has two parts: the reason and the request id (XID), separated with a colon (`:`). The XID is a unique representation of the request/response and can be disregarded; it's only a identifier we at Transparent Edge use for finding a specific request in the logs.
The reason is far more interesting, because tells us things about the response in case of error. Below is a table including the most common reasons:
Everything is fine. Should be the most common reason code.
RPE is for Request Processed at Edge. The XXX matches the code used in VCL code for processing this request. A TCDN-Command of deny_request or a redirect reners this debug code. You will only see this request in CDN logs, because request and response are entirely managed at the edge node, without any intervention of the backend.
BENG is for Backend Error, No Grace. This error should appear if the request is a MISS, and the origin server renders a error code ( > 500). If the CDN node has a stale content and the grace isn't disabled by the VCL config, stale content should be served instead the error. This type of error usually tells the backend is giving the XXX error originally, so it must be fixed in the origin.
TCDN-BENG-Service unavailable
Very similar to the previous one. There's no content cached in the node for that URL, and there's a problem with the MISS request. In this case, the backend server couldn't be reached for a reply. Usually means a network problem, usually caused by a firewall or IDS blocking requests from our nodes. It also could mean that your configured healthcheck is returning an incorrect status code, so we're marking your backend as unavailable.
SBPR is for Sick Backend, POST/PUT Request. Since usually the only cacheable objects are URLs asked with the GET method, any POST/PUT requests would be uncacheable by default, and hence any stale mechanism is not applied. The XXX part is the original error answered by the backend. Should be fixed in the origin app.
DNF is for `Domain Not Found`. You should see it if a domain is pointing via CNAME to Transparent, but no VCL configuration assigning a backend to that hostname is available.
Unknown error. If you're seeing this, please contact us, including the XID of the request so we can debug the problem.