LiteSpeed og .htaccess: reglerne, pluginnet skriver

Kort svar: LiteSpeed Cache skriver sine serverregler i .htaccess mellem # BEGIN LSCACHE og # END LSCACHE samt i en NON_LSCACHE-blok. Reglerne styrer bl.a. cache-vary for mobil og login, browsercache og levering af WebP. Ret dem aldrig i hånden – pluginnet overskriver blokken, når indstillingerne gemmes. Mangler blokken efter en gendannelse eller oprydning, genskabes den ved at gemme LiteSpeed-indstillingerne igen.

Fagligt gennemgået: 2. oktober 2026

Åbner man .htaccess på et LiteSpeed-site, møder man et bundt regler, man ikke selv har skrevet. De ser tekniske ud, og fristelsen til at „rydde op“ har væltet mange velfungerende cache-opsætninger.

Guiden forklarer, hvad blokkene gør, hvornår du må røre dem, hvordan de genskabes – og hvad du gør, hvis en ændring giver 500-fejl.

Før du ændrer noget: Download en kopi af den nuværende .htaccess via SFTP eller filhåndteringen, og gem den med dato i filnavnet. En enkelt tastefejl i filen kan give 500 Internal Server Error på hele sitet, og med en kopi er du tilbage på få sekunder.

Blokkene – og hvad de gør

På en LiteSpeed-server er .htaccess vejen til at tale direkte med serverens cache-motor. Det er derfor, LiteSpeed Cache kan mere end cache-plugins på andre servere: pluginnet beder webserveren om at cache og variere siderne, i stedet for at PHP skal gøre arbejdet.

Pluginnet vedligeholder typisk to sektioner: LSCACHE-blokken med cache-reglerne og NON_LSCACHE-blokken med øvrige regler, fx browsercache-headere. Begge er indrammet af BEGIN/END-kommentarer, og alt mellem dem tilhører pluginnet:

Sådan ser filen typisk ud

Skitsen herunder er forkortet og viser kun strukturen. Din egen fil afhænger af, hvilke funktioner du har slået til:

# BEGIN LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
<IfModule LiteSpeed>
RewriteEngine on
CacheLookup on
# ... vary-regler, mobilregler, WebP-regler ...
</IfModule>
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END LSCACHE
# BEGIN NON_LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# ... browsercache og andre regler ...
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END NON_LSCACHE

# BEGIN WordPress
# ... WordPress' egne rewrite-regler for permalinks ...
# END WordPress

LiteSpeed-blokkene ligger normalt øverst, og WordPress’ egen blok med permalink-reglerne længere nede. Rækkefølgen betyder noget, fordi serveren læser filen oppefra, så lad pluginnet placere sine blokke, og flyt dem ikke rundt.

Reglerne, du oftest møder

• CacheLookup on: tænder selve opslaget i serverens cache. Uden den er alt andet ligegyldigt.
• Vary-regler (cookies): fortæller serveren, at indloggede og besøgende med varer i kurven skal have andre udgaver end anonyme. Fjernes de, blandes udgaverne sammen, og symptomerne ligner fejlene ved Guest Mode.
• Mobilregler: er separat mobilcache slået til, sørger en regel for, at mobiler får deres egen kopi.
• WebP/AVIF-omskrivning: leverer moderne billedformater til browsere, der understøtter dem – makkeren til billedoptimeringen i QUIC.cloud.
• Browsercache-headere: sætter levetider på statiske filer, så tilbagevendende besøgende ikke henter dem igen.
• Login-cookie-regel: sikrer, at wp-admin og indloggede aldrig får offentlig cache.

Må jeg rette i dem?

Inde i blokkene: nej. Pluginnet genskriver dem ved næste gem af indstillinger, så håndrettelser overlever ikke – og en tastefejl giver øjeblikkelig 500-fejl på hele sitet. Vil du ændre adfærden, så ændr indstillingen i LiteSpeed Cache, og lad pluginnet skrive reglerne.

Egne regler som redirects, sikkerhedsregler eller blokering af bestemte filer placeres uden for BEGIN/END-sektionerne – så lever de fredeligt side om side. Generel førstehjælp til .htaccess, inklusive gendannelse af WordPress-standardblokken, står i guiden til at gendanne .htaccess.

Når blokken mangler eller er ødelagt

Efter en gendannelse fra backup, en flytning eller en hårdhændet oprydning kan LSCACHE-blokken mangle. Symptomet er subtilt: pluginnet ser aktivt ud, men cachen opfører sig forkert – ingen hits, eller forkert varieret indhold.

1. Bekræft, at blokken mangler

Åbn .htaccess, eller søg i den fra en terminal:

