You tested your socket.io connectionally on your local development environment, but after deploying to your remote server or production server, socket connection breaks. I think everyone has gone through this the first time. This is just a dirty example to counter the problem unless you configure your web server’s reverse proxy
Why separate paths matter When you run locally the Socket.IO endpoint usually sits at /socket.io, but in production your app is often mounted behind a gateway, load‑balancer or path prefix (for example /api-name). That means the browser must request /api-name/socket.io, otherwise the handshake requests (polling and websocket upgrade) go to the wrong path and will 404 or fail to upgrade. Separating path logic lets the client use the correct URL for each environment without changing reverse proxy configuration.
import { io, Socket } from "socket.io-client";
const isDev = process.env.NODE_ENV === "development";
const SOCKET_PATH = isDev ? "/socket.io" : "/api-endpoint/socket.io";
const SOCKET_HOST = isDev ? undefined : "https://api-endpoint.com";
const socket: Socket = io(SOCKET_HOST, {
path: SOCKET_PATH,
transports: ["websocket", "polling"],
});
export default socket;- We check process.env.NODE_ENV === “development”. That expression is false if NODE_ENV is undefined or any string other than “development”, so production or missing envs will use the production path.
- SOCKET_PATH becomes “/socket.io” in development and “/api-endpoint/socket.io” otherwise.
- SOCKET_HOST is left undefined for dev so the client connects to the same origin; in production you can set it to the real API origin if needed.
- Keep the path consistent between client and server; no trailing slash; ensure CORS and websocket upgrade headers are allowed by your API host.