421 Misdirected Request i cPanel med NGINX og Apache

Plutselig opplevde vi en uregelmessig, men kritisk feil som påvirket flere domener på vår cPanel-server med både Apache og NGINX aktivert. Problemet viste seg som tilfeldige 421 Misdirected Request-feil på et flerspråklig byrånettsted også:

• 🔗 https://www.nordicdigisolutions.com
• 🔗 https://www.nordicdigisolutions.no

Til tross for et gyldig SSL-oppsett og rene omdirigeringer, ble HTTPS-forespørsler av og til feilrutet eller avvist. Dette innlegget dokumenterer hele feilsøkingsprosessen vår og løsningen, og kan være en nyttig referanse for andre som opplever lignende problemer.

Symptomer vi observerte

• ❌ Tilfeldige 421 Misdirected Request-feil som kun dukket opp på HTTPS-sider
• 🌐 Begge domenene var påvirket: .com og .no
• 🔁 Problemet var uregelmessig. Noen besøk fungerte, andre feilet
• ✅ Alle omdirigeringer (non-www til www, HTTP til HTTPS) så ut til å fungere korrekt
• 🛑 Likevel returnerte den endelige destinasjonen av og til en 421-feilside

🔍 Feilsøkingstrinn

1. Sjekket Apache Virtual Hosts

• Begge domenene var korrekt konfigurert i cPanel
• Hvert domene hadde sitt eget SSL-sertifikat utstedt via AutoSSL
• DocumentRoot-stiene var separate, slik at vi unngikk aliasing eller overlapping

2. Testet omdirigeringsregler

• .htaccess-regler var på plass for:
  • Å håndheve https://
  • Å omdirigere fra non-www til www
• Cloudflare Page Rules speilet samme logikk for konsistens
• Vi bekreftet at det ikke var noen omdirigeringsløkker, feilrutinger eller ugyldige mål ved hjelp av redirect-checker-verktøy

3. Cloudflare-feilsøking

• DNS-innstillingene var korrekte. Begge domenene pekte mot serveren vår via Cloudflare-proxyer
• SSL/TLS-innstillingene var satt til «Full», ikke «Flexible»
• Vi brukte response header-analyse for å spore:
  • Omdirigeringsflyten
  • Origin IP-treff
  • Sertifikatets gyldighet
• Konklusjon: Ingenting unormalt ble funnet i Cloudflares rutingsadferd

4. Validerte SSL-sertifikater i cPanel

Under SSL/TLS → Manage SSL Sites hadde begge domenene:

• Korrekte sertifikatbindinger
• Riktig kjede (Root, Intermediate, Domain)
• Gyldige utløpsdatoer
• Sertifikatene var ikke delt eller gjenbrukt mellom domenene

5. Forsøkte å deaktivere caching midlertidig

• Tømte Cloudflare-cache
• Tømte WP Rocket-cache fullstendig
• Testet på nytt med inkognito-/privat nettlesing og curl-forespørsler
• Resultat: 421-feilen oppstod fortsatt tilfeldig, noe som tydet på at caching ikke var rotårsaken

6. Sjekket Apache Virtual Hosts på nytt

• Begge domenene var korrekt konfigurert i cPanel med separate SSL-sertifikater
• Samme /public_html/ DocumentRoot ble brukt for både .com og .no
• Polylang ble brukt for å håndtere språkversjoner av nettstedet innenfor en og samme WordPress-installasjon
• Det ble ikke funnet noen alias eller feilkonfigurasjon i VirtualHost-oppsettet

🛑 Rotårsak

Etter timer med konfigurasjonssjekker og loggjennomganger, viste det seg at rotårsaken ikke lå i Cloudflare-innstillingene, omdirigeringene, caching, eller engang Apache VirtualHost-deklarasjonene. Gjennombruddet kom via Namecheap support. De bekreftet at problemet var knyttet til en nylig EasyApache 4-oppdatering som introduserte en konflikt når NGINX brukes som reverse proxy foran Apache, noe som var akkurat vårt oppsett. Den kritiske detaljen:

• Problemet oppstod kun for HTTPS-trafikk
• Det påvirket spesifikt forespørsler som ble proxyet via EA-NGINX
• Feilen førte til at Apache feilrutet forespørsler mellom domener, noe som resulterte i 421 Misdirected Request-feil selv når SSL-sertifikatene var gyldige og domenene var separate

