Kort svar: Error 1020 “Access denied” betyder, at en firewall-regel i Cloudflare har blokeret requesten – den kommer aldrig fra WordPress selv. Find den konkrete hændelse under Security → Events (søg på den besøgendes IP eller Ray ID), se hvilken regel der udløste blokeringen, og lav en præcis undtagelse for det legitime mønster – i stedet for at slå reglen helt fra.
En kunde sender et screenshot: “Error 1020 – Access denied” med Cloudflare-logo og et Ray ID. Fejlen ligner en nedbrudt side, men er det modsatte: Cloudflare gjorde præcis, hvad en regel bad om – spørgsmålet er, om reglen ramte den rigtige. Denne guide finder reglen, vurderer den og retter den uden at åbne for det, den skulle beskytte imod.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026; Cloudflare-dashboardets stier er beskrevet pr. samme dato. Eksemplet i billedet er genskabt – det er ikke data fra hostious.io.
1020 er Cloudflares samlekode for “en firewall-regel sagde nej”: en custom WAF-regel, en managed ruleset, en IP- eller landeblokering. Requesten nåede aldrig din server – derfor står der intet i WordPress- eller serverlogs, og derfor kan du heller ikke fejlsøge den dér. Al dokumentation ligger i Cloudflare-dashboardet. Ser du derimod en 403 uden Cloudflare-branding, er det serveren eller et sikkerhedsplugin – så er det 403-guiden, du skal bruge.
Gå til Security → Events i Cloudflare-dashboardet. Filtrér på den besøgendes IP-adresse eller – endnu bedre – på Ray ID’et fra fejlsidens bund. Hver hændelse viser, hvilken tjeneste der blokerede (WAF, IP Access Rules, landeregel), hvilken regel der matchede, og hvad requesten indeholdt:
Spørg til hver hændelse: Var requesten legitim? En dansk kunde på ferie bag et udenlandsk IP, en betalings-callback, en kunde på mobilnet med skiftende IP – alt sammen legitim trafik, som brede regler let rammer. Omvendt: gentagne login-forsøg, scanninger efter /wp-config.php og åbenlyse botmønstre er præcis det, reglerne er til for. En regel, der blokerer 500 requests om dagen, hvoraf tre er kunder, skal ikke slettes – den skal have undtagelser.
/wc-api/), en kendt tjenestes IP-område eller en User-Agent. Undtag så smalt som muligt.Står du selv med 1020 på dit eget site, så log ind på Cloudflare via mobilnet eller VPN (dashboardet ligger ikke bag dine egne regler), og find din IP i Events. Læg derefter din faste IP som “Allow” i IP Access Rules – og gør det samme for serverens egen IP, så loopback-kald aldrig fænges af reglerne.
Rettelsen sidder, når den ramte besøgende (eller tjeneste) kan gennemføre sin handling, når Events viser, at det legitime mønster nu passerer – og når blokeringstælleren for selve reglen ikke falder mærkbart. Falder den til nær nul, har undtagelsen åbnet mere, end den skulle. Gennemgå Events igen efter et par dage: god WAF-pleje er løbende småjusteringer, ikke én stor åbning. Og dokumentér hver undtagelse med én linje om hvorfor – så tør du også rydde op om et år.
Nej – requesten stoppes hos Cloudflare og når aldrig serveren. Al dokumentation ligger under Security → Events i Cloudflare-dashboardet, hvor Ray ID’et fra fejlsiden slår hændelsen direkte op.
Ikke når de er smalle: én sti, én tjeneste, ét regel-ID. Det farlige er brede genveje – at slå en hel managed ruleset fra eller fjerne en landeblokering helt, fordi én kunde blev ramt.
Fordi reglerne evaluerer requestens egenskaber: IP, land, User-Agent, sti og adfærd. To kunder på hver sin forbindelse kan derfor få hver sit udfald – og netop derfor er Events-loggen, ikke gætværk, vejen til svaret.