Proxys für Lasttests in k6 und JMeter

Wenn ein Lasttest an Rate-Limits, WAF oder geografischer Lastverteilung scheitert, ist der erste Gedanke: „Ich lasse den Verkehr von verschiedenen IPs laufen“. Das klingt logisch, aber in der Praxis lösen Proxys in k6 und JMeter nur einen engen Satz von Aufgaben, während der Rest immer noch durch die Architektur des Tests behoben werden muss. In diesem Artikel werden wir besprechen, wie man Proxys technisch an beide Tools anschließt, welche IP-Typen dafür geeignet sind und wo die Verantwortung des Proxy-Servers endet.

Warum benötigt ein Lasttest verschiedene IPs

Standardmäßig senden k6 und JMeter gesamten Verkehr von einer IP-Adresse — dem Server, auf dem der Test läuft (oder einer Cloud-Maschine in CI/CD). Das ist in 90% der Szenarien in Ordnung, aber in einigen Fällen reicht eine IP nicht aus:

Rate-Limiting auf IP-Ebene. Viele APIs und Lastverteiler (nginx limit_req, AWS WAF, Cloudflare) begrenzen die Anzahl der Anfragen von einer Adresse pro Sekunde. Echte Benutzer kommen von Tausenden verschiedener IPs, während Ihr Test von einer einzigen kommt — und erreicht das Limit früher als das tatsächliche Flaschenhals des Anwendungsservers.
Testen von geoabhängiger Logik. CDN, zielgerichtete Inhalte, regionale Preise, Geo-Blockierungen — all dies muss mit IPs aus bestimmten Ländern überprüft werden, nicht aus dem Rechenzentrum, in dem Ihr Test-Runner physisch steht.
Überprüfung des Lastverteilers und des Anycast-Netzes. Wenn die Infrastruktur den Verkehr basierend auf der IP des Clients auf Regionen verteilt, wird ein Test von einer Adresse nur einen Pfad überprüfen, nicht das gesamte Netzwerk.
Simulation einer realen Verkehrverteilung. Bei Produktionsverkehr sind IPs über Anbieter, Subnetze und manchmal über Mobilfunkanbieter verteilt — dies beeinflusst das Verhalten von CDN, Caches und Edge-Logik.

Es ist wichtig, sofort zu unterscheiden: Wenn Sie die Leistung des Backends testen (wie viele RPS Ihr API aushält), sind Proxys fast nie erforderlich — dort zählt die reine Last, nicht die Vielfalt der Quellen. Proxys sind notwendig, wenn das Testszenario genau von der IP-Adresse des Clients abhängt.

Welche Proxys sind geeignet: Datacenter, Residential, Mobile

Die Wahl des Proxy-Typs hat direkten Einfluss darauf, was genau Sie testen — die Bandbreite der Infrastruktur oder das Verhalten des Systems unter „lebendigen“ IPs.

Proxy-Typ	Latenz und Geschwindigkeit	Wann in Lasttests verwenden
Datacenter-Proxys	Niedrige Latenz, hohe Bandbreite	Überprüfung von Rate-Limits, Umgehung des Limits „N Anfragen von IP“, Erzeugung eines großen Volumens an RPS aus verschiedenen Subnetzen
Residential-Proxys	Höhere Latenz, Geschwindigkeit begrenzt durch den Kanal des echten Benutzers	Testen von Geo-Logik, Überprüfung von CDN und Anti-Bot-Systemen, die Residential-Bereiche mehr vertrauen als Datacenter
Mobile Proxys	Höchste Latenz, instabile Geschwindigkeit	Nischen-Szenarien: Testen von mobilen APIs, Verhalten bei häufigem IP-Wechsel (Anbieter ändern die Adresse des Clients dynamisch)

Für eine reine Überprüfung von RPS und Rate-Limits sind Datacenter-Proxys fast immer ausreichend — sie bieten stabile niedrige Latenz und verzerren die Testergebnisse nicht durch externe Netzwerkinstabilität. Residential- und mobile IPs fügen den Geo-Tests Realismus hinzu, bringen jedoch eigene Latenz mit sich, die bei der Analyse der Metriken berücksichtigt werden muss — andernfalls kann man leicht „Proxy-Netzwerk verlangsamt“ mit „Ihr Server verlangsamt“ verwechseln.

Proxy-Einrichtung in k6

k6 ist ein Tool auf JavaScript (die Engine ist in Go geschrieben, die Skripte werden in JS geschrieben), und standardmäßig gibt es keine integrierte Unterstützung für HTTP-Proxys über Skriptoptionen: Proxys in k6 werden über Umgebungsvariablen oder Systemeinstellungen festgelegt, da k6 unter der Haube den Go HTTP-Client verwendet.

Der einfachste Weg sind Umgebungsvariablen:

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

