Skip to main content

[URGENT] 421 Misdirected Request

V3NTUS
  • Edited

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.

Comments

141 comments

Date Votes
  • AdminGuy

    @amaroarcast

    you save my day, may tahnks

    0
  • Ahmed Ghazi

    Completely Uninstalling NGINX proxy resolved the issue. I am on cPanel + CloudLinux. 

    I hope a fix update is released by cPanel soon.

    0
  • cPRex Jurassic Moderator

    The CloudLinux team has said they are working on a fix for the recent issues, but this is only happening with CloudLinux systems at this point.

    0
  • mtindor

    From Cloudlinux:

    https://cloudlinux.zendesk.com/hc/en-us/articles/21282870470172-421-Misdirected-Request-Error-After-Recent-ea-apache-Update

    Scroll down to "The Latest Update"

    There you will find the yum command to update from the cl-ea4-testing repo

     

    0
  • cPRex Jurassic Moderator

    I do want to be clear that today's issue affected CloudLinux systems and was not related to cPanel tools or packages as we haven't performed a release since the rollback last week.

    -1
  • AccessWeb

    cPRex

    "I do want to be clear that today's issue affected CloudLinux systems and was not related to cPanel tools or packages as we haven't performed a release since the rollback last week."


    With all due respect, I find that statement even more concerning.

    So let me get this straight: cPanel has known for over a week that there is a serious compatibility issue between Apache 2.4.64 and systems running NGINX Reverse Proxy — a configuration actively supported and documented by cPanel — and yet nothing was done to proactively prevent this from reaching production servers via the update mechanism of the CloudLinux/Immunify360 servers last night?

    Are we now to believe that no one at cPanel anticipated that CloudLinux would eventually ship this Apache version to their customers — many of whom are cPanel users? That doesn’t just feel like poor coordination — it feels like negligence.

    Let’s not forget: most of us are subscribed to the STABLE branch specifically to avoid these kinds of breaking issues. But now it appears that even with known, reported issues that directly affect cPanel-integrated setups (like NGINX), no measures are taken to shield us — and the response is simply: "It's not our package"?

    Technically accurate? Maybe.
    Practically helpful? Not at all.

    As a customer, I expect cPanel to take a more active role in safeguarding its users — not shifting blame. If your software stack relies on multiple vendors (CloudLinux, Imunify360, etc.), then you must test and coordinate accordingly — or clearly warn your users in advance.

    This didn’t feel like a surprise — it felt like a car crash in slow motion that no one tried to stop.

    - AccessWeb

    1
  • SD14

    @cPRex thanks for the clarity. I wish cPanel would take the overall responsibility for the platform. Allowing a promoted 3rd party addon to bring down your platform should be acknowledged as the platform's responsibility.

    Clients expect the platform to audit and block promoted 3rd party addons or replace the 3rd party addon with internal solutions over which they have full control. 

     

    1
  • RFranco COL
    • Edited

    This is a temporary solution that works for me, but every time the files are recreated I have to do it again.

    I had to add a line (proxy_ssl_server_name on;) in every conf file at /etc/nginx/conf.d/users
    this line has to be added before *every* "proxy_pass" line.

    Example:
    BEFORE:

        location / {
            include conf.d/includes-optional/cpanel-proxy.conf;
            proxy_pass $CPANEL_APACHE_PROXY_PASS;
        }

    AFTER:

        location / {
            include conf.d/includes-optional/cpanel-proxy.conf;
            proxy_ssl_server_name on;
            proxy_pass $CPANEL_APACHE_PROXY_PASS;
        }

    I also add an "s" in every proxy_pass URL, example:
    BEFORE:
     proxy_pass http://127.0.0.1:2090/Microsoft-Server-ActiveSync;
    AFTER:
     proxy_pass https://127.0.0.1:2090/Microsoft-Server-ActiveSync;

    then I restarted nginx with 

    "nginx -t && /scripts/restartsrv_nginx"

    And worked for me with Almalinux.

    I also did this script to change every conf file at once:

    #!/bin/bash

    # Base directory
    CONF_DIR="/etc/nginx/conf.d/users"

    # Verify Directory
    if [ ! -d "$CONF_DIR" ]; then
      echo "Directory not found: $CONF_DIR" >&2
      exit 1
    fi

    # Find and modify all .conf files
    find "$CONF_DIR" -type f -name "*.conf" | while read -r CONF_FILE; do
      echo "Processing: $CONF_FILE"

      # Create backup files
      cp "$CONF_FILE" "$CONF_FILE.bak"

      # Insert proxy_ssl_server_name before each proxy_pass
      # and replace http:// with https:// in proxy_pass
      sed -i '/^\s*proxy_pass /{
        h
        s/^\(\s*\).*/\1proxy_ssl_server_name on;/
        G
      }' "$CONF_FILE"

      sed -i 's|\(proxy_pass\s*\)http://|\1https://|g' "$CONF_FILE"
    done

    echo "OK Process completed. All files modified with .bak backup."

    I hope this help some of us.

     

     

     

    0
  • cPRex Jurassic Moderator

    UPDATE

    A recent update in Apache 2.4.64 introduced a bug fix that inadvertently caused HTTP 421 errors in many common proxy configurations. To prevent widespread disruption, we temporarily rolled back the change, giving both Apache and our team time to address the issue properly in version 2.4.65.

    For customers using ea-nginx, we've implemented a workaround by switching the proxy protocol from HTTP/1.1 to HTTP/1.0. This mitigates the issue for now, but depending on your setup, you may still encounter some side effects.

    🔍 What You Might Experience

    • If you're using ea-nginx: You may notice limitations with HTTP/1.1 features, such as WebSockets.

    • If you're using another proxy: You might encounter intermittent HTTP 421 errors until your proxy is adjusted to accommodate Apache’s updated behavior. There may be side effects from their solution.

    🛠 Technical Details

    For a deeper dive into the root cause and technical explanation, please refer to the following article: https://github.com/CpanelInc/ea-nginx/blob/main/docs/Apache-2.4.26-421.md

    🧪 How to Verify Your Setup’s Behavior

    To safely test the updated Apache and NGINX configuration before deploying to production, follow these instructions:

    • RPM .repo file : http://ea4testing.cpanel.net/Apache-2.4.64-421.repo

      • wget http://ea4testing.cpanel.net/Apache-2.4.64-421.repo -O /etc/yum.repos.d/Apache-2.4.64-421.repo
      • yum clean all

    • Deb .list files

      1. http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_24.04.list

        1. wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_24.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_24.04.list
        2. curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_24.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
        3. apt update

      2. http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_22.04.list

        1. wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_22.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_22.04.list
        2. curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_22.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
        3. apt update

      3. http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_20.04.list

        1. wget http://ea4testing.cpanel.net/Apache-2.4.64-421.xUbuntu_20.04.list -O /etc/apt/sources.list.d/Apache-2.4.64-421.xUbuntu_20.04.list
        2. curl -fsSL http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_20.04/Release.key | gpg --yes --dearmor | gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/ea4testing.gpg --import
        3. apt update

    You can ignore apt update’s gpg warning, which will look similar to this:

    W: GPG error: http://ea4testing.cpanel.net/Apache-2.4.64-421/xUbuntu_22.04 ./ InRelease: The following signatures were invalid: BADSIG ACFD2F50F8D0C701 EA4 Tool (This is used by `et pub` to sign debs) <ea4-tool@cpanel>

    Also you may need to adjust permissions on /etc/apt/trusted.gpg.d/ea4testing.gpg

    -1
  • Katherine Cooke

    Sorry I'm late to the party. I have several cPanel servers that were affected by this, though we don't run NGINX on either of them. I followed the advice below, which worked:

    Confirm version: rpm -q --changelog ea-nginx | head -2

    Then we did:
    dnf downgrade ea-apache24-2.4.63
    yum -y install yum-plugin-versionlock
    yum versionlock ea-apache24

    This fixed the issue and got us up and running again. However, I now am getting confused with all of the various messages and whether they are Apache specific or NGINX specific etc. 

    Can anybody confirm what my next steps would be in order to get the servers back to "normal" or is there still not an official fix, other than to lock the versions? Currently we have the versions locked on Apache, but if there is now a working version available, i'd obviously much rather unlock the versions, update Apache, and carry on as I was pre-problem.

    Can anybody help (in simple terms). If it is that there is still not an official working fix for the Apache version, then obviously i'll just leave the versions locked until there is. Thanks for any help.

    0
  • cPRex Jurassic Moderator

    Normal will happen with the release that is scheduled for tomorrow!

    3
  • Onur Tural

    ❌ Drawbacks of This Approach (from a developer’s point of view)

       

    Downgrading protocol

    Using HTTP/1.0 is a step backward; it lacks keep-alives and chunked transfer encoding, which HTTP/1.1 and HTTP/2 support.

    Performance penalty

    Less efficient than HTTP/1.1 or HTTP/2 due to lack of persistent connections and pipelining.

    Not scalable

    May reduce performance under high load, especially for dynamic or high-traffic sites.

    Workaround, not a fix

    It treats the symptom, not the root — the mismatch in SNI expectations between the frontend (NGINX) and backend (Apache) isn’t truly “solved”, just avoided.

    Architectural inconsistency

    Mixing HTTP/2 (client-side) and HTTP/1.0 (proxy backend) may cause unexpected issues with newer applications expecting richer protocol features.
    0
  • netserver

    Today I woke up to find all the servers down. This is the second week that I’ve experienced this impact affecting more than 30 users hosted with WHM/cPanel licenses. This should not happen; we are all paying for usage licenses, which guarantee that the WHM/cPanel packages have been approved and validated. Otherwise, all that work and every manual action are being carried out by the end users. It has been three weeks since the first incident, and the panel has still not resolved this issue.

    0
  • imorandin

    Hey, has anyone else experienced that the latest update of ea-nginx and ea-apache24 doesn’t completely fix the issue, and the errors "AH02032: Hostname xxxx provided via SNI and hostname xxxx provided via HTTP have no compatible SSL setup" are still showing up?

    0
  • cPRex Jurassic Moderator

    imorandin - yes, it is expected that if you're using something besides Nginx or Cloudflare that you may need to adjust the SNI configuration in order to get things working.

    -1
  • Pro Active
    • Edited

    imorandin cPRex We started seeing these errors again this morning, too. We're also using ea-nginx and ea-apache on Cloudlinux, not any non-cPanel services, and both are up to date. The errors look like this in the Apache error log:

    AH02032: Hostname aaaaa.com provided via SNI and hostname bbbbb.com provided via HTTP have no compatible SSL setup

    Where bbbbb.com is the actual domain, and aaaaa.com is a random, completely unrelated domain.

    0
  • cPRex Jurassic Moderator

    It looks like this issue is still affecting CloudLinux users.  I've reached out to their team and they are currently investigating things, but I don't have any other details at this time.

    1
  • Pro Active

    cPRex Thank you for the update.

    0
  • Jeff

    We un-versionlocked our Apache Yum update last week and the very next day, we had 4 sites on that server that went back to having the 421 error problem. I had understood from cPREX's post on July 18th that the problems were all worked out with the latest release and that it was safe to update, so I allowed my servers to continue updating it again. Boy was I wrong.

    This sure does erode our trust in cPanel. And, this has been going on now for over a month!

    1
  • cPRex Jurassic Moderator

    Jeff - it likely doesn't help, but today's changes appear to be from CloudLinux as cPanel doesn't release updates to Apache except for our Wednesday release days.

    0
  • Jeff
    • Edited

    @cPRex - unrelated to this issue but I’m a different user named Jeff and received an email alert from your mention - Does this forum have duplicate usernames? 😅

    0
  • cPRex Jurassic Moderator

    Yes - the new system allows duplicate usernames and gets confusing quickly!

    0
  • Nicolas

    The problem remain also in DirectAdmin if you have the bad idea to remove the versionlock : 

    https[:]//forum.directadmin[.]com/threads/all-sites-with-error-412-misdirected-request-directadmin-and-cloudlinux.74291/#post-391560

    CloudFlare still did not update his SNI compliance. 

    It seems Apache don't want to change his mind and we would be stuck at the 2.4.63 version for a while.

    0
  • cPRex Jurassic Moderator

    Update - CloudLinux is currently looking into a fix for this situation and they are testing it today.

    2
  • Richard Brandson
    • Edited

    Thank you for the updates. Looking forward to the fix.

    PS. Not a solution, but a temporary workaround that worked for me (WHM / Cloudlinux) was downgrading

    dnf downgrade ea-apache24
    0
  • Pro Active

    For us, we were already on ea-apache24 2.4.63, but we started seeing the errors again yesterday, only intermittently instead of constantly.

    Downgrading ea-nginx seems to have fixed the problem. Version 1.26.3-15 had the errors, but 1.26.3-11 is ok.

    0
  • cPRex Jurassic Moderator

    Pro Active - are you also on CloudLinux?

    0
  • Pro Active

    cPRex Yes, CloudLinux 9.

    0
  • Richard Brandson

    Can they fix it please?

    Its extremely irritating to have to do the downgrade every day, and its extremely bad idea to lock the version.

    The solution is not to push an update with a bug to users, it is to stop all automatic upgrades until the upgrade is actually WORKING!

    Think please!

    0
  • cPRex Jurassic Moderator

    Richard Brandson - I haven't heard an update from CloudLinux other than they are still investigating the issue when I checked just a few minutes ago.

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post