Wie sich Kontosperren bei KI-Relay-Diensten wirksam reduzieren lassen

Wokey Team · 2026-06-27

Die Modellanbieter haben kürzlich eine massive Welle von Kontosperren durchgezogen – so breit, dass sogar einzelne Nutzer mit legitimer Nutzung ins Kreuzfeuer gerieten.

Wenn du einen Relay-Dienst betreibst oder dir gerade einen aussuchst, lohnt es sich, ernsthaft darüber nachzudenken: Sind Sperren eine Frage des Glücks oder eine Frage der Architektur?

Meine Antwort ist Letzteres. Sperrquoten sind kein Zufall – die Architektur bestimmt sie.

Treten wir einen Schritt zurück. Wenn Anbieter entscheiden, ob ein Konto geteilt oder weiterverkauft wird, achten sie typischerweise auf diese Signale:

• IP-Wechsel und IP-Typ – deine Anfragen springen plötzlich von einer Privatanschluss-IP zu einer Rechenzentrums-IP oder wechseln zwischen verschiedenen Standorten.
• Auffälliges Verhalten – Aufrufhäufigkeit, Parallelität und zeitliche Verteilung, die eindeutig nicht nach einer einzelnen Person aussehen.
• Mehrere Konten mit gemeinsamem Ausgang – die Anfragen von Dutzenden Konten laufen über dieselbe Gruppe von IPs.
• Auffälliger Client-Fingerabdruck – Request-Header, TLS-Fingerabdruck und Gerätemerkmale, die nicht zu einem normalen Client passen.

Kommen diese Signale zusammen, markiert das Risikosystem des Anbieters dein Konto.

Fragst du aber, welches Signal am meisten Gewicht hat und am leichtesten zu erkennen ist – ich würde sagen: die IP.

Der Grund ist einfach: Die IP ist das äußerste und günstigste Prüfkriterium. Eine Anfrage von einer Privatanschluss-IP und eine von einer Rechenzentrums-IP gehören für ein Risikosystem zu völlig verschiedenen Risikostufen. Rechenzentrums-ASN, IP-Sprünge und geografische Auffälligkeit – treten diese drei zusammen auf, sagt das dem Risikosystem praktisch: „Das ist kein normaler Nutzer.“

Ehrlich gesagt tritt die Architektur herkömmlicher Relay-Dienste genau auf diese Mine: Alle Anfragen verlassen das Netz über die Server des Relays, und Dutzende Konten teilen sich dieselbe Gruppe von Rechenzentrums-IPs. Egal, wie du die Last verteilst oder deinen Proxy-Pool rotierst, der Ausgangspunkt ist im Kern ein Serverraum. Ich habe mir die Lösungen anderer Relay-Betreiber angesehen – sie rotieren fleißig Proxys, aber ein kurzer ASN-Lookup zeigt, dass alles Cloud-Anbieter sind. Andere Maske, dasselbe Gesicht.

Deshalb wechseln manche zwischen drei Relay-Diensten und werden bei jedem alle zwei Wochen gesperrt – das ist kein Pech, sondern jeder Dienst hat dieselbe Architektur.

Wie hältst du die IP also unverändert?

Für einzelne Nutzer gibt es bereits einen bewährten Ansatz: Betreibe ein zentrales Gateway wie New API oder One API auf einem NAS zu Hause, oder nutze Tools wie sam-to-API, und leite alle Anbieter-APIs darüber. Dein Smartphone, dein Laptop, jeder Client, der ein Modell aufruft – keiner davon spricht direkt mit dem Anbieter. Stattdessen laufen sie über dein Gerät zu Hause, das an die API des Anbieters weiterleitet. So ist die Ausgangs-IP aus Sicht des Anbieters immer die IP deines Heimanschlusses, egal welches Modell du aufrufst – nicht davon zu unterscheiden, dass du zu Hause sitzt und es ganz normal nutzt.

Und wenn du unterwegs bist? Leite den Traffic deines Smartphones oder Laptops mit Mesh-Networking-Tools wie Tailscale oder WireGuard zuerst zurück zum NAS zu Hause und von dort hinaus. Ob im Café, im Büro oder im Zug: Deine Anfragen verlassen das Netz weiter über deinen Heimanschluss. Der Anbieter sieht deine IP nie springen, nur weil du das WLAN gewechselt oder mobile Daten eingeschaltet hast.

