Kort svar: Kontrollér først, om køen reelt står stille, eller om “URLs i kø” blot tæller flere variationer end “Pages Cached”. I FlyingPress 5+ henter cloudservere siderne og renderer dem, så websitet og WordPress REST API skal være offentligt tilgængelige. Kør den indbyggede REST-test, kontroller URL-status og firewallblokering af User-Agent med “FlyingPress”, og hæv ikke concurrency, før adgang og origin er stabile.
En preload-kø kan se fastlåst ud af flere grunde: siden er ikke tilgængelig udefra, REST API er blokeret, optimizerens request rammer en firewall, en URL returnerer fejl, eller origin kan ikke følge med. Nogle gange er der slet ikke en fejl – tællerne beskriver forskellige enheder.
I FlyingPress version 5 og nyere bliver sider hentet af FlyingPress' cloudservere og renderet i en browser. Det gør offentlig reachability og REST-kommunikation til en del af preloadkæden.
Versionsgrundlag: Trinene er gennemgået den 28. august 2026 mod WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151. Selve fejlscenariet skal reproduceres på staging eller en sikkert afgrænset URL, før du ændrer preload på et aktivt website. Gem køstatus, REST-test, HTTP-status og firewall-/originbevis som din egen sags dokumentation.
På denne side
Notér køens tal og tidspunkt, vent et rimeligt interval uden at ændre indstillinger, og genindlæs visningen. Sammenlign:
At køtallet er større end antal cachede sider betyder ikke automatisk, at sider mangler. Et website kan have queryvariationer, mobile varianter eller andre URL-former, som behandles separat.
Tag et screenshot og gem tallene. Klik ikke gentagne gange på Purge & Preload; hver fuld purge kan nulstille brugbar cache og sende nye uncached requests mod origin.
Skriv tre målepunkter med fem minutters mellemrum: klokkeslæt, Pages Cached, URLs in Queue, antal fejl og den næste konkrete URL, du følger. Hvis køen eksempelvis går fra 120 til 91 til 63, mens samme test-URL skifter fra kø til cache og ingen 4xx/5xx opstår, arbejder systemet. En stor forskel mellem tællerne er ikke i sig selv et stopkriterium.
Hvis alle tre rækker er identiske, vælger du én URL og følger den hele vejen. Kontroller først offentlig status og body, dernæst REST-test og til sidst en matchende access-/WAF-hændelse. Ændr kun det lag, hvor beviset stopper. På den måde undgår du at hæve concurrency for en URL, der i virkeligheden bliver afvist med 403.
| Signal i kø eller log | Sandsynlig årsag | Næste sikre kontrol |
|---|---|---|
| Tallet falder langsomt, og der kommer ingen fejl eller gentagne URL'er | Normal behandling af flere URL-varianter, ikke en fastlåst kø | Gem tre tidsstemplede målinger og kontroller, om konkrete stier går fra kø til cache |
| Køen står helt stille, og den indbyggede REST-test fejler | REST-endpointet bliver afvist, omdirigeret eller blokeret | Gem testsvaret og hent samme endpoint uden adminsession; match status og tidspunkt mod sikkerhedsloggen |
| De samme URL'er får 403 eller 429 igen og igen | WAF, rate limit eller adgangsregel afviser optimizerens requests | Find én matchende event med sti og User-Agent, og afprøv kun den mindst mulige tilladelse |
| Preload-requests når origin, men ender i 5xx eller timeout | PHP, database eller worker-kø kan ikke levere den kolde side stabilt | Test én berørt URL uncached og sammenhold requesttidspunktet med PHP-, webserver- og ressourcebevis |
| Problemet findes kun på staging bag login eller Basic Auth | Testmiljøets adgangsværn stopper den eksterne cloudbrowser | Bevar beskyttelsen; brug en godkendt, ikke-følsom test-URL eller dokumentér miljøbegrænsningen |
| Gamle redirects, 404'er eller parametervarianter vender tilbage i køen | Sitemap, internt link eller custom filter føder køen med forkerte URL'er | Spor én URL tilbage til kilden, ret den dér og kontroller den næste køkørsel uden fuld purge |
| Køen starter forfra efter hvert kontrolforsøg | Gentagne Purge & Preload nulstiller arbejdet | Stop manuelle purges, gem starttid og følg én uændret kørsel, før andre indstillinger vurderes |
Vælg én URL fra køen og hent den som anonym bruger uden admincookies. Kontrollér:
Hvis URL'en returnerer 404, 403, 429 eller 5xx, skal den underliggende årsag rettes eller URL'en fjernes fra den kilde, der køsætter den. Et højere antal preload-workers løser ikke en afvist eller defekt URL.
FlyingPress bruger WordPress REST API til preloadkommunikation. I Tools → FlyingPress Queue bruges den indbyggede Test REST API.
Gem hele resultatet og tidspunktet. Hvis testen fejler:
Deaktivér ikke al REST-beskyttelse på live. Lav en minimal regel, der tillader den dokumenterede FlyingPress-kommunikation, og behold beskyttelsen for endpoints, der ikke behøver offentlig adgang.
Cloudserveren kan ikke optimere en staging-side bag HTTP Basic Auth uden en understøttet adgangsmetode. Det samme gælder maintenance mode, loginwall, IP-whitelist eller en browserchallenge.
Vælg den sikre løsning efter miljøet:
En stagingblokering er ikke nødvendigvis et produktionsproblem. Dokumentér miljøforskellen.
FlyingPress dokumenterer, at man kan tillade requests med en User-Agent, der indeholder FlyingPress. Der bruges ikke en stabil liste af faste IP-adresser, som bør hardcodes.
Før du opretter en regel:
En global “skip all security” for enhver User-Agent-streng er for bred. Brug WAF'ens mindst privilegerede handling, og bevar logning.
Hvis requests når origin, men returnerer 5xx eller tager meget lang tid, så match dem mod:
Test samme URL manuelt uden cache. Hvis den også er langsom, er preload kun budbringeren. Brug TTFB-guiden eller 502-guiden afhængigt af beviset.
FlyingPress kan opdage og køsætte URLs fra sitets indhold og konfiguration. Hvis køen gentagne gange indeholder redirectede, duplikerede eller defekte URLs, skal de rettes ved kilden:
Ekskludér ikke en hel sektion for at skjule en enkelt defekt kilde. Ret linket eller filteret, og bekræft at den endelige URL returnerer korrekt status.
FlyingPress' dokumenterede standard og sikreste concurrency er 1. Højere concurrency kan gøre opvarmningen hurtigere, men øger samtidig belastningen på origin. Hvis køen står stille på grund af adgang eller fejl, hjælper concurrency ikke.
Når adgang, REST og URL-status er dokumenteret sunde, kan du teste et lille trin op på staging eller i et roligt vindue:
Der findes også en preload-delay mellem sider. Reducér den ikke uden ressourcebevis; på en mindre origin kan en større pause være mere stabil.
Brug Preload cache, når eksisterende sider ikke skal fjernes, men manglende/udløbne sider skal opvarmes. Brug Purge & Preload, når en ændring kræver, at hele den relevante cache genopbygges. En fuld purge er ikke et diagnostisk “prøv igen”-værktøj.
Ved rettelse af én side eller exclusion skal du vælge URL-specifik purge/regenerering, hvis det er tilstrækkeligt. Det reducerer risikoen for en cold-cache-bølge.
Fejlen er løst, når:
Test til sidst som anonym bruger fra en ny session. En grøn adminvisning er ikke nok.
Lav også en funktionskontrol på mindst én kompleks skabelon. Åbn menu og formular, og gennemfør en sikker WooCommerce-kurv, hvis sitet har shop. Preload er ikke vellykket, hvis den blot producerer hurtige, men forældede eller sessionsblandede sider. Sammenlign en lille synlig stagingændring før og efter URL-specifik purge, så du ved, at cacheinvalideringen når det lag, der leverer HTML.
Gendan concurrency, delay, WAF-regel eller custom preload-filter til den gemte startværdi, hvis ændringen ikke hjælper. Fjern kun den regel, du selv tilføjede, og kontroller at den øvrige sikkerhed er intakt.
Kontakt hosting/WAF-administrator med tidspunkt, sti, status, request-id og den konkrete blokeringsregel. Kontakt FlyingPress-support med pluginversion, REST-testresultat, en anonymiseret URL, køstatus og relevante logs. Hostious WordPress-support kan samle en sikker reproduktion uden at dele credentials.
Gem køstatus, REST-testoutput, headers eller body-hash, WAF-event-id, accesslog-request-id og ressourcegraf. Et syntetisk stagingforløb dokumenterer kun den afprøvede fejlmekanisme; det er ikke CrUX-, Lighthouse- eller produktionsbevis. Fjern origin-IP, cookies, tokens og private URL'er.
I FlyingPress 5+ renderes siderne af cloudservere – så sitet og REST API’et skal kunne nås udefra. Blokerer firewall, bot-beskyttelse eller htpasswd adgangen, kommer køen aldrig videre.
‘URLs i kø’ tæller også mobil-/desktopvariationer, så tallet kan være større end antal sider. Sammenlign over tid: falder Pages Cached ikke, mens køen er stor, er den reelt gået i stå.
Nej – fuld purge tømmer den cache, dine besøgende får gavn af nu. Ret først adgangs-/firewallproblemet, og lad preload bygge videre på den eksisterende cache.
