Любые проблемы или несовместимости могут быть вызваны не самим SignalR, а скорее общим механизмом открытия дуплексного канала связи между HTTP-клиентом и сервером (т. Е. Набором методов AKA 'Comet').
SignalR разработан для использования Websocket, если и клиент, и сервер поддерживают его (и стоит отметить, что спецификация Websocket в настоящее время находится в Рекомендации кандидата, поэтому не была завершена, хотя и близка). Это подразумевает, что прокси-серверы между клиентом и сервером также будут поддерживать его.
Если промежуточный клиент, сервер и прокси-серверы не поддерживают Websocket, то SignalR попытается выполнить откат к отправленным событиям на сервере, а затем, если SSE не поддерживается, выполнить длинный опрос.
Важной проблемой является то, что эти методы обычно полагаются на постоянное соединение, которое каким-то образом остается открытым. Ваши прокси / акселераторы могут решить, что они неэффективны, и закрыть их, если данные не передаются по ним; в этом случае клиент SignalR снова откроет соединение, но за счет времени, потраченного на настройку соединения снова.
Возможно, вы сможете настроить прокси-серверы для проверки типа соединения, которое было открыто, и может ли оно быть соединением с конечной точкой SignalR, чтобы сделать его менее агрессивным в отношении закрытия соединения.