Dieser Ansatz ist in der fnOS-Community und der Self-Hosting-Szene rund um KI gut erprobt, mit vielen Tutorials und Anwendern. Für einzelne Nutzer ist er derzeit die zuverlässigste Lösung, um die IP festzuhalten.

Das löst aber nur das Problem einer einzelnen Person.

Ein Relay-Dienst verwaltet Konten von Dutzenden oder Hunderten Providern. Du kannst nicht zu jedem nach Hause fahren, ein NAS installieren und ein Gateway konfigurieren. Du brauchst eine systematische Lösung, bei der jeder Provider einen schlanken Node installiert und sich mit der Plattform verbindet – die Anfragen verlassen das Netz weiter über den eigenen Anschluss des Providers, aber die Verteilung der Aufträge und das Routing des Traffics übernimmt zentral die Plattform.

Diese Architektur heißt Provider-seitiger Ausgang – die Anfragen verlassen das Netz über den eigenen Anschluss des Providers, nicht über die Server des Relays.

Ein Vergleich: Der NAS-Ansatz ist wie ein eigener kleiner Laden an der Straße – du versendest von zu Hause und kümmerst dich um Einkauf, Auswahl und Bestellungen ganz allein. Ein Provider-Node ist wie der Beitritt zu einem Franchise einer Plattform – du versendest weiter von zu Hause, aber die Bestellungen weist dir die Plattform zu. Die Versandadresse ändert sich nicht; es ändert sich, wer die Bestellungen verteilt.

Genau das macht der Wokey Provider-Node.

Die Installation ist einfach – ein einziger Befehl, für macOS, Linux, Windows und Docker. Öffne nach der Installation die lokale Konsole, verknüpfe dein Wokey-Konto und importiere deine lokalen Abo-Zugangsdaten. Sobald der Node läuft, hält er eine WebSocket-Verbindung zur Wokey-Plattform. Die Plattform schickt Nutzeranfragen hinüber, und der Node stellt die Anfrage an die API des Anbieters lokal. Der gesamte Vorgang läuft über die eigene IP des Providers – für den Anbieter sieht das genauso aus, als würde der Provider sein eigenes Abo ganz normal nutzen.

Zu den derzeit unterstützten Anbietern gehören OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI und weitere.

Nachdem ich diese Architektur selbst betrieben habe, ist die naheliegendste Erkenntnis: Sie „bekämpft“ die Risikokontrollen nicht – sie löst die Voraussetzungen für eine Risikoerkennung schlicht gar nicht erst aus. Aus Sicht des Anbieters ist das einfach ein normaler Nutzer, der zu Hause sein eigenes Abo verwendet, und es gibt nichts Auffälliges zu erklären.

Das gesamte Projekt ist Open Source unter Apache-2.0, und die Whitelist der Ausgänge ist fest im Quellcode verankert. Es ist nicht sicher, weil ich das sage – es ist sicher, weil jede Zeile Code überprüfbar ist.

Natürlich behaupte ich nicht, dass ein Provider-seitiger Ausgang null Sperren garantiert. Die IP ist nur einer der Faktoren für Sperren – auch Aufrufhäufigkeit, Parallelitätsmuster und zeitliche Verteilung können Risikokontrollen auslösen. Keine Lösung kann eine Sperrquote von null garantieren.

Die Logik ist aber klar: Solange du das größte Signal nicht angegangen bist, baut jede andere Optimierung auf Sand.

Der Schlüssel zu niedrigeren Sperrquoten ist, dass deine Nutzung von normaler Nutzung nicht zu unterscheiden ist. Die IP unverändert zu halten ist dabei der wichtigste Baustein. Einzelne Nutzer haben Lösungen für Einzelne; Relay-Dienste brauchen einen systematischen Ansatz mit Provider-seitigem Ausgang.

Wenn der Wettbewerb unter Relays sein Endspiel erreicht, wird es nicht darum gehen, wer mehr Modelle oder niedrigere Preise hat – sondern darum, wessen Architektur dafür sorgt, dass der Anbieter nicht erkennen kann, dass du ein Relay bist. Der Dienst, den du gerade nutzt – über wessen Netz verlassen die Anfragen das System?