Testeur / client WebSocket

Connectez-vous à n’importe quel point de terminaison ws:// ou wss://, déclarez des sous-protocoles facultatifs, envoyez des messages texte ou JSON et suivez un journal complet du cycle de vie : transitions d’état, codes et raisons de fermeture, et chaque message avec sa direction, son heure et sa charge utile. Tout s’exécute localement dans votre navigateur grâce à l’API WebSocket native — rien ne transite par un serveur. Pour les API HTTP classiques, utilisez le Client / testeur d’API REST ; voir toute la famille Outils API.
Connexion
CLOSED Envoyer un JSON de bienvenue à la connexion
Envoyer un message
Journal des messages 0 événement
Rien pour l’instant. Connectez-vous à un serveur pour commencer.
Limites des WebSocket dans le navigateur à connaître : les en-têtes de requête ne peuvent pas être personnalisés (seuls les cookies et le sous-protocole Sec-WebSocket-Protocol ci-dessus sont envoyés) ; la poignée de main n’est pas régie par CORS, mais la directive connect-src de la politique de sécurité de contenu (Content-Security-Policy) de la page peut la bloquer ; une page sécurisée (https) ne peut ouvrir que des wss:// ; JavaScript ne peut pas envoyer de trames ping au niveau du protocole (le navigateur répond automatiquement aux pings du serveur — utilisez des messages applicatifs comme {"type":"ping"} pour simuler des battements de cœur) ; les certificats auto-signés ne sont pas approuvés. Recommandé pour les tests en local : faites tourner votre propre serveur, ou utilisez un écho public comme wss://ws.postman-echo.com/raw ou wss://echo.websocket.org.
Explication de WebSocket
Une WebSocket offre un canal de messages bidirectionnel et persistant entre le navigateur et un serveur. Contrairement à HTTP, les messages peuvent circuler dans les deux sens sur une seule connexion.
ws:// contre wss://—ws:// n’est pas chiffré (comme http://); wss:// est chiffré (comme https://). Si cette page est servie en HTTPS, le navigateur n’autorise que les connexions wss://. Depuis un fichier local (file://) les deux schémas sont autorisés, mais de nombreux serveurs d’écho publics (dont echo.websocket.org) n’acceptent que wss://.
Sous-protocoles — la liste facultative séparée par des virgules correspond à l’en-tête de poignée de main Sec-WebSocket-Protocol. Le serveur doit prendre en charge l’un d’eux, sinon le navigateur refuse la connexion.
Pourquoi la connexion se termine-t-elle sans que la zone « Envoyer un message » n’apparaisse ? Le formulaire d’envoi n’apparaît que lorsque l’état passe à OPEN. Si le serveur interrompt la poignée de main, vous verrez un événement d’erreur, suivi de CLOSED avec le code 1006 (fermeture anormale — aucune trame de fermeture). Causes typiques : utiliser ws:// avec un serveur qui n’accepte que wss://, un mauvais hôte ou port, un sous-protocole qui ne correspond pas, ou un serveur hors ligne.
Codes de fermeture que vous pouvez rencontrer — 1000 normal ; 1001 fermeture de l’onglet du navigateur ; 1006 anormal / échec de la poignée de main ; 1009 message trop volumineux ; 1011 erreur serveur. Le journal affiche automatiquement le code et une courte raison.
Dépannage d’une connexion échouée : commencez par passer le schéma sur wss://, vérifiez que l’hôte est joignable, retirez les sous-protocoles dont vous n’avez pas besoin, et consultez la console du navigateur pour les erreurs TLS ou de contenu mixte.