Analyse von Nginx-Fehlerprotokollen zur Fehlerbehebung bei Verbindungsverweigerungen

Die Analyse von Nginx-Fehlerprotokollen zur Fehlerbehebung bei Verbindungsverweigerungen hilft Ihnen, von einer generischen 502-Seite zu einem spezifischen Backend-Fehler zu gelangen. Der Ausdruck „Verbindung verweigert“ bedeutet normalerweise, dass Nginx versucht hat, eine Verbindung zu einer Upstream-Adresse herzustellen, aber kein Prozess die Verbindung angenommen hat.

Dies unterscheidet sich von einem Timeout, DNS-Fehler oder einer fehlerhaften Antwort. Sobald Sie das Protokollmuster erkennen, können Sie die Behebung schnell eingrenzen.

Was „Verbindung verweigert“ bedeutet

In Nginx-Protokollen sieht eine häufige Meldung wie folgt aus:

connect() failed (111: Connection refused) while connecting to upstream

Dies bedeutet, dass das Betriebssystem den Verbindungsversuch abgelehnt hat. Nginx hat das Ziel erreicht, aber auf dem Zielport hat nichts zugehört, oder die Verbindung wurde aktiv verweigert.

Sie könnten dies sehen, wenn Nginx an folgende Adresse weiterleitet:

proxy_pass http://127.0.0.1:3000;

aber die Anwendung gestoppt ist oder auf einem anderen Port lauscht.

Dieser Fehler tritt häufig nach Bereitstellungen auf. Ein Prozessmanager kann die App möglicherweise nicht neu starten, ein Container kann abstürzen, oder eine neue Konfiguration kann den App-Port ändern, ohne Nginx zu aktualisieren.

Behandeln Sie nicht jeden 502 als Verbindungsverweigerung. Eine Timeout-Meldung weist in eine andere Richtung. Eine Berechtigungsverweigerungsmeldung weist oft auf Sockets oder Sicherheitsrichtlinien hin. Der genaue Protokolltext ist wichtig.

Das richtige Nginx-Fehlerprotokoll finden

Der Standardpfad für Fehlerprotokolle ist oft:

/var/log/nginx/error.log

Aber Serverblöcke können benutzerdefinierte Protokolle definieren:

error_log /var/log/nginx/app-error.log warn;

Überprüfen Sie die relevante Nginx-Konfiguration, wenn das Standardprotokoll keine aktuellen Einträge anzeigt. Auf einigen Systemen erscheinen dienstbezogene Meldungen auch im Systemjournal.

Nützliche Befehle sind:

tail -n 100 /var/log/nginx/error.log

und:

journalctl -u nginx -n 100

Lösen Sie beim Testen eine Anfrage im Browser oder mit curl aus und überprüfen Sie dann sofort die neuesten Protokollzeilen. Das macht es viel einfacher, den benutzerseitigen Fehler mit dem Backend-Fehler zu verbinden.

Eine gute Protokollüberprüfung erfasst vier Informationen:

• Den Zeitstempel der fehlgeschlagenen Anfrage.
• Die Upstream-Adresse und den Port.
• Den Anforderungspfad.
• Den genauen Systemfehler, wie z. B. 111: Connection refused.

Für eine breitere Nginx-Fehlerbehebung siehe Behebung von Nginx 502 Bad Gateway-Fehlern.

Zuordnen des Protokolleintrags zum Upstream

Eine typische Protokollzeile kann einen Upstream-Wert wie enthalten:

upstream: "http://127.0.0.1:3000/api/status"

Das sagt Ihnen genau, wohin Nginx die Anfrage senden wollte. Überprüfen Sie nun, ob dort etwas lauscht:

ss -ltnp

Suchen Sie nach 127.0.0.1:3000, 0.0.0.0:3000 oder der erwarteten Adresse. Wenn der Port fehlt, lauscht die App nicht dort, wo Nginx sie erwartet.

Testen Sie den Upstream direkt:

curl -i http://127.0.0.1:3000/api/status

Wenn dies mit Verbindungsverweigerung fehlschlägt, haben Sie das Problem ohne Nginx dazwischen bestätigt.

Wenn die App in Docker läuft, seien Sie vorsichtig mit 127.0.0.1. Vom Host aus bedeutet es den Host. Von innerhalb eines Nginx-Containers aus bedeutet es den Nginx-Container selbst. In einer Compose-Einrichtung muss Nginx normalerweise an einen Dienstnamen weiterleiten, wie z. B.:

proxy_pass http://app:3000;

vorausgesetzt, beide Container teilen sich dasselbe Docker-Netzwerk.

