Zimbraの「Nginxプロキシサービスが停止しました」エラーを修正する方法

Zimbraが「Nginxプロキシサービスが停止しました」と報告する場合、プロキシプロセスが停止しているか、ステータスチェックで実行中であることを確認できない状態です。一時的な停止であれば再起動することでアクセスを回復できますが、NGINXが生成された設定を読み込めない、必要なポートをバインドできない、証明書を読み取れない、または有効なアップストリームサーバーに接続できない場合にも、同じメッセージが表示されることがあります。望ましい結果は、単にステータスが緑色になることだけではありません。プロキシは実行状態を維持し、Zimbraウェブメールは意図した公開URLから読み込まれ、プロキシログには起動失敗のエラーが表示されなくなります。

このガイドは、バンドルされている Zimbra Proxy サービスを使用する Zimbra デプロイメントに適用されます。正確なコマンドと構成の詳細は、Zimbra のバージョンとトポロジによって異なる場合があります。マルチサーバー構成の場合、プロキシ ノードでチェックを実行し、他のサーバーが停止したと報告したからといって、メールボックス ノードまたは MTA ノードでプロキシを有効にしないでください。Zimbra のプロキシ ガイドとプロキシ CLI リファレンスには、サービスとその診断ファイルについて記載されています。テクニカル センターのトラブルシューティング ページの中には、作業中とマークされているものもあるため、インストール済みのリリースに関するドキュメントと併せて使用してください。

1. プロキシがこのサーバー上で実行されることを確認してください。

プロキシをホストしているZimbraサーバーに接続し、Zimbraアカウントに切り替えます。サービス一覧全体とプロキシ固有のステータスの両方を確認してください。

su - zimbra
zmcontrol status
zmproxyctl status
zmprov gs `zmhostname` zimbraServiceEnabled

proxy有効になっているサービスでを探し、ステータス出力で実行中の NGINX プロセスを探してください。Zimbra は、、 、、、アクションzmproxyctlを含むドキュメントを扱っています。このホストがメールボックス専用または MTA 専用ノードの場合、プロキシが停止している可能性があります。サーバーを有効にする前に、デプロイメントにおけるサーバーの役割を確認してください。startstoprestartreloadstatus

プロキシがアクティブであるべきなのにステータスが停止している場合は、変更を加える前に現在の状態をキャプチャしてください。これにより、再起動の失敗と、ノード上でそもそも有効化されていなかったサービスを区別できます。

2. 再起動する前にNGINXのエラーログを確認してください。

Zimbraのプロキシトラブルシューティングガイドでは/opt/zimbra/log/nginx.log、と/opt/zimbra/log/nginx.access.logを重要なプロキシログとして特定しています。最近のエラーエントリと、メイン設定ファイルが存在するかどうかを確認してください。

tail -n 100 /opt/zimbra/log/nginx.log
tail -n 50 /opt/zimbra/log/nginx.access.log
ls -l /opt/zimbra/conf/nginx.conf

エラーメッセージは通常、次のチェック項目を示しています。「欠落」は、nginx.conf生成された構成の調査が必要であることを示唆しています。listenディレクティブ内の「無効なポート」は、ポートまたはバインド設定の問題を示しています。秘密鍵または証明書のエラーは、SSL関連の問題を示しています。バインドの失敗は、別のプロセスが既にそのアドレスとポートを使用している可能性があることを示しています。

エラーを解消するために、NGINXの設定ファイルを削除したり、生成されたファイルを編集したりしないでください。Zimbraは、設定ディレクトリとLDAPに保存されているテンプレートと値に基づいてNGINXの設定を構築します。この生成モデルについては、ベンダーのプロキシ設定およびテンプレートガイドを参照してください。生成されたファイルを手動で編集した場合、後日再起動または設定更新を行う際に上書きされる可能性があります。

3. サポートされているプロキシを再起動して結果を確認してください。

