After upgrading to Apache 2.4.64 (or after applying linux vendors updates) many sites behind a reverse proxy started returning 421 Misdirected Request. The practical cause is simple: when your proxy makes an HTTPS connection to Apache, Apache now expects a correct TLS SNI value that matches the HTTP host. If the proxy omits SNI or sends a different name than the Host header, Apache can reject the request with 421. This change exposed default proxy settings that used to work by accident.
What the 421 error means
The HTTP 421 Misdirected Request status means the request reached a server that is not configured to respond for the combination of scheme and authority that you used. Browsers often reuse HTTP/2 connections across hosts if the server allows it, but Apache 2.4.64 tightened the checks so that connections without a matching SNI and Host are rejected. That is why you can see the error only on some requests or only on some subdomains after the update. The error message is the following:
Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
Who is affected
You are affected if a reverse proxy connects to Apache over HTTPS and does not pass SNI to the backend. This is common for nginx in front of Apache, HAProxy with HTTPS backends, and some CDNs or load balancers that re-encrypt to the origin. Panels that pair nginx and Apache (for example EA-Nginx on cPanel, Plesk, Hestia, and similar) were among the first to report 421 after the update.
Fix: send the correct SNI to Apache and keep it consistent with Host
The fix is to enable SNI on the upstream HTTPS hop and make its value match the HTTP Host that Apache should serve. Keep the connection private (VPC, VLAN, VPN, or same host) if you do not want the name visible outside your network. Do not roll back the Apache security update. Configure your proxy once and the 421 errors stop.
nginx to Apache over HTTPS
Enable SNI toward the backend and keep Host consistent.
Use an https URL whose hostname is the site you want to serve so that Apache sends that name as SNI to the backend.
SSLProxyEngine on
ProxyPass / https://site.example.com/
ProxyPassReverse / https://site.example.com/
How to test and confirm
From the proxy host, curl the backend using the public hostname and the backend IP to confirm that SNI and Host agree. Watch your Apache error log for messages about missing SNI or a vhost mismatch while you test.
The 421 you see is produced by the stricter SNI and authority checks added around 2.4.64 and enforced by HTTP/2 handling. The cure is to send a correct SNI on the upstream connection and keep it consistent with Host.
Do I need to verify the backend certificate for SNI to matter? No. Apache uses SNI during the TLS handshake to pick the correct SSL vhost and certificate before it even reads the HTTP request. Certificate verification by the proxy is a separate operational choice. The important part for avoiding 421 is that the SNI you send and the Host header you send resolve to the same Apache vhost, precisely the ServerName and ServerAlias directives. Matching the SNI with a domain in a certificate that is missing in the apache vhost directives will also fail.
Every time Mojang ships a new Bedrock build, your server goes stale. Clients update themselves, refuse to connect to an older server, and you are back to SSH, hunting down a zip, and copying files over your install while trying not to touch your worlds folder.
This script does that for you. It checks the official download API, does nothing at all if you are already current, and if you are not, it swaps in the new server files while leaving your worlds and your configuration alone. Bedrock Dedicated Server on Linux only, not Java Edition.
What the script does
On every run it:
Asks the official Minecraft download API for the current Linux Bedrock build.
Compares that version against a small version file inside your server folder.
Exits immediately if they match. Nothing is downloaded, nothing is touched.
Otherwise downloads the zip to a temp folder, tests it for corruption, and confirms the server binary is in there.
Copies the new files over your install with rsync, skipping your configs and your worlds.
Records the new version number and cleans up.
What it does not do:
It does not restart your server. The files get replaced, but the running process keeps serving the old version until it restarts. There is a section on this below.
It does not back up your worlds. It never touches them, but take backups anyway.
It does not remove files that disappeared from newer releases.
Run it as the user that owns the server files. Nothing here needs root.
The API returns a plain JSON list of the current download links, one per platform. The jq filter picks the entry tagged serverBedrockLinux. Swap that string for serverBedrockPreviewLinux if you want to follow preview builds, and keep preview builds away from worlds you care about. This is why the script does not scrape the download page. The old scraping scripts all broke when bot protection went up in front of it, and the API does not care what your user agent is.
bedrock-server.version is a one line file the script writes into your server folder. It is not part of the official zip and the server never reads it. It is the script’s only memory, and it is what makes a daily cron job cheap: on a server that is already current, the entire run is one HTTPS request and an exit. Delete that file to force a clean reinstall of the current version.
Everything downloads into a temp folder, never into the live server folder. unzip -t tests the archive before a single file is copied, so a truncated download or a full disk dies there instead of halfway through overwriting your server binary.
Then rsync copies the new files in, and the excludes are what keep your server yours:
server.properties is your port, difficulty, gamemode, view distance, and everything else you tuned. The zip ships a default copy that would flatten it.
permissions.json and ops.json are your operator lists.
allowlist.json is the allowlist, and whitelist.json is what it used to be called. Both are excluded, so this works on old installs and new ones.
valid_known_packs.json lists the packs the server knows about. The server rewrites this file itself. If a release ever makes it complain about packs, delete the file and let it rebuild.
worlds/ is your saves. The one that matters.
There is no --delete, so files that vanish from newer releases just stay behind. That wastes a little disk and it avoids the entire class of accident where one wrong exclude pattern eats a world.
One quirk worth knowing: the character class in grep -o '[0-9.]\+' also matches the dot in front of zip, so the version comes out as 1.26.33.2 with a trailing dot on the end. Nothing breaks, because the same expression writes the version file and reads it back. If it bothers you in the log, use grep -oE '[0-9]+(\.[0-9]+)+' instead.
Step 3: Make It Executable
chmod +x ~/update-bedrock.sh
Run it once by hand before you trust it to cron. On a clean box it doubles as the installer: the server folder does not exist yet, so rsync creates it and you never have to download the zip yourself.
Step 4: Automate with Cron (Optional)
Edit your crontab with crontab -e and add this line to check daily at 3 AM:
Put that in the crontab of the user that owns the server, not root. The script builds every path from $HOME, and root’s home is /root.
Restart the server after an update
This is the part that catches people out. rsync renames each new file into place, so replacing files under a live process does not crash it, but the running server keeps its old binary open. It carries on serving the old version, players still get told the server is out of date, and the script has already cheerfully printed Updated.
The update is not finished until the server process restarts.
Assuming your server runs as a systemd service called bedrock, add this just above the rsync block:
SERVICE="bedrock"
RESTART=0
if systemctl is-active --quiet "$SERVICE"; then
echo "Stopping $SERVICE..."
sudo systemctl stop "$SERVICE"
RESTART=1
fi
And this at the very end, after the version file is written:
if [[ "$RESTART" == 1 ]]; then
echo "Starting $SERVICE..."
sudo systemctl start "$SERVICE"
fi
Because the script already exited earlier when there was nothing to do, this only ever fires on a real update. Your server is not bounced nightly for no reason.
For cron to run those two commands without a password, add a narrow sudo rule with sudo visudo -f /etc/sudoers.d/bedrock-update, using your own username:
Failed to extract URL/version. The API is unreachable, or its JSON changed shape. Run the curl above by hand and look at what comes back. Your install has not been touched.
ZIP test failed. Truncated download or a full disk. Check df -h and run it again.
It says Updated but players still see the old version. The server was never restarted.
Permission denied during the rsync. You ran the script as the wrong user. If you ran it once as root, fix the ownership with sudo chown -R minecraft:minecraft ~/bedrock-server.
Cron never runs it. Check that the script is executable and that crontab -l shows the line under the right account. An empty log usually means the crontab belongs to another user.
Done
Your server now spots new releases on its own, refuses to touch anything if the download looks wrong, keeps your worlds and settings across every update, and comes back up on the new version without you logging in. Check the log now and then to make sure it is still saying what you expect.
Renting a server at Alvotech and thinking about installing OpenVPN? Then follow this tutorial.
This tutorial has been done on the default configuration of the Alvotech VPS: Debian 5 64bit, and on Debian 6 64bit.
The specs page of the vservers show that TUN/TAP is usable, but when you rent the VPS, no TUN interface is enabled.
The first thing is to ask the support to enable it, after they say they did, you need to reboot your server through the control panel.
Note that you don’t need any iptable rule, ip forwarding is enabled and you cannot add any iptable rule anyway, Alvotech will enable the necessary rules on the Host.
Then enter your server through ssh and check ifconfig, you might have something like this:
port 1194
proto udp
dev tun2391-136 #Your TUN device in ifconfig
ifconfig 10.0.2.97 10.0.2.98 # your TUN interface settings in ifconfig
ifconfig-noexec
route-noexec
keepalive 10 120
persist-key
persist-tun
comp-lzo
verb 3
fragment 1200
mssfix 1200
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
user nobody
group nogroup
tls-server
push “dhcp-option DNS 8.8.8.8”
Restart openvpn:
/etc/init.d/openvpn restart
Now copy the ca.crt client1.crt and client1.key on your client, and create a client.conf file (or client.ovpn) with this content:
client
dev tun
proto udp
remote 88.88.88.88 1194 #your server ip address/port
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb 3
ifconfig 10.0.2.98 10.0.2.97 #change it according to the IPs of your TUN interface, notice it is the CONTRARY of the server config
redirect-gateway
fragment 1200
mssfix 1200
And now just run “sudo openvpn client.conf”, on Windows you might need to adjust the paths to something like this: “cert c:\\Users\\admin\\desktop\\client1.crt” (for the key+certs).
If you need another client to connect, just ask the support another TUN device (they added one on my server), copy server.conf to server2.conf, modify the TUN interface IPs/name + change the openvpn port in server2.conf, and don’t forget to generate a second client certificate!
Enjoy!
(thanks to the support @ Alvotech for providing the details i was missing)
I was searching for this fix for quite some time. I couldn’t forward X anymore using “ssh -Y” or “ssh -X” on my debian server (i have xauth installed), i was always getting this error:
~$ xterm
xterm Xt error: Can't open display:
xterm: DISPLAY is not set
“X11UseLocalhost no” was making it working but this wasn’t the right solution..
On this bug report i found out i had the same problem and the same symptoms: i had disabled ipv6 support, and this is what broke the forwarding!
Today i had to face a weird problem with Apache 2. I wanted to setup a webmail on the SAME virtualhost that i was using to proxy to another host.
Here’s a summary of my configuration:
<VirtualHost *:80>
ServerAdmin sysadmin@localhost
DocumentRoot /var/www/folder
ServerName localhost
Alias /mail /var/lib/roundcube/
<Directory /var/lib/roundcube/>
The problem is that the auth_basic wasn’t working correctly in this setup, Apache was answering with a 200 instead of a 401 message, which prevented the browser from understanding it was actually an authentication..
But this config was working fine without the auth, the webmail was working. And it was working fine with auth but no proxypass.
So what was wrong?! Thanks to the guys @freenode i discovered that Apache was proxying the requests to custom errors in /error/ (as i uncommented the custom errors in apache2.conf). The solution was to add:
ProxyPass /error/ !
Turn loglevel to debug in case you have a similar issue, in my case i could read this:
[Fri Mar 04 15:44:36 2011] [debug] mod_proxy_http.c(56): proxy: HTTP: canonicalising URL //10.10.10.10/error/HTTP_UNAUTHORIZED.html.var
[Fri Mar 04 15:44:36 2011] [debug] proxy_util.c(1506): [client 1.1.1.1] proxy: http: found worker http://10.10.10.10/ for http://10.10.10.10/error/HTTP_UNAUTHORIZED.html.var
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c: In function ‘zim_ffmpeg_frame_toGDImage’:
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c:336: error: ‘PIX_FMT_RGBA32’ undeclared (first use in this function)
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c:336: error: (Each undeclared identifier is reported only once
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c:336: error: for each function it appears in.)
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c: In function ‘zim_ffmpeg_frame_ffmpeg_frame’:
/tmp/ffmpeg-php-0.6.0/ffmpeg_frame.c:421: error: ‘PIX_FMT_RGBA32’ undeclared (first use in this function)
make: *** [ffmpeg_frame.lo] Erreur 1
To fix this, replace PIX_FMT_RGBA32 with PIX_FMT_RGB32 . You can use “rpl” to replace files recursively:
cd to the ffmpeg folder and run this command (beware!):
You also need yacc, it will fail if you use bison or btyacc:
btyaccpa.ske:111: erreur: expected specifier-qualifier-list before ‘yyparsestate’
btyaccpa.ske:128: erreur: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
btyaccpa.ske:131: erreur: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
btyaccpa.ske:180: erreur: expected ‘)’ before ‘*’ token
btyaccpa.ske:181: erreur: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
btyaccpa.ske:182: erreur: expected ‘)’ before ‘*’ token
btyaccpa.ske: In function ‘yyparse’:
btyaccpa.ske:193: erreur: ‘yyparsestate’ undeclared (first use in this function)
btyaccpa.ske:193: erreur: (Each undeclared identifier is reported only once
btyaccpa.ske:193: erreur: for each function it appears in.)
btyaccpa.ske:193: erreur: ‘yyerrctx’ undeclared (first use in this function)
btyaccpa.ske:206: erreur: ‘yyps’ undeclared (first use in this function)
btyaccpa.ske:257: erreur: ‘yypath’ undeclared (first use in this function)
You might need a graphical editor to edit large dump files. Most of the graphical editors on linux cannot handle large files, so check out nedit, using it i was able to edit a 17mb file without delay.