SignalR issues with WebProxies or Accelerators?

Any issues or incompatibilities would not necessarily be as a result of SignalR itself, but rather the general mechanism for opening a duplex communication channel between an HTTP client and server (i.e. the range of techniques AKA 'Comet').

SignalR is designed to use Websocket if both client and server support it (and its worth mentioning, that the Websocket spec is currently at Candidate Recommendation, so hasn't been finalised although it is close). Implicit in this is that the proxies inbetween the client and server will also support it.

If client, server and proxies inbetween do not support Websocket then SignalR will attempt to fallback to Server Sent Events, and then if SSE not supported, long polling.

The significant issue is that these techniques generally rely on a persistent connection being held open in some way. Your proxies/accelerator may well decide that these are inefficient and close them down if data is not being streamed across them; in which case the SignalR client will open the connection again by design, but at the cost of time spent in setting up the connection again.

You might be able to configure your proxies to check the type of connection that has been opened, and if it is likely to be a connection to a SignalR endpoint to make it less aggressive with respect to closing the connection.