Collabora CODE not working with some users?

Installation & Configuration
1

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.

Screenshot_20250425_112627
Screenshot_20250425_1126271253×879 138 KB

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:

image_2025-04-25_09-51-11 (3)
image_2025-04-25_09-51-11 (3)1000×536 62.1 KB

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

2

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

3

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

4

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