Pathing status

​​ Understanding pathing

Cloudflare issues the following Edge Pathing Statuses:

• EdgePathingSrc (pathing source): The stage that made the routing decision.
• EdgePathingOp (pathing operation): The specific action or operation taken.
• EdgePathingStatus (pathing status): Additional information complementing the EdgePathingOp.

​​ EdgePathingSrc

EdgePathingSrc refers to the system that last handled the request before an error occurred or the request was passed to the cache server. Typically, this will be the macro/reputation list. Possible pathing sources include:

• err
• sslv (SSL verification checker)
• bic (browser integrity check)
• hot (hotlink protection)
• macro (the reputation list)
• skip (Always Online or CDNJS resources)
• user (user firewall rule)

For example:

$ jq -r .EdgePathingSrc logs.json | sort -n | uniq -c | sort -n | tail
1 err
5 user
93 macro

​​ EdgePathingOp

EdgePathingOp indicates how the request was handled. wl is a request that passed all checks and went to your origin server. Other possible values are:

• errHost (host header mismatch, DNS errors, etc.)
• ban (blocked by IP address, range, etc.)
• tempOk (challenge successfully completed)
• chl (challenge issued)

For example:

$ jq -r .EdgePathingOp logs.json | sort -n | uniq -c | sort -n | tail
1 chl
1 errHost
97 wl

​​ EdgePathingStatus

EdgePathingStatus is the value EdgePathingSrc returns. With a pathing source of macro, user, or err, the pathing status indicates the list where the IP address was found. nr is the most common value and it means that the request was not flagged by a security check. Some values indicate the class of user; for example, se means search engine. Others indicate whether the visitor saw an error or a captcha, such as, captchaNew or jschlOK.

For example:

$ jq -r .EdgePathingStatus logs.json | sort -n | uniq -c | sort -n | tail
1 captchaNew
1 dnsErr
5 ip
92 nr

​​ How does pathing map to Threat Analytics?

Certain combinations of pathing have been labeled in the Cloudflare Threat Analytics feature (in the Analytics app in the Cloudflare dashboard). The mapping is as follows:

​​ Understanding response fields

The response status appears in three places in a request:

• edgeResponse
• cacheResponse
• originResponse

In your logs, the edge is what first accepts a visitor’s request. The cache then accepts the request and either forwards it to your origin or responds from the cache. It is possible to have a request that has only an edgeResponse or a request that has an edgeResponse and a cacheResponse, but no originResponse.

This is how you can see where a request terminates. Requests with only an edgeResponse likely hit a security check or processing error. Requests with an edgeResponse and a cacheResponse either were served from the cache or saw an error contacting your origin server. Requests that have an originResponse went all the way to your origin server and errors seen would have been served directly from there.

For example, the following query shows the status code and pathing information for all requests that terminated at the Cloudflare edge:

$ jq -r 'select(.OriginResponseStatus == null) | select(.CacheResponseStatus == null) |"\(.EdgeResponseStatus) / \(.EdgePathingSrc) / \(.EdgePathingStatus) / \(.EdgePathingOp)"' logs.json | sort -n | uniq -c | sort -n
1 403 / macro / captchaNew / chl
1 403 / macro / nr / wl
1 409 / err / dnsErr / errHost

The information stored is broken down based on the following categories:

​​ Errors

These occur for requests that did not pass any of the validation performed by the Cloudflare network. Example cases include:

• Whenever Cloudflare is unable to look up a domain or zone.
• An attempt to improperly use the IP for an origin server.
• Domain ownership is unclear (for example, the domain is not in Cloudflare).

​​ User-based actions

These occur for actions triggered from users based on the configuration for a specific IP (or IP range).

To understand the behavior of challenge pages, refer to JavaScript and Captcha Challenge .

​​ Firewall Rules

Cloudflare Firewall Rules triggers actions based on matching customer-defined rules.

To understand the behavior of challenge pages, see JavaScript and Captcha Challenge .

​​ Zone Lockdown

Zone Lockdown blocks visitors to particular URIs where the visitor’s IP is not allowlisted.

To understand the behavior of challenge pages, see JavaScript and Captcha Challenge .

​​ Firewall User-Agent Block

Challenge (Captcha or JavaScript) or block visitors who use a browser for which the User-Agent name matches a specific string.

To understand the behavior of challenge pages, refer to JavaScript and Captcha Challenge .

​​ Browser Integrity Check

Assert whether the source of the request is illegitimate or the request itself is malicious.

To understand the behavior of challenge pages, refer to JavaScript and Captcha Challenge .

​​ Hot Linking

Prevent hot linking from other sites.

To understand the behavior of challenge pages, see JavaScript and Captcha Challenge .

​​ L7-to-L7 DDoS mitigation

Drop DDoS attacks through L7 mitigation.

To understand the behavior of challenge pages, refer to JavaScript and Captcha Challenge .

​​ IP Reputation (MACRO)

The macro stage is comprised of many different paths. They are categorized by the reputation of the visitor IP.

All other paths in the MACRO stage issue a challenge. Possible scenarios include:

• A clean IP (acceptable threat level) with IUAM on will trigger the JS challenge.
• A greylisted IP triggers the JS challenge (Managed Challenge if IUAM is on).
• An IP with a bad reputation (also TOR) with a threat level above the accepted threshold triggers a Managed Challenge (JS challenge if IUAM is on).

​​ Rate Limiting

To understand the behavior of challenge pages, refer to JavaScript and Captcha Challenge .

​​ Special cases

​​ JavaScript and Captcha Challenge