[URGENT] 421 Misdirected Request
All my customers are reporting this issue since this morning.
I searched around and it could be related to the last Apache's update (2.4.62).
For instance:
1) NO, it's not related to Cloudflare (disabling it doesn't fix the issue at all)
2) NO, running this command as fix DID NOT HELP:
echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;\nproxy_ssl_session_reuse off;" > /etc/nginx/conf.d/fixssl.conf && systemctl restart nginx
3) NO, running
dnf update
as shown here: https://support.cpanel.net/hc/en-us/articles/33553346450455-Websites-show-421-Misdirected-Request-error-while-using-EA-Nginx does not help.
4) NO, disabling http/2 does not help as well
5) NO, disabling NGINX Manager does not help as well
6) The only temporary solution appears to be completely uninstalling NGINX reverse proxy, which can't be really called a solution as it will negatively impact the performance of every website.
I tried everything I could, and nothing worked. Everyone gets random and frequent "421 Misdirect Request" errors while browsing. Please provide a resolution as soon as possible as I'm sure it's a global issue affecting everyone since the last update, thank you.
-
cPRex Thanks, but...
The rollback doesn't work (for many here, it seems, including myself) and is no longer listed here: https://support.cpanel.net/hc/en-us/articles/33553346450455-Websites-show-421-Misdirected-Request-error-while-using-EA-Nginx-or-other-proxies What is listed there doesn't work either, per my post above.
I'm on AlmaLinux v8.10.0 and cPanel 128.0.17 and none of these workarounds work.
Can we get a tested 100% effective rollback procedure?
1 -
At this time, I don't have such a thing available.
0 -
cPRex how to downgrade apache and nginx on cpanel with ubuntu os?
Please guide me and provide us the commands0 -
To verify the versions, we executed the following command:
rpm -q --changelog ea-nginx | head -2
rpm -q --changelog ea-apache24 | head -2On an effective server, we used the commands below, and after running them, everything worked again
dnf downgrade ea-apache24-2.4.63
dnf downgrade ea-nginx-1.26.3-7.11.1.cpanel.x86_64
yum -y install yum-plugin-versionlock
yum versionlock ea-apache24
yum versionlock ea-nginx0 -
PeteS
I am on the same and this works:This is what I did and it works:
I did Apache from 2.4.64 -> 2.4.63 (to avoid the original 421 issue)
and EA-Nginx from 1.26.3-10 → 1.26.3-7 (because the "421 fix" attempts were causing server-wide SNI/Host mismatches)
I have helped several people using this. Im not sure if yall are skimming over this solution but it works.1 -
how can a bug like this pass the testing release tests? so easily spotted since the websites stop working... amazing.
2 -
Thanks, John Mahlow! I suspected the missing link was an Nginx rollback too, but cPanel never said that in their workaround. SMH
I didn't skim past it, just decided to see if cPanel would have a fix out today (Nginx is uninstalled for now, since it doesn't cause an immediate issue for our servers).
ispweb posted the same versions as compatible, above, so that seems solid.
Kind of a bummer that we have to trail-and-error our way to a fully documented workaround. I expected cPanel to be on top of that!
0 -
PeteS - if I would have had a known-good fix that would work for everyone, I would have shared it. However, we didn't end up finding one today. <see below post for more details>
1 -
THE PLAN: We are currently testing a new build that reverts the changes introduced in yesterday's CVE-related release. While this update does not address the root cause, it will restore normal update functionality and prevent disruptions for users in the short term. We expect to release this build shortly.
Unfortunately, some upstream changes had unforeseen consequences, and we sincerely apologize for the inconvenience this has caused. Our team is actively working on a long-term solution to resolve the underlying issue, to address some inadequate testing procedures, and steps to prevent such events in the future, with development efforts ongoing into next week.
0 -
dnf downgrade ea-apache24-2.4.63
dnf downgrade ea-nginx-1.26.3-7.11.1.cpanel.x86_64What should I do for Ubuntu 20 please?
0 -
Intekhab - there isn't a specific downgrade command for Ubuntu, but running /scripts/upcp or letting the nightly update handle it will fix the issue. It hasn't been released just yet but it should happen within the hour.
0 -
The update is syncing out now so it should be live within the next 15 minutes.
0 -
Everything is synced out now so you're all good to run upcp to get things working normally if you haven't already.
2 -
Engintron released a fix :
https://engintron.com/docs/#/pages/Changelog
Updating that fixed the issue for me0 -
Thank you cPRex
Updating via /scripts/upcp fully resolved the issue on my server!
-1 -
Confirming that upcp rollback is working.
Thanks for keeping us informed, cPRex.
...and we sincerely apologize for the inconvenience this has caused. Our team is actively working on a long-term solution to resolve the underlying issue, to address some inadequate testing procedures, and steps to prevent such events in the future, with development efforts ongoing into next week.
Much appreciated and good to hear. Can you please post here as soon as the retry for Apache and corresponding Nginx updates are going to hit upcp?
0 -
Oh for sure - I'll have updates next week when things start happening.
1 -
As far as the main problem is concerned, Apache v2.4.63 with ea-nginx v1.26.3-11.14.1.cpanel works without giving any HTTP 421 responses. Indeed, I used some crawler and visited more than 10.000 pages of my website, and didn't receive any HTTP 421 responses. However, the above fix was not provided as a solid solution but a workaround, so I cannot be sure for any possible complications that may cause.
Important point for the Software: With the Apache v2.4.64 installed, I was advised to remove NGINX Reverse Proxy, as there was initially some conclusion that Apache v2.4.64 gave HTTP 421 responses only when it worked with NGINX Reverse Proxy. Well I tried twice to remove NGINX via NGINX Manager of WHM, and though the removal process seemed to be successfully completed within WHM, the NGINX Reverse Proxy remained intact. So, this case should be also thoroughly checked in the scope of having a solid solution for Apache v2.4.64.
Important point for the Process: The problem with the HTTP 421 occurred because Apache v2.4.64 was not properly tested on cPanel. I can't believe that Apache v2.4.64 was successfully tested with NGINX Reverse Proxy on some Test System of cPanel, so this disaster could not be anticipated when deployed on Live Systems. Also, another serious problem was the lack of a rollback plan; i.e. Apache and ea-nginx and any other package that have been updated should have been rolled-back to some versions known to be stable. After that the developers could take their time and provide a solid solution, and not a quick workaround so as to just put out the fire.
Apache company is definitely not responsible for this case, because they did not have any reason to test their software with NGINX, or any other competitor software. The same applies to NGINX company. This situation was totally cPanel's responsibility which offer Apache and NGIXN Reverse Proxy. For customers who have cPanel servers through some ISP, and not cPanel directly, the responsibility goes to ISP which let cPanel propagate the relevant update to the servers of their customers.
1 -
You're absolutely right to emphasize the need for proper testing and rollback strategies. However, that's precisely what makes this situation more frustrating.
According to cPanel's own release tier definitions:
STABLE – 128.0.17: A version that is feature-complete, fully tested, and is in widespread use.
RELEASE (Recommended) – 128.0.17: A version that is feature-complete and well tested.Both STABLE and RELEASE currently point to the same build — 128.0.17 — and cPanel explicitly says it is well tested. If that's the case, then how did something as critical as the Apache 2.4.64 + ea-nginx 1.26.x 421 errors get through?
This raises serious concerns about what “well tested” actually means at cPanel. Either:
-
The integration with ea-nginx wasn’t tested properly despite being part of their stack, or
-
The testing process does not reflect real-world configurations that customers use — which makes the "well tested" label misleading.
As you said, the root issue lies in the lack of proper integration testing and the absence of a real rollback path. For something marked as STABLE and RELEASE, this should never have reached production environments.
1 -
-
EasyApache updates are unrelated to the cPanel version tiers, so that wouldn't apply here.
1 -
Thanks for the clarification. If EasyApache updates are indeed decoupled from the cPanel version tiers, then perhaps that’s exactly the problem.
Since these updates can introduce breaking changes — like the recent Apache 2.4.64 + ea-nginx 421 issue — there should be a proper rollback mechanism, or at the very least, a tiered release system for EasyApache, similar to how cPanel itself uses EDGE / CURRENT / RELEASE / STABLE.
Right now, server admins are caught off guard with critical updates that may not have been tested against real-world configurations, and once they're installed, there’s no easy path to revert. That’s risky for production environments.
A rollback button in WHM or even a structured EasyApache release tier would go a long way toward preventing issues like this from spreading to stable systems.
2 -
Thank you, cPRex, for clarifying that EasyApache updates are separate from cPanel's version tiers. However, this separation highlights a critical issue: these Apache and ea-nginx updates, packaged within cPanel’s EasyApache framework, appear to bypass the rigorous testing cycles that customers expect from a premium product. The widespread HTTP 421 Misdirected Request errors caused by the Apache 2.4.64 update demonstrate that these components are not being adequately vetted in real-world configurations before being pushed to production environments.
Whether or not EasyApache updates align with cPanel’s STABLE or RELEASE tiers, they should undergo their own robust testing process to ensure compatibility, especially with ea-nginx, a core part of cPanel’s stack. The fact that this issue reached live systems suggests a significant gap in quality assurance. Compounding the problem, the lack of a clear rollback plan left sysadmins with disruptive workarounds like downgrading packages or uninstalling NGINX entirely—hardly viable solutions for complex, production-grade setups.
WebPros leadership needs to step up and take responsibility. Once the dust settles—ideally later this week or next—I would urge WebPros to provide a detailed postmortem outlining how these updates bypassed sufficient testing, why they were deployed to production, and what concrete measures will be implemented to prevent such oversights moving forward. This level of transparency is essential to rebuild trust with the community, who rely on cPanel/WHM for enterprise-grade reliability.
1 -
I have run:
yum versionlock clear and updated via /scripts/upcp
Still shows :
Server version: Apache/2.4.63 (cPanel)
Server built: Jul 18 2025 23:20:58nginx version: nginx/1.26.3
Should it be Apache/2.4.64 ?
0 -
Marek Pravlik - no, since we rolled back the version from 64 to 63. What you're seeing is expected.
0 -
Minor update - there won't be a release today as we're still deciding how we want to handle this. I'll update once I know more.
0 -
SOLUCAO : Amigos apos dias de luta e com alguns comentarios resolvi da seguinte forma , fiz downgrade , Voltei a versao do servidor para apache 24.62 , o atual e 24.64 , DEU TUDO CERTO sem maiores problemas , tambem funciona com NGINX versao EA-Nginx de ATUAL 1.26.3-10 PARA → 1.26.3-7, MAS deixei sem ate terem nova versao apache , OUTRA SOLUCAO inslatar litespeedy ja que nao usa apache e se torna mais rapido que NGINX e independente .
0 -
Hello.
Same problem here.
After doing:
dnf clean all
dnf update ea-*
And uninstall NGINX Proxy, through NGINX MANAGER the problemas was solve.1 -
Dear cPanel team,
I am extremely disappointed and frustrated with what has just happened.
Roughly one hour ago, I was alerted by my monitoring system that all websites on one of my shared hosting servers were offline. Upon immediate investigation, every site was throwing a “Misdirect Request (SNI)” error. This was not due to any local misconfiguration, but the direct result of a recent automatic cPanel update that had just been pushed to my server.
After further research, I came across a thread on this very forum that already reported this issue more than 7 days ago. Despite that, cPanel still allowed this broken update to be rolled out to production servers—including mine. This is completely unacceptable for a product I pay a premium license fee for, and which is supposed to be stable and enterprise-ready.
To restore functionality for my clients, I had no other choice but to manually remove the NGINX Proxy integration, which is completely unacceptable as a middle-of-the-night emergency workaround. I have business clients relying on my infrastructure and service continuity. This incident has not only disrupted my sleep but seriously damaged my confidence in cPanel’s QA and update procedures.
How can a known issue like this, which affects core HTTP functionality for all hosted domains behind NGINX Proxy, be left unresolved and still be pushed in an automatic update a full week after discovery?
This is a serious breach of trust.
I expect:
-
A formal response and root cause explanation;
-
An immediate rollback or hotfix for affected systems;
-
A clear improvement in cPanel’s update testing and release management strategy going forward;
-
And preferably an option to defer or block updates known to affect specific modules or configurations like NGINX Proxy.
This level of disruption is not what I signed up for—and not what I expect from a product of this caliber.
Please escalate this issue internally and provide answers.
Sincerely,
A very dissatisfied and sleep-deprived customerEDIT:
P.S. I understand that cPanel updates are not forcibly “pushed” but rather pulled via standard update channels as configured (STABLE here); but that’s not the point. What truly concerns me is that even after being aware of the Apache 2.4.64 issue, this version is still being made available to systems running Imunify360 and CloudLinux, where it is now causing widespread service disruption as I can see.
If cPanel, CloudLinux, or Imunify360 teams were aware of the incompatibility (as seems to be the case from public threads, and this thread for 7 days), this version should have been held back or blocked from deployment on affected configurations. Instead, it went live on my production server last night; a dangerous oversight in any serious software ecosystem.
0 -
-
Hello,
Today, Saturday, July 26 at 6 AM for my time zone, an UPCP update caused a downtime of 15 minutes on all our cPanel + CloudLinux servers.
We are on the tier Stable.
We were aware of the issue (experienced before with DirectAdmin + CDN (bunny net), which limited the duration of the downtime, but without prior knowledge, the impact would have been significantly worse.
We ran the command "dnf downgrade ea-apache24" to temporarily resolve the issue.
The official cPanel article about this concern do not mention this workaround, but just recommend to make an update, which does not work :
Websites show "421 Misdirected Request" error while using EA-Nginx or other proxies
https://support.cpanel.net/hc/en-us/articles/33553346450455-Websites-show-421-Misdirected-Request-error-while-using-EA-Nginx-or-other-proxiesIn another article, not linked to the previous one, cPanel seems to blame CloudLinux packages from CL repositories, still shipping the wrong version of Apache :
Websites experiencing 421 Misdirected requests after upgrading to CloudLinux's ea-apache24-2.4.64
https://support.cpanel.net/hc/en-us/articles/33724988525207-Websites-experiencing-421-Misdirected-requests-after-upgrading-to-CloudLinux-s-ea-apache24-2-4-64yum downgrade ea-apache24*
It's also possible (but NOT recommended) to disable UPCP updates following this article :
How to customize cPanel's Update Preferences from the Command Line
https://support.cpanel.net/hc/en-us/articles/360052313594-How-to-customize-cPanel-s-Update-Preferences-from-the-Command-LineSee below, about "versionlock".
1. However, to ensure stability and continuity of services, what are the next steps to follow?
2. How can I ensure I’m using the correct Apache version moving forward to avoid future "Misdirected Request" errors?
3. Could you provide an update on the status of this resolution?
It seems that to temporarily stop updates with UPCP during the time you all completely fix this issue :
I saw this command lines seen on your forum :
yum install yum-plugin-versionlock
yum versionlock add ea-apache24*
To revert this later, after CloudLinux (repository) and cPanel defenetely adress the issue :
yum versionlock delete ea-apache24*
Thanks in advance to cPanel for providing clear recommendations and a timeline for a definitive resolution.
0 -
All said and done, I fail to understand why "cPanel stable build number was not lowered" to ensure that the stable tier servers were not affected?
7 days is enough time to mitigate or protect the Stable tier from the impact of known issue that remained unresolved! This is a L4 or L5 decision-making failure
2
Please sign in to leave a comment.
Comments
141 comments