Fixing "421 Misdirected Request" for Plesk Sites on Ubuntu 22.04 After Apache Update

Fixing the 421 Misdirected Request Error on Plesk (Ubuntu 22.04)

After certain Apache security updates on Ubuntu 22.04, all HTTPS sites managed by Plesk may suddenly return a "421 Misdirected Request" error. This guide explains the root cause, provides a step-by-step fix, and shows how to automate the workaround so it survives future updates.

1. Symptoms

• All HTTPS sites on Plesk for Ubuntu 22.04 begin returning 421 Misdirected Request.
• Browsers display a message about the requested hostname not matching the Server Name Indication (SNI) in use.
• HTTP sites continue to work normally; only HTTPS traffic is affected.

2. Root Cause

Recent CVE patches for Apache changed how it enforces SNI (Server Name Indication) matching on TLS connections. In Plesk's architecture, nginx sits in front of Apache as a reverse proxy. By default, nginx does not forward the SNI hostname when proxying HTTPS requests to Apache. After the Apache update, Apache now strictly requires that the SNI hostname matches the requested virtual host, and since nginx is not sending it, Apache rejects the connection with a 421 error.

3. Step-by-Step Resolution

3.1 SSH into the Server

ssh root@your-server-ip

3.2 Create the nginx Fix File

Add the following directives to forward the SNI header from nginx to Apache:

cat <<'EOF' > /etc/nginx/conf.d/99-proxy-sni.conf
proxy_ssl_server_name on;
proxy_ssl_name $host;
EOF

3.3 Reload nginx

service nginx restart

3.4 Verify Apache Connectivity

Watch Apache's error log:

tail -f /var/log/apache2/error.log

Then test with curl:

curl -Ik https://www.your-domain.com/

We should see a 200 OK response instead of the 421 error.

4. Why the Fix Works

• proxy_ssl_server_name on; tells nginx to include the SNI extension in the SSL handshake with Apache.
• proxy_ssl_name $host; ensures the handshake uses the requested hostname.

With SNI enabled, Apache selects the correct SSL virtual host and certificate, eliminating the 421 error.

5. Automating the Workaround

To ensure the fix survives package updates and nginx restarts, we can create a simple script and schedule it via cron:

cat <<'EOF' > /usr/local/sbin/plesk-nginx-sni-fix.sh
#!/bin/bash
echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;" > /etc/nginx/conf.d/99-proxy-sni.conf
service nginx reload
EOF
chmod +x /usr/local/sbin/plesk-nginx-sni-fix.sh
ln -s /usr/local/sbin/plesk-nginx-sni-fix.sh /etc/cron.daily/plesk-nginx-sni-fix

This runs daily to re-apply the configuration if it gets overwritten.

6. Best Practices & Tips

• Disable auto-OS updates during peak hours in Plesk to avoid surprises.
• Monitor logs with journalctl -f and tail -f /var/log/nginx/error.log.
• Staging first: clone and test before applying updates to production.
• Snapshots: back up the VM or instance before critical package changes.
• Stay informed: follow the Plesk knowledge base for official patches.
• Use Ansible or Puppet for fleet-wide rollout and verification of the SNI fix.