En kunde skriver at nettbutikken din "ikke slipper dem inn". De fikk opp en side fra Cloudflare med en firesifret kode, ga opp og handlet et annet sted. Serverloggene dine viser ingenting, fordi forespørselen aldri kom forbi Cloudflare. Dette skjer i WooCommerce-butikker, på WordPress-sider som skal skaffe henvendelser, på headless-frontender bygget med Astro eller Next.js og i alle egenutviklede applikasjoner som går via Cloudflare. Årsaken er nesten alltid en regel i din egen sone, og Cloudflare noterer hvilken.
Her går vi gjennom rekkefølgen som fungerer: skaff Ray ID, slå den opp, les hvilken funksjon som grep inn, og stram deretter inn den funksjonen slik at den slutter å fange kjøpere og betalingsvarsler. All oppførsel som beskrives under, er hentet fra Cloudflares utviklerdokumentasjon slik den så ut i oktober 2026.
Hva betyr Cloudflare feil 1015, 1020 og 1009
Koden forteller deg hvor du skal lete. Et innlegg i r/CloudFlare 21. oktober 2026 oppsummerte kodene, og hver av dem stemmer med Cloudflares egne feilsøkingssider:
- 1015 (HTTP 429): en rate limiting-regel slo til. Cloudflare råder deg til å se over tersklene, og hvis regelen teller over en svært kort periode, som ett sekund, å prøve 10 sekunder.
- 1020 (HTTP 403): en sikkerhetsregel med handlingen Block og uten eget svar. Siden om 1020 nevner skjemavalidering og JWT-validering i API Shield som eksempler, og slår fast at WAF custom rules og managed rules ikke lenger returnerer 1020. De viser WAF-blokkeringssiden i stedet.
- 1009 (HTTP 403): en blokkering av land eller region satt i IP Access rules. Landblokkering der finnes bare på Enterprise. På andre planer er en landblokkering en custom rule, og da vises WAF-blokkeringssiden.
- 1010 (HTTP 403): Browser Integrity Check avviste nettleserens signatur.
- “Just a moment…” eller en utfordringsside: en Managed Challenge fra en custom rule, en rate limiting-regel, Bot Fight Mode eller Under Attack Mode.
Detaljen om 1020 sparer deg for timer. Leter du gjennom custom rules etter den som ga 1020, leter du i feil liste.
Hvor finner jeg Ray ID i Cloudflare
Be kunden om et skjermbilde av hele feilsiden. Der står koden, Ray ID og et tidsstempel i UTC. Den som startet den samme tråden, la til dette i et svar:
koden er den enkle biten, det folk overser er ray id-en på samme skjerm. lim den inn i security events så ser du hvilken av dine egne regler som slo til.
(u/Hot_Bee_5451, r/CloudFlare, 22. oktober 2026, egen oversettelse)
En Ray ID knyttes til hver forespørsel som går gjennom Cloudflare, og sendes til opprinnelsesserveren i headeren cf-ray. Cloudflare advarer om at Ray ID ikke er garantert unik, så sjekk også tidspunkt og IP. Kan ikke kunden sende skjermbilde, ber du om den offentlige IP-adressen, omtrent klokkeslett og hvilket land de var i. Når en utfordring feiler, finnes det en annen vei, foreslått i en annen tråd:
Vel, du kan gi Ray ID-en som lages når testen kjøres, til administratoren av nettstedet, så kan de slå opp nøyaktig hvorfor du ikke kom gjennom.
(u/Logvin, r/CloudFlare, 21. oktober 2026, egen oversettelse)
Slik søker du opp en Ray ID i Cloudflare Security Events
Åpne Security > Analytics i dashbordet og gå til fanen Events. Legg til et filter på Ray ID eller på klientens IP, og velg et tidsrom som dekker klagen. Gjør først om UTC-tiden fra feilsiden til norsk tid. Cloudflares side om 1020 påpeker dette uttrykkelig.
To begrensninger i dokumentasjonen for Security Events er viktige her. Data lagres i opptil 31 dager. Og listen bygger på utvalgslogger, så i en sone med mye trafikk kan en enkelt forespørsel mangle. Gir søket på Ray ID ingen treff, snevrer du tidsvinduet inn til noen få minutter og filtrerer på IP. Et kortere vindu viser flere hendelser. Én forespørsel kan også gi flere hendelser hvis flere funksjoner grep inn.
Hvilken Cloudflare-regel blokkerte kunden
Åpne hendelsen. Feltet Service viser funksjonen, og for regler får du også regelens navn eller ID. Dette betyr de som regel:
- Custom rules: ditt eget uttrykk. Vanlige syndere er landblokkeringer, ASN-blokkeringer rettet mot vertsleverandører (som også treffer VPN-brukere) og for brede stiregler på
/wp-login.phpeller/checkout. - Managed rules: en signatur fra Cloudflare eller OWASP kjente igjen noe i forespørselen. Lange søk, skjemafelt med kodebiter og enkelte nyttelaster fra sidebyggere utløser disse.
- Rate limiting-regler: tilfellet med 1015. Kunder bak samme IP fra et kontor eller en mobiloperatør deler teller når regelen teller per IP.
- Bot Fight Mode eller Super Bot Fight Mode: botproduktene. Ifølge Cloudflares dokumentasjon om boter kan begge utfordre trafikk fra API-er og mobilapper.
- Security Level eller Under Attack Mode: mellomsiden som gjelder hele sonen.
En slettet regel vises som “Rule unavailable”. Sjekk revisjonsloggen for å se hvem som fjernet eller endret den.
Hvordan lage en Skip-regel i Cloudflare uten å åpne hele nettstedet
Løsningen er en custom rule med handlingen Skip, plassert over regelen som blokkerte, som bare treffer trafikk du stoler på. Med Cloudflares Skip-valg kan du hoppe over alle gjenværende custom rules, alle rate limiting-regler, alle managed rules og alle regler i Super Bot Fight Mode. Via API-et kan du i tillegg hoppe over Browser Integrity Check, Security Level, User Agent Blocking, Zone Lockdown og Hotlink Protection. Custom rules kjøres i rekkefølge, så plasseringen betyr noe.
Hold uttrykket smalt. For Stripe-utvidelsen til WooCommerce, som bare bruker /?wc-api=wc_stripe som webhook-endepunkt:
(http.request.uri.query contains "wc-api=wc_stripe" and ip.src in $stripe_webhooks)Her er $stripe_webhooks en IP-liste du lager ut fra Stripes publiserte IP-adresser for webhooks. For en integrasjon som kaller WooCommerce REST API fra en fast server:
(starts_with(http.request.uri.path, "/wp-json/wc/") and ip.src in $erp_servers)Har en falsk positiv rammet ekte kunder, er det ofte bedre å endre den opprinnelige regelen enn å legge til et unntak: forleng perioden i rate limiting-regelen, begrens en landblokkering til /wp-login.php, eller bytt Block ut med Managed Challenge. La Log matching requests stå på for Skip-regelen, så ser du at den virker.
Hvorfor blokkerer Cloudflare Stripe-webhooks og kall til WooCommerce REST API
Kall fra server til server har ingen nettleser og kan derfor ikke løse en JavaScript-utfordring. Enhver funksjon som utfordrer i stedet for å blokkere, stopper dem likevel. En butikkeier beskrev akkurat dette i r/CloudFlare:
Når jeg slår på Under Attack Mode, stopper trafikken fra Singapore i GA4. Men Under Attack Mode gjør nettstedet mitt tregt, og API-kallene mine fra server til server (WooCommerce REST API) får Cloudflare-utfordringen “Just a moment…”, så de feiler.
(u/lastoneinbatumi, r/CloudFlare, 19. oktober 2026, egen oversettelse)
Hvor mye det koster, avhenger av leverandøren. Stripe prøver en mislykket webhook på nytt med eksponentiell backoff i opptil tre dager i live-modus, så ordrer som står fast på “venter på betaling” kommer som regel inn når du har rettet regelen. Shopify prøver opptil åtte ganger i løpet av fire timer og fjerner deretter abonnementet. Det er viktig hvis appen eller headless-backenden din tar imot Shopify-webhooks bak Cloudflare-sonen din. Se etter mislykkede leveranser i dashbordet til hver leverandør etter enhver endring i sikkerhetsoppsettet.
Under Attack Mode er ment som en siste utvei under et angrep. Cloudflares side om Security Level sier at du skal bruke en configuration rule for å slå den av eller på for API-et ditt eller andre deler av domenet. Hold den avslått for /wp-json/, webhook-stier og API-verten din.
Den samme tråden ga en lærdom til. Når blokkert trafikk fortsetter å dukke opp i statistikken, bør du spørre om den i det hele tatt går gjennom Cloudflare:
Er verten din satt opp til bare å tillate trafikk til og fra Cloudflare? Ellers kan den nås direkte via ip
(u/Wilbo007, r/CloudFlare, 19. oktober 2026, egen oversettelse)
Cloudflares dokumentasjon om IP-adresser anbefaler å blokkere trafikk på opprinnelsesserveren som ikke kommer fra Cloudflare eller fra partnere du stoler på. Slipp også inn adressene til betalingsleverandørene dine i den brannmuren.
Kan en WAF-regel omgå Bot Fight Mode
Nei. Siden om Bot Fight Mode sier at du ikke kan omgå eller hoppe over den med WAF custom rules eller Page Rules, fordi den ikke kjører på Ruleset Engine. Skip, Bypass og Allow har derfor ingen effekt. Siden om Skip-valg gjentar at bare Super Bot Fight Mode kan hoppes over. Ett unntak er dokumentert: Bot Fight Mode utløses ikke hvis en IP Access-regel treffer forespørselen først.
På gratisplanen har du altså tre valg hvis Bot Fight Mode utfordrer betalingsleverandøren din, ERP-systemet eller oppetidsovervåkingen: en IP Access-regel som tillater leverandørens adresser, å slå av Bot Fight Mode, eller å gå over til en betalt plan der Super Bot Fight Mode godtar Skip-regler. Super Bot Fight Mode har også innstillingen Optimize for WordPress, som slipper gjennom WordPress sine loopback-forespørsler og dermed retter feil i Site Health uten en egen regel.
Feilsøking av Cloudflare-blokkering i tabellform
| Hva kunden eller loggen viser | Sannsynlig regel | Løsning |
|---|---|---|
| Feil 1015, HTTP 429 | Rate limiting-regel | Lengre telleperiode, høyere terskel eller Skip for rate limiting fra IP-er du stoler på |
| WAF-blokkeringsside, HTTP 403, ingen 1xxx-kode | WAF custom rule eller managed rule | Finn regelen via Ray ID, gjør uttrykket smalere eller legg en Skip-regel over den |
| Feil 1020, HTTP 403 | En annen Block uten eget svar (for eksempel API Shield) | Let i Security Events, ikke i custom rules |
| Feil 1009 | Landblokkering i IP Access rules | Tillat besøkendes IP eller flytt geoblokkeringen til en avgrenset custom rule |
| Feil 1010 | Browser Integrity Check | Hopp over den for den berørte stien via API, eller slå den av |
| Utfordring i løkke på alle sider | Under Attack Mode eller Security Level | Slå den av, eller avgrens den med en configuration rule |
| Webhook eller REST API feiler, ingen person involvert | Bot Fight Mode, Under Attack Mode eller en utfordringsregel | IP Access-tillatelse eller Skip-regel i Super Bot Fight Mode, hold UAM unna API-stier |
| Ingenting i Security Events | Utvalg, feil tidssone, eller forespørselen nådde aldri Cloudflare | Kortere tidsvindu, filtrer på IP, sjekk DNS og brannmuren på opprinnelsesserveren |
Hvordan følge med på Cloudflare-blokkeringer etter rettingen
Ikke stopp ved én kunde. Filtrer i Security Events på Action lik Block eller Managed Challenge, og grupper etter sti. Forespørsler til /checkout, /cart, /my-account, /wp-json/ eller endepunktet for kontaktskjemaet er de som koster penger. Den filtrerte URL-en kan deles, så en kollega ser samme visning. Opptil 500 hendelser fra utvalget kan eksporteres som JSON.
Sjekk deretter den andre siden: mislykkede leveranser i Stripe, PayPal eller Shopify, WooCommerce-ordrer som står fast på venter, og antall innsendte kontaktskjema per dag. Et fall dagen etter en sikkerhetsendring peker rett på regelen du la til. Cloudflare-tjenesten vår omfatter slike gjennomganger av regler, og løpende WooCommerce-drift inkluderer denne overvåkingen for WooCommerce-butikker.
Les også: om AI-botinnstillingene i Cloudflare også stopper søkemotorenes crawlere, finner du i blokkerer Cloudflare Googlebot. Hvor stor del av trafikken på et lite nettsted som er automatisert, og hvorfor det frister til strenge bot-regler, viser vi i 72 % av trafikken vår er ikke en nettleser. Vil du flytte logikk ut i kanten av nettverket, se Cloudflare Workers og WooCommerce.
