How can I run SignalR and custom WebSocket endpoints concurrently in ASP.NET Core 8?

The issue isn’t that you can’t run both on one port—it’s that both SignalR and your custom WebSocket endpoint are using the same underlying WebSocket mechanism, and if their endpoints aren’t clearly separated (and the middleware isn’t ordered correctly) they can “step on each other’s toes.”

Here are some key points and recommendations:

• Different Endpoints:
  Make sure that your SignalR hub(s) and your custom WebSocket handler use distinct URL paths. For example, if your SignalR hub is mapped at “/hub” and your custom WebSocket endpoint is mapped at “/ws” you’re clearly separating their requests. This prevents the possibility of one middleware erroneously handling the request meant for the other.

• Middleware Order:
  The call to app.UseWebSockets() applies to all incoming requests. You must ensure that both your SignalR endpoints (registered with app.MapHub<YourHubType>("/hub")) and your custom WebSocket endpoint (mapped at “/ws”) are added after UseWebSockets(), so that the correct handler accepts the connection. The order in which you map endpoints can affect which requests get handled first.

• Connection Hijacking:
  When a request is made, there is an upgrade handshake to switch to a WebSocket protocol. If your custom HandleWebSocketConnection method “claims” a connection that was intended for SignalR (or vice versa), then you’ll see both sides blocked until one connection disconnects. Keeping the endpoints separate prevents this kind of connection hijacking.

• No Overlap in Path Matching:
  Double-check that your routing doesn’t have overlapping patterns or ambiguous matches. SignalR performs its own handshake validation and expects its own message protocol. A custom endpoint should explicitly check for a WebSocket upgrade request and only handle connections for its specific path.

For example, your configuration might look like this:

CSHARPCopied
var builder = WebApplication.CreateBuilder(args);

// Register SignalR services with detailed errors
builder.Services.AddSignalR(options =>
{
    options.EnableDetailedErrors = true;
});

var app = builder.Build();

// Enable the WebSockets middleware globally
app.UseWebSockets();

// Map your custom WebSocket endpoint on a dedicated path
app.Map("/ws", WebSocketHandler.HandleWebSocketConnection);

// Map SignalR hubs on their own dedicated paths, e.g.:
app.MapHub<MyHub>("/hub");

// Map REST endpoints, etc.
app.MapControllers();

app.Run();

By keeping SignalR and your plain WebSocket endpoint on clearly separate routes and ensuring the middleware is in the proper order, you prevent them from interfering with each other.

In summary, both can be enabled on the same server without conflict provided you:

• Separate the endpoints clearly (for example, “/hub” for SignalR and “/ws” for your custom WebSocket).

• Order your middleware correctly (calling UseWebSockets() early so that only the request paths intended to be handled by a custom provider are intercepted).

Implementing these recommendations should resolve the problem where communication stops for both connections until one disconnects.