← Zurück zum Blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

WebSocket, gRPC, HTTP/2 über Proxy: So wählen Sie das richtige Protokoll für Ihren Stack aus

Wir analysieren die Besonderheiten des Proxying von WebSocket, gRPC und HTTP/2 – welches Protokoll zu wählen ist, wie man einen Proxy-Server einrichtet und häufige Fehler von Entwicklern vermeidet.

📅21. September 2026

Bei der Arbeit mit Proxys stehen Entwickler oft vor der Herausforderung, dass klassische HTTP-Proxy-Einstellungen für WebSocket-Verbindungen nicht funktionieren und gRPC überhaupt mit TLS-Handshake-Fehlern abbricht. Das Problem ist, dass WebSocket, HTTP/2 und gRPC nicht einfach „Varianten von HTTP“ sind, sondern verschiedene Transportmodelle mit eigenen Anforderungen an Tunneling, Multiplexing und Header-Verarbeitung. In diesem Artikel werden wir erörtern, wie man jedes dieser Protokolle proxiert, welche Fallstricke in der Praxis auftreten und wie man das Protokoll und den Proxy-Typ für eine bestimmte Aufgabe auswählt – vom Parsen über WebSocket bis hin zu hochbelasteten gRPC-Mikroservices.

Wie sich die Protokolle unterscheiden und warum das für Proxys wichtig ist

HTTP/1.1 funktioniert nach dem „Anfrage-Antwort“-Modell: Der Client öffnet eine Verbindung, sendet eine Anfrage, erhält eine Antwort und schließt entweder die Verbindung oder hält sie für die nächste Anfrage offen (keep-alive). Proxy-Server wurden über Jahrzehnte genau für dieses Modell optimiert – Parsing von Headern, Pufferung des Anfragekörpers, einfache Routing nach dem Host-Header.

WebSocket bricht dieses Modell: Nach dem anfänglichen HTTP-Handshake (Upgrade: websocket) wird die Verbindung zu einem dauerhaften bidirektionalen Kanal, in dem Daten jederzeit in beide Richtungen fließen können. Der Proxy muss diese Verbindung „freigeben“ und einfach Bytes in beide Richtungen weiterleiten, ohne zu versuchen, sie als HTTP-Anfragen zu interpretieren.

HTTP/2 fügt Multiplexing hinzu – mehrere logische Anfragen laufen parallel über eine TCP-Verbindung, wobei binäre Frames anstelle von Text-Headern verwendet werden. Für den Proxy bedeutet dies, dass man nicht einfach Text zeilenweise lesen kann – es ist Unterstützung des binären HTTP/2-Protokolls auf der Proxy-Ebene oder transparentes TCP-Tunneling über TLS erforderlich.

gRPC geht noch weiter: Es basiert strikt auf HTTP/2, verwendet Protocol Buffers zur Serialisierung und erfordert einen HTTP/2-kompatiblen Transport auf dem gesamten Weg vom Client zum Server. Wenn der Proxy an irgendeinem Punkt die Verbindung auf HTTP/1.1 „downgradet“, wird die gRPC-Anfrage einfach nicht durchkommen.

Das Verständnis dieser Unterschiede ist entscheidend, da die Wahl des falschen Proxytyps oder eine falsche Konfiguration des Tunnelings zu Verbindungsabbrüchen, Timeouts und schwer erklärbaren Fehlern führen kann, die ohne Verständnis der Transportebene schwer zu diagnostizieren sind.

WebSocket über Proxy: Einrichtung und Code

Für WebSocket über Proxy gibt es zwei Hauptszenarien: HTTP-Proxy mit der CONNECT-Methode (für WSS, also WebSocket über TLS) und SOCKS5-Proxy, der TCP-Verbindungen ohne Protokollunterscheidung tunnelt. SOCKS5 verursacht normalerweise weniger Probleme, da es ursprünglich als „transparente Röhre“ für jeden TCP-Verkehr konzipiert wurde.

