Spurious 524 timeout on login/form submission

Getting Started
#1

We switched usbji.org over to Cloudflare last weekend. The site itself loads fine. When attempting to submit a form or to log in, however, the request always fails with a 524 timeout.

This timeout is spurious. If I bypass Cloudflare and attempt to log in (e.g. from the internal network), the login works fine, responding in less than a second. If, while the browser is still spinning, you stop the browser and refresh the page, the dashboard for an authenticated user will appear normally as well, and after that, you can click around and submit forms as an authenticated user without any problem. The same is true if, from the 524 error screen, you click on the supposedly failing URL.

This is a Drupal 7 site with CiviCRM. We have multiple such sites set up on Cloudflare and this is the first time we have ever encountered this problem. The server is not under load or remotely close to it, and indeed connections to this server are restricted to Cloudflare IPs.

I have attempted the following:

  • tried all three SSL settings (our other sites are all set to Full (strict) and work fine)
  • set page rules to bypass Cloudflare for the login and CiviCRM URLs

The Speed Test, incidentally, was also failing for www.usbji.org .

Any insights would be appreciated.

#2

This sounds like your host is rate limiting Cloudflare and/or their firewall is kicking in. Have you contacted them about this?

#3

We self-host with Cogent. There is no rate limiting in place, but even if there were, it would not explain why other sites on the same server would come up. It seems like Cloudflare is fine with GETs, but fails to detect a successful POST.

#4

Does this happen sporadically? When I try to login with a non-existent user, i don’t get a 524.

#5

It happens consistently, for example, when trying to edit my user profile, or on a sample form like https://www.usbji.org/node/1209 .

For the latter, the delay may be occurring because the server cannot reach the SMTP servers (SMTP2GO), even though https://support.smtp2go.com/hc/en-gb/articles/360022578154-DNS-Setup-for-CloudFlare has been followed, and we are using outbound port 465 for SSL, which works flawlessly with other sites which use Rackspace for SMTP.

#6

could you make a limited account on your site and post the login details here for testing? I am unable to create one myself to investigate this deeper.

#7

Thanks for all the responses thus far. In attempting to create a test account that didn’t have access to certain backend functionality, I’ve discovered that the failures seem to occur when there is a redirect after login. That is, users of certain roles get redirected to one screen after login, users of different roles to another screen. If I remove the redirects, the login proceeds as normal; otherwise, it stalls out in the browser, even though the CMS log says the redirect was successful.

I’ve no idea why this should be the case; these are application redirects, not Apache or network redirects.

The inability to connect to SMTP2Go (despite confirming the account information and using the settings from https://support.smtp2go.com/hc/en-gb/articles/360022578154-DNS-Setup-for-CloudFlare ) is a more pressing question, as PHPmailer being unable to reach mail.smtp2go.com on ports 465 or 587 does introduce a delay which may be causing the request to time out.

#8

I’m not super familiar with Drupal but my primary job is dealing with PHP. if you are able to send me the script responsible for redirecting users and you make the test account as discussed then I’d be happy to look into it for you. I also understand that you don’t want to expose any part of your sites back end on a public forum so if it’s not possible to make a test account that doesn’t expose sensitive areas of your site we can try some other work around.

#9

Thanks. The behavior occurs both with the Login Destination module as well as if I configure the redirect using Rules. Both call drupal_goto() which issues a 302 redirect to the destination path, and I suspect this 302 is confusing the proxy somehow.

#10

It’s unlikely, but if you can actually find the code for the drupal_goto function I may be able to provide more insight.

1 Like
#11

Thanks again. The code is at the link I provided, or you can find it in the Git repo for common.inc, line 682. It constructs a path, then issues an HTTP 3xx redirect to it.

#12

Peculiarly, we opened up port 443 for outbound connections, and now things have returned to “normal.” This is, suffice to say, a very unexpected coincidence, but I am not well-versed in the vagaries of networking. I surmise that once Drupal issues the redirect, the web server tries to open a connection to the destination but couldn’t, because we had it blocked on our firewall, hence the operation never completed, hence Cloudflare timed out.

I greatly appreciate all the participation in this thread regardless. Happy New Year.

2 Likes
#13

This topic was automatically closed after 31 days. New replies are no longer allowed.