Terug naar hoofdinhoud
Webservers voor Joomla
Op deze pagina
# Topics

Webservers voor Joomla

27 juni 2026

Elke Joomla-site, hoe eenvoudig of hoe groot ook, draait op een stukje software waar bijna niemand het over heeft: de webserver. Dit is het programma dat luistert naar verzoeken van browsers, het werk doorgeeft aan PHP en de voltooide pagina terugstuurt. Kies de juiste webserver en configureer deze goed, dan is je site snel, veilig en stabiel. Doe je het verkeerd, dan krijg je te maken met kapotte URL’s, trage pagina’s en beveiligingslekken die niets met Joomla zelf te maken hebben.

Dit artikel bespreekt de webservers waarop Joomla in de praktijk draait: Apache, Nginx, OpenLiteSpeed en LiteSpeed, Microsoft IIS en enkele nieuwere opties. Het behandelt de basisprincipes voor website-eigenaren, de configuratiedetails voor beheerders en de technische aspecten die ontwikkelaars moeten kennen, waaronder SEF-URL-herschrijving, PHP-handlers, prestaties en beveiliging.

Joomla genereert de pagina, maar de webserver bepaalt hoe snel en hoe veilig deze de bezoeker bereikt.

Het doel is simpel: je helpen begrijpen welke webserver bij jouw Joomla-site past en hoe je deze correct kunt configureren.

1. De basis

1.1 Wat is een webserver?

Een webserver is de software die verzoeken van browsers beantwoordt. Als iemand https://example.test/about-us opent, stuurt de browser een HTTP-verzoek, en de webserver is het eerste programma op je hosting dat dit ontvangt. Vervolgens beslist hij wat hij doet: een bestand direct terugsturen, of het verzoek doorgeven aan een applicatie zoals Joomla.

Twee dingen delen de naam "webserver", en het helpt om ze uit elkaar te houden:

  • De machine (de fysieke of virtuele server die je site host).
  • De webserversoftware (Apache, Nginx en de rest). Dit artikel gaat over de software.

1.2 Statische bestanden versus PHP

Een Joomla-pagina is geen bestand dat op schijf staat. Joomla bouwt hem ter plekke op met PHP en de database. De webserver moet het verschil herkennen tussen twee soorten verzoeken:

  • Statische bestanden zoals afbeeldingen, CSS, JavaScript en lettertypen. De webserver leest ze van schijf en stuurt ze direct terug. Dat is snel.
  • Dynamische verzoeken voor pagina's die Joomla moet genereren. De webserver geeft die door aan PHP, wacht op het resultaat en stuurt het terug.

1.3 Het verzoektraject

Bijna elke Joomla-pagina volgt hetzelfde traject:

Browser
   ↓
Webserver (Apache / Nginx / LiteSpeed / IIS)
   ↓
