Cloudflares regel Block AI bots kan tyst ta ner din egen MCP-server

Om din MCP-server ligger bakom Cloudflare Access med managed OAuth, och klienten loggar in men sedan inte listar några verktyg, kontrollera Cloudflares inställning Block AI bots (eller dess nyare AI bot policies) innan du rör någon kod. Vi stötte på det här när vi byggde MCP-servern för shrtnr, vår URL-förkortare, och varje lager i stacken rapporterade framgång medan anslutningen inte ledde någonstans.

Felläget ser ut så här. OAuth-handskakningen slutförs. Cloudflare Access registrerar en lyckad inloggning. MCP-klienten rapporterar ansluten, eller får timeout efter en stund. Sedan händer ingenting: inga verktyg, inget fel från servern och inget anrop i Worker-loggarna, eftersom anropet aldrig nådde Workern.

Uppsättningen

En Cloudflare Worker serverar en MCP-endpoint över Streamable HTTP på en egen subdomän, mcp.your-domain.com. En self-hosted Cloudflare Access-applikation skyddar den subdomänen med Managed OAuth påslaget. Access agerar då som OAuth authorization server: den hanterar klientregistrering, utfärdande av tokens och validering vid edge. Workern implementerar inga egna OAuth-endpoints. Den tar emot autentiserade anrop med identitetsheaders och måste validera Access-JWT:n som kommer i headern Cf-Access-Jwt-Assertion; Cloudflare kräver det för Managed OAuth på en MCP-server.

Det här är uppsättningen Cloudflare dokumenterar för MCP-servrar, och den fungerar. Managed OAuth är fortfarande i beta, så vissa etiketter i dashboarden kan ändras.

Varje lager säger ja

Det som gör det här svårt att diagnostisera är att ingenting går fel där du tittar.

Access visar inloggningen. Zero Trust > Insights > Logs > Access authentication logs listar en lyckad autentisering för din användare mot MCP-applikationen. Det är allt den registrerar. Cloudflares egen dokumentation påpekar att autentiseringsloggarna inte fångar vad som händer under sessionen efteråt.

Workern visar ingenting alls. Ingen invokation, ingen loggrad, inget undantag. En Worker kan inte logga ett anrop den aldrig tog emot, så en tom logg läses som "ingen trafik" snarare än "trafik blockerad".

Klienten har minst att säga. Den fick en token, öppnade en anslutning, och anslutningen kom tillbaka tom eller hängde sig. Dess felmeddelande, när den visar ett, nämner ingen säkerhetsregel.

Platsen där blockeringen registreras är zonens Security Analytics, som Cloudflares dokumentation hänvisar till för att se blockerad AI-bottrafik. Dit skulle du bara titta om du redan misstänkte en säkerhetsregel. Ingenting i OAuth-flödet, Access-dashboarden eller Workern pekar dig dit.

Orsaken

Block AI bots är en hanterad regel i Cloudflares botskydd. Cloudflare beskriver den som att den blockerar verifierade bottar som klassificeras som crawlers för AI-träning, plus ett antal overifierade bottar som beter sig likadant. Den körs vid edge, innan något anrop når din Worker.

I vårt fall klassificerade Cloudflare MCP-trafiken som AI-bottrafik, och den hanterade regeln fångade upp den innan den nådde Workern. Webbläsarhalvan av OAuth-flödet lyckades ändå, eftersom klienten öppnar ett webbläsarfönster för Cloudflare Access vid första anslutningen, och det är vanlig webbläsartrafik. Autentiseringen slutfördes, och MCP-anropen som följde blockerades vid Cloudflares edge, medan klienten gav lite eller ingen användbar information om varför.

Det betyder inte att varje MCP-klient klassificeras så här. MCP är ett protokoll, och en klient kan vara en hostad assistent, en desktop-app, en editor eller ditt eget CLI. Klassificeringen beror på klienten och på hur dess anrop når Cloudflare. Men om OAuth lyckas medan din Worker inte ser någon MCP-trafik är Cloudflares AI bot policies värda att kontrollera innan du felsöker själva applikationen.

Lösningen

Stäng av regeln på zonen som hostar MCP-subdomänen:

Cloudflare Dashboard > your zone > Security > filter by Bot traffic > Block AI bots > Do not block (off)

Inställningen gäller för hela zonen, så det här måste göras på varje zon som hostar en MCP-subdomän. Om din MCP-endpoint ligger på en subdomän till en domän som också serverar en marknadsföringssajt, stängs den av även för marknadsföringssajten.

