Разместите Collabora за Nginx, не нарушая работу WebSockets.

Разместите Collabora на выделенном HTTPS-хосте в Nginx, перенаправьте пути редактора и обнаружения на coolwsd, и явно передавайте заголовки обновления WebSocket в маршрутах активных сокетов. Для одного хоста Nginx может завершать публичный TLS и отправлять HTTP-запросы в Collabora через частный интерфейс; если Nginx и Collabora работают в разных контейнерах, используйте имя службы Collabora в их общей сети вместо 127.0.0.1.

В этом примере предполагается, что пользователи открывают приложение https://office.example.com, а Nginx обрабатывает его сертификат. Порт прослушивания по умолчанию в Collabora — 9980; используйте порт, доступный в вашей системе. Для префикса URL-адреса, например, https://example.com/collabora/требуется согласованный путь и настройки корневого каталога службы, поэтому данная конфигурация корневого хоста не будет применяться без изменений.

1. Определите карту соединений с исходящим и WebSocket-каналами.

В контексте Nginx httpдобавьте имя вышестоящего сервера для Collabora и карту, которая устанавливает заголовок соединения upgradeтолько тогда, когда клиент запрашивает WebSocket. Разместите этот блок вне любого другого serverблока. Замените адрес, если Nginx обращается к Collabora другим способом.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream coolwsd {
    server 127.0.0.1:9980;
}

Если сам Nginx является контейнером, 127.0.0.1то используется именно этот контейнер Nginx, а не контейнер Collabora. В общей сети Docker вместо этого можно server collabora:9980;использовать имя сервиса, которое разрешается в этой сети.

2. Добавьте виртуальный хост HTTPS и маршруты Collabora.

Внутри блока HTTPS serverдля office.example.comперенаправьте ресурсы браузера, конечные точки обнаружения, соединения WebSocket и оставшиеся пути Collabora. Расположение соответствует рекомендациям Collabora по использованию прокси. Размещайте конкретные адреса сокетов выше более общего маршрута cool/ lool, чтобы Nginx корректно применял заголовки WebSocket.

server {
    listen 443 ssl;
    server_name office.example.com;

    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/private-key.pem;

    location ^~ /browser {
        proxy_pass http://coolwsd;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }

    location ^~ /hosting/discovery {
        proxy_pass http://coolwsd;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }

    location ^~ /hosting/capabilities {
        proxy_pass http://coolwsd;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }

    location ~ ^/cool/(.*)/ws$ {
        proxy_pass http://coolwsd;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }

    location ^~ /cool/adminws {
        proxy_pass http://coolwsd;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }

    location ~ ^/(c|l)ool {
        proxy_pass http://coolwsd;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Замените пути к сертификатам файлами вашего хоста. Если в вашей установке не используется консоль администратора, указание /cool/adminwsместоположения может не потребоваться для редактирования документов; основной /cool/.../wsмаршрут имеет важное значение. proxy_read_timeoutЗдесь указан один час в качестве примера, это не универсальное требование. Таймаут чтения прокси-сервера Nginx по умолчанию составляет 60 секунд между последовательными чтениями. Выберите значение, превышающее периоды простоя, необходимые для ваших сессий, или используйте соответствующий трафик WebSocket ping, если это поддерживается.

3. Настройте режим TLS в Collabora в соответствии с прокси-сервером.

Пользователи должны подключаться к Collabora по HTTPS, даже если частный канал Nginx-Collabora использует HTTP. В такой конфигурации с завершением TLS настройте coolwsdпрокси-сервер как терминатор TLS: SSL отключается на внутреннем слушателе, а завершение SSL включается. Примените эти настройки способом, поддерживаемым вашим пакетом или образом контейнера, а затем перезапустите/перезагрузите Collabora в соответствии с требованиями документации.

Используйте HTTP-протокол только в доверенной частной сети и заблокируйте публичный доступ к порту 9980. Если политика требует шифрования между Nginx и Collabora, используйте HTTPS-протокол и правильно настройте проверку сертификата; не отключайте проверку, чтобы скрыть несоответствие сертификата. В документации по настройкам прокси Collabora различается SSL на прокси-сервере и SSL между прокси-сервером и coolwsd.

Также установите URL-адрес Collabora в интеграции хранилища на общедоступное имя хоста HTTPS. В руководстве администратора Nextcloud требуется, чтобы браузер и оба сервера могли взаимодействовать друг с другом по протоколу HTTP(S) с использованием соответствующих внешних протоколов. Ограничьте список разрешенных адресов WOPI ожидаемым хостом хранилища и адресом Collabora; не ослабляйте его для решения проблемы с маршрутизацией через прокси.

4. Проверьте конфигурацию с обеих сторон.

Перед перезагрузкой проверьте синтаксис Nginx:

sudo nginx -t
sudo systemctl reload nginx

Если Nginx работает в контейнере, используйте процедуру проверки и перезагрузки этого контейнера. С хоста Nextcloud проверьте общедоступные конечные точки Collabora, используя фактическое имя хоста:

curl -fsS https://office.example.com/hosting/discovery -o /dev/null
curl -fsS https://office.example.com/hosting/capabilities -o /dev/null

Откройте эти HTTPS-адреса в браузере пользователя. Они проверяют доступность, но успешный ответ на запрос обнаружения сам по себе не доказывает работоспособность редактирования документа. Откройте документ и используйте панель «Сеть» в браузере, чтобы убедиться, что ресурсы загружены и соединение /cool/.../wsостается открытым. Успешное соединение HTTP/1.1 WebSocket обычно показывает ошибку 101 Switching Protocols; точное отображение может зависеть от браузера и протокола передачи данных. Если эта стандартная настройка работает в Firefox, но не работает в Chromium, проверьте метод запроса и протокол. В отчете об ошибке Collabora, открытом для версии 25.04, описывается соединение Chromium WebSocket через HTTP/2 с CONNECTошибкой 405; оно остается открытым, как проверено 9 октября 2026 г. Это отчет, специфичный для версии, а не универсальное поведение. Сравните версии Collabora, Nginx и браузера, прежде чем изменять настройки HTTP/2. См. проблему Collabora 12155 .

Если обнаружение не удается, проверьте журнал ошибок Nginx и убедитесь в правильности имени хоста, порта и протокола вышестоящего сервера. Если обнаружение работает, но редактирование не удается, проверьте маршрут WebSocket, заголовки, таймаут и журналы Collabora. Ошибка авторизации WOPI указывает на список разрешенных хостов хранилища. В руководстве по устранению неполадок Nextcloud Office рекомендуется проверить доступность из браузера, Nextcloud и Collabora, а затем просмотреть журналы обоих серверов.

В руководстве по проксированию WebSocket в Nginx объясняется, почему Upgradeпараметры Connectionдолжны передаваться явно и почему важно поведение таймаута простоя. См. справочник по модулю прокси Nginx для получения информации о поведении директив. После успешного прохождения проверок откройте, отредактируйте, сохраните и снова откройте тестовый документ, прежде чем предлагать пользователям использовать новый маршрут.