Disabling Socket.io transport in FeathersJS v5: handling unexpected client connections

The short answer

If you never register the Socket.io adapter, there is nothing to suppress: no socket.io endpoint exists, so connection attempts fail at the HTTP layer (a 404 on the /socket.io/ path) and cost virtually nothing. For a low-traffic REST-only app, omitting the adapter is the recommended approach — no custom middleware, no error-handling code, and no fallback to long-polling is needed because nothing is listening.

Confirmed facts vs. likely explanation

Confirmed: Feathers v5 only exposes transports you explicitly register. Without @feathersjs/socketio, the framework serves only the REST endpoints. There is no built-in automatic fallback from Socket.io to long-polling — that fallback exists within Socket.io (websocket → polling), not between Socket.io and REST.

Likely explanation for your situation: the "unexpected connection attempts" you're worried about come from stale clients, bots scanning for /socket.io/, or developers testing with default Socket.io client settings. These attempts are harmless when no adapter is registered — they get a fast 404 and move on.

Option 1: Omit the adapter (recommended)

// app.js — REST only, no socket.io anywhere
app.configure(express.rest());
// Do NOT call: app.configure(socketio());

Verify with a quick client-side probe:

// In a browser console against your running app:
import { io } from 'https://cdn.socket.io/4.7.5/socket.io.esm.min.js';
const s = io('http://localhost:3030');
s.on('connect_error', (e) => console.log('failed as expected:', e.message));

You should see a connection error and, in your server logs, a 404 for GET /socket.io/?EIO=4&transport=polling. That is the entire cost of an "unexpected attempt."

Option 2: Explicit rejection middleware (only if you need a signal)

If you want clients to receive a deliberate message rather than a generic 404 — for example, during a migration period where old clients still exist — add a tiny Express middleware before Feathers registers its routes:

app.use('/socket.io', (req, res) => {
  // Optional: rate-limit this log on busy systems
  console.warn(`socket.io attempt from ${req.ip}`);
  res.status(410).json({
    error: 'Realtime transport removed. Use the REST API.'
  });
});

Why 410 Gone rather than 400/403: it tells a well-behaved client the endpoint is permanently retired, which is more informative than a generic rejection. Whether to log-and-drop vs. respond depends on your threat model: for a public low-traffic API, responding is fine and aids debugging; silently dropping saves nothing meaningful but makes diagnosing legitimate client failures harder.

Option 3: Shared server with other Socket.io services

If the same HTTP server must host Socket.io for something else but not for Feathers, register the adapter with no working transports and disconnect immediately:

app.configure(socketio({ transports: [] }, (io) => {
  io.on('connection', (socket) => {
    console.warn(`rejected socket from ${socket.handshake.address}`);
    socket.disconnect(true);
  });
}));

Note: transports: [] behavior depends on the Socket.io adapter version bundled with your Feathers release — verify against your installed version before relying on it.

What to fix on the client

Server-side handling is secondary: clients configured with Feathers' Socket.io client will never recover on their own. Remove @feathersjs/socketio-client and switch to @feathersjs/rest-client (fetch or axios). That eliminates the attempts at the source, which no server configuration can do.

Verification checklist

1. Start the app without the adapter; confirm GET /socket.io/ returns 404 (or your 410 middleware response).
2. Confirm REST calls still work: curl http://localhost:3030/your-service.
3. Watch memory/CPU over a day — with no websocket connections held open, baseline usage should drop noticeably.

One caveat: if you are seeing a high volume of attempts rather than occasional ones, that changes the recommendation — share where the attempts originate (logs with source IPs/paths), because that pattern suggests a misconfigured deployed client rather than random noise, and the fix belongs in that client's build.