Bei Unix-Sockets kann das Protokoll auf einen Pfad anstelle eines Ports verweisen:

upstream: "http://unix:/run/app/app.sock:/"

Überprüfen Sie in diesem Fall, ob der Socket existiert und ob der Nginx-Worker-Benutzer darauf zugreifen kann.

Häufige Ursachen und Lösungen

Die häufigste Ursache ist ein gestoppter Backend-Dienst. Überprüfen Sie ihn mit:

systemctl status your-app

Wenn er fehlgeschlagen ist, lesen Sie die App-Protokolle, bevor Sie neu starten. Ein Neustart kann die Seite wiederherstellen, aber die Protokolle erklären, warum sie fehlgeschlagen ist.

Eine weitere häufige Ursache ist ein Port-Konflikt. Zum Beispiel hat die App von Port 3000 auf 8080 gewechselt, aber Nginx leitet immer noch an 3000 weiter. Korrigieren Sie das Nginx-Upstream-Ziel oder stellen Sie den erwarteten Port der App wieder her.

Eine dritte Ursache ist die Bindung an die falsche Schnittstelle. Eine App, die nur auf 127.0.0.1 lauscht, ist von einem lokalen Nginx auf demselben Host erreichbar. Aber wenn Nginx in einem anderen Container oder einem anderen Server läuft, ist sie über diese Loopback-Adresse nicht erreichbar. In solchen Konfigurationen muss die App möglicherweise an 0.0.0.0 im privaten Netzwerk binden.

Firewall-Regeln können Verbindungen ebenfalls ablehnen oder verweigern, insbesondere zwischen Servern. Wenn Nginx an einen anderen Host weiterleitet, bestätigen Sie, dass der Upstream-Port von der Nginx-Maschine aus geöffnet ist, nicht nur von Ihrem Laptop.

Schließlich kann der Zeitpunkt der Bereitstellung kurzzeitige Verbindungsverweigerungsfehler verursachen. Wenn Nginx Datenverkehr sendet, bevor der neue App-Prozess bereit ist, können Benutzer intermittierende 502-Fehler sehen. Ein Health Check, Readiness Probe oder eine Strategie für einen ordnungsgemäßen Neustart kann dies verhindern.

Ein praktischer Ablauf zur Fehlerbehebung

Verwenden Sie diese Reihenfolge, wenn das Protokoll eine Verbindungsverweigerung anzeigt:

1. Kopieren Sie den Upstream-Host und Port aus dem Nginx-Fehlerprotokoll.
2. Führen Sie curl zu diesem genauen Upstream vom Nginx-Server aus.
3. Führen Sie ss -ltnp aus, um zu bestätigen, dass ein Prozess lauscht.
4. Überprüfen Sie den Backend-Dienststatus und die Anwendungsprotokolle.
5. Vergleichen Sie den Nginx-proxy_pass-Wert mit der tatsächlichen Bindungsadresse der App.
6. Laden Sie Nginx erst neu, nachdem die Konfiguration korrekt ist und nginx -t bestanden wurde.

Dieser Ablauf verhindert einen häufigen Fehler: Nginx zu bearbeiten, wenn die App einfach ausgefallen ist. Er verhindert auch den gegenteiligen Fehler: die App wiederholt neu zu starten, wenn Nginx auf die falsche Stelle verweist.

Für grundlegende Befehle siehe Nginx-Protokollüberwachungsbefehle.

Wann Sie einen Fachmann hinzuziehen sollten

Holen Sie sich Hilfe, wenn Verbindungsverweigerungsfehler nur unter Last, über mehrere Upstreams hinweg oder während rollierender Bereitstellungen auftreten. Diese Fälle können Prozessüberwachung, Container-Netzwerke, Load-Balancer-Health-Checks oder Kapazitätsgrenzen betreffen.

Sie sollten auch eskalieren, wenn der Upstream ein Produktionszahlungs-, Authentifizierungs- oder kundenorientierter API-Dienst ist. Schnelle Wiederherstellung ist wichtig, aber die Aufbewahrung von Protokollen und das Verständnis des Fehlers sind ebenfalls wichtig.

Verbindungsverweigerung ist einer der klareren Nginx-Fehler, sobald Sie ihn sorgfältig lesen. Finden Sie den Upstream im Protokoll, testen Sie dieses Ziel direkt und beheben Sie den Dienst, Port, die Schnittstelle oder den Netzwerkpfad, der Nginx daran hindert, eine Verbindung herzustellen. Das Protokoll gibt Ihnen bereits den Ausgangspunkt.