Отслеживание источника ошибки Nginx в ONLYOFFICE: ошибка 502

Для начала проверьте соединение между Nginx и ONLYOFFICE Docs, затем прочтите журнал ошибок, соответствующий ответу 502. Ошибка 502 Bad Gateway означает, что шлюз не смог получить действительный ответ от своего вышестоящего сервера; сама по себе она не доказывает, что причиной является публичная конфигурация Nginx. В Docker обычное решение — перенаправить Nginx на имя службы Document Server через его внутренний порт 80 и убедиться, что оба контейнера используют одну и ту же сеть.

Что следует проверить перед редактированием Nginx?

Обратный прокси — это сервер, который принимает запрос клиента и перенаправляет его на другой сервер. В типичной конфигурации публичный Nginx обрабатывает HTTPS и перенаправляет запросы к ONLYOFFICE Docs по HTTP. ONLYOFFICE Docs также запускает собственный внутренний Nginx, поэтому страница с ошибкой 502 может быть сгенерирована внешним прокси или самим контейнером Document Server.

Сначала определите, какой сервер отправил ответ. Сравните заголовок и метку времени сервера страницы с журналом внешнего прокси и журналами сервера документов. Для конфигурации Docker проверьте состояние контейнера и последние сообщения о запуске:

docker ps --filter name=onlyoffice-documentserver
docker logs --tail 100 onlyoffice-documentserver

Если контейнер перезапускается или только что запустился, изучите журнал перед изменением настроек прокси. ONLYOFFICE отмечает, что первый запуск может занять минуту-две, пока инициализируется база данных. Для нативной установки Linux проверьте ds-docserviceи ds-converterс помощью systemctl status; журналы Document Server находятся в /var/log/onlyoffice/documentserver/.

Если служба остановлена, воспользуйтесь соответствующими официальными инструкциями по устранению неполадок ONLYOFFICE Linux .

Может ли Nginx связаться с вышестоящим сервером документов?

Проверяйте работу контейнера или хоста Nginx, а не только с ноутбука. Контейнеры в разных сетях Docker не могут разрешать друг друга по имени службы, даже если оба запущены. Когда Nginx и ONLYOFFICE используют общую пользовательскую сеть Docker, используйте имя службы Compose или разрешаемое имя контейнера и порт прослушивания контейнера. В официальном руководстве по установке Docker порт 80 указан как порт прослушивания Document Server по умолчанию; указанный порт хоста, например 8080:80, не изменяет внутренний порт.

Из контейнера прокси выполните:

curl -I http://onlyoffice-documentserver:80/

Замените onlyoffice-documentserverна фактическое имя вашей службы Compose. Если запрос выдает ошибку «Не удалось разрешить хост», подключите оба контейнера к одной и той же сети Docker или исправьте имя вышестоящего сервера. Ошибка «Соединение отклонено» обычно означает, что целевой хост разрешен, но на этом порту ничего не принимает соединения, контейнер не готов или использован неправильный порт. Если это нативная установка, проверьте локальный адрес и настроенный порт, например curl -I http://127.0.0.1/.

В руководстве по Docker от ONLYOFFICE рассматриваются порт по умолчанию, сопоставление портов, задержка запуска и журналы контейнера: установка и проверка Docker .

Как исправить целевой объект прокси Nginx?

В настройках виртуального хоста HTTPS для имени хоста ONLYOFFICE укажите proxy_passдоступный вышестоящий сервер. В этом примере предполагается использование общей сети Docker и указанного выше имени службы; измените его в соответствии с вашей конфигурацией:

location / {
    proxy_pass http://onlyoffice-documentserver:80;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Не следует направлять контейнеризированный прокси-сервер на адрес, 127.0.0.1:8080если Document Server фактически не прослушивает соединения в том же контейнере или если адрес хоста намеренно настроен и доступен. Внутри контейнера 127.0.0.1это означает сам контейнер. Также избегайте отправки HTTPS-запросов на вышестоящий сервер, если конечная точка Document Server использует обычный HTTP.

Перенаправляемый протокол и хост сообщают ONLYOFFICE, какой публичный URL-адрес использовал клиент, а заголовки обновления разрешают соединения WebSocket, используемые для связи с редактором в режиме реального времени. ONLYOFFICE предоставляет поддерживаемые примеры для запуска Docs за прокси-сервером , включая конфигурацию Nginx HTTPS-to-HTTP . Сравните с этим полным примером, если в вашей среде используется несколько прокси-серверов или префикс пути URL.

Перед применением изменений проверьте конфигурацию с помощью команды nginx -t`nginx`, затем перезагрузите Nginx, используя метод, подходящий для вашего хоста или контейнера. Не перезапускайте все службы одновременно; контролируемая перезагрузка позволит легче увидеть, изменился ли результат после внесения исправлений в исходный код.

Что если ONLYOFFICE по-прежнему возвращает ошибку 502?

Если внешний прокси-сервер может связаться со страницей приветствия Document Server, но /healthcheckвозвращает ошибку 502, проблема может быть внутри Document Server, а не в общедоступном Nginx. Проверьте журналы контейнера Document Server и внутренние журналы службы. Для нативных установок Linux просмотрите команды проверки состояния службы и каталог журналов, указанные выше. Если /welcome/служба отвечает, но проверка работоспособности не дает результата, рассматривайте это как отдельные сигналы: статическая страница приветствия не доказывает работоспособность службы Document Server и ее зависимостей.

Не стоит «исправлять» это, отключая JWT. Проверка JSON Web Token (JWT) аутентифицирует запросы интеграции; несоответствие JWT обычно приводит к ошибке авторизации, а не к невозможности подключения к вышестоящему серверу на сетевом уровне. Проверяйте настройки JWT только в том случае, если прокси-сервер отвечает, но интеграция сообщает об ошибке авторизации или токена.

Наконец, убедитесь, что Nginx направляет правильное имя хоста на правильный виртуальный хост. Опечатка в server_nameимени DNS-сервера или порту может привести к перенаправлению трафика в другое место или к выходу из прокси-сервера с устаревшей конфигурацией. Проверьте журнал ошибок Nginx на наличие строк, таких как host not found in upstream, connect() failed, или upstream timed out; каждая из них указывает на разный уровень.

Как проверить правильность исправления?

Повторно проверьте исходящий сигнал из прокси-сети, затем проверьте общедоступную точку доступа и откройте документ через подключенную платформу:

curl -I https://docs.example.com/healthcheck

Успешный ответ проверки работоспособности больше не должен быть ошибкой 502, и документ должен открываться и оставаться подключенным во время редактирования. Если проверка вышестоящего сервера проходит успешно, но публичный запрос по-прежнему завершается ошибкой, сосредоточьтесь на выбранном виртуальном хосте Nginx, его загруженной конфигурации и журналах. Если публичная страница приветствия работает, но проверка работоспособности по-прежнему выдает ошибку 502, продолжите внутреннюю диагностику службы ONLYOFFICE.

Для получения информации о поведении директив Nginx обратитесь к официальной документации модуля прокси Nginx . Точные команды и имена служб могут различаться в зависимости от проекта Docker Compose, дистрибутива Linux и версии ONLYOFFICE, поэтому замените их своими фактическими именами и проверьте логи компонента, сгенерировавшего ответ.