527 Railgun Listener to Origin Error

Avatar
Algin

For requests being optimized by Railgun, any interruption or failure in the WAN connection from Railgun's sender at CloudFlare's edge and the Railgun Listener at the customer's origin will result in the following error page being displayed in the browser: 

Overview

A 527 error indicates that the requests timeout or failed after the WAN connection has been established. This could result from an interruption or anomaly upstream from the Railgun Sender in the path to the Listener at the site's origin.

The 527 error could also occur due to an issue within the host environment when the Railgun Listener is unable to to complete or establish a connection to the origin server to receive a requested page: 

As there are a number of causes as to why the connection between the Listener and the webserver could have failed, it may be required to increase logging for Railgun in order to troubleshoot further.

Below are details on common scenarios where a 527 error would be presented to a user, and the associated Railgun error that would be found in the local Railgun logs. 


Common Railgun Log Errors

Connection Timeouts

If the Railgun Listener is unable to establish or complete a TCP handshake with the origin server, then the following errors would be produced within the Railgun logs for requests:

connection failed 0.0.0.0:443/example.com: dial tcp 0.0.0.0:443: i/o timeout
no response from origin (timeout) 0.0.0.0:80/example.com
What to do if connection timeouts are seen: 
If these errors are being seen, then it is recommended to confirm and test if the server hosting the Listener is able to connect to the origin directly.

This can be done by using commands like cURL, ping, nc, or running traceroute/mtr against the web server's source IP.

Some example commands would be:

curl -svo /dev/null --resolve example.com:PORT:SERVERIP 'http[s]://example.com/'

This cURL would need to be run on port 80 for HTTP and port 443 for HTTPS tests, depending on the protocol used for the expected traffic.

ping SERVERIP
nc -vz SERVERIP PORT

Using ping or nc is helpful to confirm the web server's ports are open and accepting traffic from the Listener.

This will help determine if the connection is being accepted from the site's origin server, or if an issue is present that is impacting the webserver from accepting requests.

If a problem at the webserver can be confirmed, then next steps would be to contact the host provider to assist in resolving the issue local to the origin server.

LAN Timeout is Exceeded 

By default, the timeout limit for the origin server to send an HTTP response to the Listener is thirty seconds. This value is determined by the lan.timeout parameter found in the railgun.conf file. If the origin server does not respond within the specified timeout limit, then the following error would be seen in the Listener logs:

connection failed 0.0.0.0:443/example.com: dial tcp 0.0.0.0:443: i/o timeout
What to do when the LAN timeout limit is exceeded:
It is advised to either increase the timeout limit, or review the webserver configuration as to why the origin is taking a long time to respond to requests from the Listener. In most scenarios, it is also helpful to check the current load/bandwidth received on the webserver to confirm if the server is overloaded and unable to respond efficiently for requests.

Connection Refusals

If requests from the Railgun Listener are being outright refused, then the following errors would be seen in the Railgun logs:

Error getting page: dial tcp 0.0.0.0:80:connection refused
What to do if requests are being refused:
If these errors are being observed, then next steps would be to ensure the Listener's server IP is whitelisted from the origin server's access control settings (such as IPtables or Fail2ban rules).

TLS/SSL Related Errors

If TLS requests fail to complete or connect to the origin server from the Railgun Listener, then the following errors could be seen within the Railgun Logs:

connection failed 0.0.0.0:443/example.com: remote error: handshake failure 
connection failed 0.0.0.0:443/example.com: dial tcp 0.0.0.0:443:connection refused
connection failed 127.0.0.1:443/www.example.com: x509: certificate is valid for example.com, not www.example.com
What to do if HTTPS requests are failing:
If any TLS/SSL errors are being seen in the logs, then the following checks should be conducted on the origin server:
  • Port 443 is open.
  • A certificate is present at the origin to serve HTTPS requests.
  • Confirm the SSL setting in your CF account is set to at least FULL or FULL (Strict) if the origin expects HTTPS traffic. 
If you are troubleshooting certificate validation errors, then you will want to confirm that the SSL certificate installed at the origin contains the requested hostname in the SAN/common name and is a valid certificate (meaning it is not expired or self-signed). Otherwise, there is the option to disable validate.cert within the railgun.conf, which will stop Railgun from checking against the origin certificate.

Submitting a Support Ticket for 527 Errors

If a support ticket is to be filed in the event further assistance is needed, please submit the following pieces of information from the Railgun Listener so that CloudFlare Support can troubleshoot further in reviewing the the Railgun configuration.

  • The railgun.conf file.
  • If internal addressing is in use for the host environment, then the railgun-nat.conf file should be submitted in the ticket.
  • Any Railgun log files that detail the errors being seen from the Listener.
Was this article helpful?
0 out of 0 found this helpful
Still not finding what you need?

The CloudFlare team is here to help. 95% of questions can be answered using the search tool, but if you can’t find what you need, submit a support request.

Submit a request

Popular questions: Why is my site slow, 522 errors, I'm expecting a spike in traffic

Powered by Zendesk