Diese Methode leitet den gesamten Testverkehr über einen Proxy — geeignet, wenn Sie einfach von der „weißen“ IP des Servers wegkommen möchten. Wenn die Aufgabe jedoch darin besteht, virtuelle Benutzer (VU) auf verschiedene IPs zu verteilen, benötigen Sie eine Liste von Proxys und eine Auswahl-Logik auf Skriptebene. k6 unterstützt nicht direkt per-VU-Proxys „out of the box“, daher ist ein verbreiteter Workaround, mehrere k6-Prozesse parallel zu starten, jeder mit seiner eigenen Umgebungsvariablen und seinem Proxy aus dem Pool:

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

Dieser Ansatz lässt sich gut skalieren in Verbindung mit k6 Cloud oder Orchestrierung über Kubernetes/Docker Compose — jeder Container wird mit seiner eigenen Proxy-Variable gestartet. Wenn eine IP-Rotation innerhalb eines Skriptlaufs erforderlich ist, ist es logischer, Proxys mit Rotation auf der Seite des Proxy-Anbieters (sticky session mit TTL) zu verwenden, anstatt die Rotation im JS-Code zu implementieren.

Proxy-Einrichtung in JMeter

In JMeter wird der Proxy nativ ohne Umgebungsvariablen über das Element HTTP Request Defaults oder direkt in den Einstellungen des HTTP Request Samplers konfiguriert:

Fügen Sie das Konfigurationselement HTTP Request Defaults zur Thread-Gruppe hinzu.
Geben Sie im Feld Proxy Server den Host und den Port des Proxys an.
Wenn der Proxy eine Authentifizierung erfordert — fügen Sie das Element HTTP Authorization Manager mit Benutzernamen und Passwort für diesen Host hinzu.
Alle HTTP Request Samplers innerhalb der Thread-Gruppe erben automatisch die Proxy-Einstellungen.

Um die Last auf mehrere Proxys in JMeter zu verteilen, ist es praktisch, CSV Data Set Config zu verwenden — eine Datei mit einer Liste von Proxys wird in die Variablen für Host und Port für jeden Thread eingefügt:

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

Verbinden Sie CSV Data Set Config mit der Thread-Gruppe, geben Sie die Variablen ${proxy_host} und ${proxy_port} in den Feldern Proxy Server/Proxy Port des Samplers an — jeder JMeter-Thread nimmt seine Zeile aus der Datei und geht über seine IP. Für den Start über die Kommandozeile (Headless-Modus, was für echte Lasttests empfohlen wird) können Proxys auch über Flags übergeben werden:

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

Diese Methode legt einen gemeinsamen Proxy für den gesamten Test fest — für Multi-Proxy-Szenarien müssen Sie dennoch CSV Data Set Config oder Distributed Testing (mehrere JMeter-Slaves, jeder mit seinem eigenen Proxy in der Konfiguration) verwenden.

IP-Rotation und Lastverteilung

Es gibt zwei grundlegend unterschiedliche Ansätze zur Verteilung von IPs in einem Lasttest:

Statische Bindung von IP an Thread/VU. Jeder virtuelle Benutzer erhält die gleiche IP für die gesamte Sitzung — simuliert einen echten Benutzer mit einer Adresse. Wird über Sticky-Session-Proxys oder einfach über eine feste Liste in CSV/Umgebungsvariablen konfiguriert.
IP-Rotation bei jeder Anfrage. Der Proxy ändert die ausgehende Adresse bei jeder HTTP-Anfrage — nützlich zur Überprüfung des Schutzes gegen Rate-Limits, spiegelt jedoch nicht das tatsächliche Verhalten von Benutzern wider, deren IP nicht jede Sekunde wechselt.

Für einen realistischen Lasttest ist es in 90% der Fälle sinnvoller, die IP für die gesamte Sitzung an VU/Thread zu binden — so spiegelt der Test das Verhalten vieler unabhängiger Benutzer wider und erzeugt keinen künstlichen Lärm. Die Rotation bei jeder Anfrage sollte nur in engen Szenarien aktiviert werden — beispielsweise bei gezielter Überprüfung der Auslösung von Rate-Limit-Regeln.

Was Proxys definitiv nicht ersetzen

Hier ist der Schlüsselpunkt des Artikels: Proxys lösen das Problem „Von welcher IP kommt die Anfrage?“, lösen jedoch nicht die Probleme, die das Lasttesten tatsächlich überprüft.

Die Bandbreite Ihres Test-Runners. Wenn der Lastgenerator (der Rechner mit k6/JMeter) an CPU, Speicher oder Netzwerkkarte stößt — Proxys werden das nicht beheben. Proxys fügen einen zusätzlichen Netzwerk-Hops und ihre eigene Latenz hinzu, anstatt die Last vom Runner zu nehmen.
Die tatsächliche Bandbreite des getesteten Servers. Der Server hält entweder die Last aus oder nicht — die IP-Adresse des Clients hat darauf keinen Einfluss, außer in Fällen von explizitem Rate-Limit nach IP.
Die Genauigkeit der Antwortzeitmetriken. Proxys fügen ihre eigene Latenz hinzu (insbesondere Residential und Mobile), die in Ihre Berichte als Teil der Antwortzeit eingeht. Wenn die Latenz des Proxys nicht separat abgezogen wird, wird der endgültige Latenzbericht verzerrt und ist für den Vergleich mit Produktionsmetriken ungeeignet.
Die Skalierung der Infrastruktur für echten Verkehr. Ein Lasttest mit Proxys zeigt das Verhalten unter einem bestimmten Anfrage-Muster, ersetzt jedoch nicht die Kapazitätsplanung, das automatische Skalieren und die Lastprofile, die auf echten Produktionsprotokollen basieren.
Die Überprüfung der Korrektheit der Geschäftslogik unter Last. Race Conditions, Sperren in der DB, Warteschlangen-Degeneration — das sind Tests auf Parallelität und Profilierung, nicht das Wechseln der ausgehenden IP.

