Znana historia? Zapytania REST przez firmowe lub chmurowe proxy latają jak gdyby nigdy nic, a gdy tylko otworzysz WebSocket albo wywołasz metodę gRPC, połączenie albo w ogóle się nie nawiązuje, albo żyje jakieś trzydzieści sekund i po cichu umiera. W przeglądarce lub w logach aplikacji widzisz tajemnicze 101, 502, 504 albo po prostu niespodziewany connection reset. To nie magia ani karma. To fundamentalna różnica między tym, jak proxy obsługuje krótkie transakcje żądanie-odpowiedź, a tym, jak powinno się zachowywać w przypadku długożyjących, dwukierunkowych strumieni.

Ten artykuł to wyczerpujący przewodnik po tym, jak przez proxy przechodzą protokoły działające na TCP: WebSocket, gRPC i w ogóle wszystko, co wymaga upgrade'u protokołu lub tunelu end-to-end. Rozłożymy mechanikę na czynniki pierwsze, aż do ostatniego nagłówka, pokażemy różnicę między ws:// przez proxy HTTP a wss:// przez metodę CONNECT, wyjaśnimy, dlaczego SOCKS5 bywa prostsze, co zrobić z gRPC po HTTP/2, jak pokonać limity czasu bezczynności i – co najważniejsze – jak to wszystko debugować, kiedy nic nie działa. Na końcu – działający kod w Pythonie i Node, checklisty i FAQ.

Od razu zastrzeżenie co do zakresu tematu: mechaniki UDP ASSOCIATE w SOCKS5 tutaj celowo nie ruszamy – to osobna, duża rozmowa o datagramach i poświęcony jest jej osobny materiał. Tu skupiamy się wyłącznie na protokołach TCP działających przez HTTP i SOCKS.