Le WebSocket établit entre le navigateur et le serveur un canal bidirectionnel et maintenu ouvert en permanence. Les tableaux de bord de données en direct, les applications de chat et les notifications en temps réel reposent sur cette technologie. Son fonctionnement via un proxy dépend du type de proxy et de sa configuration.
Comment démarre une connexion WebSocket ?
Le WebSocket n'est pas un protocole distinct : il commence par une requête HTTP et Upgrade change de protocole via ce mécanisme :
Après la réponse 101, la connexion cesse d'être du HTTP et les trames WebSocket commencent à circuler. C'est pourquoi chaque couche intermédiaire doit comprendre l'upgrade.
Comportement selon le type de proxy
La combinaison la plus sûre wss:// + tunnel CONNECT. Le trafic étant chiffré, le proxy ne peut ni interférer avec le contenu ni casser l'upgrade.
Si vous exécutez une application utilisant le WebSocket via un proxy, wss:// privilégiez le chiffré. Comme le tunnel proxy ne transporte que des octets, il ne peut aucunement interférer avec le processus d'upgrade et le problème de compatibilité disparaît.
Pourquoi certains proxies cassent-ils le WebSocket ?
En ws:// trafic non chiffré, le proxy lit la requête. Les proxies anciens ou configurés de façon stricte peuvent commettre les erreurs suivantes :
La dernière ligne est souvent négligée : si vous utilisez un rotating proxy, la connexion WebSocket se coupe dès que l'IP change. Dans ce scénario, IP statique est nécessaire.
Éviter les coupures : ping/pong
Les proxies et les routeurs intermédiaires ferment les connexions sur lesquelles aucune donnée ne circule pendant une longue période. Le protocole WebSocket définit des trames ping/pong pour ce cas. La plupart des bibliothèques le font automatiquement, mais vous devrez peut-être ajuster l'intervalle :
Maintenez l'intervalle de ping inférieur au délai d'inactivité du proxy. 20 à 25 secondes est une valeur sûre pour la plupart des configurations.
WebSocket avec SOCKS5
Comme SOCKS5 ne regarde jamais les données applicatives, il transporte naturellement le WebSocket. Le handshake d'upgrade, le changement de protocole et le flux de trames ne sont pour SOCKS5 qu'un simple flux d'octets. Cela fait de SOCKS5 l'option la plus sûre dans les scénarios WebSocket.
Pour le comportement général de SOCKS5, comment fonctionne SOCKS5 .
Connexion de longue durée et stabilité de l'IP
Le WebSocket est par nature de longue durée ; la rotation, elle, cherche à changer d'IP. Les deux entrent en conflit. Dans ce scénario, une IP statique ou une durée sticky très longue est nécessaire.
Stratégie de reconnexion
Si vous utilisez le WebSocket via un proxy, concevez la coupure non comme une exception mais comme un état attendu :
- Backoff exponentiel : des attentes croissantes de 1, 2, 4, 8 secondes.
- Ajoutez du jitter : Cela évite que de nombreux clients déconnectés en même temps ne reviennent tous simultanément.
- Synchronisation d'état : après la reconnexion, demandez les messages manqués.
- Limite maximale de tentatives : n'entrez pas dans une boucle infinie ; informez l'utilisateur.
- Surveillez la santé de la connexion : si la fréquence des coupures augmente, réexaminez la configuration du proxy.
Résumé
Le WebSocket démarre par le mécanisme d'upgrade HTTP ; c'est pourquoi les couches intermédiaires doivent comprendre le changement de protocole. wss:// Utiliser le chiffré et privilégier un tunnel CONNECT ou SOCKS5 élimine en grande partie les problèmes de compatibilité. Les connexions de longue durée entrent en conflit avec les rotating proxies ; dans ce scénario, une IP statique est nécessaire. Maintenez l'intervalle ping/pong inférieur au délai d'expiration du proxy et mettez en place une stratégie de reconnexion solide. Pour les options d'IP statique, ISP proxy .