Kort svar: Afgør først, om fejlen sker ved WordPress-parring, kontotilknytning, REST/callback eller CDN-DNS. I LiteSpeed Cache v7 bruges General → Online Services → Enable QUIC.cloud Services; det gamle Domain Key-flow er udfaset. Kontroller derefter, at WordPress REST API er offentlig tilgængelig, QUIC.cloud-IP'er ikke blokeres, og proxyen ikke skjuler forkert origin. Ændr ikke nameservers for at reparere en parring, der fejler før CDN-trinnet.
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; forbindelsesstatus, callback og kontoejerskab skal aflæses i den konkrete konto.
“Kan ikke forbinde” er ikke én status. Skriv den synlige fejltekst, tidspunkt og det sidste gennemførte trin ned. Hvis WordPress allerede viser Integration Enabled, men CDN ikke leverer trafik, ligger fejlen efter parringen og hører til DNS/CDN-verifikation.
På denne side
| Symptom/fejlpunkt | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Enable Services-knappen fejler | REST, outbound HTTPS eller adminredirect stopper | Site Health og UTC HTTP-log | Ret første fejlede forbindelsesled |
| QUIC.cloud kan ikke detektere server/IP | Origin er forkert eller maskeret | Reverse proxy og autoritativ Server IP | Brug dokumenteret proxyflow eller hostingværdi |
| Domænet knyttes til forkert/ingen konto | Gammel klon eller andet ejerskab | Konto, registreret site og domænestatus | Brug officielt unlink/relink-flow |
| Service requests bliver pending/failed | Callback, node eller quota fejler | REST, firewall, node og queue | Isoler den konkrete service/request |
CDN enabled, men ingen X-QC-Pop | DNS/proxy går uden om QUIC.cloud | Autoritativ DNS, redirect og headers | Ret CDN-ruten efter fungerende parring |
Gå til LiteSpeed Cache → General → Online Services. Brug Enable QUIC.cloud Services. Et gammelt Domain Key-felt eller tidligere tutorial-screenshot skal ikke styre en aktuel v7-installation. Genindlæs siden efter retur og kontroller, om integrationen faktisk er enabled.
Klik ikke gentagne gange og opret ikke flere konti. Gem den præcise fejl, før et nyt forsøg.
Bekræft at WordPress Address og Site Address bruger det endelige HTTPS-host. Test REST API og Site Health. Password protection, maintenance mode, basic auth eller sikkerhedsplugin kan blokere de callbacks, QUIC.cloud skal bruge.
Ret med en snæver tilladelse for de nødvendige endpoints og aktuelle dokumenterede IP'er. En midlertidig komplet deaktivering på staging kan bruges til isolation, men er ikke permanent løsning.
WordPress skal kunne starte HTTPS-forbindelsen, og QUIC.cloud skal kunne kontakte sitet. Se PHP-/HTTP API-log efter DNS-, TLS-, timeout- eller 403-fejl ved samme UTC-tid. Del ikke bearer tokens eller komplette request bodies.
Hvis origin-certifikatet er ugyldigt, ret certifikatkæden. Slå ikke TLS-verifikation fra i produktionskode.
En sikker isolation ændrer én kontrol ad gangen og har en slutdato. Start med en ufarlig QUIC.cloud-request, notér UTC-tid og find den i WordPress-, WAF- og originloggen. Hvis loggen viser 403, oprettes en snæver testregel til det dokumenterede endpoint og de aktuelle servicekilder. Hvis der ikke er nogen indgående request, undersøges DNS/rute og service-node før WordPress ændres.
Brug ikke “slå security plugin fra” som den endelige vejledning. På staging kan en kort deaktivering bekræfte ejerskab, men sammenlign før/efter-log og gendan straks. En korrekt løsning er endpoint-, metode- og kildebegrænset. Test efterfølgende, at en almindelig uvedkommende request fortsat bliver afvist.
| Maskinelt fund | Hvad det beviser | Sikker næste handling |
|---|---|---|
| Ingen request i edge/originlog | Fejlen ligger før WordPress | Kontroller node, DNS/rute og proxy |
| 401/403 på dokumenteret endpoint | Adgangslag blokerer | Snæver allowregel og retest |
| TLS-/hostnamefejl | Certifikat eller origin-host er forkert | Ret certifikat/SNI, bevar verifikation |
| 5xx med PHP-fejl-ID | WordPress/plugin fejler | Reproducer på staging og ret ejeren |
| 2xx, men UI forbliver pending | Callback/pickup eller statuslag | Match request-ID og lokal kø |
Efter migration eller staging-kloning kan gamle domain-, site- eller kontoreferencer følge med. Bekræft det synlige hostname, WordPress Address, Site Address og det domæne, QUIC.cloud viser, før unlink eller relink. En stagingkopi må ikke overtage live-domænets konto- eller CDN-status.
Ved permanent domæneskift dokumenteres gammel og ny ejer, forbindelsen afbrydes via det officielle flow, og cache-/servicefiler regenereres for det nye hostnavn. Kopiér ikke en token eller databaseværdi manuelt mellem sites. Hvis ejerskabet er uklart, stop og få kontoen verificeret; flere relink-forsøg kan gøre fejlhistorikken sværere at følge.
Cloudflare eller en anden proxy kan maskere den reelle server/IP og tierdetektion. Brug QUIC.clouds dokumenterede integrationsflow eller et kontrolleret midlertidigt bypassvindue. Kontroller Server IP i QUIC.cloud-dashboard mod hostingens autoritative værdi, men offentliggør ikke origin-IP.
Ved load balancing skal alle origins kunne modtage de samme callbacks og dele relevant WordPress-tilstand. En tilfældig node med forkert firewall giver intermitterende fejl.
Hvis forbindelsen tidligere virkede, men lokale QUIC.cloud service nodes er nede eller forældede, bruges den officielle redetect-kontrol i Current Cloud Nodes in Service. Gem før/efter node-status og test én ufarlig service request. Hardcod ikke en node-IP manuelt.
Kontroller først, om fejlen kun rammer én servicetype. Billedoptimering, page optimization og CDN-trafik følger ikke nødvendigvis præcis samme requestforløb. En fungerende billedrequest beviser derfor ikke, at CCSS-callback virker, og X-QC-Pop beviser ikke WordPress-parringen. Match altid status og log til den konkrete tjeneste, som fejler, og undgå en bred “QUIC.cloud er nede”-konklusion på baggrund af ét endpoint.
Hvis domænet allerede er knyttet til en anden konto eller en gammel klon, skal det officielle unlink/move-flow bruges. Slet ikke DNS eller domænedata, før CDN-status og rollback er afklaret. En udviklingskopi registreres som eget hostnavn, ikke som domain alias til live.
Online Services skal kunne aktiveres uden CDN-DNS. Når integrationen er enabled og kun CDN-trinnet mangler, følges QUIC.cloud-opsætningsguiden med zonebackup og X-QC-Pop-verifikation.
Der oprettes ingen forbindelse fra WordPress. Kontrollér først den aktuelle Online Services-knap, WordPress-adresser og udgående HTTPS. DNS-flytning kan ikke reparere en request, der aldrig forlader WordPress.
Kontoen kan ikke overtage eller finde domænet. Her er ejerskab, tidligere tilknytning eller en klonet database relevant. Sammenlign den viste konto og det kanoniske domæne. Opret ikke flere forbindelser i forskellige konti for at “prøve”; det gør ejerskabet mindre tydeligt.
Requesten sendes, men callback bliver afvist. Match UTC-tiden med REST-, WAF- og sikkerhedslog. En 401 eller 403 skal knyttes til en konkret regel eller autentificeringsforudsætning. Tillad kun den dokumenterede route og trafik, og bevar en negativ kontrol på andre beskyttede endpoints.
Integration er aktiv, men CDN leverer ikke. Det er et senere trin. Kontrollér, om CDN overhovedet er valgt, derefter DNS og ægte leveringsheaders. Online Services kan fungere uden CDN, så “ingen CDN-header” er ikke i sig selv en fejl i parringen.
En stagingkopi er lavet fra produktion og indeholder gamle integrationsdata. Dashboardet forbinder domænet med en anden URL, eller requests ser ud til at komme fra forkert miljø. Stop før re-detect eller DNS. Dokumentér begge WordPress-adresser, miljøets rolle og hvilken konto der ejer produktionsdomænet. Fjern eller nulstil kun stagingens integrationsbinding efter backup og efter den aktuelle officielle arbejdsgang; produktionens konto må ikke overtages ved et uheld.
Send den ordrette fejltekst, LiteSpeed Cache-version, WordPress Site/WordPress Address, UTC-tid, sidste vellykkede trin og redigeret HTTP-status. Til QUIC.cloud hører domain/report-id i en privat sag; til hosting hører den matchende firewall-, REST- eller outbound-hændelse. Undlad screenshots af hele kontoen og hemmelige nøgler. Jo præcisere trin, desto mindre risiko for, at nogen foreslår et nameserverskift til et problem, der ligger før DNS.
X-QC-Pop; ikke-CDN-brugere har ikke ændret DNS.Gendan tidligere sikkerheds-/proxyregel, hvis forbindelsen stadig fejler, og fjern midlertidige allowlists. Ved fejlagtig konto-linkning bruges Disconnect/Unlink efter QUIC.clouds flow; slet ikke domænet eller flyt DNS blindt. Ved CDN-rollback gendannes den gemte DNS-zone/nameservers med TTL-forbehold.
Hosting skal have UTC-tid, HTTP/TLS-fejl, redigeret endpoint og proxy/firewallbevis. QUIC.cloud skal have domain-/report-ID, node-status og den synlige fejl uden kontonøgler. Se LiteSpeed hosting hos Hostious ved originadgang.
Oftest fordi REST API’et eller callbacket blokeres af firewall eller sikkerhedsplugin, eller fordi sitet ikke er offentligt tilgængeligt (staging, htpasswd, vedligehold). QUIC.cloud skal kunne nå /wp-json/ udefra.
Under General → Online Services → Enable QUIC.cloud Services. Det gamle Domain Key-flow er udfaset – følg det nye flow, og godkend tilknytningen på QUIC.cloud-kontoen.
Ja, hvis firewall eller sikkerhedsplugin blokerer ukendte kald: hent den aktuelle IP-liste hos QUIC.cloud, og tillad dem i serverens firewall – ellers fejler både parring og senere tjenester sporadisk.
Gem den ordrette fejltekst, UTC-tid og det sidste trin, der lykkedes. Tilføj en redigeret REST-/HTTPS-status og den matchende firewall- eller serverhændelse. Konto-id, nodeadresser og sikkerhedstokens skal ikke deles i artikler eller åbne supportsager.
Efter rettelsen skal integrationsstatus genindlæses og stadig være aktiv, og én afgrænset service-request skal kunne gennemføres. Hvis CDN ikke er valgt, skal du ikke kræve en CDN-header som bevis. Dine egne dashboarddata i QUIC.cloud er altid facit – kontrollér status og quota dér.