Does the client embed a VM connection in an iframe so it can create a
thumbnail view of the VM from the VM picker screen?  If so, I might
recommend that the setup docs provide guidance to ensure that proxy
configurations allow for X-Frame-Options to be set with SAMEORIGIN.

Incidentally, this change _did_ fix the issue for us, but we didn't observe
it correctly until we did a hard refresh.  So, the mystery is solved!

On Fri, Nov 7, 2025 at 5:24 PM Carl Anderson <[email protected]>
wrote:

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

Reply via email to