WebSocket Fails but HTTPS Works: Network Checks

When WebSocket fails but HTTPS works, first find out whether the opening handshake failed or an established connection later closed. A successful website request does not prove that its separate real-time endpoint, authentication, or long-lived connection is working.

Key Takeaways:

• Record the WebSocket endpoint and failure phase before changing a network setting.
• For the HTTP/1.1 handshake, status 101 is a protocol switch, not proof of application success.
• Authentication rejection and server errors need their own fixes.
• Compare the same authorized connection over another route only after checking the endpoint and proxy.

Step 1: What should you record when WebSocket fails?

Start with a service you own or have explicit permission to diagnose. Ask its operator for a harmless test channel and an expected message, rather than opening somebody else's subscription or capturing private chat traffic. Record the browser version, operating system, sanitized endpoint, connection time, and visible error. If several applications fail, use the device-wide troubleshooting sequence first.

Open your browser's developer tools before reproducing the problem. In the Network panel, select the WebSocket request; Chrome provides a WS filter, but labels differ between browsers. Inspect the actual request host and path instead of the page address. A page can load from one domain while its live connection targets another domain with different authentication and routing requirements.

For the traditional HTTP/1.1 upgrade covered here, a valid opening response uses status 101 and the expected handshake headers. Any other status means this exchange has not become the requested WebSocket connection. Modern deployments can also use other standardized transports; do not demand 101 from a service documented to use an HTTP/2 mechanism.［1］［4］

Use the flow to separate a refused opening exchange from a connection that opened and then closed. Keep a response status, if present, separate from a browser's generic console error. A response exists only after some server or intermediary has answered; it is different evidence from a request that never completes its connection attempt.

Step 2: What does the response actually establish?

Compare the endpoint with the service's documented URL and protocol. Secure pages normally need a secure WebSocket endpoint; do not replace it with an insecure endpoint to silence an error. Inspect the negotiated subprotocol when the application requires one. The RFC defines subprotocol negotiation and an Origin header used by browser clients; these are application-facing decisions, not a country-selection problem.［1］

Observation	Investigate next	Safe action
No opening response	Name lookup, TLS, network path, or browser restriction	Preserve the error and verify the intended endpoint
401 or explicit authentication rejection	Session or API credentials	Reauthenticate through the approved application flow
403 with a documented Origin or access rejection	Application access policy	Ask the operator to verify permitted origins and access
404 or unexpected HTML	Wrong route or upstream mapping	Confirm the real-time path with the operator
502 or another upstream error	Reverse proxy and upstream service	Provide a timestamp and sanitized request identifier
101 followed by a close	Established channel, timers, or application behavior	Inspect messages, close information, and idle duration

A 403 is not automatically an Origin error: retain the service's explanation rather than inventing a cause from the number alone. Likewise, an HTTP 200 containing a login page is not a successful upgrade. Do not copy cookies or bearer tokens into a public reproduction; use the operator's test account or a non-sensitive local example.

If ordinary command-line requests also fail, investigate the browser and curl request-path differences separately. A successful curl download does not validate the WebSocket handshake, subprotocol, or authenticated subscription. For certificate failures, follow the certificate warning investigation, keeping certificate and hostname verification enabled.

Step 3: Does the WebSocket proxy preserve the upgrade?

If you administer the reverse proxy, examine the configuration that actually serves the WebSocket route. HTTP/1.1 Upgrade and Connection are hop-by-hop headers, so NGINX requires explicit forwarding for the tunnel to its upstream. Its official example binds the upgraded tunnel to both the client's request and the upstream's 101 response. Check your installed version before copying configuration defaults.［2］

Distinguish this reverse proxy from a browser's forward proxy or a VPN tunnel. They sit at different places in the path. Changing the laptop's network exit does not rewrite the service operator's reverse-proxy location, create its missing upstream, or correct the application's authentication checks.

Ask the owner to compare a small authorized request at the upstream and through the public proxy, preserving the intended trust boundary. Do not expose an internal backend on the internet or bypass mandatory organizational controls just to test it. If you do not own the server, send the endpoint, timestamp, response status, and connection phase to its operator.

A controlled local demonstration accompanies this guide. It opens an actual WebSocket to a loopback test service, receives a harmless message, and records the close event. The screenshot is a live diagnostic report, not a production trace, an application login screen, or evidence of any VPN's performance.

The report separates the observed opening from message receipt and closure. Use the same separation in your own notes. This loopback example has no internet route to compare, so it cannot establish whether an external intermediary is responsible for your incident.

When the WebSocket route carries your own proxy through a CDN, the VLESS WebSocket and XHTTP walkthrough lists the Upgrade headers the origin proxy needs and how to prove traffic really passes through the edge.

Step 4: Is the WebSocket idle timeout repeatable?

Record when the connection opens, the last received message, and when it closes. Repeat a harmless test only enough to distinguish a consistent interval from an irregular interruption. Keep active and idle sessions separate: a channel that closes after silence gives different evidence from one that closes during continuous traffic.

NGINX's documented default closes the proxied connection if no upstream data arrives within 60 seconds. The relevant read timeout is not a promise that every connection lasts exactly a minute, and other components can use different limits. A recurring interval is a clue to investigate the deployed timers, not a unique fingerprint of NGINX.［2］

