So wählst du einen Proxy-Standort und eine Datacenter-Stadt

Sollte der Proxy nahe der Website oder nahe der Nutzer sein?

Setze den Proxy nahe der Website, wenn dir Geschwindigkeit wichtig ist, und nahe der Nutzer, wenn dir wichtig ist, was sie sehen. Die beiden Ziele können auf verschiedene Städte zeigen.

• Geschwindigkeitsaufgaben (eine API überwachen, viele Seiten abrufen): Jede Anfrage durchläuft den Pfad Proxy–Website, ein kurzer Pfad spart also bei jeder einzelnen Zeit.
• Lokale Ansicht (Preise, Suchergebnisse, Anzeigen, Sprach-Weiterleitungen): Die Website entscheidet anhand des Landes der IP, was sie anzeigt. Wähle das Land der Zielgruppe, dann die nächstgelegene Rechenzentrumsstadt in diesem Land.
• Zugriff über Allowlist: Den Partner interessiert nur, dass die IP auf seiner Liste steht. Wähle eine Stadt nahe den Servern des Partners und behalte bei der Verlängerung möglichst dieselben IPs.

Im Zweifel miete eine IP in jeder Kandidatenstadt und messe; dafür ist der 1 IP-Plan gedacht.

Warum ändert ein CDN die Antwort?

Ein Content Delivery Network antwortet vom Edge-Server, der dem Besucher am nächsten ist, die "Hosting-Stadt" einer Website hinter einem CDN ist also dort, wo du stehst. Viele große Websites veröffentlichen eine IP, die aus Dutzenden Städten gleichzeitig angekündigt wird (Anycast). Dein Traffic erreicht die nächstgelegene.

Für einen Proxy bedeutet das zwei Dinge. Erstens erreicht fast jede Rechenzentrumsstadt schnell einen CDN-Edge, weil CDNs ihre Edges in denselben Hubs wie Rechenzentren bauen. Zweitens hängt der Inhalt, den der Edge ausliefert, vom Land deiner IP ab. Wähle bei Websites hinter einem CDN also zuerst das Land und dann die Stadt.

Wie viel Latenz fügt Entfernung hinzu?

Jede 100 km Luftlinie fügen mindestens 1 ms zur Roundtrip-Zeit hinzu, weil Licht in Glasfaser etwa 200 km pro Millisekunde zurücklegt und ein Roundtrip die Strecke zweimal überwindet. Die folgende Tabelle gibt diese Untergrenze für gängige Paare an.

Die Entfernungen sind Großkreis- (Luftlinien-)Entfernungen, berechnet aus den Koordinaten der Stadtzentren. Es sind Untergrenzen: Reale Kabel sind länger, und jeder Router auf dem Weg fügt etwas hinzu. Wie weit über der Untergrenze ein realer Pfad landet, hängt von der Route ab, miss also selbst.

Wie messe ich die echte Latenz durch einen Proxy?

Messe sie mit den Timing-Variablen von curl, mehrmals hintereinander, durch jede Kandidaten-IP. Der Befehl unten gibt die Zeit bis zum Proxy, die Zeit bis zum abgeschlossenen TLS-Handshake mit der Website und die Gesamtzeit aus:

curl -s -o /dev/null -x http://USERNAME:PASSWORD@IP:PORT -w "%{time_connect} %{time_appconnect} %{time_total}\n" https://example.com

Durch einen Proxy ist time_connect die Strecke von dir zum Proxy. Die Differenz zwischen time_connect und time_appconnect umfasst den Tunnelaufbau und den TLS-Handshake mit der Website – also den Teil, den die Datacenter-Stadt verändert. Vergleiche den Median aus fünf Läufen, nicht einen einzelnen Lauf. Die Codebeispiele zeigen einen Timing-Test in Python.