Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
support@hostious.io
Cloudflare til WordPress 8 min. læsning Opdateret 3. oktober 2026

Bot Fight Mode blokerer betalings-callbacks og overvågning

Cloudflare Bot Fight Mode rammer legitim automatik: hængende ordrer, fejlede webhooks og falske nedbrud. Byg målrettede regler i stedet.

Bot Fight Mode blokerer betalings-callbacks og overvågning

Kort svar: Cloudflare Bot Fight Mode udfordrer alt, der ligner automatiseret trafik – og betalings-callbacks, uptime-overvågning, webhooks og apps er teknisk set bots. Tilstanden kan ikke undtages med WAF-regler (Skip virker ikke), kun med IP Access-regler for kendte IP-adresser. På en webshop på gratis-planen bør den derfor som regel være slukket og erstattet af målrettede WAF-regler og rate limiting. Tjek hændelsesloggen for udfordrede POST-requests til /wc-api/ og webhook-stier, hvis ordrer hænger som „Afventer betaling“.

Fagligt gennemgået: 2. oktober 2026

Bot Fight Mode lyder som en gratis vagthund – og på et rent indholdssite er den ofte harmløs. Men en webshop lever af automatiseret trafik: betalingsgatewayen melder tilbage, fragtsystemet henter ordrer, overvågningen tjekker oppetid, og regnskabssystemet synkroniserer. Når vagthunden ikke kan kende ven fra fjende, bider den også postbuddet.

Denne guide viser, hvordan du genkender problemet, bekræfter det i Cloudflares hændelseslog og erstatter Bot Fight Mode med regler, du selv styrer – uden at åbne for den trafik, du faktisk vil holde ude.

Før du ændrer noget: Notér, hvilke Cloudflare-sikkerhedsindstillinger der er slået til nu, og hvornår du ændrer dem. Sluk aldrig flere beskyttelser på én gang – så kan du ikke se, hvilken ændring der løste problemet, og du står med et site uden beskyttelse, mens du leder.

Hvad Bot Fight Mode gør – og ikke kan

Bot Fight Mode genkender trafik, der matcher mønstre fra kendte bots, og svarer med beregningstunge challenges, som klienten skal løse, før den slipper igennem. En browser klarer det i baggrunden; et serverkald fra en betalingsgateway kan ikke løse en challenge og ender derfor med en fejl. Tilstanden ligger i Cloudflare-dashboardet under Security → Settings, hvor du filtrerer på Bot traffic.

Cloudflares verificerede bots – Googlebot, Bingbot og andre på deres liste – behandles særskilt. Problemet er alt det legitime, der ikke står på listen: mindre danske tjenester, betalingsgatewayens callback-servere, jeres eget overvågningsværktøj, mobilapps og integrationer, der kalder REST API’et.

Den vigtigste begrænsning er, at Bot Fight Mode ikke kører i Cloudflares regelmotor (Ruleset Engine). Ifølge Cloudflares dokumentation kan den derfor ikke omgås med Skip-, Bypass- eller Allow-handlinger i WAF custom rules eller Page Rules. Den eneste undtagelse er IP Access-regler: matcher en IP Access-regel først, udløses Bot Fight Mode ikke. Ellers er tilstanden simpelthen tændt eller slukket for hele zonen.

Bot Fight Mode slår desuden JavaScript-detektion til, som ikke kan slås fra separat. Har du en Content Security Policy, skal den tillade Cloudflares scripts under /cdn-cgi/challenge-platform/, ellers kan rigtige besøgende også få problemer.

FunktionPlanerKan undtages med WAF Skip?Kan undtages med IP Access Allow?
Bot Fight ModeFreeNejJa, hvis reglen matcher først
Super Bot Fight ModePro, Business, EnterpriseJaJa
Bot ManagementEnterpriseJa, med finjustering af tærsklerJa

1. Genkend symptomerne

  • Ordrer hænger som „Afventer betaling“, selvom kunden har betalt – gatewayens callback nåede aldrig frem. Se også guiden om ordrer, der afventer betaling.
  • Webhooks fejler til lager-, fragt- eller regnskabssystemer – leveringsloggen viser timeouts eller 403; se webhook-guiden.
  • Uptime-overvågningen melder falske nedbrud – sitet er oppe, men monitorens requests bliver udfordret.
  • Apps og integrationer mod REST API’et eller admin-ajax.php fejler sporadisk, typisk med 403 eller en HTML-side, hvor de forventede JSON.
  • RSS-læsere, billeder i nyhedsbreve og link-forhåndsvisninger opfører sig ustabilt uden tydeligt mønster.

Fællesnævneren er, at fejlen rammer maskine-til-maskine-trafik, mens sitet ser helt normalt ud for dig i browseren. Det er netop det, der gør problemet svært at opdage.

2. Bekræft det i hændelsesloggen

Åbn Cloudflares Security Events (hændelsesloggen for zonen), og filtrér på tjenesten „Bot Fight Mode“. Sammenhold tidspunkterne med de fejlede callbacks, webhooks eller falske alarmer. Matcher de, er sagen bekræftet:

Genskabt eksempel: Bot Fight Mode blokerer en betalings-callback til wc-api
Genskabt eksempel, 30. august 2026: en POST til betalings-callbacken blev challenged af Bot Fight Mode – og callbacks kan ikke løse challenges. Eksemplet er ikke data fra hostious.io.

