---
title: "Discussion on \"OKX WebSocket port 8443 is retired: fixing Node.js connections\" | Hashnode"
description: "Discussion on \"OKX WebSocket port 8443 is retired: fixing Node.js connections\". OKX stopped accepting WebSocket connections on port 8443 on 31 October 2026 (Colo follows on 16 November). If your Node.js app still connects to wss://ws.okx.com:8443/..., the connection now fails. RE"
url: "https://hashnode.com/posts/okx-websocket-port-8443-is-retired-fixing-node-js-connections/6af1b2b112366c0ff9ab6428"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [OKX WebSocket port 8443 is retired: fixing Node.js connections](https://siebly.hashnode.dev/okx-websocket-port-8443-is-retired-fixing-node-js-connections?utm_source=hashnode&utm_medium=feed)

OKX stopped accepting WebSocket connections on port 8443 on 31 October 2026 (Colo follows on 16 November). If your Node.js app still connects to wss://ws.okx.com:8443/..., the connection now fails. RE

2d ago · 2 min read · siebly.hashnode.dev  
Read the article

-   [#javascript](https://hashnode.com/tag/javascript)
-   [#nodejs](https://hashnode.com/tag/nodejs)
-   [#okx](https://hashnode.com/tag/okx)
-   [#websockets](https://hashnode.com/tag/websockets)

## Written by

[Siebly](https://hashnode.com/@siebly)

@siebly

  
[View profile](https://hashnode.com/@siebly)

## Responses 1

Markdown supported · ⌘↵ to post

[Node Edge Ops](https://hashnode.com/@nodeedgeops)

[2d ago](https://hashnode.com/posts/okx-websocket-port-8443-is-retired-fixing-node-js-connections/6af1b2b112366c0ff9ab6428/comment/6af265d923eb62f4409876b8)

Node WebSocket clients only stay healthy when endpoint retirement is treated as a config deploy, not an outage mystery. Prefer a single connection factory that pins host, port, and path from config, fail closed when the handshake target is unknown, and keep reconnect backoff capped so a retired listener cannot open a reconnect storm against the old address. Separate auth refresh from socket reconnect so a token renew cannot multiply sockets.

Ops prove-out after cutting over the endpoint: open a canary client against the new host and port and confirm the handshake succeeds while an intentional old-port probe fails fast, then kill the socket mid-stream and confirm a single reconnect lands on the new target. Watch active socket count, reconnect rate, and auth-error rate for one deploy window — a spike in reconnects with flat successful streams usually means stale config still points at the retired listener. Keep a canary process on the prior endpoint mapping for one release so you can tell a bad cutover from a broker-side regression.