Urmăriți Upstream-ul pentru a șterge Nginx 502 al ONLYOFFICE

Începeți prin a verifica conexiunea dintre Nginx și ONLYOFFICE Docs, apoi citiți jurnalul de erori care corespunde răspunsului 502. Un Gateway Defect 502 înseamnă că un gateway nu a putut primi un răspuns valid de la serverul său din amonte; nu dovedește, în sine, că configurația publică Nginx este cauza. În Docker, soluția obișnuită este de a trimite Nginx către numele serviciului Document Server pe portul său intern 80 și de a vă asigura că ambele containere partajează o rețea.

Ce ar trebui să verifici înainte de a edita Nginx?

Un proxy invers este un server care acceptă o cerere a clientului și o redirecționează către un alt server. Într-o implementare obișnuită, Nginx public gestionează HTTPS și redirecționează cererile către ONLYOFFICE Docs prin HTTP. ONLYOFFICE Docs rulează, de asemenea, propriul Nginx intern, astfel încât o pagină 502 poate fi generată de proxy-ul extern sau de containerul Document Server în sine.

Mai întâi identificați serverul care a emis răspunsul. Comparați antetul și marcajul temporal al serverului paginii cu jurnalul proxy extern și jurnalele serverului de documente. Pentru o configurare Docker, verificați starea containerului și mesajele recente de pornire:

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

Dacă containerul repornește sau abia a pornit, verificați jurnalul înainte de a modifica setările proxy. ONLYOFFICE notează că prima pornire poate dura un minut sau două în timp ce baza de date se inițializează. Pentru o instalare nativă Linux, verificați ds-docserviceși ds-convertercu systemctl status; jurnalele Document Server se află sub /var/log/onlyoffice/documentserver/.

Folosește instrucțiunile oficiale de depanare ONLYOFFICE Linux corespunzătoare dacă un serviciu este oprit.

Poate Nginx să acceseze serverul de documente în amonte?

Testați din containerul sau gazda Nginx, nu doar de pe laptop. Containerele din rețele Docker separate nu se pot rezolva reciproc după numele serviciului, chiar și atunci când ambele rulează. Când Nginx și ONLYOFFICE partajează o rețea Docker definită de utilizator, utilizați numele serviciului Compose sau un nume de container rezolvabil și portul de ascultare al containerului. Ghidul oficial de instalare Docker identifică portul 80 ca ascultător implicit al serverului de documente; un port gazdă publicat, cum ar fi 8080:80, nu modifică portul intern.

Din containerul proxy, executați:

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

Înlocuiți onlyoffice-documentservercu numele real al serviciului Compose. Dacă solicitarea spune „Nu s-a putut rezolva gazda”, atașați ambele containere la aceeași rețea Docker sau corectați numele din amonte. „Conexiune refuzată” înseamnă de obicei că gazda țintă a fost rezolvată, dar nimic nu acceptă conexiuni pe acel port, containerul nu este gata sau a fost utilizat portul greșit. Dacă aceasta este o instalare nativă, testați în schimb adresa locală și portul configurat, de exemplu curl -I http://127.0.0.1/.

Ghidul Docker de la ONLYOFFICE acoperă portul implicit, mapările porturilor, întârzierea la pornire și jurnalele containerelor: instalarea și verificarea Docker .

Cum corectezi ținta proxy Nginx?

În gazda virtuală HTTPS pentru numele de gazdă ONLYOFFICE, indicați proxy_passcătre upstream-ul accesibil. Acest exemplu presupune o rețea Docker partajată și numele serviciului afișat mai sus; modificați-l pentru a se potrivi cu implementarea dvs.:

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

Nu direcționați un proxy containerizat către 127.0.0.1:8080serverul Document Server decât dacă acesta ascultă efectiv în același container sau dacă adresa gazdei este configurată intenționat și accesibilă. În interiorul unui container, 127.0.0.1înseamnă containerul respectiv. De asemenea, evitați trimiterea HTTPS către serverul din amonte atunci când endpoint-ul serverului Document Server este HTTP simplu.

Protocolul redirecționat și gazda indică ONLYOFFICE ce adresă URL publică a utilizat clientul, iar anteturile de actualizare permit conexiunile WebSocket utilizate pentru comunicarea live cu editorul. ONLYOFFICE oferă exemple întreținute pentru rularea Docs în spatele unui proxy , inclusiv configurația Nginx HTTPS-to-HTTP . Comparați cu exemplul complet dacă mediul dvs. are mai multe hopuri proxy sau utilizează un prefix de cale URL.

Înainte de a aplica modificările, validați configurația cu nginx -t, apoi reîncărcați Nginx folosind metoda corespunzătoare gazdei sau containerului dvs. Nu reporniți fiecare serviciu simultan; o reîncărcare controlată facilitează verificarea dacă corecția din amonte a modificat rezultatul.

Ce se întâmplă dacă ONLYOFFICE returnează în continuare un formular 502?

Dacă proxy-ul extern poate accesa pagina de bun venit a serverului Document, dar /healthcheckreturnează eroarea 502, problema poate fi în interiorul serverului Document, nu în Nginx-ul public. Verificați jurnalele containerului serverului Document și jurnalele de servicii interne. Pentru instalările native de Linux, examinați comenzile de stare a serviciului și directorul de jurnal de mai sus. Dacă /welcome/răspunde, dar verificarea stării de funcționare nu răspunde, tratați-le ca semnale separate: o pagină de bun venit statică nu dovedește că serviciul Document și dependențele sale sunt sănătoase.

Nu „remediați” acest lucru dezactivând JWT. Validarea JSON Web Token (JWT) autentifică cererile de integrare; o nepotrivire JWT provoacă de obicei o eroare de autorizare, nu o incapacitate la nivel de rețea de a se conecta la un upstream. Verificați setările JWT numai dacă proxy-ul răspunde, dar integrarea raportează o eroare de autorizare sau de token.

În cele din urmă, confirmați că Nginx direcționează numele de gazdă corect către gazda virtuală corectă. O greșeală de scriere în server_name, numele DNS upstream sau portul poate trimite trafic în altă parte sau poate părăsi proxy-ul folosind o configurație învechită. Verificați jurnalul de erori Nginx pentru linii precum host not found in upstream, connect() failed, sau upstream timed out; fiecare indică către un strat diferit.

Cum verifici remedierea?

Retestați amonte-ul din rețeaua proxy, apoi verificați endpoint-ul public health și deschideți un document prin platforma conectată:

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

Un răspuns la verificarea stării de funcționare reușită nu ar trebui să mai fie un 502, iar un document real ar trebui să se deschidă și să rămână conectat în timpul editării. Dacă testul din amonte reușește, dar solicitarea publică tot eșuează, concentrați-vă pe gazda virtuală Nginx selectată, configurația încărcată și jurnalele acesteia. Dacă pagina publică de bun venit funcționează, dar verificarea stării de funcționare rămâne 502, continuați cu diagnosticarea internă a serviciului ONLYOFFICE.

Pentru comportamentul directivei Nginx, consultați documentația oficială a modulului proxy Nginx . Comenzile și numele exacte ale serviciilor pot varia în funcție de proiectul Docker Compose, distribuția Linux și versiunea ONLYOFFICE, așadar înlocuiți-le cu numele reale și verificați jurnalele de la componenta care a generat răspunsul.