Jak naprawić błąd Zimbra „Usługa proxy Nginx zatrzymana”

Gdy Zimbra zgłasza komunikat „Usługa proxy Nginx zatrzymana”, proces proxy jest wyłączony lub jego status nie może potwierdzić jego działania. Ponowne uruchomienie może przywrócić dostęp, gdy zatrzymanie było tymczasowe, ale ten sam komunikat może zostać zwrócony, jeśli NGINX nie może załadować wygenerowanej konfiguracji, powiązać wymaganego portu, odczytać certyfikatu lub nawiązać połączenia z prawidłowym serwerem nadrzędnym. Przydatnym rezultatem nie jest tylko zielony status: proxy powinno pozostać uruchomione, poczta internetowa Zimbra powinna ładować się przez docelowy publiczny adres URL, a logi proxy nie powinny już wskazywać błędu uruchamiania.

Niniejszy przewodnik dotyczy wdrożeń Zimbra korzystających z dołączonej usługi Zimbra Proxy. Dokładne polecenia i szczegóły konfiguracji mogą się różnić w zależności od wersji i topologii Zimbra. W przypadku instalacji wieloserwerowej należy przeprowadzić kontrole na węźle proxy i nie włączać proxy na skrzynce pocztowej lub węźle MTA tylko dlatego, że inny serwer zgłasza jego zatrzymanie. W podręczniku Zimbra Proxy Guide i dokumentacji interfejsu CLI proxy opisano usługę i jej pliki diagnostyczne. Niektóre strony rozwiązywania problemów w Centrum technicznym są oznaczone jako prace w toku, dlatego należy z nich korzystać wraz z dokumentacją zainstalowanej wersji.

1. Potwierdź, że serwer proxy ma działać na tym serwerze

Połącz się z serwerem Zimbra, który hostuje serwer proxy i przełącz się na konto Zimbra. Sprawdź zarówno ogólną listę usług, jak i status konkretnego serwera proxy:

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

Poszukaj proxywłączonych usługach i działającego procesu NGINX w wynikach statusu. Dokumenty Zimbra zmproxyctlz akcjami start, stop, restart, reloadi status. Jeśli ten host jest węzłem obsługującym tylko skrzynkę pocztową lub tylko MTA, można spodziewać się zatrzymania serwera proxy. Przed próbą jego włączenia sprawdź rolę serwera we wdrożeniu.

Jeśli serwer proxy powinien być aktywny, a stan jest zatrzymany, przed wprowadzeniem jakichkolwiek zmian należy zapisać aktualny stan. Ułatwia to odróżnienie nieudanego restartu od usługi, która nigdy nie została włączona na węźle.

2. Przed ponownym uruchomieniem przeczytaj dziennik błędów NGINX

Przewodnik Zimbra do rozwiązywania problemów z proxy identyfikuje /opt/zimbra/log/nginx.logi /opt/zimbra/log/nginx.access.logjako kluczowe logi proxy. Sprawdź ostatnie wpisy błędów i upewnij się, że główny plik konfiguracyjny istnieje:

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

Tekst błędu zazwyczaj wskazuje na następne sprawdzenie. Brakujący element nginx.confsugeruje, że wygenerowana konfiguracja wymaga sprawdzenia. „Nieprawidłowy port” w listendyrektywie wskazuje na port lub ustawienie powiązania. Błąd klucza prywatnego lub certyfikatu wskazuje na materiał SSL. Błąd powiązania wskazuje, że inny proces może już posiadać adres i port.

Nie usuwaj plików konfiguracyjnych NGINX ani nie edytuj wygenerowanych plików, aby błąd zniknął. Zimbra buduje konfigurację NGINX na podstawie szablonów i wartości przechowywanych w katalogu konfiguracyjnym i LDAP. Ten model generowania jest wyjaśniony w podręczniku dostawcy dotyczącym konfiguracji proxy i szablonów . Ręczne zmiany w wygenerowanych plikach mogą zostać zastąpione podczas późniejszego ponownego uruchomienia lub aktualizacji konfiguracji.

3. Wypróbuj obsługiwany restart serwera proxy i sprawdź wynik

Jeśli logi nie wskazują na trwały błąd konfiguracji lub certyfikatu, uruchom ponownie usługę za pomocą kontrolera Zimbra jako użytkownik Zimbra:

zmproxyctl restart
zmproxyctl status

Następnie sprawdź jeszcze raz pełną listę usług:

zmcontrol status