Proxys sind ein Werkzeug für die spezifische Aufgabe „Verkehr von verschiedenen IPs emulieren“, kein universeller Verstärker für Lasttests. Wenn das Ziel darin besteht, zu verstehen, wie viele RPS das Backend aushält, sind Proxys in den meisten Fällen überhaupt nicht notwendig: Es genügen einige Test-Runner ohne Proxys, mit richtig konfiguriertem Keep-Alive und Verbindungspool.

Typische Fehler beim Testen über Proxys

In der Praxis lassen sich die meisten Probleme mit Proxys in Lasttests auf einige wiederkehrende Fehler zurückführen.

Vermischung der Latenz des Proxys mit der Latenz des getesteten Dienstes. Ohne Baseline-Messung (direkte Anfrage ohne Proxy) ist es unmöglich zu verstehen, wie viele Millisekunden der Proxy-Server selbst hinzufügt.
Verwendung von mobilen oder Residential-Proxys dort, wo reine Bandbreite benötigt wird. Solche Proxys sind durch den tatsächlichen Kanal des Endgeräts begrenzt und halten physisch keine Zehntausenden von RPS aus — für reine Last sind Datacenter-Proxys erforderlich.
Unzureichender IP-Pool für eine große Anzahl von VUs. Wenn auf 5000 virtuelle Benutzer 10 Proxy-Adressen entfallen, stößt der Test dennoch auf dasselbe Rate-Limit, nur mit Verzögerung — der Dienst wird schnell das Muster „10 IPs, Tausende von Anfragen“ erkennen.
Ignorieren von Timeouts auf der Proxy-Seite. Bei hoher gleichzeitiger Last kann der Proxy-Server selbst beginnen, Verbindungen abzulehnen — es ist wichtig, im Voraus die Limits für gleichzeitige Sitzungen beim Proxy-Anbieter zu klären.
Starten des Tests ohne Überprüfung von Whitelisting/Autorisierung. Wenn der Proxy eine IP-Authentifizierung erfordert und der Test aus CI/CD mit einer dynamischen Adresse des Runners gestartet wird — die Anfragen werden mit 407 Proxy Authentication Required fehlschlagen, und die Testergebnisse werden sinnlos sein.

Checkliste vor dem Teststart

Haben wir festgestellt, ob die Aufgabe wirklich verschiedene IPs benötigt, oder reicht ein Test von einer Adresse aus?
Haben wir den Proxy-Typ für die Aufgabe ausgewählt: Datacenter für RPS und Rate-Limit, Residential/Mobile für Geo-Logik?
Haben wir eine Baseline-Messung ohne Proxy durchgeführt, um die Netzwerkverzögerung von der Proxy-Verzögerung zu trennen?
Haben wir die Limits für gleichzeitige Verbindungen beim Proxy-Anbieter für die erforderliche Anzahl von VUs überprüft?
Haben wir die Proxy-Autorisierung (Benutzername/Passwort oder Whitelisting der IP des Runners) konfiguriert?
Haben wir entschieden, ob eine Sticky-Session für VUs oder eine Rotation bei jeder Anfrage erforderlich ist?
Haben wir den Test über einen kurzen Zeitraum (1-2 Minuten) vor dem vollständigen Durchlauf gestartet, um die Konfiguration zu überprüfen?

Fazit

Proxys in k6 und JMeter sind eine funktionierende Methode, um Verkehr von verschiedenen IP-Adressen zu emulieren, das Verhalten von Rate-Limits und geoabhängiger Logik zu überprüfen. Aber sie sind kein Ersatz für eine fundierte Planung von Lasttests: Proxys überprüfen und verbessern nicht die Bandbreite des Servers, die Stabilität des Backends unter gleichzeitiger Last und die tatsächliche Kapazitätsplanung. Verwenden Sie sie gezielt — dort, wo der Test wirklich von der IP-Adresse des Clients abhängt, und nicht als universelles Werkzeug „für die Fairness“.

Wenn die Aufgabe darin besteht, die Limits nach IP zu überprüfen und massiven Verkehr mit hoher Bandbreite zu simulieren, ist es sinnvoll, mit Datacenter-Proxys zu beginnen — sie bieten minimale Latenz und halten eine große Anzahl gleichzeitiger Sitzungen aus. Für Tests, die auf Geo-Logik und das Vertrauen von Anti-Bot-Systemen in die Herkunft des Verkehrs angewiesen sind, sind Residential-Proxys besser geeignet, und für Nischen-Szenarien mit mobilem Verkehr — mobile IPs.