Why are Railgun Requests Showing as Direct?

If Cf-Railgun header contains the status direct (and sometimes be followed by a field description),

this indicates that Railgun Listener did not handle the request but went directly to the origin web server.

If a direct status is seen repeatedly for requests, there are two common reasons why this would occur:

1. For a site with low traffic, this typically indicates that Railgun was starting a new connection to the remote rg-listener and that connection wasn't ready yet. Running a second request to test will usually succeed and show compression. 
2. For a site with a large amount traffic, this usually indicates that the Listener is not working or cannot be contacted.

Troubleshooting Repeated direct Status for Requests

When requests are seen as going direct continuously, it is recommended to check the Listener configuration for the following:

1. The Railgun service is running on the server hosting the Listener.
2. Port 2408 is open.
3. Cloudflare IPs are whitelisted and allowed to connect to the Listener server. A list of Cloudflare's IP ranges can be found here.

direct Status Header Descriptions

Here are the possible field descriptions, when a request has a Railgun status of direct:

all WAN connections are busy

This status occurs when it is not possible to open any more WAN connection between the Sender and Listener due to the maximum number of WAN connections has been reached and all the WAN connections are busy. The maximum number of WAN connections is set by the rg-sender wan.lanes parameter. In production, this is set to 1,000 connections.

starting new WAN connection

There was no free WAN connection between the Sender and Listener so rather than wait for it to come up the request goes direct. When this happens it's often on a lightly used site and is an optimization to prevent us for waiting for a WAN connection. While this is happening Railgun makes a WAN connection to the remote rg-listener.

waiting for pending WAN connection

Very similar to to 'starting new WAN connection', but indicates that the new connection has already happened, but the Railgun Sender is waiting on rg-listener for the WAN connection that has not been established.

internal error or Internal channel failure

This occurs when there is an internal error with the Railgun Sender at Cloudflare's edge. If this error is being observed in the request headers, please please submit a Support ticket for additional assistance. 

Intended Behavior

Here is a typical sequence of requests where the initial connection establishes the WAN, then subsequent requests are optimized while the WAN is open between the Railgun Sender and Listener:

Cf-Railgun: direct (starting new WAN connection) Cf-Railgun: 6a622d1e98 0.02 0.001751 0030 3350 Cf-Railgun: c562e934d3 0.02 0.002268 0030 3350 Cf-Railgun: 342a904d9c 0.02 0.002070 0030 3350 Cf-Railgun: c3f365ab80 0.02 0.004062 0030 3350

The above pattern in the request stream is normal when using Railgun. If this pattern is being reproduced when testing/debugging, then this means that Railgun is optimizing the site's traffic as intended.