Alle Standorte aktiv · 99.99% Uptime
Netzwerktechnik

Wie funktioniert die Gateway-(Backconnect-)Architektur?

Wenn Sie einen Residential Proxy kaufen, erhalten Sie keine Liste mit Tausenden IP-Adressen. In der Regel bekommen Sie eine einzige Adresse: gateway.saglayici.com:8000. Dennoch sehen Sie bei jeder Anfrage eine andere Exit-IP. Diese Architektur nennt man Backconnect-Gateway , und nahezu alle modernen Proxy-Dienste arbeiten so.

In diesem Beitrag behandeln wir die interne Funktionsweise des Gateways, die Umsetzung des Session-Routings und die Unterschiede zum Modell mit direkten IPs.

Die Grundidee

Das Gateway ist ein fester Eingangspunkt, mit dem Sie sich verbinden. Dahinter stehen Tausende Exit-Nodes. Sie senden die Anfrage an das Gateway, das Gateway leitet sie an einen aus dem Pool ausgewählten Exit-Node weiter und bringt die Antwort zu Ihnen zurück.

ABBILDUNGBackconnect-Gateway-Architektur
Die Komponenten einer Datacenter-Proxy-InfrastrukturIhr Clientverbindet sich mit einer einzigen AdresseSession-ManagerSchlüssel → Node-ZuordnungTR-Exit-NodesTausende AdressenDE-Exit-NodesTausende AdressenUS-Exit-NodesTausende AdressenHealth-Monitoringsortiert tote Nodes ausGatewayeinziger Eingangspunkt

In Ihrer Konfiguration gibt es nur eine einzige Adresse; die gesamte Komplexität wird hinter dem Gateway verwaltet. Das vereinfacht die Client-Seite radikal.

Drei Wege, dem Gateway Anweisungen zu geben

Sie müssen dem Gateway mitteilen, aus welchem Land und mit welcher Session-Kennung der Exit erfolgen soll. In der Branche werden drei Verfahren eingesetzt:

ABBILDUNGWie werden Gateway-Parameter übergeben?
METHODEEinbettung in den Benutzernamenmusteri-country-tr-session-a1Eine Adresse, ein Port genügenErfordert keine CodeänderungEin Tippfehler ändert das Verhalten unbemerktDie verbreitetste MethodePortbasierte Auswahlgateway:10001 → Session 1gateway:10002 → Session 2Zugangsdaten bleiben unverändertDer Portbereich muss dokumentiert seinPraktisch bei einfachen Clients

Die dritte Methode ist der API-Aufruf: Die Session wird zunächst per API erstellt, dann verbindet man sich mit der zurückgegebenen Kennung. Das ist flexibel, erfordert aber einen zusätzlichen Request-Durchlauf.

Die Methode, Parameter in den Benutzernamen einzubetten, haben wir in unserem Beitrag zur Authentifizierung ausführlich gezeigt.

Der Weg einer Anfrage innerhalb des Gateways

ABBILDUNGDie Phasen einer Anfrage, die über das Gateway läuft
LEBENSZYKLUS01Authentifizierungprüfen~2 msBenutzername/Passwortoder Whitelist02Um Chrome mit einem bestimmten Proxy zu starten:Parsing~1 msLand, Session,TTL werden gelesen03Node-Auswahl~3 mspassender Exitaus dem gesunden Pool04Weiterleitung an den ExitvariabelHier entsteht die eigentliche Netzwerklatenz05Antwortübertragungvariabelzurück über das GatewayGesamtdauer →

Die reine Verarbeitungszeit des Gateways liegt typischerweise bei wenigen Millisekunden. Der Großteil der Gesamtlatenz entsteht durch die Entfernung zwischen Exit-Node und Ziel.

Hinweis zur Latenz

Das Gateway-Modell fügt naturgemäß einen zusätzlichen Hop hinzu: Sie → Gateway → Exit → Ziel. Gegenüber dem Modell mit direkter IP sind 10–40 ms zusätzliche Latenz normal. Im Gegenzug werden Ihnen Pool-Verwaltung, Health-Checks und Rotation vollständig abgenommen.

Vergleich zwischen Gateway und dem Modell mit direkten IPs