Ein Beispiel für die Verbindung zu WebSocket über SOCKS5-Proxy in Python mit der Bibliothek websockets und python-socks: 

import asyncio
from python_socks.sync import Proxy
import websockets
import websockets.sync.client as ws_client

def connect_ws_via_proxy():
    proxy = Proxy.from_url("socks5://user:pass@proxy_host:1080")
    sock = proxy.connect(dest_host="echo.websocket.events", dest_port=443)

    ws = ws_client.connect(
        "wss://echo.websocket.events",
        sock=sock,
        server_hostname="echo.websocket.events"
    )
    ws.send("Hello via proxy")
    print(ws.recv())
    ws.close()

connect_ws_via_proxy()

In Node.js wird eine ähnliche Aufgabe über das Paket ws in Verbindung mit socks-proxy-agent gelöst: 

const WebSocket = require('ws');
const { SocksProxyAgent } = require('socks-proxy-agent');

const agent = new SocksProxyAgent('socks5://user:pass@proxy_host:1080');
const socket = new WebSocket('wss://echo.websocket.events', { agent });

socket.on('open', () => socket.send('Hello via proxy'));
socket.on('message', (data) => console.log(data.toString()));

Wenn der Proxy nur über HTTP (mit der CONNECT-Methode) verfügbar ist, ist das Schema ähnlich – die meisten modernen WebSocket-Clients können über ein HTTP-Tunnel arbeiten, es ist nur wichtig sicherzustellen, dass der Proxy nicht langanhaltende Verbindungen aufgrund von Timeouts abbricht. Dies ist ein häufiges Problem bei günstigen Data-Center-Proxys, die eine strikte Grenze von 30-60 Sekunden für inaktive Verbindungen haben – für Streaming-WebSocket-Aufgaben ist dies entscheidend, und es ist besser, die Keep-Alive-Parameter beim Anbieter zu klären.

HTTP/2 über Proxy: Multiplexing und Fallstricke

Die größte Schwierigkeit bei HTTP/2 über Proxy besteht darin, dass viele Proxy-Server (insbesondere alte Squid oder einfache Forward-Proxys) nur nach HTTP/1.1 arbeiten und die Verbindung automatisch „downgrade“. Für den Client ist dies oft nicht bemerkbar (die Anfrage wird trotzdem ausgeführt), aber die Vorteile des Multiplexings gehen verloren – die Latenzen steigen, insbesondere bei einer großen Anzahl paralleler Anfragen an einen Host.

Um zu überprüfen, ob die Verbindung über den Proxy HTTP/2 unterstützt, kann man cURL mit dem Flag --http2 und detaillierter Ausgabe verwenden: 

curl -v --http2 -x http://user:pass@proxy_host:8080 https://example.com

# Suchen Sie in der Ausgabe nach der Zeile:
# * Using HTTP2, server supports multiplexing
# Wenn sie nicht vorhanden ist – die Verbindung ist auf HTTP/1.1 gefallen

In Python wird für HTTP/2 über Proxy die Bibliothek httpx mit aktivierter HTTP/2-Unterstützung benötigt: 

import httpx

proxies = {
    "http://": "http://user:pass@proxy_host:8080",
    "https://": "http://user:pass@proxy_host:8080",
}

with httpx.Client(proxies=proxies, http2=True) as client:
    response = client.get("https://example.com")
    print(response.http_version)  # erwarten "HTTP/2"
    print(response.status_code)

Ein wichtiger Punkt: HTTP/2 erfordert TLS mit ALPN-Erweiterung zur Protokollverhandlung, daher muss der Proxy TLS-Verkehr transparent über CONNECT tunneln und nicht selbst TLS terminieren (es sei denn, es handelt sich um einen spezialisierten HTTP/2-kompatiblen Proxy). Aus diesem Grund verhalten sich für HTTP/2-Anwendungen Residenzproxies und Data-Center-Proxys unterschiedlich – es ist wichtig, beim Anbieter zu klären, ob durchgängiges TLS-Tunneling ohne Unterbrechung der ALPN-Verhandlungen unterstützt wird.

