tobychui
[BUG] Apache Guacamole very laggy with zoraxy
Apache Guacamole requires several settings on a reverse proxy as you can see here:
https://guacamole.apache.org/doc/gug/reverse-proxy.html#proxying-with-apache
I tried to move from nginx to zoraxy but the established remote desktop session is very laggy an unusable.
Log is full of
POST /tunnel?write:0039daa4-8e32-3f85-a70b-a8381774011d 200
about 5 lines per second.
I cant´find the (probably) related settings in zoraxy for proxy_buffering off and SetEnvIf Request_URI "^/guacamole/tunnel" dontlog
To Reproduce Steps to reproduce the behavior:
- Use zoraxy as reverse porxy for apache guacamole
- Establish connection to rdp or vnc and see how laggy it works
Expected behavior On nginx with same backend everything runs smooth and rdp is usable like physical pc
Host Environment (please complete the following information):
- Arch: amd64
- Device: LXC Container
- OS: Debian 12
- Zoraxy 3.1.1r3
@psycho160 I am kinda amazed that they didn't use websocket for that.
Back to your question, currently Zoraxy don't have ways to disable log for a certain path. Even if it does, Zoraxy speed will not be comparable with apache or nginx. That was caused by the implementation of Zoraxy are highly focused in "smart" routing logic in which some extra code segments (and thus, CPU cycles) are used to do things like SNI, request header sniffing or auto path rewrite corrections.
If speed and low latency are really your main concerns, I would recommend keeping the current setup or use Zoraxy as a secondary reverse proxy (i.e. use nginx in your gateway node which forward some subdomains / hostnames to Zoraxy).
They use websocket indeed but maybe i have to configure something that zoraxy can use it. In the upstream i disabled the Skip websocket... option.
Hi, just stumbled upon this issue, just adding my feedback, I can't replicate this behaviour, for me VNC and RDP seem to work fine on guacamole or at least on a similar latency than NPM, guacmaole is not "the quickest" to load up.
Thanks for the feedback! It seems the issue has resolved itself during the previous dpcore optimizations. I am closing this now.