Summary
Add optional SignalR / websocket passthrough for the arr /<base>/signalr/* path so consumers that rely on the arr real-time push channel keep working when repointed through starrproxy with a scoped key.
Background
starrproxy proxies /<base>/api/* beautifully — scoped keys, least-privilege, per-consumer logging. But Sonarr/Radarr also expose a SignalR endpoint at /<base>/signalr/messages (websocket, authenticated with the same API key via ?access_token=) that clients use for real-time "library changed" push instead of polling.
When a consumer that uses SignalR is repointed at starrproxy, /api/* works but the SignalR channel is dropped, because starrproxy only routes /api/* — every other path 404s.
Concrete case: Bazarr. Repointing Bazarr's Sonarr/Radarr connections at starrproxy + a scoped key works for all REST calls, but Bazarr's sonarr_signalr / radarr_signalr go DOWN and it silently falls back to scheduled polling — losing sync-on-import. Bazarr uses a single host:port per arr connection for both /api and /signalr, so it cannot be split at the client (point /api at the proxy and /signalr at the arr directly).
Verified behavior (current)
GET <proxy>/radarr/signalr/messages -> 404 (no route)
GET <proxy>/radarr/api/v3/system/status -> 401 (route exists, needs key)
Requested behavior
For a registered backend, optionally pass /<base>/signalr/* (websocket upgrade included) through to the backend arr, translating the scoped key on the SignalR handshake to the backend's real key the same way /api/* already does. Ideally gated per-app/per-template so it stays opt-in and least-privilege.
Why it matters
Without it, any consumer that uses arr SignalR (Bazarr is the first we hit; likely others) can't fully migrate to scoped keys without losing real-time push — which partially defeats the point of moving everything behind the proxy. A websocket passthrough would close that gap.
Happy to test against a build. Thanks for starrproxy!
Summary
Add optional SignalR / websocket passthrough for the arr
/<base>/signalr/*path so consumers that rely on the arr real-time push channel keep working when repointed through starrproxy with a scoped key.Background
starrproxy proxies
/<base>/api/*beautifully — scoped keys, least-privilege, per-consumer logging. But Sonarr/Radarr also expose a SignalR endpoint at/<base>/signalr/messages(websocket, authenticated with the same API key via?access_token=) that clients use for real-time "library changed" push instead of polling.When a consumer that uses SignalR is repointed at starrproxy,
/api/*works but the SignalR channel is dropped, because starrproxy only routes/api/*— every other path 404s.Concrete case: Bazarr. Repointing Bazarr's Sonarr/Radarr connections at starrproxy + a scoped key works for all REST calls, but Bazarr's
sonarr_signalr/radarr_signalrgo DOWN and it silently falls back to scheduled polling — losing sync-on-import. Bazarr uses a single host:port per arr connection for both/apiand/signalr, so it cannot be split at the client (point/apiat the proxy and/signalrat the arr directly).Verified behavior (current)
Requested behavior
For a registered backend, optionally pass
/<base>/signalr/*(websocket upgrade included) through to the backend arr, translating the scoped key on the SignalR handshake to the backend's real key the same way/api/*already does. Ideally gated per-app/per-template so it stays opt-in and least-privilege.Why it matters
Without it, any consumer that uses arr SignalR (Bazarr is the first we hit; likely others) can't fully migrate to scoped keys without losing real-time push — which partially defeats the point of moving everything behind the proxy. A websocket passthrough would close that gap.
Happy to test against a build. Thanks for starrproxy!