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 i Cloudflares Security Events (søg på Ray ID eller den besøgendes IP), 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.
Fagligt gennemgået: 2. oktober 2026
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.
Før du ændrer noget: Slå ikke WAF’en, en managed ruleset eller en landeblokering helt fra for at få én kunde igennem. Find først hændelsen og den konkrete regel. Notér reglens nuværende udtryk, før du redigerer den, så du kan gå tilbage, hvis undtagelsen åbner for meget.
Hvad 1020 betyder
Cloudflare beskriver 1020 som en blokering fra en firewall-regel, som sitets ejer har sat op: typisk en custom WAF-regel, en IP Access Rule eller en lande- eller ASN-blokering. 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.
Ikke alle blokeringer ser ens ud. Ser du en 403 uden Cloudflare-branding, er det serveren eller et sikkerhedsplugin – så er det 403-guiden, du skal bruge. Andre Cloudflare-funktioner viser deres egne sider:
| Det besøgende ser | Hvad det typisk er | Guide |
|---|---|---|
| Error 1020 „Access denied“ | En firewall-regel blokerede requesten | Denne guide |
| Captcha eller en side, der beder dig bekræfte, at du er et menneske | Challenge fra en regel eller bot-beskyttelse | Challenge-guiden |
| 429 Too Many Requests | En rate limiting-regel | 429-guiden |
| Betalings-callbacks eller overvågning fejler | Bot Fight Mode eller en bred regel rammer automatiseret trafik | Bot Fight Mode-guiden |
| 403 uden Cloudflare-logo | Serveren eller et sikkerhedsplugin | 403-guiden |
1. Saml oplysningerne fra fejlsiden
Bed den berørte om et screenshot af hele fejlsiden. Du skal bruge tre ting: Ray ID’et nederst på siden, tidspunktet og gerne den besøgendes IP-adresse, som de fleste fejlsider kan vise ved et klik. Tidspunktet på Cloudflares fejlside er angivet i UTC; dansk tid er en time foran om vinteren og to timer foran om sommeren. Husk omregningen, når du søger i loggen.
2. Find hændelsen i Security Events
I Cloudflare-dashboardet finder du blokeringerne under Security → Analytics på fanen Events (i ældre visninger hed menupunktet Security → Events). Filtrér på Ray ID’et – eller på den besøgendes IP-adresse, hvis du ikke har Ray ID’et. Hver hændelse viser, hvilken tjeneste der blokerede (fx custom rules, managed rules eller IP Access Rules), hvilken regel der matchede, og hvad requesten indeholdt: sti, land, ASN, User-Agent og metode.
Kan du ikke finde hændelsen, så tjek, at du står i den rigtige zone (domænet), at tidsfilteret dækker tidspunktet, og at du har omregnet fra UTC. Skal du genskabe blokeringen selv, kan du sende en request med samme sti og User-Agent og se, om svaret indeholder headeren cf-ray og statuskode 403:
curl -sI https://eksempel.dk/wc-api/eksempel/ -A "Den-blokerede-User-Agent" | grep -i -E "^HTTP|cf-ray"3. Vurdér om blokeringen er korrekt
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, en overvågningstjeneste eller en kunde på arbejdets VPN – 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.
Kig på mønsteret over tid, ikke kun på den ene hændelse. En regel, der blokerer 500 requests om dagen, hvoraf tre er kunder, skal ikke slettes – den skal have undtagelser. En regel, der næsten kun rammer legitim trafik, skal derimod omskrives eller fjernes.
4. Lav en præcis undtagelse
- Custom WAF-regel rammer for bredt: tilføj en betingelse, der undtager det legitime mønster – fx en bestemt sti (
/wc-api/), en kendt tjenestes IP-område eller verificerede bots. Undtag så smalt som muligt. - Landeblokering rammer kunder: overvej „Managed Challenge“ i stedet for „Block“ for de lande, hvor legitime besøg kan forekomme – så får mennesker en chance, mens bots stoppes. Mere om challenges i challenge-guiden.
- IP Access Rule er for gammel: blokerede IP-områder fra et gammelt angreb kan i dag tilhøre almindelige mobilnet. Ryd op i regler, der er over et år gamle og uden dokumenteret årsag.
- Managed ruleset giver falsk positiv: hændelsen viser regel-ID’et – lav en undtagelse (exception) for præcis det ID på præcis den sti, i stedet for at slå hele sættet fra.
En landeblokering, der skal lade betalings-callbacks og verificerede bots passere, kan i Cloudflares regeludtryk se sådan ud. Sti og land er eksempler, som du tilpasser til din egen shop:
(ip.src.country ne "DK" and not starts_with(http.request.uri.path, "/wc-api/") and not cf.client.bot)Alternativt kan du oprette en særskilt regel med handlingen Skip, der ligger over den blokerende regel og springer de efterfølgende regler over for det legitime mønster. Rækkefølgen er afgørende: Cloudflare evaluerer custom rules oppefra, så en Skip-regel under blokeringen virker ikke.
Vær varsom med undtagelser baseret på User-Agent alene. En User-Agent kan forfalskes på sekunder, så brug den kun sammen med andre betingelser som sti eller IP-område. Til betalingsudbydere er en kombination af sti og udbyderens dokumenterede IP-områder mere robust.
Når du selv er blokeret
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. Har du ikke en fast IP, så ret den regel, der ramte dig, frem for at tillade et helt IP-område fra din internetudbyder.
Gør det samme for serverens egen IP, så loopback-kald aldrig fanges af reglerne. Når WordPress kalder sig selv, går requesten gennem Cloudflare, hvis domænet peger dertil – og en blokering her kan få wp-cron, REST API og Webstedstilstand til at fejle uden en synlig 1020 for nogen.
Når betalinger og integrationer rammes
Den dyreste 1020 er den, ingen ser. Betalingsudbydere, fragtplatforme og regnskabsintegrationer kalder din shop automatisk, og bliver de blokeret, får du ikke en fejlside – du får ordrer, der bliver stående som „Afventer betaling“, eller webhooks, der fejler. Søg i Events efter blokeringer på stier som /wc-api/ og /wp-json/, og sammenhold dem med tidspunkter for fejlede ordrer. Guiderne om ordrer, der afventer betaling og webhooks, der ikke virker tager den videre derfra.
Verifikation
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 – fx i reglens beskrivelsesfelt – så tør du også rydde op om et år.
Læs også
- Hub: Cloudflare til WordPress
- Besøgende møder captcha eller challenge
- Bot Fight Mode blokerer betalings-callbacks og overvågning
- 403 Forbidden i WordPress
- Cloudflare-indstillinger: sikker basisopsætning
- WordPress hosting hos Hostious – LiteSpeed, daglig backup og dansk support 24/7
Ofte stillede spørgsmål om Error 1020
Kan jeg se 1020-blokeringer i WordPress?
Nej – requesten stoppes hos Cloudflare og når aldrig serveren. Al dokumentation ligger i Security Events i Cloudflare-dashboardet, hvor Ray ID’et fra fejlsiden slår hændelsen direkte op.
Er det farligt at lave undtagelser?
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.
Hvorfor rammes kun nogle besøgende?
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.
Hvad gør jeg som besøgende, der får Error 1020?
Send et screenshot af fejlsiden med Ray ID til sitets ejer – kun ejeren kan se og ændre reglen. Prøv eventuelt fra en anden forbindelse, fx mobilnet uden VPN, hvis du har travlt.
Udgivet 30. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026