Webservers voor Joomla
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 boven2. 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:
| Taak | Waarom 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 boven3. 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.
| MPM | Hoe het werkt | Afweging |
|---|---|---|
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.
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.
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 boven6. 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 boven7. 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.
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.
| Server | Beste voor | SEF-instelling | Leest .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 boven9. 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=42in/news/42-my-article. Dit werkt op elke webserver. - URL-herschrijving gebruiken - haalt de
index.phpuit het pad zodat de URL/news/my-articlewordt. 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 boven10. 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.
| Handler | Gebruikt met | Opmerkingen |
|---|---|---|
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.
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 boven12. 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.phpen eventuele*.bak- of*.old-kopieën.- Verborgen mappen zoals
.giten.env-bestanden. - De mappen
cli/entmp/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:
- De browser controleert het certificaat van de server en bevestigt dat het geldig en vertrouwd is.
- Beide kanten spreken een cipher af (de versleutelingsmethode).
- Ze stellen gedeelde sessiesleutels op.
- 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.
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:
| Variabele | Waar 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.
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
httpdoor naarhttpsen kies ófwwwóf zonderwww, 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
404teruggeven, een verplaatste pagina een301. Een server die alles met200beantwoordt, 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 boven15. 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.
16. Best practices
Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:
- Hernoem het geleverde configuratiebestand (
htaccess.txtofweb.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 vanpreforkmetmod_php. - Stem de FPM-pool af op je geheugen; kies
pm.max_childrenzo 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,.giten 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.
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 boven18. 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
.htaccessleest zoals Apache. - IIS draait Joomla op Windows via
web.configen 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

Peter is Joomla specialist en Linux admin voor snelle, veilige en schaalbare websites.
Veelgestelde vragen
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.
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.
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.
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.
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.
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.
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.
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.


