Kort svar: Ved Error 524 har Cloudflare allerede forbindelse til origin, men får ikke et HTTP-svar inden proxyens tidsgrænse. Find den præcise langsomme handling i access-, PHP- og databaseloggen: import, backup, rapport, billedjob, checkout eller et fastlåst plugin-kald. Flyt langvarige jobs til kø eller CLI, og optimer den konkrete forespørgsel. En højere timeout er sjældent den egentlige løsning og er ikke tilgængelig på samme måde på alle planer.
Risiko: Middel til høj Forventet tid: 30 minutter til flere timer Hav klar: URL, tidspunkt, Ray ID, PHP-/databaseprofilering og en frisk backup før kodeændringer
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Arbejdsgangen er fagligt gennemgået; Hostious er ikke bag Cloudflare, og ingen 524 er fremprovokeret i produktion. Et syntetisk stagingforløb kan vise en langsom request, men er ikke Cloudflare- eller produktionsbevis.
524 er en ventetidsfejl efter en vellykket forbindelse. Det fortæller to ting: Cloudflare kunne nå origin, og origin accepterede requesten. Problemet opstår bagefter, fordi serveren ikke leverer et HTTP-svar hurtigt nok. Cloudflares aktuelle standard for Proxy Read Timeout er 125 sekunder; write-timeouts har andre grænser. Brug værdien som diagnose, ikke som et mål for, hvor længe en webrequest bør køre.
På denne side
Notér URL, HTTP-metode, tidspunkt, tidszone og Ray ID. Hvis fejlen sker i wp-admin, gem navnet på handlingen og omtrent datamængde. Hvis det er checkout, må screenshots og logs ikke vise kunde-, ordre- eller betalingsdata.
| Mønster | Sandsynlig årsag | Sikker kontrol | Næste skridt |
|---|---|---|---|
| Én import/export fejler | Jobbet kører synkront for længe | Mål varighed og log sidste gennemførte trin | Del jobbet op eller kør via kø/CLI |
| Checkout rammer 524 | Gatewaykald, webhook, lager- eller plugin-hook | Tidslinje uden persondata; PHP slow log | Isolér det langsomme kald |
| Mange dynamiske sider rammes | Database, PHP-workers eller IO under pres | Ressource- og slow-query-data | Ret fælles flaskehals |
| Kun wp-admin-rapport fejler | Stor query eller eksport | Kør med mindre interval/datasæt | Paginer eller generér asynkront |
| Fejlen begyndte efter pluginændring | Ny synkron hook eller ekstern request | Rollback på staging og tidsmåling | Ret eller fjern den konkrete ændring |
Find requesten i accessloggen og forbind den med PHP slow log eller applikationslog. Kig efter den sidste registrerede handling før timeout. Hvis databasen har slow-query-log eller APM, find den forespørgsel, der fylder tidslinjen.
Mål mindst:
En 524-side i browseren betyder ikke nødvendigvis, at origin stoppede arbejdet. Et importjob kan fortsætte og blive startet igen af brugeren, hvilket skaber dubletter. Kontrollér job- eller ordrestatus, før du trykker igen.
Importer, backupper, billedoptimering og store rapporter bør normalt ikke holde en browserrequest åben. Del datamængden op i mindre batches, og gem fremdrift mellem hvert trin. Vis brugeren en jobstatus i stedet for at vente på det færdige resultat.
På WordPress kan en etableret jobkø eller WP-CLI være bedre end en lang admin-request. Sørg for idempotens: et job, der starter igen, må ikke oprette de samme data to gange. Log job-id, start, sidste checkpoint og slutstatus uden persondata.
Hvis slow log peger på en databasequery, skal den undersøges for manglende indeks, ubegrænset datasæt, dyre wildcard-søgninger eller gentagne opslag i en løkke. Begræns resultatet og paginer. Tag databasebackup før indeks- eller strukturændringer, og afprøv på staging med en realistisk datamængde.
Hvis et plugin-hook er langsomt, kontrollér om det kalder en ekstern API synkront. Sæt en kort, begrundet timeout, håndtér fejl, og flyt ikke-kritisk arbejde til baggrunden. Checkout må eksempelvis ikke vente på en marketingintegration, der kan køres efter ordren er gemt.
Ved 524 under betaling må brugeren ikke blot få besked på at prøve igen. Betalingen kan være gennemført, selv om browseren ikke fik svaret. Kontrollér gatewayens transaktion, WooCommerce-ordrenoter og callback/webhook før et nyt betalingsforsøg.
Deaktivér kun den konkrete langsomme integration på staging eller i et vedligeholdelsesvindue. Efter rettelsen skal du teste med gatewayens testtilstand eller et godkendt lavrisikoflow; ingen rigtige betalingsdata må bruges i artiklens beviser.
Cloudflares muligheder for at ændre Proxy Read Timeout afhænger af plan og konfiguration. Selv når det er muligt, gør en længere grænse ikke en langsom request sund. Den kan øge antallet af samtidige workers og gøre et kapacitetsproblem værre.
Overvej kun en justering, når processen er kendt, begrænset, idempotent og ikke kan flyttes ud af HTTP-flowet. Dokumentér den oprindelige værdi og sæt den mindste nødvendige ændring. En separat DNS-only subdomæne til et administrativt job kan også eksponere origin og skal ikke oprettes som hurtig genvej.
Import eller eksport: Del arbejdet i batches, og lad browseren få et job-id og en status i stedet for at holde én HTTP-forbindelse åben. Gem batchstørrelse, samlet antal poster og fejl pr. batch. Hvis et job kan genoptages efter afbrydelse, undgår du både 524 og risikoen for at starte hele importen forfra.
Backup, billedbehandling eller rapport: Disse opgaver hører som regel til i en kø, en planlagt proces eller CLI. En brugerrequest kan oprette jobbet og vende tilbage hurtigt. Kontroller at kørunneren faktisk arbejder, og at adgang til resultatet er beskyttet; det er ikke nok at flytte timeouten fra browseren til et usynligt baggrundsjob, der aldrig afsluttes.
Checkout eller formular: Her er idempotens vigtigere end tålmodighed. En bruger kan klikke igen, når 524 vises, selv om origin eller gateway fortsætter. Brug en testordre og følg ordre-id, betalingsforsøg og callback. Den færdige løsning skal give et entydigt svar eller en sikker statusvisning uden at skabe dobbeltbetaling, dobbeltordre eller to mails.
Adminside med tung forespørgsel: Find den konkrete query eller hook og mål den med samme input. Pagination, indeks, caching af en ufølsom beregning eller mindre datamængder kan være rigtige løsninger. At hæve PHP execution time uden profilering flytter blot den øvre grænse.
En vigtig 524-egenskab er, at Cloudflare kan have opgivet at vente, mens origin fortsætter. Kontroller derfor ikke kun brugerens browser. Se om jobbet stadig kører, om data blev gemt, og om et nyt forsøg vil være sikkert. Først derefter kan du beslutte, om brugeren skal prøve igen.
Et praktisk supportnotat bør svare på tre spørgsmål: Fik origin requesten? Fuldførte origin handlingen? Fik brugeren et entydigt resultat? Kombinationen “ja, ja, nej” kræver et andet design end “ja, nej, nej”. Den første handler om status og idempotens; den anden om selve den langsomme behandling.
Gendan den seneste kode-, plugin- eller databaseændring fra den afgrænsede backup. Hvis et job blev flyttet til kø, skal du kunne slå den nye runner fra uden at miste checkpoints. Rul en timeoutændring tilbage til den dokumenterede værdi, hvis den blot flytter fejlen eller øger serverpresset.
Hosting skal levere slow logs, worker-, database- og IO-data. En udvikler skal ændre synkrone jobs, queries og hooks. Ved checkout skal gatewayleverandøren inddrages, hvis tidslinjen viser et langsomt eller tvetydigt betalingskald. WooCommerce-hosting hos Hostious kan være relevant, når drift og checkout skal undersøges samlet.
At origin var forbundet, men ikke leverede et HTTP-svar inden for Cloudflares tidsgrænse (100 sekunder på de fleste planer). Altså: noget på serveren arbejder for længe.
Imports, rapporter, backups, billedgenerering og tunge databasequeries – ofte startet fra wp-admin. Access- og slowquery-loggen på samme tidspunkt viser den konkrete synder.
Flyt langvarigt arbejde ud af requesten: kør det via WP-CLI eller cron, del det op i bidder, og optimér den langsomme query. En højere timeout skjuler kun problemet – og Cloudflares grænse flytter sig ikke.
Start med en enkel tidslinje: brugerens klik, requestens start, tidspunktet hvor 524 blev vist, og hvad serveren fortsatte med bagefter. Knyt access log, PHP slow log, databaseforespørgsel og eventuel køstatus til den samme request. Fjern kunde-, ordre- og serveridentitet, men bevar varighed, endpoint og den komponent, der ejer arbejdet.
Ved import, eksport og billedbehandling skal førtesten beskrive datamængden. “Tog 40 sekunder efter rettelsen” betyder intet, hvis første test havde 10.000 rækker og anden test 100. Ved checkout dokumenteres i stedet gatewaykald, ordrestatus og om et nyt klik kan skabe en dobbelt handling. Brug kun gatewayens testtilstand og en dedikeret testordre.
Den bedste eftertest viser, at den offentlige request returnerer hurtigt, mens det lange arbejde fortsætter sikkert i en kø eller er blevet konkret optimeret. Gem både brugerens respons og jobstatus. Hvis løsningen var en queryændring, registreres samme input, querytid og resultat før og efter. En længere proxytimeout er kun et driftsvalg; den må aldrig præsenteres som bevis for, at den langsomme kode er blevet sund.
