Kort svar: Forbind WordPress via LiteSpeed Cache → General → Online Services → Enable QUIC.cloud Services. Vælg derefter bevidst mellem kun Online Services og selve CDN'et. Billed-, CCSS-, UCSS- og VPI-tjenester kræver ikke, at DNS flyttes. CDN gør. Før en DNS-ændring eksporteres hele zonen, origin-IP og mailrecords kontrolleres, TTL/rollback planlægges, og REST-/firewalladgang verificeres. Efter skiftet skal
X-QC-Popbekræfte edgelevering.
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, CDN og quota er ikke aktiveret eller verificeret; guiden beskriver derfor et fagligt kontrolleret forløb, som skal bekræftes mod den aktuelle konto og DNS-zone.
QUIC.cloud Online Services og QUIC.cloud CDN bliver ofte blandet sammen. Online Services genererer blandt andet Critical CSS, Unique CSS, viewportdata og billedoptimering. CDN'et bliver en del af trafik- og DNS-kæden. Du kan bruge de første uden det sidste. Det skel skal du have styr på, før opsætningen er sikker.
På denne side
| Mål | Kræver WordPress-forbindelse | Kræver QUIC.cloud-konto | Kræver DNS-ændring |
|---|---|---|---|
| CCSS/UCSS/VPI/billedtjenester | Ja | Ikke nødvendigvis | Nej |
| Dashboard, statistik og ekstra quota | Ja | Ja | Nej |
| QUIC.cloud CDN | Ja | Ja | Ja |
Lav ikke navneserverskift, hvis du kun vil bruge Online Services.
| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Enable Services stopper | REST, outbound HTTPS eller adminflow fejler | Site Health og UTC HTTP-log | Ret forbindelsen før DNS berøres |
| Online Service står pending | Callback, quota eller service node | Requeststatus og redigeret fejl | Isoler den konkrete service |
| CDN er enabled, men header mangler | DNS går uden om QUIC.cloud | Autoritativ DNS og responseheaders | Ret kun den dokumenterede DNS-rute |
| Web virker, men mail stopper | Zoneimport mangler MX/TXT | Før/efter DNS-diff og mailtest | Gendan manglende records eller rollback zonen |
Root virker, www fejler | Record, redirect eller certifikat dækker ikke hosten | DNS-, TLS- og redirectmatrix | Ret det konkrete hostled |
| Dynamisk side får cache-hit | Bypass/cachepolicy er forkert | Kurv/login/konto som anonyme og brugere | Stop CDN-aktivering og ret policyen |
Gem LiteSpeed-konfiguration, DNS-zone, nuværende nameservers, A/AAAA/CNAME, MX, SPF, DKIM, DMARC, CAA og verifikationsrecords. Notér origin-IP og nuværende proxy/CDN. En stagingkopi skal forbindes som sit eget domæne og må ikke tilføjes som alias til produktion.
Tag en HTTP-headerbaseline for forside, artikel, login og eventuelle dynamiske sider. Notér også DNS-TTL og et realistisk rollbackvindue.
I aktuelle LiteSpeed Cache-versioner bruges Online Services-siden; et gammelt Domain Key-felt er ikke længere den rigtige vej. Klik Enable QUIC.cloud Services, og lad tjenesten registrere servertype og IP. Vælg anonym brug, hvis du kun har brug for de understøttede Online Services uden dashboardkonto, eller forbind den korrekte konto.
Efter redirect skal WordPress vise, at integrationen er enabled. Hvis forbindelsen fejler, stop her. DNS vil ikke rette en blokeret REST API eller forkert origin.
QUIC.cloud skal kunne kommunikere med WordPress og origin. Kontroller Site Health/REST, sikkerhedsplugin, basic auth og WAF. Tillad kun QUIC.clouds aktuelle dokumenterede IP-kilder og nødvendige endpoints. Slå ikke hele firewallen fra permanent.
Hvis en anden reverse proxy skjuler originens serverheader/IP, kan det forstyrre detektion. Dokumenter den nuværende proxy, og brug QUIC.clouds specifikke integrationsflow. Eksponer ikke origin-IP i artikelscreenshots.
QUIC.cloud tilbyder DNS/nameserver-flow og andre dokumenterede DNS-metoder. Uanset metode skal de importerede records sammenlignes linje for linje med eksporten. Især mailrecords og tredjepartsverifikationer bliver let overset, fordi websitet stadig virker efter skiftet.
Ved navneserverskift:
Bekræft gyldigt certifikat mellem klient/CDN og origin efter den valgte model. Test både root og www, IPv4/IPv6 hvis begge annonceres, og alle redirectvarianter. Et certifikatproblem skal løses ved det led, der præsenterer det, ikke med en mere lempelig global SSL-indstilling.
Et website kan se rigtigt ud, selv om en DNS-flytning har brudt mail, kalender, helpdesk eller domæneverifikation. Derfor skal zonekontrollen udføres som en egentlig diff og ikke som et hurtigt blik på A-recorden. Kontroller mindst:
Test indgående og udgående mail med en godkendt testkonto efter skiftet, men publicer ikke adresser, headers med persondata eller hele DNS-zonen. En screenshotguide bør vise felttyper og redigerede eksempelværdier, mens maskinbeviset gemmer den interne før/efter-diff.
Sænk kun TTL, hvis det sker i god tid før flytningen og passer til den eksisterende DNS-model. Notér starttid, ansvarlig, gamle nameservers og et tidspunkt, hvor ændringen rulles tilbage, hvis web, mail eller certifikat ikke består testen. Et stopkriterium kan være gentagne TLS-fejl, manglende MX-opslag, en forkert origin eller at den nye zone ikke er ens på de autoritative nameservers.
Under propagation kan forskellige resolvere se forskellige svar. Det er derfor ikke nok, at administratorens egen browser virker. Sammenlign autoritativt svar, mindst to uafhængige resolvere og en mobil forbindelse. Ændr ikke flere records, mens den første fejl endnu ikke er klassificeret; ellers bliver det uklart, hvilken ændring der skabte eller løste problemet.
Som anonym bruger skal X-QC-Pop vise, at requesten er leveret via et QUIC.cloud PoP. X-QC-Cache kan vise hit/miss efter siden og planen. Sammenlign også X-LiteSpeed-Cache, cache-control, age, vary og redirectkæde.
Et PoP-header beviser CDN-ruten, men ikke at alle sider bør caches. Login, konto, kurv og checkout skal fortsat følge deres dynamiske bypassregler.
CCSS, UCSS og VPI deler page-optimization-flow og quota. Aktiver én funktion på staging, følg request/queue i LiteSpeed og QUIC.cloud-dashboard, og test layoutet før næste. Quotaudløb er ikke samme fejl som en blokeret callback.
Ved en fastlåst kø bruges guiden om CCSS/UCSS-kø. Ved forbindelsesfejl bruges domæneguiden.
Hvis Cloudflare eller en anden proxy allerede er aktiv, skal rollerne defineres. To CDN'er kan bruges i et dokumenteret integrationsflow, men ikke ved blot at stable proxyer og page cache. Bevar den eksisterende Cloudflare vs. QUIC.cloud-sammenligning som ejer af produktvalget; denne artikel handler kun om QUIC.cloud-implementering.
“Vi vil bruge billedoptimering og UCSS.” Det er et Online Services-valg. Start med WordPress-parring, REST/callback og en enkelt ufølsom service-request. Der er ingen grund til at flytte nameservers alene for at nå dette mål.
“Vi vil have QUIC.cloud til at levere webtrafikken.” Det er et CDN- og DNS-projekt. Ud over integrationen skal du kortlægge origin, certifikat, mailposter, TTL, cachegrænser og sikker rollback. Planlæg det som en driftsændring, ikke som næste knap efter Online Services.
Denne adskillelse er også nyttig ved fejl. Hvis Integration Enabled mangler, er nameservers sjældent første løsning. Hvis integrationen er aktiv, men X-QC-Pop aldrig vises på et hostname, ligger spørgsmålet senere i CDN-, DNS- eller leveringskæden.
Ved et nameserverskift kopieres hele zonen, men en mailpost eller DKIM-værdi bliver overset. Websitet kan se korrekt ud, mens indgående mail eller signering fejler. Kontroller derfor zonen efter funktion før delegation: A/AAAA/CNAME til web, MX, SPF, DKIM, DMARC, verifikationer og særskilte tjenester. Del aldrig de fulde tokenværdier i screenshots.
Efter skiftet testes funktionerne hos deres respektive ejere. En webrequest kan ikke bevise maillevering, og en grøn DNS-status i dashboardet beviser ikke, at checkout eller callbacks virker. Hvis stopkriteriet rammes, rulles nameservers eller den konkrete post tilbage efter den aftalte plan; undgå improviserede delvise rettelser midt i udbredelsen.
www, certifikat og redirects matcher baseline efter CDN-skift.X-QC-Pop; cachebare requests viser forventet miss/hit-flow.Ved Online Services-fejl deaktiveres den senest aktiverede service og dens relevante genererede cache purges. Ved CDN-fejl slås CDN fra efter QUIC.clouds flow, og DNS gendannes til de gemte records/nameservers. Bevar zonen og logs, indtil alle resolvere, web og mail er verificeret. En DNS-rollback er ikke øjeblikkelig på grund af caches/TTL.
Hosting skal bekræfte origin-IP, firewall, REST/loopback og certifikat. QUIC.cloud skal have domain-ID, fejltidspunkt, node-/requeststatus og redigerede headers — aldrig nøgler eller fulde DNS-hemmeligheder. Se LiteSpeed hosting hos Hostious ved originrelateret driftshjælp.
Kun hvis du vil bruge selve CDN’et. Billedoptimering, Critical CSS, UCSS og VPI kører via Online Services uden DNS-ændringer. Flyt først nameservere, når zonen er eksporteret, og rollback-planen er på plads.
Tjek svarets headers for X-QC-Pop. Viser en anonym request headeren, leveres siden fra QUIC.clouds edge. Test også login, formularer og eventuel checkout, så du fanger funktioner, der ikke må caches.
Der er en gratis kvote, som rækker til mindre sites – og LiteSpeed-servere får ekstra. Store billedmængder eller meget trafik kræver credits, så hold øje med forbruget i QUIC.cloud-dashboardet.
Gem status før og efter for Online Services, men beskær konto-id, domæneidentitet og kvotedata. Hvis CDN vælges, suppleres med en redigeret DNS-diff, certifikatkontrol og headers fra samme hostname. X-QC-Pop eller andre ægte leveringssignaler skal komme fra din egen request; de må ikke erstattes af en syntetisk illustration.
Skriv tidspunkt, TTL, nameserverstatus, stopkriterium og rollback ned før DNS-skiftet. Eftertesten skal omfatte forside, login, formularer og eventuel checkout samt mail- og verifikationsposter. Det gør det muligt at rulle tilbage uden at gætte, hvis webtrafikken virker, men en sidefunktion eller anden DNS-tjeneste fejler.