Traceer de upstream om de Nginx-fout 502 van ONLYOFFICE op te lossen.

Begin met het controleren van de verbinding tussen Nginx en ONLYOFFICE Docs en lees vervolgens het foutenlogboek dat overeenkomt met de 502-respons. Een 502 Bad Gateway betekent dat een gateway geen geldige respons van de upstream-server kon ontvangen; dit bewijst op zichzelf niet dat de openbare Nginx-configuratie de oorzaak is. In Docker is de gebruikelijke oplossing om Nginx naar de servicenaam van de Document Server te sturen op de interne poort 80 en ervoor te zorgen dat beide containers hetzelfde netwerk delen.

Wat moet je controleren voordat je Nginx gaat bewerken?

Een reverse proxy is een server die een clientverzoek accepteert en doorstuurt naar een andere server. In een gangbare implementatie handelt de publieke Nginx HTTPS af en stuurt verzoeken door naar ONLYOFFICE Docs via HTTP. ONLYOFFICE Docs draait intern ook een eigen Nginx-server, waardoor een 502-pagina kan worden gegenereerd door de externe proxy of door de Document Server-container zelf.

Identificeer eerst welke server het antwoord heeft verzonden. Vergelijk de serverheader en het tijdstempel van de pagina met het logboek van de externe proxy en de logboeken van de documentserver. Controleer bij een Docker-configuratie de containerstatus en recente opstartberichten.

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

Als de container opnieuw opstart of net is gestart, controleer dan het logbestand voordat u de proxy-instellingen wijzigt. ONLYOFFICE merkt op dat de eerste opstart een minuut of twee kan duren terwijl de database wordt geïnitialiseerd. Voor een native Linux-installatie kunt u de logbestanden controleren met ds-docservice; de logbestanden van de documentenserver bevinden zich onder .ds-convertersystemctl status/var/log/onlyoffice/documentserver/

Raadpleeg de bijbehorende officiële ONLYOFFICE Linux-instructies voor probleemoplossing als een service is gestopt.

Kan Nginx de documentserver stroomopwaarts bereiken?

Test vanuit de Nginx-container of -host, niet alleen vanaf je laptop. Containers op aparte Docker-netwerken kunnen elkaar niet vinden via de servicenaam, zelfs niet als beide actief zijn. Wanneer Nginx en ONLYOFFICE een door de gebruiker gedefinieerd Docker-netwerk delen, gebruik dan de Compose-servicenaam of een oplosbare containernaam en de luisterpoort van de container. De officiële Docker-installatiehandleiding geeft poort 80 aan als de standaard luisterpoort voor de Document Server; een gepubliceerde hostpoort zoals 8080:80 verandert de interne poort niet.

Voer vanuit de proxycontainer het volgende commando uit:

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

Vervang dit onlyoffice-documentserverdoor de daadwerkelijke naam van uw Compose-service. Als de aanvraag aangeeft "Could not resolve host", koppelt u beide containers aan hetzelfde Docker-netwerk of corrigeert u de upstream-naam. "Connection refused" betekent meestal dat de doelhost wel is opgelost, maar dat er geen verbindingen worden geaccepteerd op die poort, dat de container niet gereed is of dat de verkeerde poort is gebruikt. Als dit een native installatie betreft, test dan in plaats daarvan het lokale adres en de geconfigureerde poort, bijvoorbeeld curl -I http://127.0.0.1/.

De Docker-handleiding van ONLYOFFICE behandelt de standaardpoort, poorttoewijzingen, opstartvertraging en containerlogboeken: Docker-installatie en -verificatie .

Hoe corrigeer ik de Nginx-proxydoelgroep?

Zorg ervoor dat de HTTPS virtuele host voor de hostnaam ONLYOFFICE proxy_passverwijst naar de bereikbare upstream-server. Dit voorbeeld gaat uit van een gedeeld Docker-netwerk en de hierboven weergegeven servicenaam; pas deze aan uw implementatie aan:

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