grep -n "BEGIN\|END" .htaccess

Du skal se komplette par for LSCACHE og NON_LSCACHE. Et BEGIN uden tilhørende END er lige så slemt som en manglende blok.

2. Lad pluginnet skrive blokken igen

Åbn LiteSpeed Cache-indstillingerne, og klik Gem uden at ændre noget. Så skriver pluginnet sine blokke igen. Sker der intet, har PHP sandsynligvis ikke skriveadgang til filen.

3. Tjek filrettigheder

.htaccess skal normalt have rettighederne 644 og være ejet af den samme bruger som resten af WordPress-filerne. Hvad tallene betyder, står i guiden til filrettigheder.

4. Fjern rester fra tidligere cache-plugins

Ligger der halve sektioner fra tidligere cache-plugins – fx regler for et plugin, der ikke længere er installeret – kan de forstyrre. Fjern i så fald hele den fremmede sektion fra BEGIN til END, ikke kun enkelte linjer, og test sitet bagefter.

500-fejl efter en ændring i .htaccess

Giver sitet 500 Internal Server Error lige efter en ændring, kommer du hurtigt tilbage ved at lægge din datomærkede kopi af filen op igen. Har du ingen kopi, kan du omdøbe .htaccess midlertidigt til fx .htaccess.fejl. Så forsvinder både fejlen og LiteSpeeds regler, og forsiden burde svare igen.

Gem derefter permalinks i WordPress (Indstillinger → Permalinks) for at få WordPress-blokken tilbage, og gem LiteSpeed-indstillingerne for at få cache-blokkene tilbage. Sammenlign til sidst den gamle fil med den nye, og flyt kun dine egne regler over – én ad gangen. Fejllogen fortæller ofte præcis, hvilken linje serveren ikke kunne læse; se guiden til at læse serverlogs og den generelle guide til 500-fejl.

Andre servere: Apache, OpenLiteSpeed og nginx

LSCACHE-direktiverne virker kun på LiteSpeed-webservere. På Apache ligger de inde i <IfModule LiteSpeed> og ignoreres derfor stille – harmløst, men uden effekt. nginx læser slet ikke .htaccess, så dér skal tilsvarende regler skrives i serverens egen konfiguration.

OpenLiteSpeed, den frie udgave, understøtter kun en del af .htaccess – primært rewrite-regler – og ændringer kan kræve en genstart af webserveren, før de slår igennem. Ser cachen ud til at ignorere dine indstillinger, så spørg din hosting, hvilken webserver sitet reelt kører på.

Verifikation

Opsætningen er sund, når:

• .htaccess indeholder komplette BEGIN/END-par for LSCACHE og NON_LSCACHE;
• cache-headerne viser hit for anonyme og no-cache for indloggede (test begge);
• WebP leveres, hvor du forventer det;
• sitet svarer 200 på forside, en underside og en side med permalink-struktur.

Tag en kopi af den fungerende .htaccess, og gem den med dato. Det koster ingenting og gør næste fejlsøgning eller flytning meget lettere.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• Ødelagt .htaccess: gendan WordPress-standardfilen sikkert
• LiteSpeed Cache cacher ikke siden: sådan læser du cache-headerne
• LiteSpeed Guest Mode giver forkert eller blinkende indhold
• LiteSpeed Cache sammen med andre optimeringsplugins
• LiteSpeed hosting til WordPress hos Hostious – serveren, hvor reglerne faktisk virker

Ofte stillede spørgsmål om LiteSpeed og .htaccess

Kan jeg slette LSCACHE-blokken for at nulstille cachen?

Nej – det nulstiller ikke cachen, det fjerner reglerne for korrekt variering. Brug purge-funktionerne i pluginnet til at rydde cache, og lad blokken være.

Hvorfor kommer mine håndrettelser i blokken ikke til at virke?

Fordi pluginnet ejer indholdet mellem BEGIN og END og genskriver det ved næste gem. Ændr indstillingen i pluginnet i stedet – eller læg din egen regel uden for sektionen.

Virker reglerne, hvis jeg flytter til en anden server?

LSCACHE-direktiverne virker kun på LiteSpeed-servere – på Apache ignoreres de stille (harmløst), og på nginx læses .htaccess slet ikke. Flytter du til LiteSpeed-hosting, virker reglerne igen af sig selv.

Hvor skal mine egne redirects stå i .htaccess?

Uden for BEGIN/END-sektionerne, typisk øverst i filen før LiteSpeed- og WordPress-blokkene, så de rammer, før WordPress’ egne regler tager over. Test hver ny regel for sig, og behold en kopi af den fungerende fil.