LiteSpeed Cache cacher ikke siden: sådan læser du cache-headerne

Kort svar: Test en almindelig offentlig GET-URL som anonym bruger to gange uden query strings. Første svar er normalt X-LiteSpeed-Cache: miss, og næste skal blive hit. Ingen LiteSpeed-header peger på server-/integrationsproblemet eller et andet CDN-lag. X-LiteSpeed-Cache-Control: no-cache betyder, at siden bevidst er dynamisk. Et nyt miss hver gang kræver kontrol af cookies, excludes, purge-events, CDN og cachemappe — ikke Force Cache.

Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, LiteSpeed Cache 7.9, PHP 8.4.23 og Chrome 151 på isoleret staging. QUIC.cloud-integration og quota er ikke aktiveret eller verificeret; cacheheaders skal aflæses i det konkrete miljø, fordi server- og CDN-lag kan ændre resultatet.

“Cacher ikke” er kun præcist, når den samme cachebare URL, samme host, samme cookiefrie klient og samme cachelag testes gentagne gange. En indlogget browser, en preview-URL eller ?nocache=1 kan være korrekt dynamisk.

Den firegrenede headerdiagnose

Lav en ren test

1. Vælg en publiceret artikel, ikke login, søgning, preview, REST eller checkout.
2. Brug et privat vindue eller curl uden cookies.
3. Brug den endelige canonical URL uden query string.
4. Gem fulde responseheaders ved request 1 og 2.
5. Gentag efter 10–15 sekunder uden at gemme eller purge noget i WordPress.
6. Test origin direkte kun via en godkendt metode, der ikke eksponerer eller omkonfigurerer DNS.

1. Hvis headeren mangler

Bekræft at pluginets Cache-funktion er aktiv, og at miljøet understøtter LiteSpeed page cache eller QUIC.cloud. Pluginets CSS-/billedfunktioner kan bruges på andre webservere, men det beviser ikke server-page-cache.

Kontroller reverse proxy/CDN. Den kan svare fra eget cachelag og skjule originheaders. Sammenlign edge- og origin-test med sikker host-header-metode. Hvis domænepath og filpath er forskellige, skal hosting kontrollere, hvor LiteSpeed forventer konfigurationen; hardcod ikke serverstier ud fra et blogeksempel.

2. Hvis svaret siger no-cache

Se LiteSpeed Cache → Cache → Excludes for URI, query string, cookie, user agent, category, tag eller rolle. Læs debugloggen for den konkrete URL og request-ID. POST, admin, søgning og andre dynamiske requests er normalt ikke cachebare.

Fjern kun en ekskludering, når indholdet er offentligt og ens for alle relevante brugere. Brug aldrig Force Cache på kurv, konto, personlige priser eller formularresultater for at få et hit.

3. Hvis hvert svar er miss

Se efter:

• en cookie, der oprettes ved første request og udløser bypass;
• en purge-hook, som kører ved hvert besøg;
• dynamisk CSS/JS eller pluginindhold, der regenererer og purger;
• et CDN, der sender bypass/no-cache mod origin;
• cachemappe-/rettighedsfejl;
• mobile, sprog-, valuta- eller Guest Mode-varies, så du tester forskellige cachekeys;
• load balancer-noder uden delt cache eller konsistent routing.

Aktiver debuglog kortvarigt, reproducer to requests, og slå logging fra igen. Loggen kan indeholde URL'er, IP'er og cookies.

Sammenlign den samme cachekey

To URL'er, der ser ens ud i browseren, kan være forskellige for cachemotoren. Sammenlign derfor scheme, host, port, path, trailing slash, query string, HTTP-metode, sprog, valuta, mobilvariant og de cookies, der faktisk sendes. Gem en lille matrix, hvor kun én variabel ændres ad gangen:

Hvis A bliver hit, men B aldrig gør, er problemet ikke en generel defekt cache. Undersøg om sprog-/valutapluginet med vilje bypasser, eller om det bør oprette en begrænset vary. Kopier ikke en fremmed cookie-vary-liste; hver ekstra værdi kan multiplicere antallet af cacheobjekter og øge lager- og crawlerbelastningen.

Kontroller svaret, ikke kun headernavnet

Et hit er kun korrekt, hvis body tilhører den forventede URL og brugerstate. Sammenlign titel, canonical, sprog, pris og en ufølsom indholdsmarkør i responsen. Test to isolerede browsere, og kontroller at ingen session, nonce, kurv eller personligt navn lækker mellem dem. Hvis et cache-hit indeholder personlig data, skal den berørte URL straks bypasses, cachen målrettet tømmes, og hændelsen behandles som en sikkerhedsfejl.

Kontroller også statuskode og redirectkæde. En 301 til canonical kan være korrekt, men det er den endelige 200-URL, der skal gennemføre miss → hit. En tilsyneladende “cachetest” på en redirect måler ikke siden. HEAD kan desuden håndteres anderledes end GET; brug en anonym GET, når sidecachen skal bevises.

Undgå at cache en fejltilstand

Før en side gøres cachebar, skal du åbne den uden cache og kontrollere, at origin svarer korrekt. En vedvarende 500, tom template eller vedligeholdelsesside må ikke skjules bag et hit. Test også, at WordPress kan purge efter en rigtig indholdsændring. Cache virker først sikkert, når både opbygning og ugyldiggørelse er dokumenteret.

4. Deaktivér andre cachelag på staging