gRPC über Proxy: TLS, ALPN und besondere Anforderungen

gRPC ist das anspruchsvollste Protokoll in diesem Zusammenhang. Es ist strikt an HTTP/2 gebunden und verwendet häufig bidirektionales TLS (mTLS) zur Authentifizierung. Ein gewöhnlicher Forward-Proxy, der kein HTTP/2 CONNECT Tunneling „wie es ist“ unterstützt, wird einfach keinen gRPC-Verkehr durchlassen – die Verbindung wird mit Fehlern wie UNAVAILABLE: upstream connect error abgebrochen.

Für das Proxieren von gRPC in Python (mit der Bibliothek grpc) wird der Proxy über Umgebungsvariablen festgelegt, da es historisch keine eingebaute Unterstützung für Proxys in den Channel-Optionen gab: 

import os
import grpc

os.environ["grpc_proxy"] = "http://user:pass@proxy_host:8080"
os.environ["https_proxy"] = "http://user:pass@proxy_host:8080"

channel = grpc.secure_channel(
    "grpc.example.com:443",
    grpc.ssl_channel_credentials()
)

# Beispielaufruf über den generierten Stub
# stub = YourServiceStub(channel)
# response = stub.YourMethod(request)

In Node.js wird der Proxy für gRPC über die Channel-Optionen grpc-js in Verbindung mit einem HTTP/2-kompatiblen Proxy-Agenten konfiguriert: 

const grpc = require('@grpc/grpc-js');
const { HttpsProxyAgent } = require('https-proxy-agent');

process.env.grpc_proxy = 'http://user:pass@proxy_host:8080';
process.env.https_proxy = 'http://user:pass@proxy_host:8080';

const client = new YourServiceClient(
  'grpc.example.com:443',
  grpc.credentials.createSsl()
);

Für einen stabilen Betrieb von gRPC über Proxy sind niedrige Latenz und eine stabile TCP-Verbindung ohne häufige Abbrüche entscheidend – multiplexierte gRPC-Streams sind empfindlicher gegenüber Netzwerkfehlern als einzelne HTTP/1.1-Anfragen. In solchen Szenarien zeigen Residenzproxies oft eine bessere Stabilität im Vergleich zu günstigen Data-Center-Pools, da der Weg zum Zielserver durch eine vorhersehbarere Netzwerk-Infrastruktur verläuft.

Vergleichstabelle der Protokolle

Protokoll Verbindungstyp Anforderungen an den Proxy Empfohlener Proxytyp
HTTP/1.1 Anfrage-Antwort, keep-alive minimale Anforderungen, jeder HTTP-Proxy Data-Center-Proxys
WebSocket dauerhafter bidirektionaler Kanal Unterstützung für lange Verbindungen, keine Timeouts Residenzproxies
HTTP/2 multiplexierte binäre Streams durchgängiges TLS-Tunneling, ALPN Residenz- oder Data-Center-Proxys
gRPC HTTP/2 + Protobuf, oft mTLS niedrige Latenz, Stabilität, HTTP/2 CONNECT Mobile Proxys zum Umgehen strenger Filter

Wie man das Protokoll und den Proxy für seinen Stack auswählt

Die Wahl des Protokolls ist selten eine freie Entscheidung – sie wird durch die Ziel-API diktiert. Aber die Wahl des Proxytyps für dieses Protokoll liegt bereits in Ihrer Verantwortung, und hier sollte man sich auf das spezifische Szenario stützen:

Datenparsing über WebSocket (z. B. Streaming von Kursen oder Echtzeitdaten von Marktplatz-Websites) erfordert eine stabile, langanhaltende Verbindung ohne Timeouts. Hier funktionieren Residenzproxies besser – sie fallen seltener unter die Anti-Fraud-Algorithmen des Zielservices und halten die Verbindung länger als typische Data-Center-Pools.