Pomyślny wynik oznacza, że ​​serwer proxy zgłasza działanie i pozostaje aktywny po zakończeniu polecenia. Dokumentacja serwera proxy Zimbra opisuje zmproxyctl restarttę operację jako usługę, która również wywołuje generowanie konfiguracji. Unikaj używania opcji systemowej systemctl restart nginxjako zamiennika: Zimbra zarządza własną konfiguracją i usługą serwera proxy. Jeśli restart się nie powiedzie, wróć do najnowszego błędu w nginx.log; wielokrotne restarty bez odczytania błędu zazwyczaj nie usuwają przyczyny.

4. Dopasuj błąd do docelowej naprawy

Jeśli plik konfiguracyjny jest nieobecny lub generowanie się nie powiedzie

Notatka Zimbry dotycząca rozwiązywania problemów z brakującym serwerem /opt/zimbra/conf/nginx.confopisuje przypadki, w których generowanie konfiguracji proxy kończy się niepowodzeniem, ponieważ atrybut nadrzędny zawiera nieistniejący serwer lub serwer, który nie jest serwerem skrzynki pocztowej. Najpierw sprawdź odpowiednie wartości na poziomie serwera i wartości globalne:

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

Porównaj każdą nazwę hosta z inwentarzem serwerów na żywo i planowanym projektem routingu. Popraw nieaktualne lub nieprawidłowe wpisy dopiero po potwierdzeniu, który serwer powinien odbierać ten ruch. Nie kopiuj przykładowej nazwy hosta ze strony dostawcy do środowiska produkcyjnego. Oficjalna notatka dotycząca rozwiązywania problemów „Nginx nie uruchamia się” zawiera polecenie generatora konfiguracji dla konkretnego wzorca brakującej konfiguracji/generatora błędów:

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

Użyj tego tylko wtedy, gdy zaobserwowany błąd pasuje do tego wzorca i po sprawdzeniu odpowiednich wartości. Jeśli generator nadal zgłasza wyjątek lub plik nadal brakuje, zatrzymaj się i sprawdź pełny ślad stosu oraz atrybuty serwera, zamiast wielokrotnie go uruchamiać.

Jeśli w dzienniku zgłoszono nieprawidłowy port lub błąd powiązania

Najpierw zidentyfikuj, który skonfigurowany nasłuchiwacz nie działa. Sprawdź wartości portu usługi Zimbra i proxy dla tego węzła, a następnie sprawdź, czy inny proces nasłuchuje już na danym adresie. Na przykład, jeśli komunikat ma nazwę portu 443, sprawdź, czy publiczny nasłuchiwacz HTTPS należy do Zimbra NGINX, czy do oddzielnego serwera WWW lub agenta równoważenia obciążenia. Nie kończ nieznanego procesu ani nie przypisuj nowego portu, dopóki nie zrozumiesz, w jaki sposób klienci docierają do usługi.

Błąd taki jak „ invalid port ...:0nie jest powodem do zgadywania numeru portu. Może wskazywać na niespójne ustawienia proxy lub wygenerowaną konfigurację. Porównaj wartość z oczekiwaną topologią, przejrzyj ostatnie zmiany i popraw ustawienia źródłowe za pomocą obsługiwanych narzędzi Zimbra. Następnie uruchom ponownie zmproxyctli sprawdź, czy wygenerowany nasłuchiwacz jest prawidłowy.

Jeśli uruchomienie nie powiedzie się podczas ładowania certyfikatu lub klucza prywatnego

Przeczytaj cały błąd SSL i zidentyfikuj ścieżkę certyfikatu w nim wskazaną. Upewnij się, że certyfikat i klucz prywatny są ze sobą powiązane, są czytelne dla oczekiwanego konta usługi i nie wygasły. Dokumentacja rozwiązywania problemów z proxy Zimbra zawiera opis przypadku, w którym proxy nie może załadować klucza. Postępuj zgodnie z procedurą wdrażania certyfikatu dla swojej wersji Zimbra, zamiast doraźnie zastępować pliki. Pomyślne ponowne uruchomienie powinno usunąć błąd uruchamiania SSL, a przeglądarka powinna wyświetlić oczekiwany certyfikat dla publicznej nazwy hosta poczty internetowej.

Jeśli NGINX uruchamia się, ale użytkownicy widzą błędy bramy

