TDS auf Cloudflare Workers: Traffic sortieren, bevor er Ihren Server erreicht

Meine Website liegt auf einem VPS in Frankfurt. Wie kann ein Cloudflare Worker meine Besucher woandershin schicken, bevor sie dort ankommen?

In der Frage steckt eine Annahme: dass ein Worker ein Ort ist, an dem die Website wohnen muss, so wie bei einem Hoster. Ein Worker auf einer Route ist etwas anderes. Er läuft am Edge von Cloudflare, auf dem Weg zwischen dem Besucher und der Adresse, auf die Ihr DNS zeigt, und er sieht jede Anfrage an diesen Hostnamen, bevor Ihr Server sie sieht.

Genau diese Stelle braucht ein Traffic-Verteilungssystem, eine TDS. Sie schaut sich jeden Besucher an, prüft eine Liste von Regeln und entscheidet, wohin er geht: auf die Seite für sein Land, zum mobilen Offer, auf eine von drei Landingpages im Split-Test oder weiter zu Ihrem Server, als wäre nichts gewesen. Der Server kann alles sein: ein VPS, Shared Hosting, ein Baukasten oder statische Dateien auf Cloudflare Pages, wo Site Generator die Affiliate-Websites ablegt, die er baut. Der TDS ist das egal, denn sie reicht immer nur an ihn weiter. Ob die TDS auf die Domain der Website gehört oder auf eine eigene Subdomain für Anzeigenklicks, steht weiter unten.

Dieser Leitfaden erklärt, wie das auf Cloudflare funktioniert, am Beispiel der TDS von 301.st, gelesen aus ihrem Quellcode. Jedes Cloudflare-Limit unten ist am 6. Oktober 2026 an der Dokumentation von Cloudflare geprüft.

Wo der Worker sitzt

Ist ein DNS-Eintrag in einer Cloudflare-Zone proxied (die orange Wolke), verbindet sich der Browser des Besuchers nicht mit Ihrem Server. Er verbindet sich mit Cloudflare. Cloudflare beendet TLS, wendet die Regeln der Zone an und öffnet dann eine eigene Verbindung zur Adresse im Eintrag. Eine Worker-Route hängt sich in diesen mittleren Schritt. Die Dokumentation von Cloudflare zu Routen beschreibt, was passiert, wenn der Worker die Anfrage weitergibt:

Calling fetch() on the incoming Request object will trigger a subrequest to your application server, as defined in the DNS settings of your Cloudflare zone.

Der Worker ersetzt Ihren Server also nicht. Er steht davor, und der Server bleibt dort, wohin der DNS-Eintrag zeigt.

Damit das stimmt, müssen vier Bedingungen erfüllt sein, und an jeder davon scheitert eine Einrichtung gern, ohne dass es jemand merkt.

Die Zone liegt bei Cloudflare. Die Nameserver der Domain zeigen auf Cloudflare. Eine Route lässt sich nur in einer Zone anlegen, die Sie haben.

Der Eintrag ist proxied. Routen brauchen „a DNS record set up for the domain or subdomain proxied by Cloudflare“. Ein Eintrag mit grauer Wolke schickt Besucher direkt an die IP Ihres Servers, und der Worker läuft für sie nie.