Integration mit gRPC-Mikroservices über einen externen Proxy (z. B. beim Testen von APIs aus verschiedenen Geolokationen) erfordert niedrige Latenz und Unterstützung für HTTP/2 auf dem gesamten Weg. Dafür eignen sich Residenz-IP mit guter Routing-Qualität, und für zeitkritische Aufgaben – mobile Proxys, wenn der Zielservice aggressiv Data-Center-Bereiche filtert.

Massive HTTP/2-Anfragen an REST/GraphQL-APIs mit Multiplexing – das häufigste Szenario, in dem schnelle und günstige Data-Center-Proxys ausreichen, solange der Zielservice nicht standardmäßig Data-Center-IP-Bereiche blockiert.

Eine allgemeine Regel: Je „launischer“ das Protokoll in Bezug auf die Stabilität der Verbindung (WebSocket, gRPC), desto mehr Sinn machen Residenz- oder mobile IPs. Je einfacher und kürzer die Anfrage (gewöhnliches HTTP/1.1 oder HTTP/2 ohne lange Sitzungen), desto komfortabler ist die Arbeit mit Data-Center-Proxys – sie sind schneller und bieten eine höhere Bandbreite.

Häufige Fehler und deren Lösungen

Fehler 1: WebSocket bricht alle 30-60 Sekunden ab. Grund: Der Proxy oder der Zwischenlastverteiler schließt „inaktive“ Verbindungen. Lösung: Aktivieren Sie Ping/Pong-Frames auf Anwendungsebene mit einem Intervall von weniger als dem Timeout des Proxys (in der Regel sind 20-25 Sekunden ausreichend).

Fehler 2: gRPC schlägt über den Proxy mit UNAVAILABLE fehl, funktioniert aber direkt. Der Proxy unterstützt kein HTTP/2 CONNECT Tunneling. Lösung: Überprüfen Sie die Dokumentation des Anbieters auf Unterstützung für HTTP/2 oder verwenden Sie einen SOCKS5-Proxy, der TCP ohne Protokollinterpretation tunnelt.

Fehler 3: HTTP/2 wird unbemerkt auf HTTP/1.1 heruntergestuft. Dies geschieht häufig aufgrund fehlender ALPN-Unterstützung im Proxy. Überprüfen Sie die Protokollversion explizit im Code (wie im obigen Beispiel mit httpx) – verlassen Sie sich nicht darauf, dass „alles funktioniert“, wenn Sie die http_version in der Antwort nicht überprüft haben.

Fehler 4: Hohe Latenz beim Multiplexing von gRPC über Proxy. Oft verursacht durch eine große Anzahl von Zwischenknoten beim Proxy-Anbieter. Lösung: Testen Sie die Latenz im Voraus mit einer einfachen RTT-Anfrage und wählen Sie einen Anbieter mit direkter Routing-Qualität, insbesondere für zeitkritische gRPC-Aufrufe.

Fazit

WebSocket, HTTP/2 und gRPC erfordern unterschiedliche Ansätze zur Proxy-Konfiguration, weil sie auf unterschiedlichen Transportmodellen basieren: vom einfachen „Freigeben der TCP-Verbindung“ für WebSocket bis hin zu strikter Unterstützung von HTTP/2 CONNECT und ALPN für gRPC. Überprüfen Sie die Protokollversion explizit im Code, testen Sie die Stabilität langanhaltender Verbindungen im Voraus und wählen Sie SOCKS5 dort, wo maximale Transparenz beim Tunneling erforderlich ist.

Wenn Ihr Stack langanhaltende WebSocket-Verbindungen oder latenzempfindliche gRPC-Aufrufe umfasst, empfehlen wir, Residenzproxies auszuprobieren – sie bieten stabilere und vorhersehbarere Verbindungen im Vergleich zu typischen Data-Center-Pools. Für einfache HTTP/2-Anfragen mit hoher Bandbreite sind Data-Center-Proxys geeignet, und für Aufgaben mit aggressiver Anti-Fraud-Filterung des Zielservices – mobile Proxys.