Kort svar: En 522 betyder, at Cloudflare ikke fik forbindelsen til origin etableret eller bekræftet i tide. Fejlen ligger typisk i netværk, firewall, overbelastning eller en forkert origin-destination — ikke i browsercachen. Gem URL, tidspunkt, Ray ID og datacenter. Få derefter hosting til at kontrollere Cloudflare-IP'er, TCP-fejl, serverbelastning og routing. Skift ikke permanent til DNS only; det skjuler proxyproblemet og eksponerer origin.
Risiko: Middel til høj Forventet tid: 30-90 minutter Hav klar: Ray ID, fejltidspunkt, hostingkontakt og adgang til firewall-/netværksdata
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Diagnosemetoden er fagligt kontrolleret, men Hostious er ikke bag Cloudflare, og der er ikke skabt en 522 mod Hostious-produktion. Syntetisk staging kan illustrere statusvisningen, ikke dokumentere et reelt netværksforløb.
Cloudflare bruger 522, når kontakten til origin ikke kommer ordentligt i gang. Det kan ske før TCP-forbindelsen er etableret, eller efter forbindelsen, hvis origin ikke bekræfter Cloudflares request i tide. Det adskiller sig fra 521, hvor forbindelsen aktivt bliver afvist, og fra 524, hvor forbindelsen er etableret, men selve HTTP-svaret tager for lang tid.
På denne side
Test fra mere end ét netværk, men undgå at hamre på en presset server. Notér om fejlen gælder alle URL'er, bestemte paths eller bestemte tidspunkter.
| Mønster | Sandsynlig retning | Kontrol | Næste skridt |
|---|---|---|---|
| Alle URL'er viser 522 | Netværk, firewall eller origin nede/overbelastet | Service-, load- og TCP-kontrol | Hosting undersøger origin og routing |
| 522 kommer i trafikspidser | For få forbindelser, CPU/IO-pres eller rate limit | Sammenlign ressourcegraf med Ray-tider | Fjern flaskehals eller skaler ansvarligt |
| Kun enkelte Cloudflare-datacentre | Routing mellem origin og Cloudflare | MTR/traceroute fra origin mod relevant Cloudflare-IP | Netværksleverandør undersøger ruten |
| Kun ét hostname | Forkert A/AAAA/Origin Rule | Sammenlign destinationer og vhost | Ret den specifikke routing |
| Direkte test virker, proxied timer ud | Cloudflare ranges blokeret eller dårlig returvej | Firewalllog og routekontrol | Ret allowlist/routing, bevar proxy |
Cloudflares dokumentation skelner mellem to 522-forløb: manglende SYN+ACK under etableringen og manglende ACK på requesten efter en etableret TCP-forbindelse. Tidsgrænserne er et diagnostisk signal, ikke noget du bør forsøge at “løse” med en WordPress-indstilling.
Hvis origin slet ikke svarer, start ved port, firewall og routing. Hvis forbindelsen bliver etableret, men serveren ikke bekræfter requesten, er kø, overload eller et sikkerhedslag mere sandsynligt. Cloudflare Error Analytics eller Origin Analytics kan, afhængigt af kontoadgang, hjælpe med at skelne TCP-fejl fra path-specifikke fejl.
Se CPU, hukommelse, disk-I/O, antal samtidige forbindelser og webserverens worker-kø på de præcise fejltidspunkter. Et lavt gennemsnit udelukker ikke korte spikes. Brug minut- eller sekunddata, hvis de findes.
Find derefter årsagen til belastningen:
At hæve alle grænser er ikke en sikker løsning. Hvis en proces er defekt, gør flere workers blot presset større. Stop eller flyt den konkrete baggrundsopgave, og mål derefter igen.
Cloudflare-forbindelser skal kunne nå origin på den relevante webport. Hosting bør gennemgå drop- og timeout-hændelser og sikre, at den aktuelle officielle Cloudflare-IP-liste er tilladt.
Samtidig skal origin gendanne den oprindelige besøgende-IP fra en betroet Cloudflare-header. Hvis rate limiting kun ser Cloudflares edge-IP, kan mange besøgende blive behandlet som én aggressiv klient. Korrekt real-IP-konfiguration er serverspecifik og skal udføres dér — ikke ved at stole på vilkårlige klientheaders fra hele internettet.
Bekræft den destination, Cloudflare faktisk bruger. En gammel A-post, en aktiv AAAA-post uden fungerende IPv6-webservice eller en Origin Rule kan sende trafikken et andet sted hen end forventet.
Lav en liste over alle records for det fejlende hostname, og sammenhold dem med hostingens aktuelle destination. Hvis du fjerner eller ændrer en post, gem den oprindelige værdi og test både IPv4 og IPv6-adfærd. Publicér aldrig origin-adressen i screenshots.
Hvis fejlen kun opstår fra bestemte Cloudflare-lokationer, bør hosting finde en Cloudflare-IP, som kontaktede origin omkring fejltidspunktet, og køre MTR eller traceroute fra origin mod den. Det er returvejen, der ofte overses. En traceroute fra din egen computer beviser ikke, hvordan serveren når Cloudflare.
Gem paketab og hop som intern driftsevidens, men maskér origin-IP og netværksnavne i publiceret materiale. Netværksleverandøren kan bruge den fulde rapport privat.
DNS only kan få en side til at virke, hvis problemet er specifikt for ruten til Cloudflare, men den direkte trafik kan ramme en origin, der ikke er dimensioneret eller beskyttet til det. Desuden bliver origin-adressen offentlig i DNS.
Brug kun en kortvarig diagnose efter aftale med hosting, når offentligt certifikat, kapacitet og firewall er klar. Gendan orange proxy-status, og kontrollér at DNS igen svarer med Cloudflare-adresser.
En 522, der opstår hvert femte minut, skal undersøges anderledes end en fejl, der kun opstår under kampagnetrafik. Regelmæssige intervaller kan følge backup, cron, logrotation eller en overvågning, der bruger mange forbindelser. Belastningsspidser peger mod worker-, forbindelses- eller I/O-grænser. Fejl fra ét Cloudflare-datacenter, mens andre virker, gør rute og peering mere relevant.
Lav derfor en lille tidsserie med mindst fem hændelser, hvis fejlen er tilbagevendende. Skriv Ray ID, datacenter, path og om origin havde en accepteret forbindelse. Sammenhold med samtidige forbindelser, kølængde, CPU, memory pressure og I/O — ikke kun et gennemsnit over hele dagen. En server kan se “20 % belastet” ud i et femminutters diagram og stadig have været helt fastlåst i ti sekunder.
Forestil dig, at en produkt- og forside svarer normalt, mens checkout sporadisk giver 522. Det beviser ikke, at WooCommerce-koden er årsagen. Checkout kan blot åbne flere PHP- og databaseforbindelser og dermed udløse en eksisterende kapacitets- eller firewallgrænse. Første kontrol er, om TCP-forbindelsen blev etableret og requesten nåede webserveren. Hvis der ingen accessloglinje er, skal netværkslaget undersøges før checkoutkoden. Hvis requesten nåede PHP og derefter var langsom, ligner sagen mere 524 eller en anden applikationsfejl.
Hvis domænet har både A og AAAA, kan en forkert eller forældet IPv6-destination skabe et ujævnt mønster. Sammenlign svar og rute for begge protokoller uden at slette AAAA som første handling. Ret adressen eller den manglende service, og kontroller derefter at begge familier når samme tiltænkte miljø. Dokumentér forskellen; ellers kan en senere DNS-ændring genindføre fejlen.
Et enkelt 200 OK efter en genstart viser kun, at origin svarede på det tidspunkt. Det beviser ikke, at forbindelsesgrænsen, ruten eller firewallmønstret er rettet. Gentag det oprindelige scenarie, følg fejlraten over et relevant vindue, og kontroller samtidig at legitim trafik stadig får korrekt klient-IP og sikkerhedsbehandling.
Gendan den senest ændrede DNS-post, firewallregel eller connection limit, hvis eftertesten bliver dårligere. Hvis en proces blev stoppet, genstart den kun i et kontrolleret vindue med overvågning. Dokumentér den faktiske årsag; ellers vender 522 ofte tilbage ved næste trafikspids.
Hosting eller netværksleverandør skal håndtere 522, når der kræves TCP-log, firewallindsigt, MTR eller kapacitetsdata. En udvikler er relevant, hvis en WordPress-baggrundsproces konsekvent udløser belastningen. Læs om WordPress-hosting hos Hostious, hvis du vil have origin og applikation vurderet sammen.
521 er en aktiv afvisning – origin siger nej. 522 er en timeout – origin svarer slet ikke i tide. 522 peger derfor oftere på overbelastning, netværksproblemer eller droppede pakker i firewallen.
Ja – når serveren er så presset, at TCP-forbindelsen ikke bekræftes i tide. Tjek CPU, RAM og antal samtidige forbindelser på fejltidspunktet, og se om mønstret følger trafikspidser.
Verificér origin-IP’en i Cloudflares DNS-panel – især efter en flytning. En glemt gammel IP giver præcis dette billede: Cloudflare venter på en server, der ikke længere svarer.
En 522-sag skal have en tidslinje, ikke kun et billede af fejlsiden. Gem Ray ID, Cloudflare-datacenter, hostname og tidspunkt med tidszone. Læg derefter serverens forbindelses-, firewall- og ressourceobservationer for det samme minut ved. Hvis CPU-grafen topper femten minutter senere, er den ikke forklaringen på den konkrete request.
Notér om fejlen ramte alle hostnames, kun IPv6, kun ét datacenter eller kun perioder med belastning. En serie på tre til fem kontroller med samme interval er mere brugbar end én tilfældig succes. Ved routingmistanke kan hosting gemme et redigeret ruteresumé; adresser og interne hop bør ikke ligge i et offentligt screenshot.
Efter en rettelse skal både forbindelsesraten og selve WordPress-responsen kontrolleres. Tre hurtige 200-svar viser ikke alene, at fejlen er væk, hvis problemet kun opstod under samtidige requests. Gentag derfor det oprindelige belastnings- eller tidsmønster i en sikker test og kontroller, at firewall og rigtig klient-IP stadig fungerer. Skriv præcist hvilken regel, service eller destination der blev rettet, så sagen kan genåbnes uden ny grundanalyse.
