Articles in this section

Websites hosted in Plesk are not accessible after an Apache update: 421 Misdirected Request

Plesk for Linux kb: technical

Applicable to:

  • Plesk for Linux

Symptoms

  • All websites show the error:

    PLESK_INFO: 421 Misdirected Request

  • The following error message is logged in domain's log (Plesk > Domains > example.com > Logs):

    CONFIG_TEXT: AH02032: Hostname default-203_0_113_2 (default host as no SNI was provided) and hostname www.example.com provided via HTTP have no compatible SSL setup

Cause

In recent Apache version, Apache team has released fixes for CVEs that affected Apache + nginx functionality: new changes do not allow Apache process requests from nginx without the server name (by default, nginx does not pass the server name through SNI when establishing a connection with a proxied HTTPS server).

This issue has been addresses in Plesk Obsidian 18.0.70 and later releases.

Resolution

Update Plesk Obsidian to the latest build.

Note: The hotfixes are compatible with the manual workaround. So, even for servers where manual solution is already applied, no extra steps are required after installing Plesk update.

Manual workaround for previous Plesk versions:

Add proxy_ssl_server_name, proxy_ssl_name and proxy_ssl_session_reuse  directives in nginx configuration to make nginx pass the server name to Apache through TLS Server Name Indication (SNI) extension:

  1. Connect to the Plesk server via SSH.
  2. Run the script (without any modifications):

    # 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

Was this article helpful?

Comments

173 comments
Date Votes
  • Same issue and fixed with the above script.

    worked like a charm and saved my day with over 100+ website.

    confirmed working on Ubuntu 22.04.5 LTS Plesk Obsidian 18.0.65 Update #2 Web Host Edition

    2
  • Tras aplicar todos los cambios propuestos por soporte (ServerName, reinicio de Apache, rebuild de vhosts, reparación de Plesk...), sigue ocurriendo el error:

    HTTP/2 421  
    server: nginx

    0
  • Thanks , with your solution I could save many of our Servers

     

    0
  • Yes unchecked everything on every of my servers. I saw in the monitoring that every couple minutes another server automaticcaly updated and the websites where not reachable anymore. Thats an unaccaptable behaviour.

    0
  • You guys seriously need a better way to alert users to critical failures like this inside the plesk control panel!!! Otherwise I spend previous minutes googling and freaking out!

    7
  • Strange, because this problem affect to my Ubuntu 24.04.2 LTS, but NOT to other server with Ubuntu 24.04.1 LTS

    Of course, the solution provided works perfectly! Thank you.


     

    1
  • I also got a 403 Error and all websites did not work anymore after applying the fix and restarting the service. Any idea? Missing default domain for exampe? 

    1
  • How is it possible to publish an update, that disables plesk hosted websites over night? that is really bad and makes me think to ditch plesk completely. 

    1
  • It works - thx

    0
  • Kuzma - thank you for the fix. Worked perfectly on both of my servers.

    0
  • For those who get he 403 error which is due to using "reverse proxy" 
     

    add 

    proxy_ssl_server_name on;
    proxy_ssl_name $host;

    to your Apache & nginx Settings (all the way down in the box “Additional nginx directives!”)
     

    0
  • It works!

    0
  • I'm getting “unrecognized service” message on SHH…

    What's the other workaround? Can I sort this using the Plesk GUI ??


     

    0
  • It worked for me too, but this morning I had a shock — UptimeRobot notified me that all my websites were down, and I have quite a few. I don’t understand why I wasn’t informed by Plesk via email that something like this could happen. I’m starting to lose trust in Plesk. I had dozens of clients complaining this morning because their websites were not working — and neither were their business emails. What happened is simply not acceptable.

    1
  • Hello,

    The fix works for me. But after apply the fix, I can´t access via Putty. I receive the following message: putty error no supported authentication methods available (server sent publickey).

    0
  • Great to see there's swift support here. Fix applied as mentioned under sudo -s and got all sites working again

    2
  • Thank you! The fix worked. Appreciate it!

    2
  • It is fixed in Ubuntu 22, but still fails in Ubuntu 18

    0
  • Roney Ngala The command you entered is incorrect — it needs to be written exactly like this, all on a single line:
    echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host" > /etc/nginx/conf.d/fixssl.conf && service nginx restart
    You had a typo at the end (e.g. restartec or similar), which breaks the command. Once you run the correct version, you can verify that everything is in order by executing nginx -t. If everything is fine, the output will be:
    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful
    That confirms the fix was applied and NGINX is ready to go.

    1
  • This worked for us like a charm - echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;" > /etc/nginx/conf.d/fixssl.conf && service nginx restart

    Unusual for Plesk updates to break significant services, great support though.

     

    Thanks

    1
  • Great, works fine

    1
  • [mid-level tech User] OK.. so this is impacting all of my (IONOS) VPS servers running Ubuntu 22.04 and Plesk.

    Now, I have successfully run that SSH command on *one* of them just now… FIXED (thank you!).

    However… before I roll it out across the other VPS environments I have..

    1. Any compromise / side-effects in running the command in question? (i.e. “solving” one problem may potentially introduce others…?)

    2. Am I best (in these circumstances) waiting for the ultimate hosts (IONOS) to fix it by other means..? (or would they merely be running the same command..?)

     

    Thanks all! Excuse my ignorance. John_

    0
  • Not worked for me BUT on plesk panel into server update, then delete ngix, then instal ngix once again, websites are working just like before

    0
  • For those stating they have updates turned off: This was NOT a Plesk update that caused it.

    The fault was caused by the general system updates on Ubuntu from `apt-daily-upgrade.service`

    Ironically, it will be the “Enable safe updates for system packages” option on Tools & Settings > System Updates.

    1
  • sudo su

    then 

    echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;" > /etc/nginx/conf.d/fixssl.conf && service nginx restart

    This solution functions very well.

    0
  • This solved my problem, thank you. However, what I'm really wondering is whether Plesk will solve this issue with an update of its own. Will the settings we made cause problems in the future? I think Plesk officials should take the settings we made into consideration.

    1
  • Bonjour,  Hello,

    La ligne de commande fonctionne. Merci.

    This fix worked! Thanks for the fast fix!

     Have a nice day !

     

     

    0
  • The problem also occurred on my running Ubuntu 24.04.2 LTS, although it is stated to be related to Ubuntu 22.04.
    The above solution worked for me, but I'm not sure if this hotfix has any side effects as described earlier.

    Can anyone comment on this?

    0
  • Arthurs solution worked. Remove ngix and reinstall it again.

    0
  •  

     

    Hi!

    The fix seems to be working at first glance, but I'm encountering a strange issue:

    In the attached screenshot, you can see the monitoring of our domains. As soon as one specific domain “group” comes back online, another domain “group” goes offline – each time with a 421 error.

    After restarting NGINX, it seems like the domain assignments get “shuffled” again, almost randomly.

    Apologies for the messy explanation – I’m not entirely sure myself what's going on here.

    Edit:
    Second interesting log:
    AH02032: Hostname <working domain> provided via SNI and hostname <not working domain> provided via HTTP have no compatible SSL setup

    after the nginx restart the domains got scrambled.

    0

Please sign in to leave a comment.