WebSocket y gRPC a través de proxy: actualización de protocolo, CONNECT y depuración de conexiones largas
¿Historia conocida? Las solicitudes REST a través de un proxy corporativo o en la nube vuelan sin problema, pero en cuanto abres un WebSocket o llamas a un método gRPC, la conexión o no se establece en absoluto, o vive unos treinta segundos y muere en silencio. Mientras tanto, en el navegador o en los registros de la aplicación ves misteriosos 101, 502, 504 o simplemente un repentino connection reset. No es misticismo ni karma. Es la diferencia fundamental entre cómo el proxy maneja transacciones cortas de solicitud-respuesta y cómo debería comportarse con flujos bidireccionales de larga duración.
Este artículo es una guía exhaustiva sobre cómo pasan a través del proxy los protocolos que viven sobre TCP: WebSocket, gRPC y, en general, todo lo que requiere una actualización de protocolo o un túnel de extremo a extremo. Analizaremos la mecánica hasta el último encabezado, mostraremos la diferencia entre ws:// a través de un proxy HTTP y wss:// mediante el método CONNECT, explicaremos por qué SOCKS5 suele ser más sencillo, qué hacer con gRPC sobre HTTP/2, cómo superar los timeouts de inactividad y, lo más importante, cómo depurar todo cuando nada funciona. Al final: código funcional en Python y Node, listas de verificación y preguntas frecuentes.
Aclaración sobre el alcance: la mecánica de UDP ASSOCIATE en SOCKS5 la dejamos fuera a propósito aquí; es una conversación grande por separado sobre datagramas y tiene su propio material. Aquí nos enfocamos exclusivamente en protocolos TCP sobre HTTP y SOCKS.