Se især efter disse kendetegn i hændelserne:

  • Metoden er POST, og stien er /wc-api/…, /?wc-api=…, /wp-json/… eller en webhook-modtager.
  • User-agent er et bibliotek eller en tjeneste (fx et HTTP-klientbibliotek eller monitorens navn), ikke en browser.
  • Kilde-IP eller ASN tilhører gatewayen, fragtplatformen eller overvågningstjenesten.

Du kan også teste fra kommandolinjen. Et simpelt kald uden browser viser, om du får en challenge-side i stedet for det forventede svar:

curl -sI https://dit-domæne.dk/wp-json/
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://dit-domæne.dk/?wc-api=test

Et 403-svar med Cloudflare-headere (fx cf-mitigated: challenge) peger på en Cloudflare-regel. Et svar fra WordPress selv – også et 400 eller 404 – betyder, at requesten nåede helt ind til serveren. Resultatet fra din egen maskine er kun en indikation; det afgørende er hændelsesloggen for de rigtige tjenesters requests.

3. Vælg løsning efter din Cloudflare-plan

Gratis-planen: Da Bot Fight Mode ikke kan undtages pr. sti, er der to muligheder. Enten slukker du tilstanden og bygger beskyttelsen med værktøjer, du kan styre (næste afsnit). Eller du opretter IP Access-regler med handlingen Allow for tjenester, der offentliggør faste IP-adresser. Den sidste løsning holder kun, så længe listerne er opdaterede, og mange cloudbaserede tjenester har slet ikke faste adresser. På en webshop er det derfor oftest mest robust at slukke Bot Fight Mode.

Pro, Business og Enterprise: Her bruger du Super Bot Fight Mode i stedet. Den kører i regelmotoren, så WAF custom rules eksekveres før den, og en regel med handlingen Skip kan undtage præcis de stier eller IP-områder, som legitim automatik bruger. Du kan også vælge, hvordan verificerede bots og „definitely automated“-trafik skal håndteres.

4. Byg målrettede regler i stedet

Når Bot Fight Mode er slukket, beholder du effekten ved at beskytte de steder, bots faktisk misbruger, og lade resten være:

  • WAF custom rules med Managed Challenge på login (/wp-login.php), xmlrpc.php og evt. søgning – aldrig på /wc-api/, webhook-stier og /wp-json/, som maskiner skal kunne kalde.
  • Rate limiting på login-stien mod brute force. Gratis-planen giver adgang til rate limiting i begrænset omfang.
  • Blokér xmlrpc.php helt, hvis ingen tjeneste bruger det (fx Jetpack eller apps, der kræver det).
  • Skip-regler for kendte tjenesters stier eller IP-områder, så de ikke fanges af dine egne WAF-regler. Husk, at Skip kun virker på regelmotoren – ikke på Bot Fight Mode.

Et eksempel på et udtryk til en challenge-regel, der kun rammer login og XML-RPC:

(http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")

Sæt handlingen til Managed Challenge, og test bagefter, at du selv kan logge ind. Har du flere administratorer, kan en regel, der kun udfordrer login fra lande, I ikke arbejder fra, være et mildere alternativ. Supplér med beskyttelse af WordPress-login mod brute force på selve sitet – Cloudflare er ét lag, ikke hele forsvaret.

5. Verificér resultatet

Balancen er på plads, når alle disse punkter holder:

  • En testbetaling gennemføres, og ordren skifter status korrekt uden manuel indgriben.
  • Webhook-leveringsloggen viser 200-svar igen.
  • Overvågningen kører en uge uden falske alarmer.
  • Hændelsesloggen viser stadig, at login-stien fanger botforsøg.

Gør testbetalingen til fast rutine efter alle sikkerhedsændringer i Cloudflare: callbacken er den første, der rammes, og den sidste, man opdager. Er der stadig ordrer, der hænger, efter Bot Fight Mode er slukket, så se efter andre regler i hændelsesloggen – fx en WAF-regel, der giver Error 1020.

Hvornår giver Bot Fight Mode mening?

På et rent indholdssite uden betalinger, webhooks og eksterne integrationer kan Bot Fight Mode være en nem ekstra beskyttelse mod scraping og automatiserede formularforsøg. Har du uptime-overvågning, så tjek den efter aktivering. Så snart sitet modtager callbacks eller kaldes af andre systemer, bør du i stedet vælge målrettede regler eller Super Bot Fight Mode på en betalt plan.

Læs også

Ofte stillede spørgsmål om Bot Fight Mode

Er det ikke usikkert at slukke Bot Fight Mode?

Nej – den er et groft værktøj, ikke din eneste beskyttelse. WAF-regler, rate limiting og challenges på de rigtige stier stopper det samme misbrug uden at ramme shoppens legitime automatik.

Hvorfor rammes Googlebot ikke?

Google, Bing og andre store crawlere står på Cloudflares liste over verificerede bots og behandles særskilt. Det er alle de små, uverificerede – men legitime – tjenester, der fanges.

Kan jeg undtage betalings-callbacks med en skip-regel?

Ikke fra Bot Fight Mode – den kører uden for regelmotoren, så Skip i WAF custom rules har ingen effekt. Du kan bruge en IP Access-regel med Allow for gatewayens offentliggjorte IP-adresser, slukke Bot Fight Mode eller skifte til Super Bot Fight Mode på en betalt plan, hvor Skip virker.

Hvordan finder jeg gatewayens IP-adresser?

I gatewayens tekniske dokumentation – mange offentliggør de IP-områder, deres callbacks kommer fra. Står de der ikke, eller ændres de ofte, er en IP-baseret undtagelse skrøbelig, og så er det mere robust at slukke Bot Fight Mode.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 30. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026