Skip to main content

[URGENT] 421 Misdirected Request

Comments

141 comments

  • Alan Lam

    You have to downgrade NGNIX by 2 versions as well.  So far this working for us, but we are still testing.

    0
  • ispweb

    It tried,
    dnf downgrade ea-apache24
    dnf downgrade dnf downgrade ea-nginx-1:1.26.3-7.11.1.cpanel

    remarked the lines but still have the same issues.

    0
  • Binh Chon

    I fixed it by changing SSL/TLS on Cloudflare to "Flexible", this worked for me, but it's not a good solution

    0
  • ispweb

    It tried,
    dnf downgrade ea-apache24
    dnf downgrade dnf downgrade ea-nginx-1:1.26.3-7.11.1.cpanel

    remarked the lines but still have the same issues.

    0
  • Wagnard

    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
  • ispweb

    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.cpanel

    I’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
  • cPRex Jurassic Moderator

    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
  • Alan Lam

    @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
  • Lina Torres

    The comment https://support.cpanel.net/hc/en-us/community/posts/33554028389655/comments/33561203145111 temporarily solves the 421 error problem.

    0
  • BenW

    I removed ea-nginx for now. it's not a solution for everybody 

    0
  • danfbach

    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
  • PeteS

    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
  • gh_support

    Any update on it?

    The error still occurs spontaneously...
    How to solve on Ubuntu 20.04?

    0
  • Jeff

    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
  • cPRex Jurassic Moderator

    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
  • PeteS

    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
  • Jeff

    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
  • Marvin Guichelaar

    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
  • Hefin

    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
  • Jason Overhulser

    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
  • John Mahlow

    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
  • imorandin

    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-nginx

    Thanks!

    0
  • John Mahlow

    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
  • Daniel Bazaes

    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
  • Jeff

    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
  • imorandin

    Try installing the plugin first:

    yum -y install yum-plugin-versionlock
    0
  • Jeff

    ahh, ok, so versionlock isn't installed by default. Thanks for the tip.

    0
  • Dimitris Andrikopoulos

    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
  • PeteS
    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
  • cPRex Jurassic Moderator

    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.