Any problems or incompatibilities need not be the result of SignalR itself, but rather a general mechanism for opening a duplex communication channel between the HTTP client and server (ie AKA "Comet" method range).
SignalR is intended to be used by Websocket if it supports both client and server (and it is worth mentioning that the Websocket specification is currently in the Applicant's Recommendation, so it has not been finalized, although it is close). Implicit in this is that the proxies between the client and the server will also support it.
If the client, server and proxies between them do not support Websocket, then SignalR will try to retreat to the events sent by the server, and then, if SSE is not supported, a long poll.
A significant problem is that these methods usually rely on a persistent connection that opens in some way. Your proxies / accelerators may well decide that they are inefficient and close them if data is not transmitted through them; in this case, the SignalR client will open the connection again by design, but due to the time spent setting up the connection again.
You may be able to configure your proxies to check the type of connection you have connected, and if it is most likely to be connected to the SignalR endpoint to make it less aggressive towards closing the connection.