WebSocket protocol Ping and Pong frames differ from an application's JSON heartbeat. Browser JavaScript does not expose a general API to emit protocol Ping frames directly; the server or a suitable non-browser client may manage them. Ask the application owner which heartbeat it expects before adding messages or changing intervals.［1］［3］

Keep the close code and reason when available. An abnormal closure without a received close frame does not identify which hop failed. A normal close may be deliberate application behavior, such as ending a test subscription. If your channel actually delivers one-way HTTP events rather than a WebSocket, use the event-stream delivery checks instead.

Step 5: Does an approved alternate route change this channel?

A route comparison is useful when the endpoint and access checks are correct but the transport still fails. First confirm permission to use another route and keep required proxies intact. If a desktop client differs from the browser, record its execution environment instead of assuming both clients take the same path.

For this comparison, run the browser on the supported computer connected through AethoVPN. Choose a currently available home-country or nearby position in the app, enable global mode, then reopen the same harmless WebSocket. Compare the opening response, first expected message, and time until disconnection with the original attempt; do not merely check whether the page loads.

Windows uses the official installer; Debian/Ubuntu x64 uses the .deb package. On Mac, obtain the VPN-client configuration through the website setup guide with Pro or Premium. Check the current public exit as preparation, but retain the WebSocket evidence because an IP page alone cannot prove this request's path.

This changes the local network route; it does not grant a subscription, correct an Origin policy, or repair an upstream timeout. If a new account is needed for the authorized comparison, start the 3-day free Pro trial, available once per user and beginning at registration.

Use the connection-verification checklist to confirm preparation. If neither route changes the symptom, restore the original route and ask the operator to inspect the server-side evidence. Do not keep rotating positions after an explicit authorization failure, or call one successful session guaranteed future availability.

If direct access and an approved proxy path behave differently, and you need coverage for this local application, compare TUN mode with the system proxy before choosing a capture method. That choice changes local traffic coverage, not the service's upgrade configuration or timers.

Step 6: What should you restore and escalate?

Return temporary client settings to their intended values, close test subscriptions, and stop diagnostic logging. Retain a short case record: runtime, sanitized host and path, handshake status, negotiated subprotocol, message arrival, idle duration, and close information. Add the route used and test time without including tokens, private messages, account identifiers, or signed URLs.

An API testing tool has its own proxy and execution behavior; if that tool fails separately, use the Postman runtime and timeout checks. Never resend a message with business consequences as a connectivity probe. Confirm its original state with the application owner before any retry.

Escalate application rejection to the application owner, repeatable proxy timing to the infrastructure owner, and certificate errors to the administrator responsible for trust. Stop when repeated attempts add no evidence. A precise failure phase is more useful than a collection of screenshots from unrelated hosts.

Summary

• Distinguish the opening exchange, message delivery, and eventual close.
• Preserve authentication, Origin policy, and certificate checks.
• Treat repeatable idle intervals as timer evidence, not proof of a specific intermediary.
• Compare only the same authorized channel, then restore settings and escalate the remaining failure.

FAQ

Why does a website open while its WebSocket fails?

The website and WebSocket may use different hosts, paths, and authentication. Loading an HTML page establishes neither permission for the real-time endpoint nor successful handling of a long-lived connection.

Does status 101 mean the application is working?

Status 101 confirms the traditional HTTP/1.1 protocol switch, provided the handshake is valid. You still need the expected application message and a usable session before treating the task as successful.

Does a disconnect after one minute prove a proxy timeout?

A recurring interval supports investigating idle timers, but it does not identify the component. Compare the last upstream data time and deployed limits before attributing it to a reverse proxy.

Should I send a heartbeat from browser JavaScript?

Use only the heartbeat format documented by the application. A JSON message is not a WebSocket protocol Ping, and arbitrary messages can cause application errors or unwanted actions.

Can I turn off Origin checks to test the handshake?

Keep Origin checks in place and ask the owner to authorize the correct test origin. Removing a security check changes the system under test and can expose another user's session.

Can a VPN repair a rejected subscription?

A rejected subscription needs its authentication or permission corrected through the service. A route comparison is meaningful only for the transport stage and does not supply application access rights.

What is safe to send to support?

Send sanitized endpoint details, times, failure phase, statuses, and close information. Remove cookies, tokens, private message payloads, signed query strings, and personal or account identifiers first.

Disclaimer: This guide describes authorized diagnostics, not a guarantee of service availability. Follow local law, organizational policy, and the service's access rules.

Sources:

1. RFC 6455 — The WebSocket Protocol — https://www.rfc-editor.org/rfc/rfc6455
2. NGINX — WebSocket proxying — https://nginx.org/en/docs/http/websocket.html
3. WHATWG — WebSockets — https://websockets.spec.whatwg.org/#ping-and-pong-frames
4. RFC 8441 — Bootstrapping WebSockets with HTTP/2 — https://www.rfc-editor.org/rfc/rfc8441

Sources checked 7 October 2026.

---

Related Articles:

• Compare command-line and browser connections
• Separate event delivery from buffering
• Check an API client's local execution path
• Verify the connection before repeating a task