Cloudflare Workers IP-Geolokalisierung: Caching
IP-Geolokalisierung auf Cloudflare Workers bedeutet, Standortdaten zu einem Besucher innerhalb eines Workers zu lesen, entweder aus dem eingebauten Objekt request.cf oder durch den Aufruf einer externen IP-Intelligence-API vom Edge aus. Beide Ansätze beantworten unterschiedliche Fragen, und das Caching- und Cold-Start-Verhalten jedes Ansatzes sollten Sie verstehen, bevor Sie darauf aufbauen.
Was Workers kostenlos mitbringt
Jede Anfrage, die einen Worker erreicht, trägt ein von Cloudflare befülltes Objekt request.cf. Es enthält Land, Stadt, Region, Koordinaten, Zeitzone, ASN und AS-Organisation des Besuchers sowie das Feld colo, das das Rechenzentrum benennt, das die Anfrage bearbeitet hat. Auch der Header CF-IPCountry trägt den Ländercode. Da diese Daten angehängt werden, bevor Ihr Code läuft, kosten sie keinen zusätzlichen Subrequest und keine zusätzliche Latenz.
Die Grenze liegt im Umfang. request.cf beschreibt den verbindenden Client der aktuellen Anfrage und sonst nichts. Es kann Ihnen nichts über eine IP-Adresse sagen, die in einer Logzeile, einem Formularfeld, einem Webhook-Payload oder einer X-Forwarded-For-Kette auftaucht, und es enthält keine Reputationssignale wie VPN-, Tor- oder Abuse-Flags. Sobald Sie eine beliebige Adresse anreichern müssen, rufen Sie eine API auf, und hier beginnen die Caching-Entscheidungen.
Anreicherungsdaten am Edge cachen
Eine IP-Abfrage aus einem Worker ist ein Subrequest, sodass jede ungecachte Abfrage dem Anfragepfad einen Netzwerk-Roundtrip hinzufügt. Cloudflare bietet mehrere Orte zum Cachen des Ergebnisses: die Cache API (pro Rechenzentrum, nicht global repliziert), KV (global lesbar, aber letztlich konsistent, wobei Schreibvorgänge Zeit zur Verbreitung brauchen) und Durable Objects, wenn Sie eine einzelne koordinierte Kopie brauchen. Keine davon ist ein Drop-in-Cache für den globalen Einsatz. Wählen Sie also danach, was Sie tolerieren können: Die Cache API ist am einfachsten und schnellsten für leseintensive Abfragen, während KV zu Werten passt, die von jedem Standort aus sichtbar sein sollen.
Die nützlichere Designentscheidung ist die Time-to-Live pro Feld, denn IP-Intelligence-Daten altern nicht gleichmäßig. Zuordnungen von Land und ASN ändern sich langsam, da Adressblöcke über Monate oder Jahre neu vergeben werden, daher ist eine TTL von vielen Stunden vertretbar. Reputations-Flags sind anders. Die VPN-, Tor- und Abuse-Feeds von ipto werden alle 6 Stunden aktualisiert und die IP- und ASN-Datensätze täglich. Ein Flag wie is_tor länger als ein paar Stunden zu cachen, heißt also, Antworten auszuliefern, die älter sind als die Quelle selbst. Eine praktische Aufteilung ist, die Netzwerkfakten (asn, asn_org, Land, Stadt) etwa einen Tag zu cachen und die Flags (is_vpn, is_tor, is_abuser, is_datacenter) höchstens so lange wie das Feed-Intervall.
- Den Cache auf der normalisierten IP aufbauen (bei IPv6 den /64 als Schlüssel erwägen, wenn Ihr Anwendungsfall pro Netzwerk statt pro Host gilt).
- Auch negative Ergebnisse cachen, damit wiederholte Abfragen einer nicht gelisteten Adresse nicht jedes Mal die API treffen.
- Bogon-Ergebnisse nie versehentlich unter einem öffentlichen Schlüssel cachen: Eine private Adresse wie
10.0.0.1lässt sich lokal ohne API-Aufruf beantworten.
Cold Starts auf Workers
Workers laufen in V8-Isolates statt in Containern, ein Cold Start dauert daher typischerweise Millisekunden und nicht die Hunderte Millisekunden, die man von containerbasierten Funktionen kennt. Ihr Code zahlt dennoch für seine eigene Initialisierung: Ein großes Bundle, aufwendiges Parsen einer großen Lookup-Tabelle auf Modulebene oder Top-Level-Awaits geschehen alle bei der ersten Anfrage an ein frisches Isolate. Die Abhilfe ist gewöhnlich: das Bundle klein halten, beim Start keine großen In-Memory-Strukturen aufbauen und einen einzelnen kleinen API-Aufruf dem Ausliefern einer ganzen Geolokalisierungsdatenbank im Worker vorziehen.
Die Warm-up-Pings, die man bei klassischem Serverless nutzt, sind hier größtenteils verschwendet. Isolates werden nach Cloudflares Zeitplan erstellt und verworfen, ein Ping erreicht nur einen Standort, und die Kosten eines Cold Starts sind so gering, dass das Cachen des Abfrageergebnisses weit wichtiger ist, als das Isolate am Leben zu halten. Messen Sie zuerst mit Workers Analytics und mit eigenen Zeitmessungen rund um den Subrequest, bevor Sie irgendetwas optimieren.
Zusammenspiel mit ipto
Ein sinnvolles Muster ist, request.cf für die sofortigen, kostenlosen Fakten über den verbindenden Client zu verwenden und eine Anreicherungs-API nur aufzurufen, wenn Sie mehr brauchen. Die API-Dokumentation von ipto zeigt die Antwort der IP-Abfrage, die Land, Stadt, ASN, org, currency_code und die Flags is_vpn, is_tor, is_abuser, is_datacenter und bogon/bogon_type liefert. Sie ist kostenlos, ohne Registrierung und mit 1.000 kostenlosen Anfragen pro Tag nutzbar, was genügt, um einen Worker ohne Schlüsselverwaltung zu prototypen.
Zeigt die Abfrage, dass die Adresse zu einem Hosting-Netzwerk gehört, können Sie in der ASN-Abfrage nachsehen, wer es betreibt und welche Ranges es announct. Bei markiertem Traffic zeigt der VPN-, Tor- und Proxy-Checker die Belege hinter is_vpn und is_tor, und der IP-Abuse-Checker den bestätigten Score. Bedenken Sie, dass der Standort auf Stadtebene eine Schätzung ist, wo ein Netzwerk registriert oder geroutet wird, und nicht, wo eine Person sitzt, eine Einschränkung, die warum die Genauigkeit auf Stadtebene begrenzt ist erklärt.
Der Edge macht Abfragen schnell, aber er macht die zugrunde liegenden Daten nicht präziser. Behandeln Sie request.cf und jedes API-Ergebnis als Belege derselben Klasse, cachen Sie jedes danach, wie schnell es sich ändert, und lassen Sie die Aktualität der Quelle, nicht die Geschwindigkeit des Edge, Ihre TTLs bestimmen.