--- title: Free WebSocket Tester description: Open a WebSocket connection to any ws:// or wss:// URL from a real probe location — handshake time, the server's remote IP, a ping/pong round-trip, and optionally send a message and check the reply against a pattern. Test a socket server the way a browser would, without writing a client. canonical: https://watchfor.io/websocket-tester --- [Back to all free tools](/free-tools) # WebSocket Tester Open a WebSocket connection to any ws:// or wss:// URL from a real probe location — handshake time, the server's remote IP, a ping/pong round-trip, and optionally send a message and check the reply against a pattern. Test a socket server the way a browser would, without writing a client. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is WebSocket Tester ? A WebSocket starts life as an HTTP request with Upgrade: websocket and, if the server agrees with a 101 Switching Protocols , becomes a persistent two-way connection that both sides can write to at any time. That's what powers live dashboards, chat, collaborative editors, trading screens and game servers — and it's what breaks in ways plain HTTP checks never see: a proxy that doesn't forward the upgrade, a load balancer that drops idle connections at 60 seconds, a TLS setup that works for https:// and fails for wss:// , a server that accepts the handshake and never answers a message. This tester opens a WebSocket to any ws:// or wss:// URL from a real probe location, times the handshake, records the server's IP, measures a ping/pong round-trip, and — if you give it one — sends a message and shows the first reply, optionally matched against a pattern. It's the browser's new WebSocket(url) without writing a client, from outside your network. ## How it works The same steps a browser takes, with timings: - 1 Upgrade handshake — An HTTP GET with Upgrade: websocket , Connection: Upgrade and a Sec-WebSocket-Key . Success is a 101 with the matching Sec-WebSocket-Accept ; anything else — 200 , 403 , 426 , a TLS error — is a failed handshake with the reason recorded. - 2 Ping / pong — A control ping frame is sent and the time to the pong measured. Servers must answer pings (RFC 6455); a missing pong usually means a middlebox that speaks HTTP but not WebSocket. - 3 Optional message exchange — Your text is sent as one frame; the first message the server sends back is captured and, if you gave a regular expression, matched against it. Many servers require an auth or subscribe message before they say anything — that's what the field is for. The connection is closed cleanly afterwards. Nothing is kept open, and nothing is sent beyond what you typed. ## When you'd use it ### "It works locally, not in production" The usual culprit is the reverse proxy: nginx needs proxy_http_version 1.1 and the Upgrade / Connection headers forwarded; some load balancers need WebSocket support enabled explicitly. A failed handshake from outside with a status code says which layer refused. ### Verifying wss:// after a certificate change Browsers are stricter about certificates on WebSockets than on page loads (no click-through). A handshake that fails with a TLS error here will fail silently in the browser console. ### Latency from another region Handshake time and ping RTT from a probe in Singapore or São Paulo tell you what users there feel — and whether your "global" endpoint is really one region. ### Smoke-testing a protocol Send {"type":"subscribe","channel":"ticker"} , expect "ticker" in the reply. If the server answers as documented, the deploy is good; if the first message is an error frame, you'll see it verbatim. ## Reading the result ### Handshake time DNS + TCP + TLS + the HTTP upgrade round-trip. Under 200 ms nearby, more across oceans. A very slow handshake with a fast ping means the TLS or upgrade step is slow, not the network. ### Ping RTT The round-trip on the established connection — the number your live updates ride on. "No pong" with a successful handshake is a proxy that terminated the upgrade but doesn't relay frames. ### First message received Whatever the server sent first, up to a size limit. A welcome frame, an error, or nothing at all if the server waits for the client to speak. ### Pattern match Whether the regular expression matched that first message. Not matched with a message shown means the format differs from what you expected; not matched with no message means the server stayed silent. ## Check it yourself curl -i -N -H 'Connection: Upgrade' -H 'Upgrade: websocket' -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' https://example.com/ws A 101 Switching Protocols response is a successful handshake. websocat wss://example.com/ws gives you an interactive session. ## Common pitfalls ### Testing http(s) instead of ws(s) A pasted https:// URL is upgraded to wss:// here, but the path must be the socket endpoint ( /ws , /socket.io/?EIO=4&transport=websocket ), not the page that opens it. ### Origin checks Servers often reject handshakes from origins they don't allow. A 403 here may be that check — the probe sends no browser Origin , which some servers treat as forbidden and others as fine. ### Idle timeouts This test lasts seconds; production connections last hours. A load balancer that kills idle connections at 60 s won't show here — use a ping interval in your client, and a WebSocket monitor for the long view. ## Run WebSocket Tester on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions How do I test a WebSocket connection? Open one to the endpoint URL from outside your network and check that the server answers the upgrade with 101 Switching Protocols , responds to a ping, and replies to your first message as documented. This tester does all three from a real probe location and shows the reply. What is the difference between ws:// and wss://? ws:// is plain; wss:// is over TLS, like http:// vs https:// . Browsers refuse ws:// from https:// pages (mixed content), so production endpoints are wss:// . Why does the handshake return 200 instead of 101? The request reached an HTTP server that didn't upgrade — usually a proxy or CDN that doesn't forward Upgrade headers, or the wrong path. Check the proxy config and that the URL is the socket endpoint. What does 426 Upgrade Required mean? The server expects a WebSocket upgrade and didn't get a valid one — often a missing Sec-WebSocket-Version: 13 or a stripped Upgrade header along the way. Why does the server not reply to my message? Most protocols require an authentication or subscription message first, in an exact format. Check the first message the server sent (often an error) and the protocol's docs; try the exact JSON your client sends. Can I monitor a WebSocket endpoint continuously? Yes — a WebSocket monitor runs this same handshake, ping and message check on a schedule from multiple locations and alerts when the handshake fails, the pong stops or the reply changes. ## Related web tools - [MCP Server CheckerTest a Model Context Protocol server: initialize handshake, protocol version, capabilities and the full tool inventory.](/mcp-server-checker) - [SSL Certificate CheckInspect certificate validity, expiry, SANs, issuer and chain trust.](/ssl-checker) - [SSL/TLS GradeGrade a server's TLS config A+ to F — protocols, ciphers, forward secrecy, post-quantum, HSTS and certificate, with the exact reasons.](/ssl-grade-checker) - [HTTP HeadersInspect response headers, status, redirect chain and security headers.](/http-header-checker) --- Canonical page: https://watchfor.io/websocket-tester · Site guide: https://watchfor.io/llms.txt