527 Railgun Listener to Origin Error

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: 

A 527 error indicates that the connection between Cloudflare and the origin's Railgun server (rg-listener) was interrupted. This could result from a firewall block or other network incident between rg-listener and Cloudflare, such as packet loss on the line.

 

It may be required to increase logging for Railgun in order to troubleshoot further, and see what rg-listener is reporting.


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.



Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.