UI not updating

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

Also, in the console (devTools) here is the webscket state :

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).

@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/ but I’m stuck with this problem for days : Any good ideas ? :slight_smile:

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;
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

$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.