Działający serwer proxy nie gwarantuje, że serwery pocztowe są sprawne. W przypadku komunikatu „Brak trasy do hosta” Zimbra zaleca sprawdzenie rozdzielczości DNS z węzła proxy oraz dostępności na poziomie portu do docelowego serwera pocztowego. W przypadku odpowiedzi 502 lub 503 należy zweryfikować usługę skrzynki pocztowej oraz hosta nadrzędnego i port; w przewodniku po serwerach proxy zaznaczono, że niedostępny proces skrzynki pocztowej może powodować błędy 503. Należy używać serwera pocztowego i portu dokładnie odpowiadającego wersji i topologii oraz sprawdzać logi serwera pocztowego przed zmianą limitów czasu proxy lub progów awarii.

5. Sprawdź odzyskiwanie zarówno z serwera, jak i przeglądarki

Po wykonaniu naprawy punktowej należy potwierdzić wszystkie poniższe elementy:

• zmproxyctl statusinformuje o uruchomieniu serwera proxy.
• zmcontrol statuspokazuje oczekiwane usługi dla tego węzła.
• Najnowsze linie /opt/zimbra/log/nginx.lognie powtarzają tego samego błędu uruchamiania.
• Oczekiwany obiekt nasłuchujący jest obecny i należy do usługi docelowej. W systemie Linux administrator może inspekcję obiektów nasłuchujących z ss -ltnpuprawnieniami ; a szczegóły danych wyjściowych różnią się w zależności od dystrybucji.
• Przeglądarka może połączyć się ze standardową nazwą hosta poczty internetowej Zimbra przez HTTPS, zalogować się i załadować skrzynkę pocztową. Jeśli klienci IMAP lub POP również korzystają z tego serwera proxy, należy przetestować te protokoły osobno.

Te kontrole definiują użyteczny sposób odzyskiwania: usługa działa, jej program nasłuchujący istnieje, ścieżka przeglądarki działa, a błąd nie został natychmiast zwrócony. Jeśli status usługi jest zielony, ale poczta internetowa nadal nie działa, zwróć uwagę na DNS, TLS, reguły zapory sieciowej, routing modułu równoważenia obciążenia lub stan zaplecza skrzynki pocztowej. Jeśli usługa ponownie się zatrzyma, zachowaj nowe wiersze dziennika i dane wyjściowe generatora konfiguracji; są one bardziej przydatne niż kolejny restart bez wiedzy użytkownika.

Rejestrowanie debugowania należy stosować wyłącznie w przypadku krótkiego, kontrolowanego dochodzenia

Jeśli normalne logi nie wyjaśniają trwałego błędu, Zimbra dokumentuje tymczasowy wzrost poziomu logów proxy NGINX. Logowanie debugowania może ujawnić poufne informacje, w tym tokeny uwierzytelniające, dlatego należy unikać włączania go w systemie produkcyjnym, chyba że jest to konieczne. Jeśli wsparcie techniczne zaleci korzystanie z tej funkcji, należy ograniczyć dostęp do logów, gromadzić tylko niezbędne dane, a następnie przywrócić poprzednią wartość ustawienia i obsługiwać logi debugowania zgodnie z polityką bezpieczeństwa. Aby uzyskać informacje o poleceniu odpowiednim dla danej wersji, należy zapoznać się z instrukcjami Zimbra dotyczącymi rejestrowania debugowania NGINX .

Jeśli generowanie konfiguracji nadal się nie powiedzie, nie można zweryfikować certyfikatu proxy, błąd wskazuje na nieznanego odbiorcę lub rola węzła jest niejasna, skontaktuj się z administratorem Zimbra lub dostawcą pomocy technicznej. Kontroler usługi może ponownie uruchomić prawidłową konfigurację; nie jest jednak w stanie samodzielnie określić prawidłowego routingu poczty, naprawić nieprawidłowego certyfikatu ani rozwiązać problemu z uszkodzoną ścieżką sieciową.

Oficjalne referencje

• Przewodnik po serwerze proxy Zimbra: rozwiązywanie problemów z dziennikami i zapleczem
• Podręcznik Zimbra Proxy: polecenia CLI proxy
• Centrum techniczne Zimbra: NGINX nie uruchamia się
• Centrum techniczne Zimbra: kroki w przypadku usługi proxy, która nie uruchamia się
• Podręcznik Zimbra Proxy: wygenerowana konfiguracja i szablony

Źródła sprawdzone 6 października 2026 r. Strony Centrum Technicznego Zimbra, do których się tu odwołujemy, zawierają starsze przykłady, a niektóre są oznaczone jako prace w toku. Przed zmianą konfiguracji produkcyjnej sprawdź polecenia w wersji Zimbra zainstalowanej na serwerze.