{"id":1578,"date":"2020-06-07T22:14:46","date_gmt":"2020-06-07T14:14:46","guid":{"rendered":"https:\/\/www.wesbytes.com\/guide\/?post_type=kb&p=1578"},"modified":"2026-01-12T13:58:54","modified_gmt":"2026-01-12T05:58:54","slug":"527-railgun-listener-to-origin-error","status":"publish","type":"kb","link":"https:\/\/www.servergigabit.com\/guide\/kb\/527-railgun-listener-to-origin-error","title":{"rendered":"527 Railgun Listener to Origin Error"},"content":{"rendered":"

527 Railgun Listener to Origin Error<\/strong><\/h3>\n

For requests being optimized by Railgun, any interruption or failure in the WAN connection from Railgun\u2019s sender. At Cloudflare\u2019s edge and the Railgun Listener at the customer\u2019s . Origin will result in the following error page being displayed in the browser:<\/p>\n

 <\/p>\n

\"527<\/p>\n

A 527 error indicates that the connection between Cloudflare and the origin\u2019s 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.<\/p>\n

 <\/p>\n

It may be required to\u00a0increase logging for Railgun\u00a0in order to troubleshoot further, and see what rg-listener is reporting.<\/p>\n

Below are details on common scenarios where a 527 error would be presented to a user, and the associated.\u00a0 Railgun error that would be found in the local Railgun logs.<\/p>\n

\n
Common Railgun Log Errors<\/u><\/h6>\n<\/div>\n
\n
Connection Timeouts<\/strong><\/h6>\n<\/div>\n

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:<\/p>\n

connection failed 0.0.0.0:443\/example.com: dial tcp 0.0.0.0:443: i\/o timeout<\/p>\n

no response from origin (timeout) 0.0.0.0:80\/example.com<\/p>\n

*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.<\/p>\n

This can be done by using commands like\u00a0cURL<\/code>,\u00a0ping<\/code>,\u00a0nc<\/code>, or running\u00a0traceroute<\/code>\/mtr<\/code>\u00a0against the web server\u2019s source IP.<\/p>\n

\n
Some example commands would be:<\/h6>\n<\/div>\n

curl -svo \/dev\/null \u2013resolve example.com:PORT:SERVERIP \u2018http[s]:\/\/example.com\/\u2019<\/p>\n

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.<\/p>\n

\n
ping SERVERIP<\/h6>\n<\/div>\n

nc -vz SERVERIP PORT<\/p>\n

Using\u00a0ping<\/code>\u00a0or\u00a0nc<\/code>\u00a0is helpful to confirm the web server\u2019s ports are open and accepting traffic from the Listener.<\/p>\n

This will help determine if the connection is being accepted from the site\u2019s origin server. Or if an issue is present that is impacting the webserver from accepting requests.<\/p>\n

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.<\/p>\n

\n
LAN Timeout is Exceeded\u00a0<\/strong><\/h6>\n<\/div>\n

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\u00a0lan.timeout<\/code>\u00a0parameter found in the\u00a0railgun.conf<\/code>\u00a0file. If the origin server does not respond within the specified timeout limit. Then the following error would be seen in the Listener logs:<\/p>\n

connection failed 0.0.0.0:443\/example.com: dial tcp 0.0.0.0:443: i\/o timeout<\/p>\n

*What to do when the LAN timeout limit is exceeded:<\/p>\n

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.<\/p>\n

\n
\u00a0<\/strong><\/h6>\n<\/div>\n
\n
Connection Refusals<\/strong><\/h6>\n<\/div>\n

If requests from the Railgun Listener are being outright refused, then the following errors would be seen in the Railgun logs:<\/p>\n

Error getting page: dial tcp 0.0.0.0:80:connection refused<\/p>\n

*What to do if requests are being refused:<\/p>\n

If these errors are being observed, then next steps would be to ensure the Listener\u2019s server IP is whitelisted from the origin server\u2019s access control settings (such as\u00a0IPtables<\/code>\u00a0or\u00a0Fail2ban<\/code>\u00a0rules).<\/p>\n

\n
TLS\/SSL Related Errors<\/strong><\/h6>\n<\/div>\n

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:<\/p>\n

0.0.0.0:443\/example.com: remote error : handshake failure<\/p>\n

0.0.0.0:443\/example.com: dial tcp 0.0.0.0:443 : connection refused<\/p>\n

127.0.0.1:443\/www.example.com: x509 : certificate is valid for example.com, not www.example.com<\/p>\n

*How to doif 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:<\/p>\n