ABBILDUNGVergleich der beiden Bereitstellungsmodelle
VERGLEICHGateway (Backconnect)Liste direkter IPsKonfigurationEinzelne AdresseListenverwaltung erforderlichPool-VerwaltungBeim AnbieterBei IhnenHealth-CheckAutomatischRichten Sie selbst einLatenzEin Hop mehrKürzester WegVorhersehbarkeit der IPNiedrigVolle KontrolleEignung für WhitelistsSchwierigEinfachTypische NutzungResidential, mobilISP, Datacenter

Wenn Sie dem Zielsystem Ihre eigene IP bekannt machen müssen (Whitelist, API-Zugriff), ist das Modell mit direkter IP zwingend; beim Gateway ist das nicht möglich, da die Exit-IP wechselt.

Für Szenarien, die eine statische IP erfordern, ISP Proxy und Datacenter Proxy arbeiten unsere Produkte mit dem Modell der direkten IP.

Die interne Mechanik des Session-Routings

Das Gateway muss sicherstellen, dass Anfragen mit demselben Session-Schlüssel zum selben Exit-Node gelangen. Dafür nutzt es eine Zuordnungstabelle:

ABBILDUNGDas Leben eines Session-Schlüssels im Gateway
SESSIONNEUNode zuweisenSchlüssel zum ersten MalgesehenVERBUNDENAnfragen laufenSchlüssel → NodezugeordnetTTL-ENDEZuordnung wird gelöschtZeit abgelaufenERNEUTneuer Node wird zugewiesenFällt der Node aus, erfolgt die Neuzuweisung, ohne das TTL abzuwarten

Genau deshalb ist eine Sticky Session keine „Garantie“, sondern ein „Best Effort“: Fällt der zugewiesene Node aus dem Netz, muss das Gateway zwangsläufig auf einen neuen Node wechseln.

Vorteile und Grenzen des Gateway-Modells

Vorteile

  • Die clientseitige Konfiguration reduziert sich auf eine einzige Zeile.
  • Pool-Gesundheit, Aussortieren toter IPs und Rotation liegen beim Anbieter.
  • Geo-Targeting lässt sich per Parameter sofort ändern.
  • Zugriff auf Millionen IPs über eine einzige Adresse.
  • Beim Skalieren sind keine Codeänderungen nötig.

Grenzen

  • Etwas höhere Latenz durch den zusätzlichen Hop.
  • Die Exit-IP ist unvorhersehbar — eine Whitelist ist nicht möglich.
  • Das Gateway ist ein Single Point of Failure.
  • Sie wissen nicht im Voraus, welche IP verwendet wird.
  • Die Fehlersuche wird abstrakter.

Fehlersuche bei Gateway-Nutzung

Um bei Problemen die Frage „welcher Exit-Node hat diesen Fehler verursacht“ beantworten zu können, müssen Sie die Exit-IP jeder Anfrage protokollieren. Andernfalls können Sie keine zielbezogene Quarantäne einrichten und problematische Nodes nicht an den Anbieter melden.

ABBILDUNGAufzeichnungen, die Sie bei Gateway-Nutzung führen sollten
LOGSession-SchlüsselMit welchem Schlüssel die Anfrage gesendet wurdeExit-IPAus dem Antwort-Header oder einer KontrollanfrageZiel und StatuscodeFür die Verteilung von 403/429Latenz (ms)Zur Berechnung von p50/p95Angefordertes LandKontrolle der Targeting-GenauigkeitVersuchsnummerUm die Kosten von Wiederholungsversuchen zu sehen

Die Exit-IP bei jeder Anfrage zu ermitteln, ist kostspielig. Die praktische Lösung: bei jedem neuen Session-Schlüssel einmal eine Kontrollanfrage senden und die IP dieser Session zuordnen.

Geo-Targeting und Gateway-Standort

Der physische Standort des Gateways beeinflusst die Latenz unmittelbar. Wenn Sie aus der Türkei arbeiten und einen europäischen Exit nutzen, senkt die Wahl eines in Europa gelegenen Gateways die Gesamtdauer deutlich.

