Ça vous dit quelque chose ? Les requêtes REST via un proxy d'entreprise ou cloud passent comme une lettre à la poste, mais dès que vous ouvrez un WebSocket ou appelez une méthode gRPC, la connexion soit ne s'établit pas du tout, soit vit trente secondes et meurt en silence. Et dans le navigateur ou les logs de l'application, vous voyez de mystérieux 101, 502, 504 ou simplement un connection reset soudain. Ce n'est ni de la magie ni du karma. C'est la différence fondamentale entre la façon dont un proxy traite de courtes transactions requête-réponse et la façon dont il doit se comporter avec des flux bidirectionnels de longue durée.

Cet article est un guide exhaustif sur la façon dont les protocoles qui vivent au-dessus de TCP traversent un proxy : WebSocket, gRPC et tout ce qui nécessite une mise à niveau du protocole ou un tunnel de bout en bout. Nous allons décortiquer la mécanique jusqu'au moindre en-tête, montrer la différence entre ws:// via un proxy HTTP et wss:// via la méthode CONNECT, expliquer pourquoi SOCKS5 est souvent plus simple, que faire avec gRPC sur HTTP/2, comment vaincre les timeouts d'inactivité et, surtout, comment tout déboguer quand rien ne fonctionne. À la fin : du code fonctionnel en Python et Node, des checklists et une FAQ.

Une précision sur le périmètre du sujet : nous n'abordons pas volontairement la mécanique du UDP ASSOCIATE dans SOCKS5 – c'est un tout autre grand sujet sur les datagrammes, traité dans un article dédié. Ici, nous nous concentrons exclusivement sur les protocoles TCP via HTTP et SOCKS.