ログに永続的な構成エラーまたは証明書エラーが示されていない場合は、ZimbraユーザーとしてZimbraコントローラー経由でサービスを再起動してください。

zmproxyctl restart
zmproxyctl status

次に、サービス一覧全体を再度確認してください。

zmcontrol status

成功した場合、プロキシは実行中と報告し、コマンド完了後も実行状態を維持します。Zimbra のプロキシに関するドキュメントでは、zmproxyctl restart構成生成も呼び出すサービス操作として説明されています。システム全体のsystemctl restart nginx代替手段としては使用しないでください。Zimbra は独自のプロキシ構成とサービスを管理します。再起動が失敗した場合は、最新のエラーに戻ってくださいnginx.log。エラーを読み取らずに再起動を繰り返しても、通常は原因は修正されません。

4. エラーを適切な修復対象に照合する

設定ファイルが見つからない場合、または生成に失敗した場合

Zimbraのトラブルシューティングノートでは、/opt/zimbra/conf/nginx.confプロキシ構成の生成が失敗するケースとして、上流属性に存在しないサーバーまたはメールボックスサーバーではないサーバーが含まれている場合が挙げられています。まず、関連するサーバーレベルおよびグローバル値を確認してください。

zmprov -l gs `zmhostname` zimbraReverseProxyAvailableLookupTargets
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamEwsServers
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamLoginServers
zmprov -l gcf zimbraReverseProxyAvailableLookupTargets
zmprov -l gcf zimbraReverseProxyUpstreamEwsServers
zmprov -l gcf zimbraReverseProxyUpstreamLoginServers

各ホスト名をライブサーバーのインベントリと意図したルーティング設計と比較してください。どのサーバーがそのトラフィックを受信するべきかを確認してから、古いエントリや無効なエントリを修正してください。ベンダーのページからサンプルホスト名を本番環境にコピーしないでください。公式の「Nginx が起動しない」トラブルシューティングノートには、特定の missing-config / generator-error パターンに対応する設定生成コマンドが示されています。

/opt/zimbra/libexec/zmproxyconfgen -s `zmhostname`
zmproxyctl restart

この機能を使用するのは、発生した障害が上記のパターンに一致し、関連する値を確認した後のみです。ジェネレーターが例外をスローしたり、ファイルが見つからない場合は、繰り返し再実行するのではなく、停止して完全なスタックトレースとサーバー属性を調査してください。

ログに無効なポートまたはバインド失敗が報告されている場合

まず、どのリスナーが失敗しているかを特定します。このノードの Zimbra サービスとプロキシのポート値を確認し、影響を受けるアドレスで別のプロセスが既にリッスンしていないか調べます。たとえば、メッセージでポート 443 が指定されている場合は、パブリック HTTPS リスナーが Zimbra NGINX によって所有されているのか、別の Web サーバーまたはロード バランサー エージェントによって所有されているのかを確認します。クライアントがサービスにアクセスする方法を理解するまでは、不明なプロセスを終了したり、新しいポートを割り当てたりしないでください。

のようなエラーは、invalid port ...:0ポート番号を推測する理由にはなりません。これは、プロキシ設定または生成された構成に矛盾があることを示している可能性があります。値を想定されるトポロジと比較し、最近の変更を確認し、Zimbra がサポートするツールを使用してソース設定を修正してください。その後、で再起動しzmproxyctl、生成されたリスナーが有効であることを確認してください。

証明書または秘密鍵の読み込み中に起動に失敗した場合

SSLエラーメッセージ全文を読み、そこに記載されている証明書のパスを特定してください。証明書と秘密鍵がセットになっており、想定されるサービスアカウントで読み取り可能で、有効期限が切れていないことを確認してください。Zimbraのプロキシトラブルシューティングドキュメントには、プロキシがキーマテリアルを読み込めないケースが記載されています。ファイルをその都度置き換えるのではなく、Zimbraのバージョンに応じた証明書展開手順に従ってください。正常に再起動すれば、SSL起動エラーは解消され、ブラウザにパブリックWebメールホスト名に対応する証明書が表示されるはずです。

