Author Topic: Google Recapcha not work on all CWP servers.  (Read 214 times)

0 Members and 2 Guests are viewing this topic.

Offline
*
Google Recapcha not work on all CWP servers.
« on: October 10, 2026, 11:14:27 AM »
We have dozens of CWP servers running version 1.18.
All servers are experiencing the same issue. Google reCAPTCHA on the sites hosted on these servers frequently returns a timeout error. (These are all different PHP-based sites; while reCAPTCHA does work very occasionally, it mostly triggers the following timeout error):

[Sat Oct 10 14:06:03.963742 2026] [proxy_fcgi:error] [pid 3726163:tid 3726196] [client 78.167.3.196:27106] AH01071: Got error 'PHP message: PHP Warning: file_get_contents(https://www.google.com/recaptcha/api/siteverify): Failed to open stream: Connection timed out in /home/USER/public_html/app/lib/vendor/google/recaptcha/src/ReCaptcha/RequestMethod/Post.php on line 80', referer: https://www.USERSITE.com/

NOTE: Increasing the `default_socket_timeout` value in `php.ini` does not resolve the issue, as that does not appear to be the root cause.

Offline
*****
Re: Google Recapcha not work on all CWP servers.
« Reply #1 on: October 10, 2026, 03:06:37 PM »
Out of curiosity, who is your host/bandwidth provider? Is this a new occurrence or has it happened in the past? Is there any pattern to the time of day? And have you done any PHPi-FPM tuning to the servers?

Offline
*
Re: Google Recapcha not work on all CWP servers.
« Reply #2 on: October 10, 2026, 04:05:29 PM »
Out of curiosity, who is your host/bandwidth provider? Is this a new occurrence or has it happened in the past? Is there any pattern to the time of day? And have you done any PHPi-FPM tuning to the servers?

Host/bandwidth provider: Contabo

This issue has emerged recently (specifically after switching to AlmaLinux 9). All of these servers were either reformatted and reinstalled recently or are brand-new servers that were set up from scratch.

At first, I thought the problem stemmed from using CloudFlare, but the same issue occurs on sites that do not use CloudFlare.

I haven't identified a specific time interval; the problem seems to occur at completely random times.

I do not believe the standard adjustments I make to the PHP-FPM .ini files are causing this issue (I generally increase values ​​like `max_execution_time`, etc., and I have been applying these same settings for years).

The fact that the issue affects all PHP-FPM versions suggests that the root cause lies elsewhere.

Also, when I check via SSH, I see there is no issue accessing the reCAPTCHA servers.

Offline
*****
Re: Google Recapcha not work on all CWP servers.
« Reply #3 on: October 10, 2026, 09:10:49 PM »
Curious why not use the built in Google Authenticator 2FA?

No editing code that could change with an update.

Offline
*
Re: Google Recapcha not work on all CWP servers.
« Reply #4 on: October 11, 2026, 09:01:39 AM »
Website owners use Google reCAPTCHA for site registrations, member logins, form submissions, and the like.
In other words, reCAPTCHA is not used for CWP panel logins or similar access points.

Offline
*****
Re: Google Recapcha not work on all CWP servers.
« Reply #5 on: October 11, 2026, 07:18:16 PM »
Website owners use Google reCAPTCHA for site registrations, member logins, form submissions, and the like.
In other words, reCAPTCHA is not used for CWP panel logins or similar access points.

So if I read that right, then this isn't a CWP 'bug' since it isn't being used for CWP logins or other access.

It's being used by sites, and hence their coding.

Offline
*
Re: Google Recapcha not work on all CWP servers.
« Reply #6 on: Today at 12:47:00 PM »
The fact that this issue occurs across hundreds of different sites (each using different PHP scripts) on dozens of CWP servers indicates that the problem originates from CWP. This issue did not exist prior to AlmaLinux 9 and the current version of CWP.

Offline
*****
Re: Google Recapcha not work on all CWP servers.
« Reply #7 on: Today at 07:03:54 PM »
CWP doesn't control that part.
If you where trying to modify the CWP user login script, then maybe an update did something.

This sounds like a file permissions issue or something with your php.ini

And is a problem between AL8, AL9 and AL10.

All those OS'es handle system security differently. Which is a royal pain in the ...

So security settings on AL8, won't act or even work on AL, and setting from AL8 or AL9 won't act or work on AL10.
This is one problem why some control panels act or do not work at all.

Was behind the Migration problem between AL8 and AL9.

I'm guessing no one bothered testing AL9 before migrating.

But if it works on AL8 with CWP 1.18, and doesn't work on AL9 with the same CWP 1.18, that rules out CWP.

As mentioned above, I would start looking into permissions (users, assigned groups, how is SELinux configured, etc, etc)

I'm not sure why RHEL did this, and hence clones.
It's a pain.

RHEL 8 and clones act similar to CentOS 7.
Another reason CWP needs to drop support for the EOL CentOS 7 and try & focus on AL9 and maybe AL10.