Das Routenmuster deckt den Hostnamen ab. example.com/* trifft example.com und jeden Pfad darunter, aber nicht www.example.com. Das ist ein eigener Hostname und braucht eine eigene Route oder ein Muster wie *example.com/*.

Keine spezifischere Route beansprucht die Anfrage. „When more than one route pattern could match a request URL, the most specific route pattern wins“, und nur dieser eine Worker läuft. Ein Worker, den Sie schon auf example.com/api/* haben, behält /api/ für sich.

Ihr Server muss dafür nichts tun. Er antwortet Cloudflare so wie vorher. Die üblichen Origin-Einstellungen gelten weiter: Der SSL-Modus der Zone muss zu dem passen, was der Server kann, sonst antwortet Cloudflare mit 525 oder 526 (der Artikel zu diesen Fehlern zeigt die Lösungen).

Was 301.st in Ihrem Konto anlegt

Die TDS läuft nicht auf unserer Infrastruktur. Sie läuft in Ihrem Cloudflare-Konto, und das ist Absicht: Die Anfragen zählen auf Ihr Workers-Kontingent, die Regeln liegen in Ihrer Datenbank, und der Worker arbeitet weiter, wenn unsere API nicht erreichbar ist.

Beim Verbinden eines Kontos geben Sie 301.st ein API-Token. Das Token deckt die ganze Plattform ab, DNS und Weiterleitungen eingeschlossen; für die TDS sind davon Workers Scripts, Workers Routes, D1 und Pages (lesend) nötig. Damit legt die Plattform in Ihrem Konto an:

Was	Name	Wofür
Worker	301-tds	die TDS selbst
Worker	301-health	Prüfungen der Domains, getrennt von der TDS
D1-Datenbank	301-client	Ihre Regeln, Domain-Einstellungen und stündlichen Zähler
Route	yourdomain.com/*	eine pro Domain mit mindestens einer aktiven Regel

Eine Domain ohne Regeln bekommt keine Route, ihr Traffic berührt den Worker also nie. Eine Route, die schon einem anderen Worker gehört, übernimmt die Plattform nicht.

Achten Sie auf das Muster. Die Route wird für genau den Hostnamen angelegt, den Sie eingetragen haben. Kommen Besucher sowohl auf example.com als auch auf www.example.com, legen Sie beide als Domain an.

Hauptdomain oder go-Subdomain

Eine Route auf example.com/* stellt den Worker vor den gesamten Traffic der Website: Besucher aus der Suche, Direktaufrufe, Crawler der Suchmaschinen und jedes Bild, jedes Stylesheet und jede Schrift, die sie laden. Die Anzeigenklicks, die Sie eigentlich verteilen wollen, sind ein kleiner Teil davon. Der Rest verbraucht das Workers-Kontingent für Besucher, für die keine Regel gedacht ist, und so treibt eine TDS eine Website in den bezahlten Tarif. Ein Fehler in einer Regel trifft zudem die ganze Website, Suchmaschinen eingeschlossen.

Wir empfehlen deshalb, den Anzeigenklicks einen eigenen Hostnamen zu geben:

Tragen Sie go.example.com in 301.st als Domain ein. Die Plattform legt dafür einen proxied Platzhalter-Eintrag an, denn dort wird nichts ausgeliefert. Lassen Sie Ihre Anzeigen auf go.example.com zeigen, geben Sie der Subdomain Ihre Regeln und dazu eine letzte: ohne Bedingungen, mit der niedrigsten Priorität und einem Redirect auf https://example.com/. So landet jeder Besucher, den keine andere Regel genommen hat, auf der Website. Die Website und ihr eigener Traffic berühren den Worker nie.

Eines läuft auf go anders: Ist das Workers-Kontingent aufgebraucht, hilft der offene Modus nicht, denn ohne Worker landet die Anfrage beim Platzhalter und bekommt einen Fehler. Dafür zählen dort nur Anzeigenklicks auf das Kontingent, und es ist viel später erschöpft.

Eine TDS auf der Hauptdomain ist für den Fall, dass Sie wirklich jeden Besucher verteilen wollen. Für eine Website auf einem Server funktioniert das heute. Für eine Website auf Cloudflare Pages, also eine Custom Domain eines Pages-Projekts wie bei Websites aus Site Generator, setzt 301.st noch keine Route auf die Hauptdomain: Das Anwenden der Regeln scheitert mit einem Fehler, der eine Subdomain vorschlägt. Die Unterstützung dafür ist in Arbeit, bis dahin nehmen Sie go.

Eine Anfrage, Schritt für Schritt

So geht der Worker 301-tds mit einer Anfrage um, in der Reihenfolge des Codes.

Zwei Pfade sind belegt. Auf /health und /_health antwortet der Worker unter Ihrem Hostnamen selbst, für die Prüfungen der Plattform. Hat Ihre Website unter einem dieser Pfade eine eigene Seite, bekommen Besucher stattdessen die Antwort des Workers.

Statische Dateien gehen direkt durch. Anfragen nach Stylesheets, Skripten, Bildern, Schriften und ähnlichen Dateien überspringen die Regeln ganz. Den Worker rufen sie trotzdem auf, denn die Route deckt jeden Pfad ab, aber die Datenbank berühren sie nie.

Die Regeln kommen aus Ihrer D1 und werden eine Minute gecacht. Der Worker liest alle aktiven Regeln mit einer Abfrage und hält sie 60 Sekunden im Speicher. Der Cache lebt in einer Worker-Instanz, und Cloudflare betreibt viele davon. Nach einer Änderung sehen verschiedene Besucher deshalb bis zu einer Minute lang die alten oder die neuen Regeln.

Änderungen erreichen den Edge, wenn Sie auf Apply drücken. Eine bearbeitete Regel speichert 301.st als Entwurf. Apply schreibt die Regeln über die API von Cloudflare in Ihre D1. Einmal pro Stunde holt sich der Worker außerdem den vollständigen Regelsatz von der Plattform, als Absicherung, falls ein Push gescheitert ist.

Die erste passende Regel gewinnt. Die Regeln werden in fester Reihenfolge geprüft: zuerst Regeln, die auf Bots zielen, dann die übrigen Regeln zum Traffic-Schutz, dann die SmartLink-Regeln. Innerhalb jeder Gruppe entscheidet die Priorität, die Sie setzen, die höchste zuerst. Die erste Regel, deren Bedingungen alle erfüllt sind, führt ihre Aktion aus, und keine andere Regel wird mehr angesehen.

Die Gruppen kommen vor der Priorität, und das hat Folgen. Als Bot-Regel zählt eine Regel nur, wenn sie „Bot“ verlangt. Angenommen, Sie nutzen Bot Shield, das jeden Bot blockt, und dazu eine Rechenzentrums-Regel mit höherer Priorität, die Traffic aus Rechenzentren auf eine andere Seite schickt. Ein Uptime-Monitor auf einem Cloud-Server ist ein Bot, also sieht Bot Shield ihn zuerst und blockt ihn. Die Rechenzentrums-Regel kommt nie zum Zug.

Kein Treffer heißt: Ihr Server. Die Anfrage geht mit fetch(request) unverändert weiter, mit Methode, Headern, Cookies und Body. Der Besucher sieht Ihre Website, als gäbe es die TDS nicht. Der Worker erhöht nur den stündlichen Zähler für Durchläufe um eins.

Was eine Regel prüfen kann

Eine Regel ist ein Satz von Bedingungen. Alle müssen erfüllt sein, damit die Regel passt. Eine leere Bedingung wird gar nicht geprüft. Eine Regel, die nur eine Länderliste hat, passt also auf jedes Gerät, jeden Browser und jede Stunde in diesen Ländern.

Bedingung	Was der Worker liest
Land oder auszuschließende Länder	request.cf.country, von Cloudflare aus der IP des Besuchers gesetzt
Gerät: Mobil oder Desktop	den Client Hint Sec-CH-UA-Mobile, sonst den User-Agent; ein iPad zählt als Desktop
Betriebssystem, Browser	den User-Agent
Bot, Bot-Kategorie, bestätigt, Netzklasse	den Bot-Klassifizierer, beschrieben im nächsten Abschnitt
Stunde und Wochentag	die Uhr in UTC, nicht die Ortszeit des Besuchers
utm_source, andere Query-Parameter	den Query-String; eine Quellenliste und eine Parameterliste in derselben Regel passen, wenn eine von beiden passt
utm_campaign	den Query-String, als eigene Bedingung
Pfad	einen regulären Ausdruck auf den Pfad, ohne Query-String
Referrer	einen regulären Ausdruck auf den Header Referer

Die Stunden sind mit Absicht in UTC. Die Zähler werden nach UTC-Stunden gespeichert, und eine Regel in der Ortszeit des Besuchers würde sich über jede Stunde des Berichts verteilen. Wenn Sie „nachts in Deutschland“ wollen, rechnen Sie selbst in UTC um und denken Sie an die Zeitumstellung im März und im Oktober.

Das Paar aus utm_source und Parametern ist die einzige Stelle, an der eine Regel „oder“ sagt. Das Facebook-Preset passt auf utm_source=facebook oder darauf, dass fbclid vorhanden ist, denn Klicks aus bezahltem Social Traffic tragen oft fbclid und gar keine UTM-Tags.

Auf die IP-Adresse des Besuchers, eine bestimmte ASN-Nummer, die Browsersprache oder Cookies reagiert die TDS nicht. Brauchen Sie heute eines davon, kann eine Regel in 301.st das nicht.

Was eine Regel tun kann

Ein Redirect ist eine Antwort an den Browser. Der Worker sagt ihm, wohin, und ist fertig; der Browser verbindet sich dann selbst mit dem Ziel, wo immer es gehostet ist. Was dort passiert, sieht der Worker nicht. Deshalb braucht eine Conversion auf dem Ziel den Postback, von dem weiter unten die Rede ist.

Redirect. Mit dem Statuscode Ihrer Wahl: 301, 302, 307 oder 308. Ein permanenter Code sagt dem Browser, er soll sich die Antwort merken. Für eine TDS-Entscheidung, die vom Besucher abhängt, ist das falsch, deshalb nutzen die Presets 302. Jeder Redirect der TDS trägt außerdem Cache-Control: private, no-cache, damit kein gemeinsamer Cache die Antwort für einen Besucher dem nächsten ausliefert.

Der Redirect lässt sich auf fünf Arten senden: als einfacher HTTP-Redirect, als Meta-Refresh-Seite mit optionaler Verzögerung, als Meta-Refresh, der den Referrer versteckt, als JavaScript location.replace() oder als iframe, der Ihre Adresse in der Adressleiste lässt. Ein eigener Schalter fügt jeder dieser Arten Referrer-Policy: no-referrer hinzu. Das Verstecken des Referrers ist standardmäßig aus, denn manche Affiliate-Netzwerke ordnen über ihn zu und würden aufhören zu zählen, ohne jemandem Bescheid zu sagen.

Die Ziel-URL kann Makros enthalten, die der Worker aus der Anfrage füllt: {country}, {device}, {os}, {browser}, {path} und {host}. Eine Regel, die jedes Land auf https://example.net/{country}/ schickt, ist eine Regel und nicht zweihundert.

Block. Der Worker antwortet 403 Blocked, und Ihr Server sieht die Anfrage nie.

Split. Eine Split-Regel hat mehrere Ziel-URLs und wählt für jeden Besucher eine. Beim festen Split setzen Sie Gewichte, und 90 und 10 schicken neun von zehn Besuchern auf die erste Seite. Ein Gewicht von null pausiert eine Seite, ohne ihre Zahlen zu verlieren. Die drei anderen Modi lernen aus den Conversions, sobald sie eintreffen, und verschieben den Traffic zu der Seite, die besser konvertiert: Thompson Sampling (der Standard), UCB und Epsilon-Greedy. Ein Split kann außerdem getrennte Seitenpools pro Ländergruppe führen, damit der deutsche Traffic auf deutschen Seiten getestet wird.

Ein lernender Split muss wissen, welcher Besucher konvertiert hat. Dafür sorgt das signierte Klick-Token, das der Worker an die Ziel-URL hängt, und die Postbacks, die die Conversion zurückmelden. Wie man das mit einem Tracker oder einem Affiliate-Netzwerk einrichtet, ist ein eigenes Thema.

Wie die TDS Bots unterscheidet

Jede Anfrage durchläuft einen Klassifizierer, bevor eine Regel sie ansieht. Die Klassifizierung ordnet einen Bot anhand seines User-Agents einer von fünf Gruppen zu: Suchmaschinen, KI-Trainings-Crawler, Uptime-Monitore, Anzeigenprüfer und Abrufer für Linkvorschauen. Ein User-Agent mit weniger als zehn Zeichen gilt als Bot. Ein User-Agent mit bot, crawl oder spider darin, den keine Tabelle kennt, ist ein unbestätigter Bot ohne Gruppe.

Einen User-Agent kann jeder senden. Deshalb hält der Klassifizierer eine zweite, getrennte Antwort bereit: bestätigt oder nicht. Sie kommt nur von Cloudflare. Hat Cloudflare bestätigt, dass eine Anfrage wirklich von dem Bot stammt, der er zu sein behauptet, setzt Cloudflare request.cf.verifiedBotCategory (das Feld). Die Gruppe kommt aus der Tabelle der User-Agents, die Bestätigung von Cloudflare. Ein Scraper, der den User-Agent von Googlebot sendet, landet in der Gruppe der Suchmaschinen und bleibt unbestätigt.

Die dritte Antwort ist das Netz. Gehört das autonome System, aus dem die Anfrage kommt, einem Hosting- oder Cloud-Anbieter (AWS, Google, Azure, Hetzner, OVH, DigitalOcean und ähnliche), wird die Anfrage als Rechenzentrums-Traffic markiert. Menschen surfen aus Heim- und Mobilfunknetzen. Prüfdienste, Scraper und Review-Systeme laufen oft im Rechenzentrum, egal welchen Browser sie vorgeben.

Eine Regel kann das kombinieren: Bot oder nicht, welche Gruppen, bestätigt oder nicht, Rechenzentrum oder nicht.

Die Presets

Sie müssen Regeln nicht von Grund auf schreiben. 301.st liefert diese Vorlagen mit, jede davon eine einzelne Regel mit fertig gesetzter Priorität.

Preset	Passt auf	Tut
AI Guard	KI-Trainings-Crawler	blockt oder leitet auf eine Seite Ihrer Wahl um
Cloaking Standard	Anzeigenprüfer, Suchmaschinen, Abrufer für Linkvorschauen	leitet sie auf eine Seite Ihrer Wahl um (eine „White Page“)
Datacenter Cloak	jede Anfrage aus einem Rechenzentrumsnetz, Bot oder nicht	leitet sie auf eine Seite Ihrer Wahl um
Bot Shield	jeden Bot	blockt oder leitet um
Geo + Mobile	mobile Besucher aus den Ländern Ihrer Liste	leitet um
Mobile Redirect	mobile Besucher	leitet um
Desktop Redirect	Desktop-Besucher	leitet um
Geo Filter	Besucher aus den Ländern Ihrer Liste	leitet um
Facebook Traffic	utm_source facebook, fb, fb_ads oder meta, oder fbclid	leitet um
Google Traffic	utm_source google oder google_ads, oder gclid	leitet um
UTM Split	die utm_source-Werte Ihrer Liste	leitet um

AI Guard lässt Suchmaschinen mit Absicht in Ruhe. Sie haben ihre eigene Gruppe, und wer sie blockt, um Scraper auszusperren, nimmt die Website aus den Suchergebnissen.

Was die zwei Cloaking-Presets tun und welches Risiko sie tragen

Cloaking Standard und Datacenter Cloak zeigen den Systemen, die eine Website prüfen, eine Seite und den Menschen, die sie besuchen, eine andere. Genau das bedeutet das Wort, und wir benennen die Presets danach, damit niemand eines aus Versehen einschaltet.

Wissen Sie, worauf Sie sich einlassen. Die Spam-Richtlinien von Google definieren Cloaking als „presenting different content to users and search engines with the intent to manipulate search rankings and mislead users“. Google Ads nennt es in der Richtlinie Circumventing systems: „showing different content on your website to different people or to Google to try to hide things that might break Google Ads’ rules“. Die Strafe steht an derselben Stelle: Konten „will be suspended upon detection and without prior warning“. Andere Werbeplattformen haben Regeln derselben Art.

Dieselbe Seite von Google Ads zieht auch die Grenze für den Rest dieses Artikels. Dort steht „It’s okay to show slightly different content to different people, like showing a landing page or ad destination in different languages, having different special offers, or adjusting for geographical location“. Ihr verbotenes Beispiel ist ein Shop, der Google eine Seite mit Kleidung zeigt, während die Website Waffen verkauft. Eine Geo-Regel, die jedes Land für dasselbe Offer auf seine eigene Landingpage schickt, passt zur ersten Beschreibung. Auf welcher Seite eine bestimmte Regel liegt, ist Ihre Entscheidung und Ihr Risiko.

Wenn Sie sie nutzen, zählen zwei technische Punkte. Erstens passt Cloaking Standard auf den User-Agent, solange Sie nicht zusätzlich „bestätigt“ verlangen. Ohne diesen Schalter kommt ein Prüfer, der einen gewöhnlichen Browser-User-Agent sendet, zur echten Seite durch, und wer Googlebot in seinen User-Agent schreibt, bekommt die White Page. Zweitens erkennt Datacenter Cloak Netze am Namen des Anbieters, dem sie gehören. Das erwischt die großen Clouds und verpasst einen Anbieter, dessen Name nicht auf der Liste steht.

Was es im Free-Tarif kostet

Eine Route führt den Worker bei jeder Anfrage an den Hostnamen aus: für die Seite und für jedes Bild, jedes Stylesheet und jede Schrift, die sie lädt. Der oben beschriebene Bypass für statische Dateien spart Datenbankarbeit, keine Aufrufe. Der Workers-Free-Tarif erlaubt 100.000 Anfragen am Tag, zurückgesetzt um Mitternacht UTC (Limits).

Die Datenbank hat ein eigenes Tageskontingent. D1 im Free-Tarif enthält 5 Millionen gelesene und 100.000 geschriebene Zeilen am Tag (D1-Preise). Auf einer Domain mit Regeln liest jede Seitenanfrage die Einstellungen der Domain und schreibt mindestens eine Zählerzeile. Bei Seitenanfragen gehen beide Kontingente also bei ungefähr demselben Traffic zu Ende.

Was dann passiert, ist bei beiden verschieden.

Wenn D1 ausgeht, stoppen laut Cloudflare die Abfragen bis zum Reset. Die TDS behandelt eine gescheiterte Regelabfrage als „keine Regeln“ und reicht jede Anfrage an Ihren Server weiter. Ihre Website läuft weiter. Das Verteilen hört auf, und das Zählen auch.

Wenn die Workers ausgehen, entscheidet die Route. Eine Route läuft entweder offen weiter, „Bypasses the Worker. Requests behave as if no Worker is configured“, oder sie schließt, „Returns a Cloudflare 1027 error page“. 301.st setzt diesen Modus beim Anlegen der Route derzeit nicht. Öffnen Sie Workers & Pages im Dashboard von Cloudflare, suchen Sie die Routen von 301-tds und prüfen Sie den Modus an jeder. Für eine TDS vor einer laufenden Website ist „offen“ fast immer das Richtige: Ist das Kontingent aufgebraucht, erreichen Besucher Ihren Server unsortiert statt einer Fehlerseite.

Was das Aufheben beider Kontingente kostet. Der Workers-Paid-Tarif kostet $5 im Monat pro Konto, mit 10 Millionen Anfragen inklusive, danach $0,30 pro weitere Million (Preise). Ein Tageslimit für Anfragen gibt es dort nicht, und auch die Tageslimits von D1 fallen weg. Für eine TDS auf mehr als ein paar kleinen Domains ist das der richtige Tarif.

Der Artikel über Bot-Analytics-Worker rechnet dieselbe Routen-Arithmetik mit echten Zahlen dieser Website durch.

Einrichtung

1. Ziehen Sie die Zone zu Cloudflare um, falls sie noch nicht dort ist, und prüfen Sie, dass der Eintrag für den Hostnamen proxied ist. Lassen Sie ihn auf Ihren jetzigen Server zeigen.
2. Prüfen Sie den SSL-Modus gegen Ihren Server: Full (Strict), wenn der Server ein gültiges Zertifikat hat, Full bei irgendeinem Zertifikat, Flexible nur, wenn er keines hat.
3. Legen Sie ein API-Token an mit den Berechtigungen, die der Verbindungsdialog von 301.st auflistet, und verbinden Sie das Konto. Die Plattform legt die zwei Worker und die Datenbank an.
4. Tragen Sie die Domain ein, auf die Ihre Anzeigen zeigen: go.example.com mit der letzten Regel ohne Bedingungen wie oben beschrieben, oder die Hauptdomain, wenn Sie jeden Besucher verteilen wollen, und www als eigene Domain, falls Besucher sie nutzen.
5. Legen Sie eine Regel an, aus einem Preset oder von Hand, und drücken Sie Apply. Die Route entsteht mit der ersten aktiven Regel.
6. Stellen Sie die Route auf „offen“ im Dashboard von Cloudflare, außer Sie sind auf Workers Paid.
7. Testen Sie von außen. Der User-Agent ist die am leichtesten zu prüfende Bedingung:

curl -sI https://example.com/ | grep -i -E '^(HTTP|location)'
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) Mobile" \
  https://example.com/ | grep -i -E '^(HTTP|location)'

Die erste Anfrage sollte mit der normalen Antwort Ihres Servers zurückkommen, die zweite mit dem Redirect einer Mobil-Regel. Regeln nach Land brauchen eine Anfrage aus diesem Land, über ein VPN oder einen Remote-Browser. Geben Sie dem Regel-Cache nach Apply eine Minute.

Wann Sie überhaupt eine TDS brauchen

Brauchen Sie nur eine feste Bedingung, versuchen Sie es zuerst mit Cloudflare ohne Worker. Eine Single-Redirect-Regel ist ein Ausdruck in der Regelsprache von Cloudflare. Die hat Felder für das Land des Besuchers (ip.src.country) und den User-Agent (http.user_agent), und sie zählt auf kein Anfragekontingent. Der Free-Tarif gibt einer Zone zehn davon; alle Wege, auf Cloudflare weiterzuleiten, zeigt, was jede Option prüfen kann und was sie kostet. Der Worker lohnt sich, wenn die Entscheidung etwas braucht, das eine statische Regel nicht hat: bestätigte Bots von behaupteten unterscheiden, Traffic splitten und lernen, welche Seite konvertiert, jedes Ergebnis pro Regel und Stunde zählen und diese Regeln über ein ganzes Domain-Portfolio gleich halten. Für den letzten Teil gibt es 301.st, und die TDS ist das Stück davon, das vor Ihrem Server läuft.