[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.
-
You have to downgrade NGNIX by 2 versions as well. So far this working for us, but we are still testing.
0 -
It tried,
dnf downgrade ea-apache24
dnf downgrade dnf downgrade ea-nginx-1:1.26.3-7.11.1.cpanelremarked the lines but still have the same issues.
0 -
I fixed it by changing SSL/TLS on Cloudflare to "Flexible", this worked for me, but it's not a good solution
0 -
It tried,
dnf downgrade ea-apache24
dnf downgrade dnf downgrade ea-nginx-1:1.26.3-7.11.1.cpanelremarked the lines but still have the same issues.
0 -
ispweb
Yes they are the lines.On my end I edited them before doing the apache downgrade. (I did not downgrade nginx)
I think the order we do things is important for configuration rebuild I guess.
while you still have the SNI fixes commented out, try to
dnf update ea-apache24
and then
dnf downgrade ea-apache24
Just in case, verify with httpd -v that you are at Apache 2.4.63
In case it matters, I also have httpv2 module for apache disabled / not provisioned.A clear cache of nginx after could help too in case your config cache the 4xx errors
CloudFlare is Full-Strict on my side
Hope it work for you too.0 -
Apologies for the confusion. It does work when you perform the following downgrades:
dnf downgrade ea-apache24-0:2.4.63-2.6.2.cpanel
dnf downgrade ea-nginx-1:1.26.3-7.11.1.cpanelI’ve also temporarily locked both packages to prevent them from being updated:
yum versionlock ea-apache24
yum versionlock ea-nginx
The immediate issues have been resolved for now by applying temporary workarounds, including downgrading the affected packages. However, we are currently awaiting a permanent fix or official update from cPanel to address the root cause of the problem. We hope that a long-term solution will be provided soon to prevent further disruptions.3 -
Hey there! Our team is aware of the issue and we're working on this urgently through case EA-13031. I'll let you know as soon as we have an update.
0 -
@cPRex can you at least update the article - https://support.cpanel.net/hc/en-us/articles/33553346450455-Websites-show-421-Misdirected-Request-error-while-using-EA-Nginx
As none of these fixes alone fixes the issues.
0 -
The comment https://support.cpanel.net/hc/en-us/community/posts/33554028389655/comments/33561203145111 temporarily solves the 421 error problem.
0 -
I removed ea-nginx for now. it's not a solution for everybody
0 -
It occurred with Plesk too - https://support.plesk.com/hc/en-us/articles/33500191748887-Websites-hosted-in-Plesk-are-not-accessible-after-a-recent-Apache-update-421-Misdirected-Request
To me, this says that the apache_httpd update was shipped by apache without thorough testing, so those of you playing the blame game - this on is on apache.
Plesk suggests a fix:
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
But I have been unable to make this solution work on my cpanel servers.
0 -
The updated info here (https://support.cpanel.net/hc/en-us/articles/33553346450455-Websites-show-421-Misdirected-Request-error-while-using-EA-Nginx) regarding the hotfix does not for me.
Nginx was uninstalled, ea-apache24 not downgraded, after reinstalling and confirming the hotfix, the error returned.
EA-NGINX
We have released a hotfix to help update the cPanel-provided EA-NGINX plugin. This can be confirmed by running the following commands -
AlmaLinux/RHEL-Based:
rpm -q --changelog ea-nginx | head -2 * Thu Jul 17 2025 Cory McIntire <cory.mcintire@webpros.com> - 1.26.3-10 - EA-13014: Update to 421 Fix, order matters
0 -
Any update on it?
The error still occurs spontaneously...
How to solve on Ubuntu 20.04?0 -
I've downgraded my affected servers and things seem to be back to normal, but I'm worried that this will recur the next time my server goes out and checks for updates. cPRex can you confirm that the faulty update has been pulled and won't be pushed out again until this is fully resolved?
0 -
The updates aren't able to be pulled because they contained 8 security updates that were released yesterday. If I'm understanding things correctly, Apache also made a minor change in addition to the security update which is causing this issue.
We still hope to have a fix available within the next few hours.
0 -
Jeff, can you detail your server config and the downgrade steps you took that were successful? Most seem to not have success.
If you don't versionlock the package(s) you downgraded they will upgrade again next upcp.
0 -
Sure, PeteS. My affected servers were both Almalinux 8.x running WHM 128.0.17.
What's different/unique about my situation is that the ONLY sites that were affected on these two servers were sites that use Sucuri's WAF product. Other sites that don't use Sucuri WAF seemed to be unaffected. Neither of these two servers are running NGINX. Just straight EA Apache.
The only thing I did was run:
dnf downgrade ea-apache24
and that seemed to resolve the problem with no further edits/modifications. From reading all of the comments here, I feel like I got off easy (sorry you guys are still wrestling with it). But I'm suuuuuper frustrated at cPanel for allowing this buggy release to wreck all of our mornings. I don't know about you all, but I was pulled out of bed at 3:00am from angry clients (as well they should be). And yet...cPanel continues to raise their prices up ...and up...and up....
2 -
At my server the issue still occurs without nginx proxy. On the problem ticket;
Websites will show a "421 Misdirected Request" error when using EA-Nginx or other proxies such as Cloudflare.
I dont use any proxy and still has the 421 error. Tell the truth please
1 -
As far as I can see this issue has raised it's ugly head up because of a recent Apache update (version 2.4.64) (Bug report to Apache herehttps://bz.apache.org/bugzilla/show_bug.cgi?id=69743) that’s being extra picky about how your websites’ SSL certificates are handled. Even without a proxy like Nginx, your server’s setup is likely running into a mix-up with the certificates for your sites.
But the kicker here is that should have been seen a mile off by WebPros/WHM/cPanel are supposed to thoroughly test these Apache and Nginx updates and package them up into EasyApache packages that there software uses. They should go through the dev team/test team and Edge servers first, so issues like this never hit production. Honestly, it’s hard to imagine this was tested properly; it feels like they just rolled it out without checking!
0 -
I have Engintron plugin installed, and resolved the issue by simply allowing the plugin to update all its packages. Look for Update (or re-install) Engintron [with Nginx "stable"] toward the bottom of the plugin's configuration page.
2 -
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)
0 -
Hi,
The official fix isn't working for me either.Is there an official way to prevent the update from running during tomorrow's upcp?
Are these the correct commands?yum versionlock ea-apache24
yum versionlock ea-nginxThanks!
0 -
Yeah and use `yum versionlock list` to make sure it worked and then you run these after the update is fixed
`yum versionlock delete ea-apache24
yum versionlock delete ea-nginx`
I would suggest this over doing anything with /etc/yum.conf because it focuses on your exact versions and easer to remove. Also upcp may not respect direct changes to the conf but Im not sure.1 -
If only cPanel would give us an ETA, we could save time with our clients/users and move on to other matters instead of being stuck testing workarounds that might only work under certain conditions.
3 -
This is what I get when I try to run yum versionlock ea-apache24:
No such command: versionlock. Please use /bin/yum --help
Almalinux 8.x
0 -
Try installing the plugin first:
yum -y install yum-plugin-versionlock
0 -
ahh, ok, so versionlock isn't installed by default. Thanks for the tip.
0 -
I regret to say that this situation gives me the impression that a few people actually know how to properly work. I mean that before some software is released with cPanel, it should be thoroughly tested. On the other hand, ISPs who offer cPanel servers or similar products should have at least a rollback plan for any software upgrade. You cannot upgrade any software on a live server in cold blood without having a step-by-step plan for rolling back things in case something is going wrong. I'm totally disappointed.
3 -
Thanks Jason Overhulser Good to know.
"I have Engintron plugin installed, and resolved the issue by simply allowing the plugin to update all its packages. Look for Update (or re-install) Engintron [with Nginx "stable"] toward the bottom of the plugin's configuration page."
I moved from Engintron to the cPanel baked in Nginx, thinking I would be better taken care of... Engintron would have issues once in a while, and so far cPanel's implementation has been flawless. Until now...
cPRex - this seems like a major screw-up. I know you care, but what a letdown to see what appears to be a lack of texting (caring) by those we so dutifully pay every-single-month!
0 -
I honestly don't have much to share yet. The team is still trying to get a fix that is compatible with all the recent CVEs, but as of this time the rollback and versionlock is likely the best plan.
If I hear more I'll be sure to update.
1
Please sign in to leave a comment.
Comments
141 comments