ONLYOFFICEのNginx 502エラーを解消するために上流を追跡する

まず、NginxとONLYOFFICE Docs間の接続を確認し、502レスポンスに対応するエラーログを読み取ります。502 Bad Gatewayは、ゲートウェイがアップストリームサーバーから有効なレスポンスを取得できなかったことを意味します。このエラーだけでは、公開されているNginxの設定が原因であるとは断定できません。Docker環境では、通常、Nginxを内部ポート80のドキュメントサーバーサービス名に送信し、両方のコンテナが同じネットワークを共有していることを確認することで解決します。

Nginxを編集する前に確認すべきことは何ですか？

リバースプロキシとは、クライアントからのリクエストを受け取り、別のサーバーに転送するサーバーのことです。一般的な構成では、パブリックNginxがHTTPSを処理し、HTTP経由でONLYOFFICE Docsへのリクエストを転送します。ONLYOFFICE Docsは内部的に独自のNginxも実行しているため、502エラーページは外部プロキシまたはドキュメントサーバーコンテナ自体によって生成される可能性があります。

まず、どのサーバーが応答を発信したかを特定します。ページのサーバーヘッダーとタイムスタンプを、外部プロキシログとドキュメントサーバーのログと比較します。Docker環境の場合は、コンテナの状態と最近の起動メッセージを確認します。

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

コンテナが再起動中または起動したばかりの場合は、プロキシ設定を変更する前にログを確認してください。ONLYOFFICE は、データベースの初期化に 1～2 分かかる場合があると注意しています。ネイティブ Linux インストールの場合、ds-docserviceおよびds-converterで確認してくださいsystemctl status。ドキュメント サーバーのログは にあります/var/log/onlyoffice/documentserver/。

サービスが停止した場合は、対応する公式のONLYOFFICE Linux トラブルシューティング手順に従ってください。

Nginxはドキュメントサーバーの上流ネットワークに接続できますか？

テストは、ラップトップだけでなく、Nginxコンテナまたはホストから行ってください。別々のDockerネットワーク上のコンテナは、両方が実行されている場合でも、サービス名で互いを解決することはできません。NginxとONLYOFFICEがユーザー定義のDockerネットワークを共有する場合は、Composeサービス名、または解決可能なコンテナ名とコンテナのリスニングポートを使用してください。公式のDockerインストールガイドでは、ポート80がデフォルトのドキュメントサーバーリスナーとして指定されています。8080:80などの公開ホストポートは、内部ポートを変更しません。

プロキシコンテナから、以下を実行します。

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

実際の Compose サービス名に置き換えてくださいonlyoffice-documentserver。リクエストに「ホストを解決できませんでした」と表示される場合は、両方のコンテナを同じ Docker ネットワークに接続するか、アップストリーム名を修正してください。「接続が拒否されました」は通常、ターゲット ホストは解決されたものの、そのポートで接続を受け付けているものがなく、コンテナが準備できていないか、間違ったポートが使用されていることを意味します。ネイティブ インストールの場合は、代わりにローカル アドレスと構成済みのポートをテストしてください。例: curl -I http://127.0.0.1/。

ONLYOFFICE の Docker ガイドでは、デフォルト ポート、ポート マッピング、起動遅延、コンテナ ログについて説明しています: Docker のインストールと検証。

Nginxプロキシのターゲットを修正するにはどうすればよいですか？

ONLYOFFICEホスト名のHTTPS仮想ホストで、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コンテナ内とは、127.0.0.1そのコンテナ自体を指します。また、ドキュメントサーバーのエンドポイントが通常のHTTPである場合は、アップストリームにHTTPSを送信しないでください。

転送されたプロトコルとホストは、クライアントが使用したパブリック URL を ONLYOFFICE に伝え、アップグレード ヘッダーは、ライブ エディター通信に使用される WebSocket 接続を許可します。ONLYOFFICE は、プロキシの背後で Docs を実行するためのメンテナンスされたサンプルを提供しており、その中にはNginx HTTPS-to-HTTP 構成も含まれています。環境に複数のプロキシ ホップがある場合や、URL パスのプレフィックスを使用する場合は、この完全なサンプルと比較してください。

変更を適用する前に、設定を検証してからnginx -t、ホストまたはコンテナのメソッドを使用して Nginx をリロードしてください。すべてのサービスを一度に再起動しないでください。段階的にリロードすることで、上流の修正によって結果が変わったかどうかを確認しやすくなります。

ONLYOFFICEがそれでも502エラーを返す場合はどうすればよいでしょうか？

外部プロキシがドキュメントサーバーのウェルカムページに到達できるにもかかわらず/healthcheck502エラーを返す場合、問題は公開されているNginxではなく、ドキュメントサーバー内部にある可能性があります。ドキュメントサーバーのコンテナログと内部サービスログを確認してください。ネイティブLinuxインストールの場合、上記のサービスステータスコマンドとログディレクトリを確認してください。/welcome/応答はするもののヘルスチェックが応答しない場合は、それらを別々のシグナルとして扱ってください。静的なウェルカムページは、ドキュメントサービスとその依存関係が正常であることを証明するものではありません。

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のバージョンによって異なる場合があるため、実際の名前に置き換えて、応答を生成したコンポーネントのログを確認してください。