PHP (draait Joomla's index.php)
   ↓
Database (MySQL of MariaDB)
   ↓
HTML terug naar de browser

De webserver is de poortwachter aan het begin van deze keten. Het is het onderdeel waar de meeste mensen nooit bij stilstaan, totdat er iets misgaat.

Naar boven

2. Wat de webserver voor Joomla doet

2.1 Het enkele toegangspunt

Joomla maakt gebruik van een front-controllerpatroon. Vrijwel elk front-endverzoek komt terecht bij één bestand, index.php in de hoofdmap van de site, en de back-end draait vanuit administrator/index.php. Het is de taak van de webserver om het verzoek naar het juiste toegangspunt te leiden en het vanaf daar aan Joomla over te laten.

2.2 De vier kerntaken

Welke software je ook kiest, je vraagt een webserver om dezelfde vier dingen voor Joomla te doen:

TaakWaarom Joomla het nodig heeft
Statische bestanden serveren Afbeeldingen, CSS en JavaScript snel leveren.
PHP uitvoeren index.php uitvoeren zodat Joomla de pagina kan bouwen.
URL's herschrijven Nette SEF-URL's omzetten naar iets dat Joomla begrijpt.
HTTPS en regels afdwingen Veilige verbindingen forceren, paden blokkeren, headers instellen.

2.3 Waarom de keuze ertoe doet

Joomla draait op al deze servers. Het verschil komt op drie punten naar voren: hoe je SEF-URL’s configureert, hoe snel de server grote aantallen bezoekers tegelijk aankan, en hoe je de beveiliging versterkt. In de rest van dit artikel worden alle servers aan de hand van deze drie punten besproken.

Naar boven

3. Apache

3.1 De traditionele standaardinstelling

De Apache HTTP-server is de meest gebruikte webserver voor Joomla, met name op shared hosting en cPanel-servers. Deze server is al decennia lang de standaard voor de LAMP-stack (Linux, Apache, MySQL, PHP), en Joomla wordt standaard geleverd met een Apache-configuratiebestand.

3.2 Het .htaccess-bestand

Het kenmerk van Apache is het .htaccess-bestand: een configuratiebestand per map dat je kunt aanpassen zonder de hoofdconfiguratie van de server aan te raken. Joomla levert een kant-en-klaar bestand met de naam htaccess.txt in de hoofdmap van de site. Om nette URL's te gebruiken hernoem je het:

htaccess.txt   →   .htaccess

Deze ene hernoeming is de stap die de meeste beginners vergeten. Zonder die stap geven SEF-URL's met rewriting aan voor elke pagina behalve de homepage een "404 Not Found".

3.3 Wat de Joomla-.htaccess doet

Het geleverde bestand is niet alleen URL-rewriting. Het blokkeert ook veelvoorkomende aanvalspatronen en routeert de API. Het kernblok voor rewriting ziet er zo uit:

RewriteEngine On

# Stuur de Web Services API naar zijn eigen toegangspunt
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* api/index.php [L]

# Stuur al het andere dat geen echt bestand of map is naar index.php
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

De twee voorwaarden !-f en !-d zeggen: "als het verzoek een echt bestand of een echte map is, serveer het dan direct; geef het anders door aan Joomla." Zo bereikt een verzoek voor /about-us Joomla, terwijl /images/logo.png rechtstreeks van schijf wordt geserveerd.

3.4 De afweging

Bij elk verzoek in elke map naar .htaccess kijken is flexibel maar traag op schaal. Op een drukke site is het sneller om die regels naar de hoofd-virtualhost van Apache te verplaatsen (en AllowOverride uit te zetten), maar dan verlies je het gemak van aanpassingen per map. Op shared hosting heb je die keuze zelden, dus blijft .htaccess staan.

3.5 Multi-Processing Modules (MPM)

Apache kan verzoeken op drie verschillende manieren verwerken, de zogeheten Multi-Processing Modules. Welke je host kiest, bepaalt hoeveel geheugen de server gebruikt en hoe goed hij veel bezoekers tegelijk aankan.

MPMHoe het werktAfweging
prefork Eén proces per verzoek, geen threads. Heel stabiel, maar zwaar op geheugen. Vereist door het oude mod_php.
worker Processen die elk meerdere threads draaien. Lager geheugengebruik dan prefork.
event Zoals worker, maar gaat efficiënter om met inactieve Keep-Alive-verbindingen. De beste moderne keuze, en de natuurlijke partner voor PHP-FPM.

Voor een Joomla-site is de moderne combinatie de event-MPM met PHP-FPM (zie sectie 10). De oude combinatie van prefork met mod_php werkt nog steeds, maar gebruikt veel meer geheugen onder belasting. Biedt je host een keuze, kies dan event plus PHP-FPM.

Naar boven

4. Nginx

4.1 Gebouwd voor gelijktijdigheid

Nginx (uitgesproken als "engine-x") is ontworpen om veel verbindingen tegelijk te verwerken met heel weinig geheugen. Waar Apache van oudsher een proces of thread per verbinding start, gebruikt Nginx een event-gestuurd model dat soepel meeschaalt bij zwaar verkeer. Daardoor is het populair voor Joomla-sites met veel verkeer, VPS-hosting en als reverse proxy voor andere servers.

4.2 Hier geen .htaccess

De grootste verrassing voor wie van Apache komt: Nginx leest geen .htaccess-bestanden. Alle configuratie staat in de hoofdconfiguratiebestanden van de server, die je eenmalig aanpast en herlaadt. Dat is sneller, maar het betekent dat je geen regels in een map kunt droppen, en veel kopieer-en-plak-tutorials die voor Apache zijn geschreven gelden hier gewoon niet.

4.3 De Joomla-rewrite voor Nginx

Je plaatst de SEF-rewriteregel binnen je server { }-blok. Het Joomla-equivalent van de .htaccess-regel is kort:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    fastcgi_pass   unix:/run/php/php8.3-fpm.sock;
    fastcgi_index  index.php;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

De regel try_files is de kern: probeer het echte bestand, dan de map, en als geen van beide bestaat, stuur het verzoek naar index.php. Dat is dezelfde logica als de voorwaarden !-f en !-d van Apache, alleen anders geschreven.

4.4 Dingen die je zelf moet toevoegen

Omdat er geen door Joomla geleverd Nginx-bestand is, moet je een paar beschermingen zelf toevoegen die .htaccess je gratis geeft, bijvoorbeeld toegang weigeren tot configuration.php en tot de map .git, en /api/ naar api/index.php routeren. De Joomla-documentatie publiceert een volledige voorbeeldconfiguratie voor Nginx die je kunt aanpassen.

Naar boven

5. OpenLiteSpeed en LiteSpeed

5.1 Twee versies van hetzelfde idee

LiteSpeed is een snelle webserver die een vlottere, drop-in vervanger voor Apache wil zijn. Hij komt in twee vormen:

  • LiteSpeed Web Server (LSWS) - het commerciële product, gangbaar op managed hosting.
  • OpenLiteSpeed (OLS) - de gratis, open-source editie.

5.2 Apache-compatibiliteit

LiteSpeed Enterprise is ontworpen om te werken als een bijna naadloze vervanger van Apache. Het leest Apache-.htaccess-bestanden rechtstreeks, waardoor je een Joomla-website met weinig of geen configuratiewijzigingen van Apache kunt verhuizen: bestaande rewriteregels, redirects en veel Apache-directieven blijven gewoon werken.

OpenLiteSpeed, de gratis en open-source editie, ondersteunt Joomla's .htaccess-rewriteregels ook, mits Auto Load from .htaccess is ingeschakeld. Het is echter geen volledige vervanger van Apache: server- en virtual-host-instellingen worden beheerd via de OpenLiteSpeed-configuratie in plaats van Apache, en sommige Apache-specifieke modules en directieven worden niet ondersteund.

Voor een typische Joomla-website die het standaard .htaccess-bestand gebruikt voor Search Engine Friendly (SEF) URL's en redirects, werken beide edities goed. De belangrijkste verschillen komen pas naar voren bij geavanceerde Apache-functies en enterprise-functionaliteit.

5.3 Het LSAPI-voordeel

LiteSpeed draait PHP via zijn eigen interface, LSAPI, die doorgaans sneller is dan het klassieke FastCGI dat elders wordt gebruikt. In combinatie met de ingebouwde cache levert LiteSpeed vaak de beste ruwe prestaties voor een typische Joomla-site zonder veel afstemmen.

5.4 LiteSpeed Cache

LiteSpeed levert een paginacache op serverniveau. Er is geen officiële Joomla-LSCache-plugin zoals die er voor sommige andere platformen wel is, maar de servercache en Joomla's eigen caching helpen toch. Test zorgvuldig: agressieve full-page caching kan ingelogde gebruikers de verkeerde inhoud serveren als je niet de juiste pagina's en cookies uitsluit.

Naar boven

6. Microsoft IIS

6.1 Joomla op Windows

Internet Information Services (IIS) is de webserver van Microsoft, ingebouwd in Windows Server. Joomla draait erop, en het is de logische keuze als een bedrijf al een Windows-omgeving draait. Het is veel minder gangbaar dan de Linux-servers, maar wordt volledig ondersteund.

6.2 Het web.config-bestand

IIS gebruikt geen .htaccess. Het equivalent is een XML-bestand met de naam web.config, en Joomla levert er een als web.config.txt in de hoofdmap van de site. Net als bij Apache hernoem je het:

web.config.txt   →   web.config

Dit bestand bevat de URL Rewrite-regels die nette URL's naar index.php sturen. Het heeft de Microsoft-module URL Rewrite nodig in IIS, een aparte download en de stap die men het vaakst mist.

6.3 PHP op IIS

PHP draait op IIS via FastCGI. De padscheidingstekens, bestandsrechten en regels rond hoofdlettergevoeligheid verschillen van Linux, dus een paar extensies die Linux-paden veronderstellen kunnen zich vreemd gedragen. Voor de meeste Joomla-sites met alleen de kern werkt het goed, maar het is verstandig om externe extensies te testen voordat je je vastlegt.

Naar boven

7. Andere webservers

7.1 Caddy

Caddy is een moderne webserver die automatisch HTTPS-certificaten van Let's Encrypt aanvraagt en vernieuwt, zonder handmatige instelling. Hij draait Joomla via PHP-FPM en gebruikt een kort, leesbaar configuratiebestand. Het is een sterke keuze voor ontwikkelaars die willen dat HTTPS "gewoon werkt", al heeft hij een kleinere gemeenschap dan Apache of Nginx.

7.2 Reverse proxy-opstellingen

Veel praktijkopstellingen combineren servers. Een gangbaar patroon zet Nginx ervoor als reverse proxy en Apache erachter:

Browser → Nginx (statische bestanden, SSL, cache) → Apache (.htaccess, PHP) → Joomla

Zo krijg je de snelheid van Nginx voor statische bestanden en de flexibiliteit van de .htaccess van Apache voor Joomla. De valkuil is dat Joomla het echte protocol en adres van de bezoeker moet kennen, die de proxy doorgeeft in headers als X-Forwarded-Proto en X-Forwarded-For. Zijn die niet ingesteld, dan kan Joomla verkeerde URL's bouwen of denken dat alle bezoekers één IP-adres delen.

7.3 De lokale ontwikkelserver

PHP heeft een kleine ingebouwde webserver (php -S) die handig is voor snel lokaal testen. Hij draait met één proces en is niet voor productie bedoeld, maar hij kan een Joomla-site serveren voor een ontwikkelaar die iets op een laptop controleert. Tools als Docker, DDEV en Laragon verpakken juist een volledige Apache- of Nginx-stack voor lokaal werk.

Naar boven

8. Een webserver kiezen voor Joomla

8.1 Een praktische vergelijking

Er is niet één beste antwoord. De juiste keuze hangt af van je hosting, je verkeer en wie de server onderhoudt.

ServerBeste voorSEF-instellingLeest .htaccess?
Apache Shared hosting, cPanel, eenvoudige installatie Hernoem htaccess.txt Ja
Nginx Veel verkeer, VPS, reverse proxy Blok in serverconfig Nee
LiteSpeed Prestaties met Apache-compatibiliteit Leest .htaccess Ja (commercieel)
OpenLiteSpeed Gratis prestatieserver Eigen rewrite-instellingen Nee (standaard)
IIS Windows-omgevingen Hernoem web.config.txt Nee (gebruikt web.config)
Caddy Automatische HTTPS, ontwikkelaars Caddyfile-regels Nee

8.2 Een eenvoudige vuistregel

  • Op shared hosting krijg je meestal Apache of LiteSpeed en weinig keuze. Voor de meeste sites is dat prima.
  • Voor een drukke site op een VPS verwerken Nginx of LiteSpeed gelijktijdige bezoekers beter.
  • Hecht je aan Apache-compatibiliteit plus snelheid, dan is LiteSpeed de makkelijke upgrade.
  • Zit je vast aan Windows, dan is IIS de ondersteunde weg.

De webserver doet ertoe, maar voor de meeste Joomla-sites maken goede PHP-instellingen, caching en een geoptimaliseerde database een groter verschil voor de snelheid dan het merk van de server.

Naar boven

9. SEF-URL's en URL-rewriting

9.1 De twee Joomla-instellingen

Nette URL's in Joomla hangen af van twee opties in Systeem → Globale configuratie → Site:

  • Zoekmachinevriendelijke URL's - verandert index.php?option=com_content&view=article&id=42 in /news/42-my-article. Dit werkt op elke webserver.
  • URL-herschrijving gebruiken - haalt de index.php uit het pad zodat de URL /news/my-article wordt. Dit heeft de rewrite-engine van de webserver en het bijbehorende configuratiebestand nodig.

9.2 Waarom het stukgaat

De klassieke fout is URL-herschrijving gebruiken aanzetten zonder het configuratiebestand van de server te hernoemen. Joomla maakt dan URL's zonder index.php, maar de webserver weet niet hoe hij die moet routeren, en elke interne link geeft een 404.

De oplossing op Apache: hernoem htaccess.txt naar .htaccess. Op IIS: hernoem web.config.txt naar web.config en installeer URL Rewrite. Op Nginx en OpenLiteSpeed: voeg de try_files- of rewriteregel toe aan de serverconfig.

9.3 Het basispad

Als Joomla in een submap staat, bijvoorbeeld https://example.test/blog/, heeft Apache de juiste basis nodig. Het geleverde bestand heeft een uitgecommentarieerde regel die je uncomment en aanpast:

# RewriteBase /blog

Dit vergeten is het op een na meestvoorkomende rewriteprobleem, na het vergeten van de hernoeming.

Naar boven

10. Hoe PHP achter de server draait

10.1 De handler doet ertoe

De webserver draait PHP niet zelf. Hij geeft het verzoek door aan een PHP-handler, en de handler die je gebruikt heeft meer invloed op snelheid en geheugen dan het merk van de server.

HandlerGebruikt metOpmerkingen
mod_php Apache (oudere opstellingen) PHP draait binnen Apache. Eenvoudig maar zwaarder; wordt uitgefaseerd.
PHP-FPM Nginx, Apache, Caddy PHP draait als eigen pool van processen. De moderne standaard.
LSAPI LiteSpeed, OpenLiteSpeed LiteSpeeds eigen interface. Snel en efficiënt.
FastCGI IIS, andere Generieke interface tussen server en PHP.

10.2 PHP-FPM in gewone taal

PHP-FPM (FastCGI Process Manager) houdt een pool van PHP-workers klaar en wachtend. Als er een Joomla-verzoek binnenkomt, geeft de webserver het aan een vrije worker, die index.php draait en de pagina teruggeeft. Omdat de workers losstaan van de webserver, kun je afstemmen hoeveel er draaien, PHP herstarten zonder de webserver te herstarten, en verschillende PHP-versies draaien voor verschillende sites op dezelfde machine.

10.3 OPcache

Welke handler je ook gebruikt, zet OPcache aan. Het bewaart Joomla's gecompileerde PHP in het geheugen, zodat de server dezelfde bestanden niet bij elk verzoek opnieuw compileert. Het is de grootste gratis snelheidswinst voor elke PHP-site en staat standaard aan in moderne PHP-builds.

10.4 De FPM-pool afstemmen

PHP-FPM draait een pool van workers, en een handvol instellingen bepaalt hoeveel het er aanhoudt en wanneer het ze recyclet. De standaardwaarden zijn behoudend; op een drukke Joomla-site stem je ze af op je beschikbare geheugen.

pm = dynamic              ; workers laten groeien en krimpen met verkeer
pm.max_children = 20      ; harde limiet op gelijktijdige PHP-workers
pm.start_servers = 4      ; workers klaar bij opstart
pm.min_spare_servers = 2  ; houd minstens zoveel inactief
pm.max_spare_servers = 6  ; snoei inactieve workers hierboven weg
pm.max_requests = 500     ; recycle een worker na N verzoeken

De belangrijkste instelling is pm.max_children: die begrenst hoeveel Joomla-verzoeken tegelijk draaien. Zet je hem te hoog, dan kan een verkeerspiek het geheugen uitputten en de server laten crashen; zet je hem te laag, dan staan bezoekers in de rij. Een ruwe richtlijn is het geheugen dat je voor PHP kunt missen te delen door het gemiddelde geheugen dat één Joomla-worker gebruikt (vaak 40 tot 80 MB). De regel pm.max_requests herstart elke worker periodiek, wat stilletjes opruimt na een extensie die geheugen lekt.

Naar boven

11. Prestaties en caching

11.1 Lagen van snelheid

Een snelle Joomla-site stapelt meerdere caches en optimalisaties op, en de webserver zit daar middenin:

Browsercache         (ingesteld door de server, expires-headers)
   ↓
Servercache          (LiteSpeed Cache, Nginx FastCGI-cache)
   ↓
Joomla-cache         (System - Page Cache-plugin, view-caching)
   ↓
OPcache              (gecompileerde PHP in het geheugen)
   ↓
Database             (de traagste laag om te bereiken)

Hoe dichter bij de top een verzoek wordt beantwoord, hoe sneller het is. Een pagina die uit de browser- of servercache komt, bereikt PHP niet eens.

11.2 Compressie

Zet tekstcompressie aan op de server zodat HTML, CSS en JavaScript kleiner over de lijn gaan. Moderne servers ondersteunen Gzip en het nieuwere, betere Brotli. Joomla kan zijn eigen uitvoer ook gzippen (Globale configuratie → Server → Gzip-paginacompressie), maar het op één plek doen, op de webserver, is meestal netter. Zet het niet allebei tegelijk aan voor dezelfde inhoud.

11.3 Vervaltijd voor statische bestanden

Zeg browsers met cache-headers dat ze afbeeldingen, CSS en lettertypen lang mogen bewaren. Op Apache staat dit in .htaccess met mod_expires; op Nginx is het een expires-directive in een location-blok. Een lange vervaltijd plus versienummers in bestandsnamen betekent dat terugkerende bezoekers bij een tweede bezoek bijna niets downloaden.

11.4 HTTP/2 en HTTP/3

Zet HTTP/2 of HTTP/3 aan op de server. Daarmee kan de browser veel bestanden over één verbinding ophalen, wat past bij Joomla-pagina's die meerdere CSS- en JavaScript-bestanden laden. Ze vragen geen aanpassing binnen Joomla; het is puur een serverinstelling bovenop HTTPS.

11.5 Opschalen: load balancing

Als één server niet meer genoeg is, schaal je uit door meerdere applicatieservers achter een load balancer te draaien die de verzoeken eroverheen verdeelt:

            Load Balancer
           /      |      \
     Web 1      Web 2      Web 3
           \      |      /
            Gedeelde database
            Gedeelde media / sessies

Dit voegt redundantie toe (één server kan uitvallen zonder dat de site platgaat) en laat je onderhoud doen zonder downtime. Joomla heeft twee dingen nodig om dit goed te doen. Zet eerst Achter load balancer = Ja in de Globale configuratie zodat Joomla de doorgestuurde headers vertrouwt (zie sectie 13.2). Deel ten tweede de status die anders per server zou verschillen: bewaar sessies op een gedeelde plek zoals de database of Redis, en zet door gebruikers geüploade media op gedeelde opslag zodat elke server dezelfde bestanden ziet. De meeste kleine en middelgrote Joomla-sites hebben dit nooit nodig, maar het is het standaardpatroon voor installaties met veel verkeer.

Naar boven

12. Beveiliging en hardening

12.1 Bescherm de gevoelige bestanden

Een paar bestanden mogen nooit te downloaden zijn. Het belangrijkste is configuration.php, dat je databasewachtwoord bevat. Joomla bewaart het bewust buiten de geserveerde uitvoer, maar een verkeerd ingestelde server kan het toch blootleggen. Blokkeer op elke server directe toegang tot deze:

  • configuration.php en eventuele *.bak- of *.old-kopieën.
  • Verborgen mappen zoals .git en .env-bestanden.
  • De mappen cli/ en tmp/ tegen directe webtoegang.

12.2 HTTPS afdwingen

Stuur al het HTTP-verkeer door naar HTTPS op de server, en laat Joomla het ondersteunen met Globale configuratie → Server → HTTPS afdwingen = Gehele site. Op Apache is dit een rewriteregel in .htaccess; op Nginx een return 301 in een serverblok op poort 80. Een gratis certificaat van Let's Encrypt dekt dit, en Caddy of LiteSpeed kunnen het certificaat voor je beheren.

12.3 TLS en moderne versleuteling

HTTPS is HTTP verpakt in TLS, het protocol dat het verkeer tussen browser en server versleutelt. Voordat een pagina laadt, voeren de twee kanten een korte TLS-handshake uit:

  1. De browser controleert het certificaat van de server en bevestigt dat het geldig en vertrouwd is.
  2. Beide kanten spreken een cipher af (de versleutelingsmethode).
  3. Ze stellen gedeelde sessiesleutels op.
  4. De versleutelde uitwisseling van de werkelijke pagina begint.

Stel de server in op TLS 1.3, en hooguit TLS 1.2 als terugval. Zet de oude SSL- en TLS 1.0/1.1-versies uit, die onveilig zijn en door moderne browsers toch worden geweigerd. TLS 1.3 is ook sneller: de handshake heeft minder heen-en-weer nodig, dus de eerste pagina komt eerder aan. Dit is een serverinstelling; Joomla zelf heeft niets meer nodig dan HTTPS afdwingen.

12.4 Beveiligingsheaders horen ook op de server

Joomla levert een System - HTTP Headers-plugin die de meeste moderne beveiligingsheaders vanuit de achterkant instelt. Maar één header die hij niet instelt, X-Content-Type-Options: nosniff, kun je het best op de server toevoegen. De geleverde Joomla-htaccess.txt bevat hem al:

Header always set X-Content-Type-Options "nosniff"

Houd headers op serverniveau en pluginniveau gelijk. Stellen ze allebei dezelfde header met verschillende waarden in, dan wint degene die het laatst draait, en dat is meestal de server of een proxy.

12.5 Blokkeer foute verzoeken: WAF, Fail2ban en rate limiting

De hardening hierboven beschermt bestanden en verbindingen. De volgende laag stopt misbruikende verzoeken voordat ze Joomla bereiken:

  • ModSecurity - een Web Application Firewall (WAF) die in Apache, Nginx of LiteSpeed draait en verzoeken toetst aan regelsets zoals de OWASP Core Rule Set. Het blokkeert veelvoorkomende SQL-injectie- en cross-site-scriptingpatronen op de server.
  • Fail2ban - kijkt naar je serverlogs en blokkeert tijdelijk IP-adressen die zich misdragen, bijvoorbeeld herhaalde mislukte logins op administrator/ of een vloed aan 404's.
  • Rate limiting - begrenst hoeveel verzoeken één client in een tijdvenster mag doen. Op Nginx is dit limit_req; het vertraagt brute-force en scraping zonder gewone bezoekers te hinderen.

Een clouddienst als Cloudflare kan dezelfde WAF- en rate-limiting-laag voor elke webserver bieden. Deze tools vullen Joomla's eigen beschermingen aan; ze vervangen geen sterke wachtwoorden, updates en multifactorauthenticatie.

12.6 Verberg de versiebanner

Standaard kondigen Apache en Nginx hun naam en versie aan in de Server-responseheader. Zet ServerTokens Prod op Apache of server_tokens off; op Nginx, zodat je niet precies prijsgeeft waar een aanvaller naar kijkt.

Naar boven

13. Onder de motorkap (ontwikkelaarsblik)

13.1 Hoe Joomla de server ziet

Joomla leest de omgeving die de webserver aan PHP doorgeeft via de superglobal $_SERVER. Een paar waarden zijn belangrijk voor hoe Joomla URL's bouwt en HTTPS detecteert:

VariabeleWaar Joomla het voor gebruikt
HTTP_HOST Het domein, om absolute links te bouwen.
REQUEST_URI Het opgevraagde pad, om de pagina te routeren.
HTTPS Om te bepalen of de verbinding veilig is.
SERVER_SOFTWARE Identificeert Apache, Nginx, LiteSpeed of IIS.
HTTP_X_FORWARDED_PROTO Het echte protocol bij een proxy.

13.2 De valkuil achter een proxy

Als Joomla achter een reverse proxy of load balancer zit die HTTPS afhandelt, kan PHP gewoon HTTP zien en SERVER_ADDR van de proxy, niet van de bezoeker. Joomla loopt dan het risico http://-links te bouwen op een https://-site, wat redirect-loops of mixed-content-waarschuwingen veroorzaakt. De oplossing is de proxy X-Forwarded-Proto te laten sturen en Achter load balancer = Ja in te stellen in de Globale configuratie, zodat Joomla die headers vertrouwt.

13.3 Configuratiebestanden zijn niet overdraagbaar

De rewrite-logica is in opzet identiek tussen servers, maar geschreven in vier verschillende talen. Dezelfde Joomla-regel ziet er per server zo uit:

Apache  (.htaccess)   RewriteRule .* index.php [L]
Nginx   (server)      try_files $uri $uri/ /index.php?$args;
IIS     (web.config)  <action type="Rewrite" url="index.php" />
Caddy   (Caddyfile)   try_files {path} {path}/ /index.php?{query}

Als je een site tussen servers verhuist, kopieer je het bestand niet; je vertaalt de bedoeling. Daarom doet een "werkende" Apache-.htaccess niets op Nginx.

Naar boven

14. SEO en metadata

De webserver beïnvloedt SEO ruim voordat een plugin dat doet. Zoekmachines belonen sites die snel, veilig en consistent zijn, en alle drie beginnen bij de server:

  • Nette URL's: zet SEF-URL's en rewriting aan zodat paden leesbaar en stabiel zijn. Verander ze later niet zonder 301-redirects.
  • Eén canonieke host: stuur http door naar https en kies óf www óf zonder www, en stuur de andere door. Dezelfde pagina op meerdere hosts serveren splitst ranking-signalen.
  • Snelheid: compressie, caching, OPcache en HTTP/2 verbeteren allemaal de Core Web Vitals, die meewegen in de ranking van Google.
  • Juiste statuscodes: een ontbrekende pagina moet een 404 teruggeven, een verplaatste pagina een 301. Een server die alles met 200 beantwoordt, verwart crawlers en verspilt crawlbudget.

Hier is geen SEO-extensie voor nodig. Het is configuratie die je eenmalig op de server en in de Globale configuratie instelt, en die loont op elke pagina.

Naar boven

15. Veelgemaakte fouten en valkuilen

15.1 URL-herschrijving zonder het configuratiebestand

Symptoom: de homepage werkt, maar elke andere pagina geeft een 404 nadat je URL-herschrijving aanzet.

Oplossing: hernoem htaccess.txt naar .htaccess op Apache, of web.config.txt naar web.config op IIS, of voeg de rewriteregel toe aan Nginx of OpenLiteSpeed.

15.2 Apache-regels naar Nginx kopiëren

Symptoom: je plakt een .htaccess-fragment in Nginx en er gebeurt niets.

Oplossing: Nginx negeert .htaccess volledig. Vertaal de regel naar een location-blok en herlaad de server.

15.3 Mixed content en redirect-loops achter een proxy

Symptoom: het slotje gaat kapot, of de site blijft eindeloos doorsturen, na verhuizing achter een load balancer of CDN.

Oplossing: laat de proxy X-Forwarded-Proto doorgeven en zet Achter load balancer op Ja in de Globale configuratie.

15.4 Blootgestelde configuration.php of .git

Symptoom: een beveiligingsscan meldt dat /.git/ of een configuratieback-up te downloaden is.

Oplossing: weiger deze paden op de server. De Apache-.htaccess regelt veel hiervan; op Nginx en OpenLiteSpeed voeg je de weigerregels zelf toe.

15.5 Dubbele compressie

Symptoom: pagina's ogen kapot of downloaden als wartaal nadat je Gzip in Joomla aanzet.

Oplossing: comprimeer op slechts één plek. Comprimeert de server de uitvoer al, laat dan Joomla's Gzip-paginacompressie uit.

15.6 De RewriteBase in een submap

Symptoom: rewriting werkt op een site in de hoofdmap maar gaat stuk als Joomla in een submap staat.

Oplossing: uncomment en stel RewriteBase /submap in in .htaccess, of het bijbehorende basispad op andere servers.

Naar boven

16. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

  • Hernoem het geleverde configuratiebestand (htaccess.txt of web.config.txt) voordat je URL-herschrijving aanzet.
  • Gebruik PHP-FPM of LSAPI, nooit het oude mod_php, en houd OPcache aan.
  • Draai op Apache de event-MPM met PHP-FPM in plaats van prefork met mod_php.
  • Stem de FPM-pool af op je geheugen; kies pm.max_children zo dat een verkeerspiek het RAM niet kan uitputten.
  • Stem de rewriteregel af op de server; kopieer geen Apache-regels naar Nginx.
  • Dwing HTTPS af op de server, geef de voorkeur aan TLS 1.3, en kies één canonieke host.
  • Comprimeer en cache statische bestanden op de server, en vermijd dubbele compressie.
  • Zet Achter load balancer op Ja zodra er een proxy, CDN of load balancer voorstaat.
  • Schaal uit met een load balancer plus gedeelde sessies en gedeelde media als één server niet genoeg is.
  • Blokkeer configuration.php, .git en back-ups voor het web.
  • Voeg een verdediging op verzoekniveau toe (WAF zoals ModSecurity, Fail2ban of rate limiting) voor drukke of blootgestelde sites.
  • Houd beveiligingsheaders op serverniveau en pluginniveau consistent.
Naar boven

17. In het kort

APACHE        Hernoem htaccess.txt → .htaccess  (leest .htaccess)
NGINX         try_files $uri $uri/ /index.php?$args;  (geen .htaccess)
LITESPEED     Leest .htaccess (commercieel); LSAPI voor PHP
OPENLITESPEED Eigen rewriteregels; standaard geen .htaccess
IIS           Hernoem web.config.txt → web.config + URL Rewrite-module
CADDY         Caddyfile-regels; automatische HTTPS
SEF           Globale configuratie → Site → SEF + URL-herschrijving
APACHE MPM    event + PHP-FPM  (niet prefork + mod_php)
PHP           PHP-FPM of LSAPI + OPcache aan
FPM POOL      Stem pm.max_children af op beschikbaar geheugen
HTTPS         Afdwingen op server + HTTPS afdwingen in Joomla; TLS 1.3
PROXY         Geef X-Forwarded-Proto door + Achter load balancer = Ja
SCHAAL        Load balancer + gedeelde sessies + gedeelde media
SNELHEID      Brotli/Gzip, cache-headers, HTTP/2, servercache
VEILIG        Blokkeer configuration.php, .git, back-ups; nosniff-header
VERWEER       WAF (ModSecurity) + Fail2ban + rate limiting
Naar boven

18. Samenvatting

De webserver is de laag onder Joomla die de meeste mensen nooit zien, en die toch bepaalt hoe je site zich onder de oppervlakte gedraagt. De thema's komen bij elke optie terug:

  • Apache is de vriendelijke standaard, gestuurd door het .htaccess-bestand dat Joomla voor je levert.
  • Nginx ruilt flexibiliteit per map in voor snelheid en schaal, en heeft zijn regels in de serverconfig nodig.
  • LiteSpeed en OpenLiteSpeed jagen op prestaties, waarbij de commerciële editie .htaccess leest zoals Apache.
  • IIS draait Joomla op Windows via web.config en de URL Rewrite-module.
  • Nieuwere servers en proxy-opstellingen voegen automatische HTTPS en slimme caching toe, tegen een beetje extra instelwerk.

Bij allemaal bepalen dezelfde vier taken het succes: URL's juist routeren, PHP efficiënt draaien, statische bestanden serveren en cachen, en HTTPS en beveiligingsregels afdwingen. Krijg je die goed, dan doet het merk van de server veel minder ertoe dan mensen denken.

Is je Joomla-site traag, geeft hij 404's na een verhuizing, of breekt het slotje achter een CDN, dan ligt de oorzaak vaak in de configuratie van de webserver en niet in Joomla zelf. Een zorgvuldige blik op de rewriteregels, de PHP-handler en de proxy-headers vindt het probleem meestal snel, en dat is precies het soort fundamentwerk dat een site jarenlang snel en veilig houdt.

Naar boven
Webservers voor Joomla
Peter Martin
Peter Martin
Joomla Specialist

Peter is Joomla specialist en Linux admin voor snelle, veilige en schaalbare websites.

Veelgestelde vragen

Welke webservers en versies worden door Joomla ondersteund?

Joomla 6 ondersteunt officieel de volgende webservers:

  • Apache HTTP Server 2.4 of hoger
  • Nginx 1.26 of hoger (aanbevolen: Nginx 1.29)
  • Microsoft IIS 10 of hoger

Zie: Joomla! Programmers Documentation: Requirements for Joomla! 6.x. Naast een ondersteunde webserver vereist Joomla een ondersteunde versie van PHP en een van de ondersteunde databaseservers, zoals MariaDB, MySQL of PostgreSQL. De vereiste PHP-extensies moeten ook geïnstalleerd zijn.

Om Search Engine Friendly (SEF)-URL’s te gebruiken, vereist Apache de mod_rewrite-module, terwijl Microsoft IIS de URL Rewrite Module vereist. Nginx biedt URL-herschrijving via zijn eigen serverconfiguratie.

Hoewel dit niet in de officiële systeemvereisten wordt vermeld, draait Joomla ook zeer goed op andere moderne webservers zoals LiteSpeed Enterprise, OpenLiteSpeed en Caddy, mits deze correct zijn geconfigureerd en voldoen aan de PHP- en serververeisten van Joomla.

Voor de beste compatibiliteit, beveiliging en prestaties wordt aanbevolen om recente stabiele versies van zowel uw webserver als PHP te gebruiken.

Welke webserver is het best voor Joomla?

De beste webserver voor Joomla hangt af van de vereisten van je website, waaronder prestaties, compatibiliteit, schaalbaarheid en gebruiksgemak. Joomla draait betrouwbaar op alle grote webservers, maar elke server heeft zijn eigen sterke punten.

  • Apache is de meest ondersteunde webserver voor Joomla. Deze biedt uitstekende compatibiliteit, uitgebreide documentatie en is de standaardkeuze voor veel aanbieders van shared hosting.
  • Nginx is ontworpen voor hoge prestaties en schaalbaarheid, waardoor het een uitstekende optie is voor drukbezochte Joomla-websites en omgevingen met veel verkeer.
  • LiteSpeed Enterprise is een commerciële webserver die uitzonderlijke prestaties, ingebouwde caching op serverniveau en volledige compatibiliteit met Apache biedt, inclusief ondersteuning voor .htaccess.
  • OpenLiteSpeed is de gratis, open-sourceversie van LiteSpeed. Het biedt uitstekende prestaties en ondersteunt de .htaccess-herschrijfregels van Joomla, waardoor het een populaire keuze is voor VPS- en dedicated servers.
  • Caddy is een moderne webserver met automatische HTTPS-ondersteuning, eenvoudige configuratie en een groeiende populariteit onder ontwikkelaars en gebruikers van zelfgehoste Joomla-sites.

Voor de meeste Joomla-websites:

  • Apache, beste compatibiliteit en gebruiksgemak
  • Nginx, beste schaalbaarheid voor websites met veel verkeer
  • LiteSpeed Enterprise, beste algehele prestaties en compatibiliteit met Apache
  • OpenLiteSpeed, beste gratis alternatief met hoge prestaties
  • Caddy, de eenvoudigste moderne webserver met automatische HTTPS

Er is niet één “beste” webserver voor Joomla. Apache blijft de veiligste keuze voor maximale compatibiliteit, terwijl LiteSpeed Enterprise en OpenLiteSpeed uitstekende opties zijn voor gebruikers die op zoek zijn naar betere prestaties. Nginx blinkt uit in veeleisende omgevingen en Caddy biedt een modern, eenvoudig te beheren alternatief.

Werkt Joomla met Apache, Nginx, LiteSpeed, OpenLiteSpeed en Caddy?

Ja. Joomla ondersteunt alle gangbare moderne webservers.

Apache blijft de standaard op veel shared hostingplatforms. Nginx vereist een eigen rewrite-configuratie. LiteSpeed Enterprise is volledig compatibel met Apache's .htaccess-bestanden, terwijl OpenLiteSpeed ook de rewrite-regels van Joomla's .htaccess ondersteunt wanneer deze zijn ingeschakeld. Caddy gebruikt een eigen configuratieformaat, maar draait Joomla zonder problemen.

Is LiteSpeed of OpenLiteSpeed sneller voor Joomla dan Apache?

In de meeste gevallen wel.

Zowel LiteSpeed Enterprise als OpenLiteSpeed presteren over het algemeen beter dan Apache wat betreft responstijd, gebruik van systeembronnen en het aantal gelijktijdige bezoekers dat ze aankunnen. Ze zijn met name geschikt voor PHP-toepassingen zoals Joomla.

De daadwerkelijke prestaties zijn afhankelijk van factoren zoals PHP, database-optimalisatie, caching en de kwaliteit van de hosting.

Heeft Joomla Apache nodig?

Nee.

Joomla is niet afhankelijk van Apache en werkt even goed op Nginx, LiteSpeed Enterprise, OpenLiteSpeed en Caddy. Zolang de server voldoet aan de technische vereisten van Joomla en het herschrijven van URL’s correct is geconfigureerd, kan Joomla op vrijwel elke moderne Linux-webserver worden gehost.

Welke webserver is het veiligst voor Joomla?

De beveiliging hangt meer af van de serverconfiguratie dan van de webserver zelf.

Apache, Nginx, LiteSpeed Enterprise, OpenLiteSpeed en Caddy kunnen allemaal een veilige omgeving voor Joomla bieden, mits ze correct zijn geconfigureerd, up-to-date worden gehouden en worden gecombineerd met HTTPS, veilige PHP-instellingen, firewalls en regelmatige Joomla-updates.

Er is niet één enkele "veiligste" webserver voor Joomla.

Moet ik overstappen van Apache naar Nginx, LiteSpeed of OpenLiteSpeed?

Als uw Joomla-website betere prestaties nodig heeft of meer bezoekers verwacht, kan het de moeite waard zijn om over te stappen.

LiteSpeed Enterprise biedt de eenvoudigste migratie, omdat het volledig compatibel is met Apache-configuraties. OpenLiteSpeed ondersteunt Joomla ook zeer goed en biedt uitstekende prestaties zonder licentiekosten. Nginx is zeer schaalbaar, maar vereist doorgaans meer handmatige configuratie.

Voor kleinere Joomla-websites op betrouwbare hosting blijft Apache vaak een uitstekende keuze.

Wat is het verschil tussen LiteSpeed en OpenLiteSpeed?

LiteSpeed Enterprise en OpenLiteSpeed hebben dezelfde prestatiegerichte architectuur, maar richten zich op verschillende doelgroepen.

LiteSpeed Enterprise is de commerciële versie. Deze is ontworpen als directe vervanging voor Apache en biedt volledige .htaccess-compatibiliteit, naadloze integratie met bestaande Apache-configuraties en geavanceerde enterprise-functies.

OpenLiteSpeed is de gratis, open-source-editie. Het levert uitstekende prestaties voor Joomla en ondersteunt de .htaccess-herschrijfregels van Joomla wanneer deze zijn ingeschakeld, maar sommige Apache-specifieke functies en geavanceerde enterprise-mogelijkheden zijn niet inbegrepen.

Voor de meeste Joomla-gebruikers die hun eigen VPS of dedicated server gebruiken, biedt OpenLiteSpeed uitstekende prestaties zonder licentiekosten. Hostingproviders die maximale compatibiliteit met Apache vereisen, kiezen vaak voor LiteSpeed Enterprise.