Richt een proxy in een container niet op een specifiek adres, 127.0.0.1:8080tenzij de Document Server daadwerkelijk in dezelfde container luistert of het hostadres opzettelijk is geconfigureerd en bereikbaar is. Binnen een container 127.0.0.1betekent dit de container zelf. Vermijd ook het verzenden van HTTPS naar de upstream-server wanneer het eindpunt van de Document Server gewoon HTTP gebruikt.

Het doorgestuurde protocol en de host vertellen ONLYOFFICE welke openbare URL de client heeft gebruikt, en de upgrade-headers maken WebSocket-verbindingen mogelijk die worden gebruikt voor live-communicatie met de editor. ONLYOFFICE biedt bijgewerkte voorbeelden voor het uitvoeren van Docs achter een proxy , inclusief de Nginx HTTPS-naar-HTTP-configuratie . Vergelijk dit met dat volledige voorbeeld als uw omgeving meerdere proxy-hops heeft of een URL-padprefix gebruikt.

Voordat u wijzigingen toepast, valideert u de configuratie met ` nginx -tnginx reload` en herlaadt u Nginx vervolgens met de methode die geschikt is voor uw host of container. Herstart niet alle services tegelijk; een gecontroleerde herstart maakt het gemakkelijker om te zien of de upstream-fix het resultaat heeft veranderd.

Wat als ONLYOFFICE nog steeds een 502-foutmelding geeft?

Als de externe proxy de welkomstpagina van de Document Server kan bereiken, maar /healthcheckeen 502-fout retourneert, ligt het probleem mogelijk bij de Document Server zelf in plaats van bij de openbare Nginx-server. Controleer de containerlogboeken van de Document Server en de interne servicelogboeken. Voor native Linux-installaties kunt u de servicestatusopdrachten en de logmap hierboven raadplegen. Als de /welcome/server wel reageert, maar de health check niet, beschouw dit dan als afzonderlijke signalen: een statische welkomstpagina bewijst niet dat de documentservice en de bijbehorende afhankelijkheden gezond zijn.

Los dit probleem niet op door JWT uit te schakelen. JSON Web Token (JWT)-validatie authenticeert integratieverzoeken; een JWT-mismatch veroorzaakt meestal een autorisatiefout, geen netwerkprobleem waardoor er geen verbinding met de upstream-server kan worden gemaakt. Controleer de JWT-instellingen alleen als de proxy reageert, maar de integratie een autorisatie- of tokenfout meldt.

Controleer tot slot of Nginx de juiste hostnaam naar de juiste virtuele host routeert. Een typefout in server_namede upstream DNS-naam of poort kan verkeer naar een andere server sturen of ervoor zorgen dat de proxy een verouderde configuratie gebruikt. Controleer het Nginx-foutlogboek op regels zoals host not found in upstream, connect() failedof upstream timed out; elk verwijst naar een andere laag.

Hoe controleer je of de oplossing werkt?

Test de verbinding vanaf het proxynetwerk opnieuw, controleer vervolgens het eindpunt voor volksgezondheid en open een document via het verbonden platform:

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

Een succesvolle healthcheck zou geen 502-fout meer moeten geven en een daadwerkelijk document zou moeten openen en verbonden moeten blijven tijdens het bewerken. Als de upstream-test slaagt, maar het openbare verzoek nog steeds mislukt, concentreer u dan op de geselecteerde Nginx virtuele host, de geladen configuratie en de bijbehorende logbestanden. Als de openbare welkomstpagina werkt, maar de healthcheck een 502-fout blijft geven, ga dan verder met de interne servicediagnose van ONLYOFFICE.

Raadpleeg voor meer informatie over het gedrag van Nginx-richtlijnen de officiële documentatie van de Nginx-proxymodule . De exacte commando's en servicenamen kunnen variëren afhankelijk van het Docker Compose-project, de Linux-distributie en de ONLYOFFICE-versie. Vervang daarom de namen door uw eigen namen en controleer de logboeken van de component die het antwoord heeft gegenereerd.