ABBILDUNGEinfluss des Gateway-Standorts auf die Latenz
ROUTETRIstanbul (Sie)0 msDEFrankfurt-Gateway38 msDEDeutscher Exit-Node52 msDEZielserver61 msLiegen Gateway und Exit-Node in derselben Region, sinken die Kosten des zusätzlichen Hops auf wenige Millisekunden; liegen sie auf verschiedenen Kontinenten, können sie hundert Millisekundenüberschreiten.

Bietet Ihr Anbieter mehrere Gateway-Standorte an, wählen Sie den Ihrer Zielgruppe nächstgelegenen. Für die Standortoptionen unsere Standortseite können Sie nachlesen.

Zusammenfassung

Die Gateway-Architektur ermöglicht den Zugriff auf Millionen IPs über eine einzige Adresse; die Komplexität von Pool-Verwaltung, Health-Checks und Rotation geben Sie an den Anbieter ab. Im Gegenzug nehmen Sie einen Hop Latenz und den Kontrollverlust über die Exit-IP in Kauf. Bei Aufgaben, die eine Whitelist erfordern oder auf minimale Latenz zielen, ist das Modell mit direkter IP die richtige Wahl, bei Aufgaben, die Flexibilität und geografische Breite erfordern, das Gateway-Modell. Um Ihre Konfiguration zu überprüfen Ob ein Datacenter-Proxy ausreicht, haengt vom Schutzniveau des Ziels ab — und das laesst sich messen. Nehmen Sie die direkte Verbindung als Referenz und testen Sie vergleichend mit derselben Rate; waehlen Sie die Stufe anhand der Erfolgsquote. Eine Logik zur gestuften Hochstufung aufzubauen und pro Ziel Statistiken zu sammeln, minimiert sowohl die Kosten als auch den Geschwindigkeitsverlust. Zum Einstieg koennen Sie können Sie nutzen.

Häufig gestellte Fragen

01Wie erfahre ich bei Gateway-Nutzung meine Exit-IP?

Senden Sie pro Session einmal eine Anfrage an einen neutralen Endpoint zur IP-Rückmeldung und markieren Sie die zurückgegebene Adresse für diese Session. Eine Abfrage bei jeder Anfrage ist sowohl hinsichtlich Kontingent als auch Zeit ineffizient.

02Warum ist das Gateway-Modell langsamer?

Der Traffic läuft von Ihnen zum Gateway, von dort zum Exit-Node und weiter zum Ziel. Im Modell mit direkter IP entfällt eine Zwischenstation. Der Unterschied liegt typischerweise bei 10–40 ms und verringert sich, wenn Gateway und Exit in derselben Region liegen.

03Kann ich die Gateway-Adresse in eine IP-Whitelist eintragen?

Wenn Sie im Zielsystem eine Whitelist pflegen müssen, ist das Gateway-Modell ungeeignet, denn die Adresse, die das Ziel sieht, ist die sich ständig ändernde Exit-IP. In diesem Szenario benötigen Sie einen ISP- oder Datacenter-Proxy mit statischer IP.

04Kann ich denselben Session-Schlüssel in zwei verschiedenen Prozessen verwenden?

Technisch ja; beide werden zum selben Exit-Node geleitet. Das verdoppelt jedoch die Anfragelast auf diesem Node und erhöht das Risiko von Rate Limits.

05Was passiert, wenn das Gateway ausfällt?

Da es nur einen Eingangspunkt gibt, kommt Ihr gesamter Traffic zum Erliegen. Bei kritischen Abläufen erhöht eine zweite Gateway-Adresse (sofern vorhanden, in einer Ersatzregion) oder ein zweiter Anbieter die Ausfallsicherheit erheblich.

Verwandte Beiträge und Seiten

NÄCHSTER SCHRITT

Stärken Sie Ihre Proxy-Infrastruktur noch heute.

Starten Sie mit den kostenpflichtigen Paketen in wenigen Minuten oder testen Sie zuerst unsere kostenlose Proxy-Liste.

FREEPROXY.TR

Wenn Sie einen kostenlosen Proxy suchen, sind Sie hier richtig

Eine umfassende Proxy-Plattform: aktuelle kostenlose Proxy-Adressen ansehen, HTTP- und SOCKS-Proxy-Typen vergleichen und Ihre Proxy-Verbindungen mit kostenlosen Tools prüfen.