Śledź przepływ, aby wyczyścić Nginx 502 ONLYOFFICE

Zacznij od sprawdzenia połączenia między Nginx a ONLYOFFICE Docs, a następnie przeczytaj dziennik błędów odpowiadający odpowiedzi 502. Błąd 502 Bad Gateway oznacza, że ​​brama nie mogła uzyskać prawidłowej odpowiedzi od swojego serwera nadrzędnego; samo to nie dowodzi, że przyczyną jest publiczna konfiguracja Nginx. W Dockerze standardowym rozwiązaniem jest wysłanie Nginx do nazwy usługi serwera dokumentów na jego wewnętrznym porcie 80 i upewnienie się, że oba kontenery korzystają ze wspólnej sieci.

Co należy sprawdzić przed edycją Nginx?

Odwrotny serwer proxy to serwer, który akceptuje żądanie klienta i przekazuje je do innego serwera. W typowym wdrożeniu publiczny serwer Nginx obsługuje protokół HTTPS i przekazuje żądania do serwisu ONLYOFFICE Docs przez HTTP. Serwis ONLYOFFICE Docs uruchamia również wewnętrznie własny serwer Nginx, więc strona 502 może zostać wygenerowana przez zewnętrzny serwer proxy lub przez sam kontener serwera dokumentów.

Najpierw zidentyfikuj serwer, który wyemitował odpowiedź. Porównaj nagłówek serwera i znacznik czasu strony z dziennikiem zewnętrznego serwera proxy i dziennikami serwera dokumentów. W przypadku konfiguracji Dockera sprawdź status kontenera i ostatnie komunikaty startowe:

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

Jeśli kontener jest restartowany lub dopiero co uruchomiony, sprawdź dziennik przed zmianą ustawień proxy. ONLYOFFICE zauważa, że ​​pierwsze uruchomienie może potrwać minutę lub dwie, ponieważ baza danych jest inicjowana. W przypadku natywnej instalacji systemu Linux sprawdź ds-docservicei ds-converterza pomocą systemctl status; dzienniki serwera dokumentów znajdują się w /var/log/onlyoffice/documentserver/.

Jeśli usługa zostanie zatrzymana, skorzystaj z oficjalnych instrukcji rozwiązywania problemów ONLYOFFICE Linux .

Czy Nginx może nawiązać połączenie z serwerem dokumentów?

Przeprowadź test z kontenera Nginx lub hosta, a nie tylko z laptopa. Kontenery w oddzielnych sieciach Docker nie mogą się wzajemnie rozwiązywać po nazwie usługi, nawet gdy oba są uruchomione. Gdy Nginx i ONLYOFFICE współdzielą zdefiniowaną przez użytkownika sieć Docker, użyj nazwy usługi Compose lub rozpoznawalnej nazwy kontenera oraz portu nasłuchującego kontenera. Oficjalny podręcznik instalacji Dockera identyfikuje port 80 jako domyślny nasłuch serwera dokumentów; opublikowany port hosta, taki jak 8080:80, nie zmienia portu wewnętrznego.

Z kontenera proxy uruchom:

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

Zastąp onlyoffice-documentserverrzeczywistą nazwą usługi Compose. Jeśli żądanie wyświetla komunikat „Nie można rozpoznać hosta”, podłącz oba kontenery do tej samej sieci Docker lub popraw nazwę nadrzędną. „Połączenie odrzucone” zazwyczaj oznacza, że ​​host docelowy został rozpoznany, ale na tym porcie nic nie akceptuje połączeń, kontener nie jest gotowy lub użyto niewłaściwego portu. Jeśli jest to instalacja natywna, przetestuj adres lokalny i skonfigurowany port, na przykład curl -I http://127.0.0.1/.

W podręczniku ONLYOFFICE dotyczącym Dockera omówiono domyślny port, mapowanie portów, opóźnienie uruchamiania i logi kontenerów: instalacja i weryfikacja Dockera .

Jak naprawić cel proxy Nginx?

W wirtualnym hoście HTTPS dla nazwy hosta ONLYOFFICE wskaż proxy_passosiągalny serwer nadrzędny. W tym przykładzie założono współdzieloną sieć Docker i nazwę usługi pokazaną powyżej; zmień ją, aby pasowała do Twojego wdrożenia:

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";
}

