# UI not updating **URL:** \ **Category:** SUSE Rancher Prime\ **Created:** [May 20, 2019, 5:13pm UTC](https://forums.suse.com/t/ui-not-updating/14333 "2019-05-20T17:13:45Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Sebastien\_ROUL](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/sebastien_roul/32/5071_2.png) [@Sebastien\_ROUL](https://forums.suse.com/u/Sebastien_ROUL)\ **Post date:** [May 20, 2019, 5:13pm UTC](https://forums.suse.com/t/ui-not-updating/14333/1 "2019-05-20T17:13:45Z")
Hi, We run Rancher behind NGINX reverse proxy and the UI not updating : by example, when deploying a new workload, scale part didn’t change color (half green, half blue) and so on. I mean there no “Instant” update of the UI to reflect the state of the cluster. Scale part : this one is red but should be green cause workload is finaly up - and become green when F5 the browser ![image](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/a/ab4faa1710b9fb4813ded401a9d99ca37cd22e3f.png) Also, in the console (devTools) here is the webscket state : ![image](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/d/d404b7159f23937b4d12b2fc92a9cdd6b3caf229.png) ---
**Author:** ![vincent](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/vincent/32/7156_2.png) [@vincent](https://forums.suse.com/u/vincent)\ **Post date:** [May 21, 2019, 8:32am UTC](https://forums.suse.com/t/ui-not-updating/14333/2 "2019-05-21T08:32:27Z")
You need to proxy websocket connections correctly, all I can see from the screen is it keeps doing and then we try to open it again. No websocket == no live updating. (And some things won’t work at all, like creating a new namespace for a new workload. That does create ns, wait for state to change, and then create workload, but you’ll wait forever). ---
**Author:** ![Sebastien\_ROUL](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/sebastien_roul/32/5071_2.png) [@Sebastien\_ROUL](https://forums.suse.com/u/Sebastien_ROUL)\ **Post date:** [May 21, 2019, 10:01am UTC](https://forums.suse.com/t/ui-not-updating/14333/3 "2019-05-21T10:01:52Z")
@vincent Thanks for reply … For proxing websocket, I just folow the Example Nginx configuration in [https://rancher.com/docs/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/](https://rancher.com/docs/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/) but I’m stuck with this problem for days : Any good ideas ? 🙂 ---
**Author:** ![billg2](https://avatars.discourse-cdn.com/v4/letter/b/34f0e0/32.png) [@billg2](https://forums.suse.com/u/billg2)\ **Post date:** [June 3, 2019, 2:21pm UTC](https://forums.suse.com/t/ui-not-updating/14333/4 "2019-06-03T14:21:49Z")
For whatever reason I too had the same issue. Using the same config from 1.6.x and applying to 2.2.3 would always net the same websocket failed error. Rancher2 itself would only log even in debug: > 2019/06/03 13:47:53 [ERROR] Error during subscribe websocket: origin not allowed > 2019/06/03 13:47:53 [ERROR] Unknown error: websocket: origin not allowed Copy and paste verbatim from the external LB page and changing the upstream URL along with reformatting for use as a virtual host never always ended with the same origin error no matter the browser (Chrome / Firefox) or computer. I eventually found someone else with a similar issue posting to the GitLab forum. The solution was to change from: `proxy_set_header Host $host;` -TO- `proxy_set_header Host $http_host;` I might still tcpdump the traffic to see why $host fails but $http\_host works but for now I can continue with testing a migration. My NGINX version is: `nginx -v nginx version: nginx/1.16.0` ---
**Author:** ![vincent](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/vincent/32/7156_2.png) [@vincent](https://forums.suse.com/u/vincent)\ **Post date:** [June 3, 2019, 3:48pm UTC](https://forums.suse.com/t/ui-not-updating/14333/5 "2019-06-03T15:48:33Z")
`$http_host` is the raw (lowercased) `Host` header value, which contains the hostname and port (if not 80/443). `$host` is just the hostname parsed out of that (without the port). The example config is for 443, so these are the same value. But if you change the port they will not be the same anymore, and rejecting a connection where the Origin doesn’t match the expected Host is a necessary security check in the backend. So it seems like the example should use`$http_host` even though it makes no difference for that specific example.