Apache vs. NGINX: Hvilken webserver er bedst til WordPress?

Hvis du kører WordPress på din egen VPS, kan både Apache og NGINX levere sitet fint, men de vælger forskellige afvejninger. NGINX er som regel det bedste standardvalg ved høj samtidighed, levering af statiske filer og valgfri HTTP/3. Apache er lettere, når din WordPress-stak afhænger af .htaccess eller Apache-specifikke moduler.

Denne sammenligning af Apache og NGINX fokuserer på de forskelle, der betyder noget for WordPress: arkitektur, PHP-håndtering, konfiguration, HTTP/3 og spørgsmålet om, hvorvidt det er den ekstra kompleksitet værd at køre begge. LiteSpeed og Caddy er uden for emnet.

Kort svar: til en selvadministreret WordPress-VPS skal du som standard vælge NGINX. Vælg Apache, hvis dit site eller dine plugins i høj grad afhænger af .htaccess. Kør kun begge, når du specifikt har brug for NGINX foran uden at give afkald på Apache-kompatibiliteten.

Hvad er Apache?

Apache er udbredt open source-webserversoftware, der udvikles og vedligeholdes af den amerikanske nonprofitorganisation Apache Software Foundation (ASF). Den er også kendt som Apache HTTP Server og HTTPD.

Apaches downloadside angiver 2.4.68, udgivet i juni 2026, som den aktuelle stabile udgivelse.