Nie należy kierować serwera proxy w kontenerze, 127.0.0.1:8080chyba że serwer dokumentów faktycznie nasłuchuje w tym samym kontenerze lub adres hosta jest celowo skonfigurowany i osiągalny. Wewnątrz kontenera 127.0.0.1oznacza to sam kontener. Należy również unikać wysyłania protokołu HTTPS do nadrzędnego serwera dokumentów, gdy punkt końcowy serwera dokumentów to zwykły protokół HTTP.

Przekierowany protokół i host informują ONLYOFFICE, z którego publicznego adresu URL korzystał klient, a nagłówki aktualizacji zezwalają na połączenia WebSocket używane do komunikacji z edytorem na żywo. ONLYOFFICE udostępnia aktualizowane przykłady uruchamiania Dokumentów za pośrednictwem serwera proxy , w tym konfigurację Nginx HTTPS-HTTP . Porównaj z tym pełnym przykładem, jeśli Twoje środowisko obsługuje wiele przeskoków proxy lub używa prefiksu ścieżki URL.

Przed wprowadzeniem zmian zweryfikuj konfigurację za pomocą nginx -t, a następnie przeładuj Nginx, używając metody odpowiedniej dla hosta lub kontenera. Nie restartuj wszystkich usług naraz; kontrolowane przeładowanie ułatwia sprawdzenie, czy poprawka wprowadzona przez serwer źródłowy zmieniła wynik.

A co jeśli ONLYOFFICE nadal zwraca kod 502?

Jeśli zewnętrzny serwer proxy może dotrzeć do strony powitalnej Serwera Dokumentów, ale /healthcheckzwraca błąd 502, problem może występować wewnątrz Serwera Dokumentów, a nie w publicznym serwerze Nginx. Sprawdź logi kontenera Serwera Dokumentów i wewnętrzne logi usług. W przypadku natywnych instalacji Linuksa zapoznaj się z poleceniami statusu usługi i katalogiem logów powyżej. Jeśli /welcome/odpowiedź jest prawidłowa, ale kontrola poprawności nie, potraktuj to jako oddzielne sygnały: statyczna strona powitalna nie dowodzi, że usługa dokumentów i jej zależności są prawidłowe.

Nie „naprawiaj” tego, wyłączając JWT. Walidacja JSON Web Token (JWT) uwierzytelnia żądania integracji; niezgodność JWT zazwyczaj powoduje błąd autoryzacji, a nie brak możliwości połączenia z nadrzędnym serwerem na poziomie sieci. Sprawdź ustawienia JWT tylko wtedy, gdy serwer proxy odpowiada, ale integracja zgłasza błąd autoryzacji lub tokena.

Na koniec sprawdź, czy Nginx kieruje poprawną nazwę hosta do właściwego hosta wirtualnego. Literówka w server_namenazwie DNS lub porcie może skierować ruch w inne miejsce lub spowodować, że serwer proxy będzie korzystał z nieaktualnej konfiguracji. Sprawdź dziennik błędów Nginx pod kątem wierszy takich jak host not found in upstream, connect() failedlub upstream timed out; każdy z nich wskazuje na inną warstwę.

Jak weryfikujesz poprawkę?

Ponownie przetestuj transmisję w górę rzeki z sieci proxy, a następnie sprawdź punkt końcowy zdrowia publicznego i otwórz dokument za pośrednictwem połączonej platformy:

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

Pomyślna odpowiedź na kontrolę stanu nie powinna już oznaczać błędu 502, a dokument powinien zostać otwarty i pozostać połączony podczas edycji. Jeśli test upstream zakończy się powodzeniem, ale żądanie publiczne nadal nie zostanie zrealizowane, skoncentruj się na wybranym hoście wirtualnym Nginx, jego załadowanej konfiguracji i logach. Jeśli publiczna strona powitalna działa, ale kontrola stanu nadal wyświetla błąd 502, kontynuuj wewnętrzną diagnostykę usług ONLYOFFICE.

Informacje na temat działania dyrektywy Nginx można znaleźć w oficjalnej dokumentacji modułu proxy Nginx . Dokładne nazwy poleceń i usług mogą się różnić w zależności od projektu Docker Compose, dystrybucji Linuksa i wersji ONLYOFFICE, dlatego należy zastąpić je rzeczywistymi nazwami i sprawdzić logi komponentu, który wygenerował odpowiedź.