📌 Referanse: Den offisielle cPanel-dokumentasjonen bekreftet senere at dette var et kjent problem: Websites show 421 Misdirected Request error while using EA-NGINX or other proxies

✅ Løsningen

Da vi først hadde identifisert kilden til problemet, var løsningen rett frem. Vi anvendte den offisielle cPanel-patchen ved å kjøre følgende kommando på serveren:

/scripts/upcp

Denne kommandoen:

• Oppdaterer alle EasyApache (EA4)-pakker
• Anvender cPanel-patchen for NGINX-til-Apache SNI-rutingsproblemer
• Restarter tjenestene på en ryddig måte

Etter oppdateringen og omstart:

• De uregelmessige 421-feilene på både .com- og .no-domenene var fullstendig løst
• Alle HTTPS-forespørsler ble konsekvent rutet til riktig virtual host
• Ingen ytterligere feilrutinger eller caching-anomalier ble observert

Vi verifiserte deretter alt på nytt:

• DNS og omdirigeringer fungerte feilfritt
• Cloudflare oppførte seg som forventet
• Ingen .htaccess-konflikter gjenstod
• Polylang var upåvirket

Lærdom

Å forvalte et oppsett med flere domener på en cPanel-server som bruker NGINX som reverse proxy foran Apache krever tett oppfølging, spesielt etter EasyApache 4 (EA4) eller lignende serviceoppdateringer. Selv små endringer i bakgrunnen kan introdusere SSL-relaterte feil som ikke er umiddelbart åpenbare. Viktige lærdommer fra erfaringen vår:

• EasyApache- og NGINX-oppsett må retestes etter oppdateringer: Selv når ingen synlige konfigurasjonsendringer er gjort, kan håndteringen av SSL (SNI) i bakgrunnen brytes stille.
• Cloudflare kan ikke fikse SSL-mismatch i bakgrunnen: Selv om Cloudflare håndterte DNS, caching og TLS-terminering perfekt, oppstod den endelige SNI-mismatchen mellom NGINX og Apache, som ligger utenfor Cloudflares kontroll.
• Diagnostiske verktøy er viktige: Verktøy som httpstatus.io, Chrome DevTools → Network-fanen og direkte curl-tester hjalp oss å følge omdirigeringsflyten og isolere når og hvor problemet oppstod.
• Separasjon av VirtualHost er kritisk: At vi hadde dedikerte SSL-sertifikater og tydelig separasjon i Apache sine virtual hosts for hvert domene, hjalp oss å utelukke feilkonfigurasjon tidlig i prosessen.

Oversikt over teknisk stack

For å hjelpe andre med å feilsøke lignende oppsett, her er et øyeblikksbilde av vår tekniske stack:

• Hosting: VPS (fra Namecheap)
• Webserver-stack: Apache (via cPanel) med NGINX (EasyApache 4 Reverse Proxy)
• CDN + Proxy: Cloudflare (Full SSL-modus)
• CMS: WordPress, med flerspråklig oppsett ved hjelp av Polylang
• SSL-sertifikater: AutoSSL (Let’s Encrypt via cPanel)

Denne hybride stacken gir både ytelse og fleksibilitet, men kommer også med en kompleksitet som må følges nøye opp.

🔁 Hva nå?

Vi har lagt denne situasjonen til vår interne sjekkliste etter utrulling for alle nettsteder som bruker:

• WordPress-nettsteder med flere domener
• Språkspesifikke domener (f.eks. .no + .com)
• NGINX → Apache reverse proxy-konfigurasjoner
• Verifiseringer etter EA4-oppdateringer (særlig SSL/SNI-ruting)

Vi vil også følge EA4-changelogger tett og utføre proaktive SNI-tester etter hver serveroppdatering.

🔑 Hovedpunkter

• 421-feil kan oppstå i NGINX + Apache (EA4)-oppsett etter EasyApache-oppdateringer
• Problemet påvirker kun HTTPS-trafikk, selv når SSL og omdirigeringer er gyldige
• Feilene er uregelmessige og kan slippe gjennom vanlige QA-sjekker
• Å kjøre /scripts/upcp løser feilen ved å patche SNI-håndteringen
• Verktøy som httpstatus.io og browser DevTools (Network-fanen) er essensielle for å spore omdirigeringskjeder og finne feilrutinger