Websockets

Ocelot supports proxying WebSockets [1] with some extra bits.

Configuration

To enable WebSockets proxying with Ocelot, you need to do the following in your Program:

var app = builder.Build();
app.UseWebSockets(); // required for Ocelot 24.x and earlier; called automatically since version 25.0
await app.UseOcelot();
await app.RunAsync();

Then, in your ocelot.json, add the following to proxy a route using WebSockets:

{
  "UpstreamPathTemplate": "/",
  "DownstreamPathTemplate": "/ws",
  "DownstreamScheme": "ws",
  "DownstreamHostAndPorts": [
    { "Host": "localhost", "Port": 5001 }
  ]
}

With this configuration, Ocelot will match any WebSockets traffic that comes in on / and proxy it to localhost:5001/ws. For clarity, Ocelot will receive messages from the upstream client, proxy them to the downstream service, receive messages from the downstream service, and then proxy them back to the upstream client.

SignalR [2]

Ocelot supports proxying SignalR. To enable this with Ocelot, you need to do the following:

First, install the SignalR Client NuGet package:

Install-Package Microsoft.AspNetCore.SignalR.Client

Note: SignalR is part of the ASP.NET Core and can be referenced as follows:

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

More information on framework compatibility can be found in the instructions: Use ASP.NET Core APIs in a class library.

Second, you need to configure your application to use SignalR. A complete reference can be found here: ASP.NET Core SignalR configuration.

builder.Services.AddOcelot(builder.Configuration);
builder.Services.AddSignalR();

Note: Make sure to pay attention to the transport-level configuration for WebSockets. Ensure that allowed transports are properly configured to enable WebSockets connections: ASP.NET Core SignalR configuration.

Next, include the following in your ocelot.json file to proxy a route using SignalR. Note that standard Ocelot routing rules apply; the key aspect is that the scheme is set to ws (WebSockets).

{
  "UpstreamPathTemplate": "/gateway/{catchAll}",
  "DownstreamPathTemplate": "/{catchAll}",
  "DownstreamScheme": "ws",
  "DownstreamHostAndPorts": [
    { "Host": "localhost", "Port": 5001 }
  ]
}

WebSocket Secure

If you define a route with the secured WebSockets protocol, use the wss scheme:

"DownstreamScheme": "wss",

Keep in mind that you can use WebSocket SSL for both SignalR and Websockets.

Note: To understand wss scheme, browse to this documentation:

If you want to ignore SSL warnings (errors) [3], configure your route as follows:

"DownstreamScheme": "wss",
"DangerousAcceptAnyServerCertificateValidator": true,

However, we strongly advise against this! Refer to the official notes regarding SSL Errors in the Configuration documentation. There, you can also explore best practices tailored for your environments.

Supported

  1. Routing

  2. Load Balancer

  3. Service Discovery

This means you can configure your downstream services to run WebSockets and either:

  • Include multiple DownstreamHostAndPorts in your route configuration.

  • Connect your route to a Service Discovery provider. This allows you to load balance requests, which we think is pretty cool!

Not Supported

Unfortunately, many Ocelot features are not specific to WebSockets, such as header handling and HTTP client functionalities. Below is a list of features that will not work:

  1. Tracing

  2. Logging Request ID

  3. Aggregation

  4. Rate Limiting

  5. Quality of Service

  6. Middleware Injection (except the OcelotPipelineConfiguration Class WebSocketsMiddlewareType and WebSocketsMiddleware properties, see Sample)

  7. Headers Transformation

  8. Delegating Handlers

  9. Claims Transformation

  10. Caching

  11. Authentication [4]

  12. Authorization

We cannot be entirely sure how this feature will behave once it is widely used. Therefore, thorough testing is strongly recommended!

Sample [5]

Project: samples / WebSocket
Solution: Ocelot.Samples.slnx

The Ocelot.Samples.WebSocket.csproj sample project demonstrates how to proxy WebSocket connections with a customized buffer size by subclassing WebSocketsProxyMiddleware and registering it via OcelotPipelineConfiguration:

public class MyWebSocketsProxyMiddleware : WebSocketsProxyMiddleware
{
    protected override int BufferSize => 65536; // 64 KB for high-throughput streams (e.g. HTTP.sys video streaming)

    public MyWebSocketsProxyMiddleware(RequestDelegate next, IOcelotLoggerFactory logging, IWebSocketsFactory factory)
        : base(next, logging, factory) { }
}

The custom middleware type is then registered through WebSocketsMiddlewareType option of the OcelotPipelineConfiguration Class:

var wsPipeline = new OcelotPipelineConfiguration
{
    WebSocketsMiddlewareType = typeof(MyWebSocketsProxyMiddleware),
};
await app.UseOcelot(wsPipeline);

Alternatively, the same can be achieved with a delegate via WebSocketsMiddleware:

var wsPipeline = new OcelotPipelineConfiguration
{
    WebSocketsMiddleware = (context, next) =>
    {
        Task Next(HttpContext ctx) => next();
        var loggerFactory = context.RequestServices.GetRequiredService<IOcelotLoggerFactory>();
        var wsFactory = context.RequestServices.GetRequiredService<IWebSocketsFactory>();
        var middleware = new MyWebSocketsProxyMiddleware(Next, loggerFactory, wsFactory);
        return middleware.Invoke(context);
    },
};
await app.UseOcelot(wsPipeline);

When WebSocketsMiddlewareType is set, it takes priority over WebSocketsMiddleware and the delegate is ignored. For the full reference, see the OcelotPipelineConfiguration Class section in Middleware Injection chapter.

Note

Starting from Ocelot version 25.0, app.UseWebSockets() is called internally during Ocelot pipeline setup. You no longer need to call it explicitly before await app.UseOcelot().

Roadmap

WebSockets and SignalR are being actively developed by the .NET community. It is important to stay updated with trends and regularly check for new releases in the official documentation:

As a team, we are unable to provide direct development advice. However, feel free to ask questions or explore coding recipes in Discussions of the repository. Additionally, we welcome any bug reports, enhancement suggestions, or proposals related to this feature. octocat

Note

The Ocelot team considers the current implementation of the WebSockets feature to be obsolete, as it is based on the WebSocketsProxyMiddleware class. WebSockets are a part of the ASP.NET Core framework, which includes the native WebSocketMiddleware class. We have a strong intention to either migrate or redesign this feature. For more details, see issue 1707.