Cloudflare håller på att ersätta den här inställningen. Enligt dokumentationen när detta skrivs är det enskilda alternativet Block AI bots utfasat från 15 september 2026 till förmån för Security Settings > Configure AI bot policies, som delar upp AI-trafik i tre förval: Search, Agent och Training. Varje förval kan sättas till Block (on all pages), Block on pages with ads eller Allow (do not block). Cloudflares definition av Agent, automatiserad aktivitet som agerar i realtid på en persons vägnar, beskriver väl många MCP-klienters interaktioner. I den nyare policymodellen, kontrollera kategorin Agent först. Vilken kategori som behöver tillåtas kan bero på hur Cloudflare klassificerar den specifika MCP-klientens trafik. Nya domäner som skapas efter det datumet blockerar som standard Training- och Agent-trafik på sidor som visar annonser.

Tre närliggande fallgropar

Ge MCP-endpointen ett eget hostnamn. I vår uppsättning ligger endpointen på mcp.your-domain.com i stället för bakom en sökväg på en befintlig applikation. Det gör Access-applikationen, dess policyer och botinställningarna lättare att resonera kring. Hostnamnet läggs till på Workern som en andra custom domain under Workers & Pages > your Worker > Settings > Domains & Routes > Add Custom Domain. Cloudflare skapar DNS-posterna åt dig.

Redirect-URI:er är per klient. Under Access-applikationens Advanced settings är Allowed redirect URIs en tillåtelselista för dynamiskt registrerade OAuth-klienter. Varje MCP-klient du ansluter behöver sin callback listad, och listan är inte densamma mellan produkter:

https://claude.ai/api/mcp/auth_callback     Claude.ai (legacy domain) and Claude Desktop
https://claude.com/api/mcp/auth_callback    Claude.ai (current domain)
https://dash.cloudflare.com/*               Cloudflare Access AI Controls portal

För att hitta en klients exakta callback: försök ansluta, låt flödet misslyckas och läs parametern redirect_uri ur fel-URL:en i webbläsaren. Lokala klienter som proxar anslutningen från din dator behöver dessutom Allow localhost clients och Allow loopback clients påslagna.

Access-ändringar tar tid att propagera. Att spara en ändring i en Access-applikation kan ta 30 till 60 sekunder innan den får effekt. Testa en gång, vänta en minut, testa igen innan du ändrar något annat, annars felsöker du ett tillstånd som inte längre finns.

Din MCP-server ansluter men gör ingenting: kontrollera detta i ordning

1. Block AI bots på zonen. Security > filter by Bot traffic > Block AI bots > Do not block (off). I den nyare dashboarden: Security Settings > Configure AI bot policies, kontrollera Agent först. Upprepa för varje zon som hostar en MCP-subdomän.
2. Security > Analytics på den zonen. Leta efter blockerade anrop mot MCP-hostnamnet. Finns de där är det en säkerhetsregel, inte din kod.
3. Access-applikationen täcker det MCP-hostnamn klienten faktiskt ansluter till.
4. Managed OAuth är på, och klientens redirect-URI finns i Allowed redirect URIs. Localhost- och loopback-klienter är tillåtna om du använder en lokal proxy.
5. Du väntade 60 sekunder efter den senaste Access-ändringen.
6. Workern har MCP-subdomänen registrerad som custom domain, och dess secrets för Access audience och JWKS är satta.
7. Först nu, läs Worker-loggarna.

Hela uppsättningen vi landade i, inklusive Worker-secrets och klientkonfiguration för Claude, Claude Code och VS Code, finns i shrtnr:s README på GitHub.

Om Oddbit

Vi är ett seniort mjukvaruutvecklingsteam baserat på Bali, Indonesien, med rötter i Sverige. Vi bygger skräddarsydd mjukvara för startups och scale-ups: webbapplikationer, mobilappar, SaaS-plattformar och integrationerna som knyter ihop dem. Våra kunder finns i Norden, Europa och Sydostasien.

Vi bygger och släpper verktygen vi själva behöver, bland annat Tanam (ett Firebase-CMS med AI-genererat innehåll), Flutter-paket med runt hundratusen nedladdningar på pub.dev och Firebase Genkit-plugins för integration av AI-modeller.

Om du sätter AI-agenter framför dina egna system och vill få dem korrekt uppkopplade, prata med oss. Vi visar hellre vårt arbete än pratar om det.