To Underdomæner, Samme Host, Forskellige Cache-headers

identisk .htaccess · samme origin · 7 dages cache på den ene, 1 år på den anden

Symptomet

To underdomæner på samme hostingkonto, samme CDN-produkt, samme server. En fontanmodning kørt gennem DevTools på begge:

domain-a.tld  →  Cache-Control: public, max-age=31536000, immutable   # 1 year
domain-b.tld  →  Cache-Control: public, max-age=604800                  # 7 days

Samme filtype (.woff2), samme konto. GTmetrix og PageSpeed Insights markerer alt under Lighthouse's ~3-måneders cache-tærskel som en "ineffektiv cache-politik" — så det var ikke kosmetisk, det skadede aktivt performance-scoren på det ene underdomæne, men ikke det andet.

Hvad jeg udelukkede først

Før jeg rørte ved nogen konfiguration, sammenlignede jeg de to .htaccess-filer linje for linje:

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|woff2?|svg|png|jpe?g|webp|avif|ico)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

Identisk direktiv, identisk værdi, på begge domæner. Så det var ikke en fejlkonfigureret origin — serveren fortalte begge zoner at cache i et år. Noget mellem origin og browseren overskrev det på den ene af de to.

Isolering af laget

Hostens CDN-dashboard har ingen per-domæne TTL-override og ingen "respekter origin-headers"-knap i UI'et — bekræftet direkte fra deres egen dokumentation, ikke antaget. Så CDN'en anvendte selv stille en anden standard per zone, uden nogen dashboard-indstilling til at rette det.

For at bekræfte, at origin faktisk var korrekt (og udelukke noget server-side), brugte jeg CDN'ens "development mode" til helt at omgå edge-cachen og ramme origin direkte. Resultat: origin returnerede den korrekte 1-års header, hver gang, på begge domæner. Uoverensstemmelsen skete 100% på CDN-laget, ikke serveren.

Rettelsen

Tilføjede s-maxage sammen med max-age i samme direktiv:

Header set Cache-Control "public, max-age=31536000, s-maxage=31536000, immutable"

s-maxage er direktivet, som delte/proxy-caches (CDN'er) burde prioritere over max-age. Den CDN-zone, der som standard brugte 7 dage, havde tilsyneladende aldrig læst max-age korrekt til sin interne TTL — men den respekterede s-maxage.

Efter at have ryddet cachen og testet en frisk (aldrig cachet før) URL gennem den live CDN-edge — ikke bypass-tilstand, ikke forældet cache, et reelt MISS-så-HIT — kom headeren tilbage præcis som forventet:

Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
X-Cache-Status: MISS → HIT

Hvorfor det er værd at dele

Intet af dette er officielt dokumenteret noget sted, jeg kunne finde. Support kunne bekræfte, at de to zoner opførte sig forskelligt, men kunne ikke forklare hvorfor eller hvordan man aligner dem fra panelet. Rettelsen kom fra at teste direktiv-for-direktiv mod de faktisk leverede headers — ikke fra en knowledge base-artikel.