Collabora CODE not working with some users?

Hi

I have a strange problem with Collabora Code (version 24.04.13.3-1) but problem looks to have started a little while ago. Code is installed using Debian packages on a debian 12 system. Reverse proxy is done with Apache with a proper SSL certificate.
Nextcloud (version 30 or 31) is configured to use it and in Admin settings of Nextcloud it states everything is good.

It’s used by multiple NC instances on that server (shared hosting server).
Server is in a datacenter.
When I try to open some documents in these Nextcloud I have no problem using either Firefox or Chromium.
Some users are unable to open documents due to a proxy error:


How it can affect only some users and not all of them ?

Update: i have found a way to mitigate the issue adding:

connectiontimeout=60 timeout=60

at ProxyPass directive but it’s far from perfect and still not working for some users :frowning:

Thanks for help,

Vincèn

Hi @vincen,

Possible Causes

  1. User networks – Firewalls, proxies, or slow connections on the client side might break WebSocket or long-lived HTTP connections.
  2. Apache config – Double-check these are set:
ProxyPass /lool/ws wss://127.0.0.1:9980/lool/ws retry=0
ProxyPassReverse /lool/ws wss://127.0.0.1:9980/lool/ws

ProxyPass / http://127.0.0.1:9980/ timeout=60 keepalive=On retry=0
ProxyPassReverse / http://127.0.0.1:9980/

Make sure proxy_wstunnel, proxy_http, and headers modules are enabled.

  1. Connection limits – Check Apache’s MaxClients, ServerLimit, and system limits (like ulimit or /proc/sys/net/core/somaxconn).
  2. IPv6 issues – Some users might hit IPv6 problems. Test with IPv6 off.
  3. Browser problems – Extensions, caching, or browser bugs. Ask affected users to try incognito or another browser.
  4. Logs – Check CODE logs (/var/log/coolwsd.log) and Apache logs when it fails.

Suggestions

  • Raise timeout, ProxyTimeout, and enable keepalive.
  • Compare logs for users where it fails vs works.
  • Get dev console output from affected users (network tab, any 502s?).

Thanks
Darshan

Hi @darshan

Thanks a lot for your message and stuffs to check. I have checked all points you list, made some modifications in config of my proxy-reverse as you suggested but still the same.
I have checked in apache logs and I don’t see any differences between my requests to open a document and some of other users excepted that mine succeeds and some others fail with a 401 error code.
For CODE logs it doesn’t log at all. It’s well configured to log in /var/log/coolwsd.log but the file doesn’t exist in my system.
Something else I can check ? and still don’t understand why it works randomly depending of users :frowning:

Vincèn

Hello @vincen

Can you please go through below points and give me some insights so it will better to solve the issue here…

1 Browser Console Logs and Dev Tools:

Ask affected users to open Dev Tools (F12 → Network tab), reload the failing document, and check:

  • Does the WebSocket connection (/lool/ws) succeed or fail?
  • Do they see CORS or TLS errors?

It will help narrow whether it’s a client issue or a server-side Apache timeout/drop.


2. Check for Intermediate Firewalls / Shared Hosting Restrictions:

Since it’s shared hosting in a datacenter:

  • Are there limits or DPI firewalls (deep packet inspection) that might interfere with WebSocket traffic?
  • Are idle or long-lived connections being killed?

You may try:

  • Setting KeepAlive On and MaxKeepAliveRequests 1000 in Apache.
  • Increasing KeepAliveTimeout 120.

3. Client-Side Network Issues:

Some users may be behind corporate proxies or ISPs that block or degrade WebSocket connections.

Ask them to try:

  • Different browsers (some proxies behave differently with Firefox vs Chrome).
  • Mobile tethering (to test if their home/corporate network is the culprit)

Thanks
Darshan