SignalR client requests timeout, when client requests are routed through a gateway service (revere proxy) running webapi stack, to the signalr servers. RRS feed

  • Question

  • User-1889899267 posted


    We are currently using signalr in production and has been running great. in the current setup, signalr is sitting behind Azure SLB. We are looking at making some changes in the existing design by introducing a reverse proxy service (gateway), what this means is -

    In the new design signalr servers will sit behind this gateway. All the client calls to signalr server will be routed through this gateway. This gateway service is running on ASP.Net Webapi which does the decision of routing the requests to the appropriate backend service, signalr being one of them.

    Issue: Here is what is happening in the new setup when calls are routed to SignalR server through the  gateway.

    We are using Server sent events transport (SSE) for signalr client requests. Turns out that the SSE calls now fail, precisely fail on the "Connect" request, this is what happens -

    • Client initiates a connection to the server "Negotiate" request. The server returns a 200Ok to the client.
    • On receiving  a 200 OK the client sends a "Connect" request... the client eventually fails with a timeout exception.

    The Connect is routed properly by the gateway to the signalr server, signalr replies to the request.. and reaches the gateway... . but the gateway never responds back to the client. 

    This is happening as the SSE connection cannot be streamed through the intermediate gateway webapi stack. 

    [note: one way (that i could think of as of now) for fixing this would be to have a support for having such bidirectional SSE requests on the gateway servers]

    Are there any  ways of fixing it ? any thoughts ?

    Wednesday, January 3, 2018 11:23 PM

All replies

  • User283571144 posted

    Hi montex,

    According to your description, I suggest you could firstly check the connect timeout you have set up in the application start event.

    If the connection time match the connect timeout value, it will show the timeout error. I suggest you could increase this value and try again.

    More details, you could refer to below codes:

    protected void Application_Start(object sender, EventArgs e)
        // Make long polling connections wait a maximum of 110 seconds for a
        // response. When that time expires, trigger a timeout command and
        // make the client reconnect.
        GlobalHost.Configuration.ConnectionTimeout = TimeSpan.FromSeconds(110);
        // Wait a maximum of 30 seconds after a transport connection is lost
        // before raising the Disconnected event to terminate the SignalR connection.
        GlobalHost.Configuration.DisconnectTimeout = TimeSpan.FromSeconds(30);
        // For transports other than long polling, send a keepalive packet every
        // 10 seconds. 
        // This value must be no more than 1/3 of the DisconnectTimeout value.
        GlobalHost.Configuration.KeepAlive = TimeSpan.FromSeconds(10);

    More details, you could refer to this article.

    Best Regards,


    Thursday, January 4, 2018 7:57 AM
  • User-1889899267 posted

    Hi Brando ZWZ,

    Thanks a lot for your reply.

    Yes I tried increasing the timeout period, but it still fails. After debugging some more what i found out is -

    • the gateway service is the request forwarder to the signalr server, hence the signalr server tries to establish the streaming connection with the gateway... now it is the responsibility of the gateway to have a SSE stream connection with the client (who has actually initiated the request) ... and this is where the connection is dying, and eventually the client timesout.
    Thursday, January 4, 2018 9:00 PM
  • User1104055534 posted

    Hi montex,


    If it's cross-origin request, please make sure CORS is set correctly. Also, please check the Application Request Routing settings of IIS, make sure uncheck Enable disk cache and set Response buffer to 0.

    Please refer to the following links for details:




    Monday, January 15, 2018 6:24 AM