We may have made a discovery to suggest that the issue is not with the guacamole-client, but with our nginx configuration. The problem seems to be caused by (or related to) the presence of an X-Frame-Options "DENY" rule, which was also added in the upgrade.
To test this, we set up a dockerized guacamole running locally, along with a dockerized nginx and dockerized guacd. When we remove the config line, we're able to reload the browser tab and the websocket reconnects, as expected. When we restore the config line, the websocket is never restored on reload. I'm not sure what to make of this, though. Also, when we made the same config change in our ops environment, it didn't resolve the problem there. We're running a slightly older version of nginx, there, so that might be a factor - but it's odd to me that nothing is logged by nginx for this. We also tried to use a "SAMEORIGIN" rule instead of the "DENY" rule in our ops environment, but that did not resolve the issue, either. So, while this doesn't seem to have much to do with the guacamole-client, I'm wondering if there is some missing error detection in the client. We end up looking at a black screen with no apparent error message - further reloading makes no difference - the easiest resolution is to click 'back' and then click 'forward' again to reconnect to the VM and restore the websocket. Maybe the client should be able to detect when it has no websocket and pop up a message saying "something seems wrong here" after 15 seconds (or something). I'm still a bit confused about why this only happens on reloads. I don't understand why the X-Frame-Options "DENY" wouldn't block the initial request to access the VM. On Thu, Nov 6, 2025 at 11:55 AM Carl Anderson <[email protected]> wrote: > We recently updated our guacamole deployment to 1.6.0 and our users have > lost the ability to reload the browser tab when connected to a VM. It > appears that the websocket tunnel is disconnected on reload and never > reconnected. When they reload the tab, the screen goes black and stops > receiving updates. The developer console shows that the websocket is gone, > and the guacd log shows that the client has disconnected. > > We're trying to troubleshoot the issue in the guacamole-client, and have > had limited success working with the webpacked client code - some of it can > be mapped to sources while other parts are still minified. So, if there > are suggestions to make it easier to debug the client, we would appreciate > any help getting started. > > To make matters more complicated, it seems that for some users in some > browsers, they _are_ able to reload the browser and the guacamole client > websocket does reconnect, but for most users it does not. > > The other thing we're seeing is - the websocket is sometimes being lost > for users who resize their browser window by dragging the window corners. > For them, the screen redraws for a bit before it goes black. This problem > seems to affect users in Windows on Edge disproportionally, but we've heard > reports from other OS and browser configurations, too. We haven't ruled > out the possibility that these could be two manifestations of the same bug, > which is why I bring it up. > > I'm happy to provide more details about our setup, if it's relevant - or > any of the logs from guacd or tomcat. > > I wish I had better details to share - we don't see anything obvious in > the tomcat guacamole log, in the nginx logs, or in the guacd logs. It > looks like the client is hanging up and never trying to reconnect. > > Thanks! >