NGINXが起動してもユーザーにゲートウェイエラーが表示される場合

プロキシが稼働しているからといって、メールボックスのバックエンドが正常であるとは限りません。「ホストへのルートがありません」というエラーが発生した場合は、プロキシノードからDNS解決を確認し、目的のバックエンドへのポートレベルでの到達可能性を確認することをZimbraは推奨しています。502または503エラーが発生した場合は、メールボックスサービスとアップストリームのホストおよびポートを確認してください。プロキシガイドには、メールボックスプロセスが利用できない場合、503エラーが発生する可能性があると記載されています。プロキシのタイムアウトや障害しきい値を変更する前に、ご使用のリリースとトポロジーに合った正確なバックエンドとポートを使用し、メールボックスサーバーのログを確認してください。

5. サーバーとブラウザの両方から復旧を確認する

対象を絞った修理後、以下のすべてを確認してください。

• zmproxyctl statusプロキシが稼働中であることを報告します。
• zmcontrol statusこのノードで期待されるサービスを表示します。
• 最新の行では、/opt/zimbra/log/nginx.log同じ起動失敗は繰り返されません。
• 想定されるリスナーが存在し、目的のサービスによって所有されています。Linux では、管理者は を使ってリスナーを調べることができますss -ltnp。権限や出力の詳細はディストリビューションによって異なります。
• ブラウザはHTTPS経由で通常のZimbraウェブメールのホスト名にアクセスし、サインインしてメールボックスを読み込むことができます。IMAPまたはPOPクライアントもこのプロキシを使用している場合は、それらのプロトコルを個別にテストしてください。

これらのチェックによって、有用な復旧状況が定義されます。サービスが稼働しており、リスナーが存在し、ブラウザのパスが機能し、障害がすぐに再発していないことが確認されます。サービスの状態が緑色であるにもかかわらず、Webメールが依然として失敗する場合は、DNS、TLS、ファイアウォールルール、ロードバランサーのルーティング、またはメールボックスバックエンドの状態に注目してください。再び停止する場合は、新しいログ行と構成ジェネレータの出力を保存してください。これらは、闇雲に再起動するよりもはるかに有用です。

デバッグログは、短時間かつ制御された調査の場合にのみ使用してください。

通常のログで継続的な障害の原因が特定できない場合、Zimbra は NGINX プロキシのログレベルを一時的に引き上げたことをログに記録します。デバッグログは認証トークンなどの機密情報を漏洩させる可能性があるため、必要でない限り本番システムでは有効にしないでください。サポートから使用を指示された場合は、ログへのアクセスを制限し、必要な情報のみを収集してから、設定を以前の値に戻し、セキュリティポリシーに従ってデバッグログを処理してください。リリースに応じたコマンドについては、 Zimbra のNGINX デバッグログの手順を参照してください。

構成生成が引き続き失敗する場合、プロキシ証明書を検証できない場合、エラーが不明なリスナーに関係している場合、またはノードの役割が不明確な場合は、Zimbra管理者またはベンダーサポートにエスカレーションしてください。サービスコントローラは正常な構成を再起動することはできますが、適切なメールルーティングを判断したり、無効な証明書を修復したり、壊れたネットワークパスを解決したりすることはできません。

公式資料

• Zimbraプロキシガイド：ログとバックエンドのトラブルシューティング
• Zimbraプロキシマニュアル：プロキシCLIコマンド
• Zimbraテクニカルセンター：NGINXの起動に失敗する
• Zimbraテクニカルセンター：プロキシサービスが起動しない場合の対処方法
• Zimbraプロキシマニュアル：生成された設定とテンプレート

情報源は2026年10月6日に確認されました。ここで参照されているZimbraテクニカルセンターのページには古い例が含まれており、一部は開発中と表示されています。本番環境の設定を変更する前に、サーバーにインストールされているZimbraのリリースに合わせてコマンドを確認してください。