⚡
LiteSpeed

LiteSpeed SSL offloading configureren in Plesk

📅 7 October 2026 ✏️ 7 October 2026 ⏱ 5 min leestijd

Leer hoe je SSL offloading met LiteSpeed correct instelt in Plesk, inclusief veelvoorkomende fouten en een stappenplan voor een werkende configuratie.

SSL offloading betekent dat SSL-verkeer wordt afgehandeld door een voorliggende laag (zoals een loadbalancer of proxy), terwijl de webserver zelf onversleuteld verkeer verwerkt. Bij LiteSpeed configureer je dit via de juiste headers en listener-instellingen, zodat je applicatie toch weet dat de oorspronkelijke verbinding via HTTPS liep. Dit artikel laat zien hoe je dit correct opzet in combinatie met Plesk, en welke valkuilen je moet vermijden.

Wat is SSL offloading en wanneer gebruik je het

Bij SSL offloading wordt de versleuteling van het verkeer afgehandeld door een apparaat of dienst vóór de webserver, bijvoorbeeld een loadbalancer, CDN of reverse proxy. De webserver zelf ontvangt dan gewoon HTTP-verkeer, maar moet wel weten dat de oorspronkelijke bezoeker via HTTPS kwam. Dit is belangrijk voor correcte redirects, cookies en beveiligingsheaders.

Je gebruikt SSL offloading meestal in situaties met meerdere servers achter een loadbalancer, of wanneer een externe partij (zoals een CDN) de SSL-verbinding beheert. Voor een enkele server met directe SSL via Plesk is offloading meestal niet nodig; dan volstaat een gewoon SSL-certificaat op de server zelf.

💡 Tip: Twijfel je of je offloading nodig hebt? Als je maar één server gebruikt zonder tussenliggende proxy, kun je waarschijnlijk gewoon direct SSL instellen zonder offloading.

LiteSpeed configureren voor SSL offloading

LiteSpeed moet weten dat inkomend HTTP-verkeer eigenlijk HTTPS was. Dit regel je met de header X-Forwarded-Proto, die de voorliggende laag meestuurt. LiteSpeed leest deze header en past het protocol intern aan, zodat scripts en redirects correct werken.

In de LiteSpeed WebAdmin console (of via de configuratiebestanden) stel je in dat de server deze header vertrouwt. Dit doe je meestal onder de listener-instellingen, waar je aangeeft welke upstream IP-adressen vertrouwd worden als bron van SSL-offloaded verkeer. Vertrouw alleen de IP-adressen van je eigen loadbalancer of proxy, nooit alle verkeer, om misbruik te voorkomen.

Daarnaast moet je ervoor zorgen dat applicaties zoals WordPress of frameworks de forwarded header herkennen. Veel CMS-systemen hebben hiervoor een aparte instelling nodig in het configuratiebestand, bijvoorbeeld om te voorkomen dat er een redirect-loop ontstaat tussen HTTP en HTTPS.

Instellingen controleren in Plesk

In Plesk vind je de SSL/TLS-instellingen van een domein onder de website- en domeininstellingen. Hier controleer je of het certificaat correct is gekoppeld en of de omleiding naar HTTPS actief staat. Bij offloading is het belangrijk dat deze omleiding niet dubbel gebeurt: zowel de proxy als de webserver mogen niet allebei onafhankelijk doorverwijzen, anders ontstaat er een lus.

Controleer ook de Apache- en nginx-instellingen (die Plesk naast LiteSpeed kan gebruiken) op eventuele conflicterende regels. Bij Tandata vind je deze instellingen overzichtelijk terug in het Plesk-paneel, inclusief de status van het SSL-certificaat per domein.

BezoekerHTTPSLoadbalancer(SSL offload)HTTP + headerLiteSpeedwebserver

Veelvoorkomende problemen oplossen

De meest voorkomende klacht bij SSL offloading is een eindeloze redirect-loop. Dit gebeurt meestal doordat zowel de proxy als de webserver proberen door te sturen naar HTTPS, terwijl de webserver het verkeer intern als HTTP blijft zien. Controleer eerst of de forwarded header correct wordt doorgegeven en herkend.

Een ander probleem is dat cookies gemarkeerd als “secure” niet werken, omdat de applicatie denkt dat de verbinding onversleuteld is. Zorg dat je applicatie of framework is ingesteld om de forwarded header te vertrouwen, niet alleen de webserver.

Mix van content (afbeeldingen of scripts die nog via HTTP worden geladen) kan ook optreden als de applicatie zelf links genereert op basis van het verkeerde protocol. Dit los je meestal op door de basis-URL of site-URL instelling in je CMS te controleren.

1

Controleer de bron van SSL-terminatie

Bepaal of SSL daadwerkelijk wordt afgehandeld door een voorliggende laag, en noteer het IP-adres hiervan.

2

Stel vertrouwde IP’s in bij LiteSpeed

Voeg alleen het IP van je proxy of loadbalancer toe als vertrouwde bron voor forwarded headers.

3

Controleer redirect-instellingen in Plesk

Zorg dat er niet dubbel wordt doorverwezen naar HTTPS, zowel door de proxy als door de webserver.

4

Test de headers en cookies

Controleer met de browserconsole of de juiste headers binnenkomen en of cookies correct als secure worden gemarkeerd.

Heb je een vraag over je configuratie die je er zelf niet uitkomt? In de kennisbank van Tandata staan meer artikelen over SSL en serverinstellingen, en via WhatsApp, ticket of e-mail helpt het support-team ook ‘s nachts mee met specifieke configuraties.

Veelgestelde vragen

Heb ik SSL offloading nodig bij één server?

Meestal niet. SSL offloading is vooral nuttig bij meerdere servers achter een loadbalancer of bij gebruik van een externe CDN. Bij één server volstaat een direct SSL-certificaat.

Waarom krijg ik een redirect-loop na het instellen van offloading?

Dit gebeurt meestal doordat de webserver het binnenkomende verkeer nog als HTTP ziet en opnieuw doorverwijst naar HTTPS, terwijl de proxy dat al heeft afgehandeld. Controleer de forwarded header.

Werkt SSL offloading samen met gratis SSL-certificaten?

Ja, het certificaat wordt dan geïnstalleerd op de voorliggende laag (proxy of loadbalancer) in plaats van op de webserver zelf.

Moet ik mijn CMS aanpassen voor SSL offloading?

Vaak wel. Veel CMS-systemen hebben een instelling nodig om forwarded headers te vertrouwen, anders ontstaan er problemen met cookies of redirects.

Conclusie

SSL offloading met LiteSpeed werkt goed zodra je de forwarded headers correct instelt en vertrouwt vanaf de juiste bron. Controleer altijd op dubbele redirects en test cookies en headers na elke wijziging. Voor de meeste standaard websites met één server is directe SSL overigens eenvoudiger en voldoende.

Bekijk webhosting →

Was dit artikel nuttig?