Test LiteSpeed alene. Tilslut derefter CDN, host-cache og andre optimeringer et lag ad gangen. Gem headers efter hvert lag. Hvis origin er hit, men edge altid får miss, er CDN-reglen ejeren. Hvis origin og edge begge misser, start ved WordPress/server.

5. Undersøg for hyppig purge

En cache kan fungere og alligevel aldrig nå hit, hvis noget purger siden mellem dine requests. Læs debugloggen for purge-tags/hooks. Et plugin, der tilføjer et tilfældigt token eller opdaterer data ved hvert besøg, kan udløse gentagen regeneration.

Deaktiver ikke alle auto-purge-hooks. Find det ene plugin/event, og brug en målrettet integration eller mindre variabel rendering.

Mikroeksempel: samme URL, men ikke samme request

Du åbner en artikel i en indlogget browser og ser no-cache. Derefter tester en kollega anonymt og får hit. Begge resultater kan være korrekte. Login-cookien ændrer requestens cacheegnethed, selv om URL'en er identisk. Derfor skal supportnotatet altid indeholde klientstate og cookienavne — uden værdier.

Et andet typisk forløb er miss, miss, miss, selv om page cache er aktiv. Før du mistænker filrettigheder, kontroller om en cookie sættes ved hvert svar, om query string ændres, eller om et cache-/deploymenthook purger URL'en mellem forsøgene. Hvis HTML-hashen også ændrer sig, kan siden have en dynamisk komponent, som gør en fælles cachekey forkert.

Beslutning efter de første to requests

• Ingen LiteSpeed-header: Bekræft servertype og integration før pluginindstillinger.
• no-cache: Find den dokumenterede årsag i route, cookie, rolle eller exclude.
• Første miss, andet hit: Page cache virker; gå videre til funktion og purge.
• Gentaget miss: Lås cachekey og undersøg lagring eller løbende purge.
• hit på en privat route: Rul cacheændringen tilbage med det samme og test sessionisolation.

Det sidste punkt er vigtigst. Målet er ikke, at alle URL'er bliver hit, men at de rigtige offentlige svar kan genbruges, mens brugerafhængige svar aldrig deles.

Brug en statisk kontrol som pejlemærke

Hvis en almindelig CSS- eller billedfil får forventet cacheadfærd, mens HTML mangler LiteSpeed-headeren, er hele serverforbindelsen ikke nødvendigvis væk. Forskellen kan ligge i HTML-route, WordPress-hook eller et foranliggende cachelag. Hvis heller ikke en cachebar statisk testressource bærer de forventede headers, skal hosting først bekræfte, hvilket lag der faktisk svarer.

Sammenlign ikke en fil med lang browsercache direkte med en WordPress-side og konkludér, at page cache virker. De to ressourcer kan være leveret af forskellige mekanismer. Pejlemærket bruges kun til at afgrænse kæden; den endelige miss → hit-test skal stadig udføres på en offentlig HTML-URL, som efter design må caches.

Verifikation

• En ren offentlig URL viser miss → hit med samme cachekey.
• En indholdsopdatering giver miss med nyt indhold og derefter hit.
• Dynamiske URL'er forbliver no-cache/bypass.
• Edge og origin viser den forventede rollefordeling.
• Debuglog har ingen ny permission-/path-/purgefejl.
• To isolerede brugere ser aldrig personligt indhold fra samme cache.

Rollback

Gendan den tidligere exclude-, cookie-, proxy- eller serverkonfiguration. Purge kun den testede URL/tag, og gentag headersekvensen. Hvis en bred Force Cache-regel blev testet, fjernes den straks før rollback-verifikation.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal have URL, UTC-tider, anonyme headers, servertype og relevant redigeret debuglog. Pluginudvikleren skal have purge-hook/cookie og reproduktion. Se LiteSpeed hosting hos Hostious ved servercache-/vhostproblemer.

Ofte stillede spørgsmål om manglende cache-hit

Hvorfor får jeg aldrig X-LiteSpeed-Cache: hit?

Enten cacher serveren ikke (ingen LiteSpeed-header overhovedet), eller også rammer hver request en no-cache-regel: login-cookie, exclude, query string eller POST. Headeren på en anonym GET-request viser hvilken.

Hvad betyder det, hvis headeren helt mangler?

At requesten ikke går gennem en LiteSpeed-server med cachemodulet aktivt – fx bag en anden proxy eller på en ikke-LiteSpeed-server. Så skal server-/integrationslaget på plads, før plugin-indstillinger betyder noget.

Kan et andet plugin blokere LiteSpeed Cache?

Ja – et andet cacheplugin, en særlig cookie eller et plugin, der sætter no-cache-headers, kan udelukke caching på alle sider. Deaktivér konkurrerende cacheplugins, og test igen med to anonyme requests.

Læs også

• QUIC.cloud og LiteSpeed Cache
• LiteSpeed Cache-indstillinger
• LiteSpeed viser gammelt indhold
• LiteSpeed crawler kører ikke

Sådan dokumenterer du din egen cachefejl

Gem de to anonyme requests side om side med URL, cookie-state og X-LiteSpeed-Cache eller det relevante CDN-header. En header uden klientkontekst er svær at bruge, så skriv også, om requesten var indlogget, havde query string eller blev sendt lige efter en purge. Cookieværdier og tokens skal fjernes.

Hvis årsagen er en exclude eller et purge-hook, dokumenteres kun den konkrete regel og det præcise tidspunkt, den påvirker URL'en. Efter rettelsen skal samme rene request gå miss → hit, mens login og andre dynamiske routes fortsat er uncached. Så beviser du, at cachen virker uden at have gjort private sider cachebare.