Kommt dir bekannt vor? REST-Anfragen über einen Unternehmens- oder Cloud-Proxy laufen wie geschmiert, aber sobald du einen WebSocket öffnest oder eine gRPC-Methode aufrufst, kommt die Verbindung entweder gar nicht erst zustande oder stirbt nach etwa dreißig Sekunden still. Dabei siehst du im Browser oder in den Anwendungslogs mysteriöse 101, 502, 504 oder einfach ein plötzliches connection reset. Das ist keine Mystik und kein Karma. Es ist der grundlegende Unterschied zwischen der Art, wie ein Proxy kurze Request-Response-Transaktionen behandelt, und dem, wie er sich bei langlebigen bidirektionalen Streams verhalten muss.

Dieser Artikel ist ein umfassender Leitfaden dafür, wie Protokolle, die auf TCP aufsetzen, Proxys durchlaufen: WebSocket, gRPC und überhaupt alles, was ein Protokoll-Upgrade oder einen End-to-End-Tunnel benötigt. Wir zerlegen die Mechanik bis zum letzten Header, zeigen den Unterschied zwischen ws:// über einen HTTP-Proxy und wss:// über die CONNECT-Methode, erklären, warum SOCKS5 oft einfacher ist, was mit gRPC über HTTP/2 zu tun ist, wie man Idle-Timeouts überwindet und vor allem, wie man das alles debuggt, wenn nichts funktioniert. Am Ende gibt es funktionierenden Code in Python und Node, Checklisten und FAQ.

Gleich vorweg eine Einschränkung zum Umfang des Themas: Die Mechanik von UDP ASSOCIATE in SOCKS5 fassen wir hier bewusst nicht an – das ist ein eigenes großes Thema über Datagramme, dem ein separater Artikel gewidmet ist. Hier konzentrieren wir uns ausschließlich auf TCP-Protokolle über HTTP und SOCKS.