Apache HTTP Server er en modulær open source-server med moden understøttelse af .htaccess-regler pr. mappe, flere Multi-Processing Modules (MPM'er), reverse proxy, URL-omskrivning, TLS og dynamisk indlæste moduler. Til WordPress er dens største praktiske fordel konfigurationskompatibilitet, ikke rå hastighed.

De Apache-funktioner, der betyder mest i denne sammenligning, er MPM'erne prefork, worker og event; .htaccess; HTTP/2; reverse proxy og load balancing; FastCGI-understøttelse; dynamiske moduler; URL-omskrivning; og TLS.

Hvad er NGINX?

NGINX ("engine x") er en open source-webserver, reverse proxy, indholdscache, load balancer, TCP/UDP-proxy og mailproxy, oprindeligt skrevet af Igor Sysoev. Dens worker-processer bruger en hændelsesdrevet model, der er designet til at håndtere mange samtidige forbindelser med lav omkostning pr. forbindelse.

NGINX' downloadside lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: de vigtigste forskelle for WordPress

Apache og NGINX adskiller sig tydeligst i, hvordan de håndterer forbindelser, konfiguration, PHP og protokolunderstøttelse. Apaches adfærd afhænger i høj grad af den MPM, den kører, mens NGINX bruger hændelsesdrevne worker-processer.

Apache vs. NGINX: arkitektur

Apaches request-model afhænger af den MPM, du kører. Prefork er procesbaseret, mens worker og event bruger tråde. NGINX bruger worker-processer bygget op omkring event loops. Derfor er den velkendte sammenligning "procesdrevet Apache mod hændelsesdrevet NGINX" for forsimplet til en aktuel Apache 2.4-opsætning.

Apaches event-MPM kan sende inaktive keep-alive-forbindelser videre til sin listener-tråd i stedet for at binde en worker-tråd til hver enkelt. Ved meget store antal samtidige forbindelser har NGINX stadig typisk lavere omkostning pr. forbindelse, men den arkitektoniske afstand er langt mindre, end gamle sammenligninger fra prefork-tiden antyder.

Apache vs. NGINX: ydeevne

NGINX' ydelsesfordel viser sig især ved høj samtidighed og statiske filer. Dens hændelsesdrevne workers kan holde mange forbindelser åbne med forholdsvis lav omkostning pr. forbindelse. Apaches event-MPM indsnævrer det gab betydeligt sammenlignet med ældre prefork-konfigurationer.

Dynamiske WordPress-forespørgsler er en anden sag. NGINX sender normalt PHP videre til FastCGI, oftest PHP-FPM. Apache kan også bruge PHP-FPM via FastCGI eller køre PHP gennem et Apache-modul.

Så snart PHP begynder at køre WordPress, kan plugin-kode, databaseforespørgsler, objekt- eller sidecaching og antallet af PHP-workers betyde mere end webserveren foran. Hvis et plugin kører et dusin dyre databaseforespørgsler pr. request, løser et skifte fra Apache til NGINX ikke det underliggende problem.

Apache vs. NGINX: understøttelse af HTTP/3 og QUIC

HTTP/3 er den nuværende version af protokollen, og den kører over QUIC i stedet for TCP. Om dit site overhovedet kan tilbyde den, afhænger af webserveren foran, og det er det ene sammenligningspunkt, hvor de to servere ikke ligger tæt på hinanden.

NGINX har haft et HTTP/3-modul siden version 1.25.0. Det bygges ikke som standard, og builden kræver parameteren --with-http_v3_module.

Dokumentationen til NGINX' HTTP/3-modul beskriver stadig modulet som "experimental, caveat emptor applies".

Apache 2.4 leverer ikke noget indbygget HTTP/3- eller QUIC-modul; den medfølgende protokolunderstøttelse stopper ved mod_http2.

Den praktiske konsekvens for en sitejer: en standardinstallation af Apache 2.4 tilbyder ikke HTTP/3. I produktion er den brugbare løsning fortsat at terminere HTTP/3 i en HTTP/3-kapabel reverse proxy eller et CDN foran Apache. Vil du have protokollen, kan du sætte NGINX foran Apache og lade NGINX terminere klientforbindelserne, netop den opstilling, der beskrives længere nede.

Apache vs. NGINX: sikkerhed

Hverken Apache eller NGINX er kategorisk "mere sikker". Begge er modne projekter med aktiv sikkerhedsvedligeholdelse, og sikkerheden i en produktionsopsætning afhænger mere af opdateringer, aktiverede moduler, TLS-konfiguration, adgangskontrol, rate limits og applikationen bag serveren.

Den nyttige sammenligning handler om angrebsflade og konfiguration, ikke om en generel vinder. Slå moduler og endpoints fra, som du ikke bruger, hold serveren opdateret, og hærd den WordPress-stak, der ligger bagved.

Apache vs. NGINX: konfiguration

Apaches .htaccess-filer pr. mappe virker, når AllowOverride tillader dem. Det er praktisk for WordPress, fordi rewrite-regler kan ændres uden at røre den globale serverkonfiguration.

Den bekvemmelighed har en pris. Apaches egen dokumentation anbefaler at lægge reglerne i serverens hovedkonfiguration, når du har root-adgang: .htaccess-filer tjekkes under forespørgsler, og at aktivere dem giver både performance- og sikkerhedsmæssige overvejelser.

NGINX har ingen pendant til .htaccess. Konfigurationen er centraliseret, så WordPress kan ikke skrive rewrite-regler på serverniveau for dig. Permalink-regler og plugin-specifikke serverdirektiver skal en administrator tilføje til NGINX-konfigurationen og derefter genindlæse.

Apache vs. NGINX: moduler og udvidelsesmuligheder

Apache har moden understøttelse af Dynamic Shared Objects (DSO): moduler kan kompileres separat og indlæses via LoadModule. NGINX understøtter også dynamisk indlæste moduler via load_module, men binær kompatibilitet med den installerede NGINX-version og dens build-konfiguration vejer tungere, så snart du bruger ikke-standard tredjepartsmoduler.

Apache har altså en fordel, hvis du afhænger af usædvanlige tredjepartsmoduler. Til almindelig WordPress-hosting vejer den forskel som regel mindre end .htaccess, PHP-håndteringen og det værktøj, du allerede bruger.

Apache vs. NGINX: platformsunderstøttelse

Apache kører på Linux, Windows, macOS og mange Unix-lignende systemer. NGINX findes også på de store platforme, men dens native Windows-build har væsentlige begrænsninger. NGINX kalder stadig Windows-versionen beta, siger at man ikke skal forvente høj ydeevne og skalering, bemærker at kun én worker reelt udfører arbejde, og understøtter hverken UDP eller QUIC. Til NGINX i produktion er et Unix-lignende styresystem det praktiske valg.

Apache vs. NGINX: håndtering af forespørgsler

Apache mapper normalt en forespørgsels-URL til filsystemet under DocumentRoot, mens konfigurationssystemet også kan anvende URI-baserede locations, rewrites og proxyregler. NGINX vælger først en server-blok og derefter en location-blok, primært ud fra forespørgslens URI, før den afgør, om den skal levere en fil eller sende forespørgslen videre.

Den forskel påvirker, hvordan du skriver konfiguration, men er ikke i sig selv bevis for, at NGINX overfører data hurtigere.

En hurtig sammenligning af NGINX og Apache

Sådan står de to servere på punkterne ovenfor, plus protokolunderstøttelse og hver servers aktuelle version.

Brug af Apache og NGINX sammen

Ja, du kan køre begge. Et almindeligt hybridt setup sætter NGINX forrest som klientvendt reverse proxy og Apache bagved. NGINX kan terminere TLS og HTTP/2 og kan terminere HTTP/3, når dens eksperimentelle HTTP/3-modul er bygget og slået til. Den kan også selv levere udvalgte statiske filer, mens applikationsforespørgsler sendes videre til Apache.

Det vigtige forbehold handler om, hvem der ejer reglerne. En forespørgsel, som NGINX besvarer direkte, når aldrig frem til Apache, så Apaches .htaccess-regler gælder ikke for den. De to konfigurationer skal være enige om rewrites, caching, videresendelse af klientens IP, TLS-adfærd og hvilken server der ejer hvilken sti.

Prisen er, at du nu kører to webservere. To konfigurationer, der skal stemme overens, to opdateringscyklusser at holde styr på, og ét sted mere at kigge, når en forespørgsel returnerer noget uventet. På ét lille site overstiger den byrde som regel gevinsten; den begynder at betale sig, når du vil have HTTP/3 eller hurtigere levering af statiske filer uden at opgive den .htaccess-adfærd, dine plugins afhænger af.

Er NGINX lettere end Apache?

Ingen af dem er lettere i alle tilfælde. NGINX er lettere, hvis du foretrækker én central konfiguration og har det fint med at redigere server-blokke. Apache er lettere, når WordPress eller tredjeparts-plugins forventer .htaccess-regler, for de regler virker på mappeniveau uden at ændre den globale serverkonfiguration.

På en server, du selv styrer, handler "lettere" mest om, hvilken konfigurationsmodel din stak allerede forventer.

Hvornår skal du vælge Apache frem for NGINX?

Vælg Apache, når din WordPress-stak afhænger af .htaccess, når plugins eller kontrolpanelværktøjer forventer Apache-rewrite-direktiver, eller når du har brug for et bestemt Apache-modul. Det er også fornuftigt at beholde Apache på et eksisterende site, der allerede kører godt: at skifte webserver for en teoretisk benchmark-gevinst er sjældent besværet værd i sig selv.

Hvornår skal du vælge NGINX frem for Apache?

Vælg NGINX, når du forventer mange samtidige forbindelser, vil have et stærkt lag til statiske filer eller reverse proxy, foretrækker central konfiguration, eller gerne vil kunne slå HTTP/3 til. For WordPress er prisen, at rewrite-regler og plugin-specifikke serverdirektiver bliver en administratoropgave i stedet for noget, WordPress kan skrive i .htaccess.

NGINX vs Apache: Hvilken webserver er bedst til WordPress?

Kør NGINX. Til et WordPress-site på en server, du selv styrer, er det det bedre standardvalg: lav omkostning pr. forbindelse ved høj samtidighed, effektiv levering af statiske filer og HTTP/3, hvis du vil have det.

Undtagelsen er .htaccess, og den betyder noget. WordPress kan skrive Apache-rewrite-regler, når .htaccess er slået til, men kan ikke ændre NGINX' serverkonfiguration. Hvis et plugin forventer rewrite-, sikkerheds- eller cachedirektiver, skal du bruge dets NGINX-vejledning eller en tilsvarende regel i server-blokken og derefter genindlæse NGINX. Vil du ikke have det driftsansvar, er Apache det lettere WordPress-valg. På et site med normal trafik er det snarere PHP, databasen og caching, der begrænser ydeevnen, end webserveren selv.

Under det hele ligger én antagelse: serveren skal være din at ændre. På managed WordPress-hosting er webserveren udbyderens beslutning, og svaret på spørgsmålet er simpelthen det, de allerede kører. Denne sammenligning henvender sig til en, der har root-adgang på sin egen maskine.

Hvordan tjekker du, om du kører Apache eller NGINX?

Hvis det er din egen VPS, så tjek de kørende tjenester direkte:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

For et fremmed website, du ikke styrer, kan HTTP-svarheaderen Server være et fingerpeg, men den er ikke afgørende. En reverse proxy eller et CDN kan vise sin egen serversoftware i stedet for originets, og headeren kan også skjules eller ændres.

Hosting af Apache eller NGINX på en VPS

Hvis VPS'en er din, er begge servere ligetil at køre. Dimensioner maskinen til hele WordPress-stakken, ikke kun til Apache eller NGINX: PHP-workers, databasen, caching, trafik og baggrundsjobs bruger normalt flere ressourcer end webserveren selv.

Uanset hvilken server du vælger, er konfiguration, opdateringer, TLS, backup og overvågning dit ansvar. At køre begge tilføjer endnu en konfiguration og endnu et opdateringsspor, så brug kun det hybride setup, når du har en konkret grund til det.

Cloudzys NGINX VPS er en selvadministreret Linux-VPS med fuld root-adgang, så serverkonfigurationen forbliver din.

Apache HTTP Server-imaget i vores marketplace installeres på samme måde, med ét klik, så at få den ene eller begge servere op at køre ikke begynder med at kompilere fra kildekoden.

LÆS

Caddy vs. Nginx på en VPS: Sammenligningen af konfigurationsfiler

Ofte stillede spørgsmål

Er Apache bedre end NGINX?

Ingen af dem er bedre i alle tilfælde. NGINX er som regel det stærkere standardvalg, når du går op i høj samtidighed, levering af statiske filer, reverse proxy eller HTTP/3. Apache er typisk lettere, når din WordPress-stak afhænger af .htaccess eller Apache-specifikke moduler.

Hvorfor er NGINX hurtigere end Apache?

NGINX kan håndtere mange forbindelser inde i hver workers event loop, hvilket holder omkostningen pr. forbindelse lav ved høj samtidighed. Apaches event-MPM håndterer også forbindelser asynkront, så forskellen er mindre, end gamle prefork-sammenligninger antyder. På WordPress kan PHP, databaseforespørgsler og caching betyde mere end forskellen mellem webserverne.

Skal jeg bruge Apache eller NGINX til WordPress?

Til en selvadministreret WordPress-VPS er NGINX et stærkt standardvalg, hvis du har det fint med selv at vedligeholde reglerne i server-blokke. Vælg Apache, hvis du læner dig op ad .htaccess eller plugins, der forventer Apache-rewrite-regler, og gerne vil have dem til at virke med mindre manuel serverkonfiguration.

Hvorfor er NGINX så populær?

NGINX kombinerer effektiv håndtering af forespørgsler ved høj samtidighed med reverse proxy, load balancing, caching, FastCGI-understøttelse og TLS-terminering. Det gør den nyttig både som primær webserver og som frontproxy.

Hvorfor bruges Apache stadig?

Apache er stadig udbredt på grund af sit moduløkosystem, .htaccess-understøttelsen, modent værktøj, bred platformsunderstøttelse og kompatibilitet med hosting- og kontrolpanel-workflows, der er bygget op omkring den.

Hvad er forskellen på Apache og apache2?

På Debian og Ubuntu er apache2 pakke- og servicenavnet for Apache HTTP Server. Systemer i RHEL- og Fedora-familien kalder typisk tjenesten httpd. Det er ikke to forskellige webservere: begge henviser til Apache HTTP Server. Apaches aktuelle stabile gren er 2.4 med 2.4.68 som seneste udgivelse.

Understøtter Apache HTTP/3?

Ikke indbygget. Apache HTTP Server 2.4 leveres ikke med et HTTP/3- eller QUIC-modul; den medfølgende protokolunderstøttelse stopper ved HTTP/2. Har du brug for HTTP/3 i produktion, kan du terminere det i en HTTP/3-kapabel reverse proxy eller et CDN foran Apache.