ERR_CONNECTION_REFUSED

Was dieser Fehler bedeutet und wie du ihn erkennst

• Chrome, Edge oder ein anderer Chromium-basierter Browser zeigt „Diese Website ist nicht erreichbar – ERR_CONNECTION_REFUSED“ an.
• Der Fehler erscheint schnell und nicht erst nach einer langen Wartezeit. Eine lange Verzögerung deutet eher auf einen Timeout wie ERR_CONNECTION_TIMED_OUT hin.
• Eine zuvor funktionierende Website fällt nach einem Serverneustart, Deployment, einer DNS-Änderung, Konfigurationsänderung oder Firewall-Änderung aus.
• SSH oder ein anderer Anwendungsport auf demselben Rechner kann weiterhin erreichbar sein, während der Webport Verbindungen ablehnt.
• Auf dem Server ausgeführte Anfragen können erfolgreich sein, während Anfragen von außerhalb fehlschlagen, wenn der Dienst nur auf localhost lauscht oder eine externe Firewall den Port blockiert.

Hauptursachen nach Wahrscheinlichkeit

1. Der Webserver oder Anwendungsprozess ist angehalten — Nginx, Apache oder der Anwendungsserver ist möglicherweise abgestürzt, wurde angehalten oder konnte beim Start nicht erfolgreich geladen werden.
2. Auf dem angeforderten Port lauscht nichts — der Dienst verwendet möglicherweise einen anderen Port, während die Anfrage an Port 80 oder 443 gesendet wird.
3. Der Dienst ist an das falsche Interface gebunden — ein Listener auf 127.0.0.1 akzeptiert lokale Anfragen, aber keine direkten externen Verbindungen.
4. Eine Host- oder Cloud-Firewall weist den Datenverkehr ab — eine Firewall des Betriebssystems, eine Security Group, eine Network ACL oder eine Provider-Firewall kann geändert worden sein.
5. DNS verweist auf das falsche Ziel — die Domain kann zu einem alten, neu erstellten oder anderweitig nicht konfigurierten Server aufgelöst werden. Ein AAAA-Record kann außerdem einige Besucher an eine IPv6-Adresse weiterleiten, auf der kein funktionierender Weblistener vorhanden ist.

So behebst du den Fehler

1. Zieladresse bestätigen

Prüfen Sie die A- und AAAA-Records der Domain und vergleichen Sie die aufgelösten Adressen mit dem Server, der die Anfrage empfangen soll. Wenn die Domain auf einen alten, außer Betrieb genommenen oder neu erstellten Server zeigt, korrigieren Sie DNS, bevor Sie die Konfiguration des Webdienstes ändern. Wenn sowohl IPv4- als auch IPv6-Records vorhanden sind, stellen Sie sicher, dass Dienst und Firewall beide Pfade unterstützen.

2. Prüfen, ob der Dienst läuft

Prüfen Sie den relevanten Dienst über eine autorisierte Administrationsmethode wie SSH. Untersuchen Sie Nginx beispielsweise mit systemctl status nginx; verwenden Sie für Apache oder den Anwendungsserver den entsprechenden Dienstnamen.

Wenn der Dienst angehalten wurde oder fehlgeschlagen ist, prüfen Sie Status und Logs, bevor Sie ihn starten. Ein durch eine kürzlich vorgenommene Änderung eingeführter Konfigurationsfehler ist eine häufige Ursache für fehlgeschlagene Starts. Validieren Sie die Konfiguration mit nginx -t für Nginx oder apachectl configtest für Apache. Erst wenn der Test erfolgreich ist und Sie zur Änderung des Dienstes berechtigt sind, sollten Sie ihn neu starten oder neu laden. Ein Neustart kann aktive Anfragen unterbrechen und während eines Produktionshochs ungeeignet sein.

3. Lauschenden Port und Interface überprüfen

Untersuchen Sie die Listener auf dem Server mit ss -tlnp oder dem entsprechenden Befehl der Plattform. Stellen Sie sicher, dass der erwartete Prozess auf dem angeforderten Port lauscht, üblicherweise auf :80 oder :443.

Prüfen Sie neben dem Port auch die Bind-Adresse:

• 0.0.0.0:80 oder 0.0.0.0:443 lauscht im Allgemeinen auf verfügbaren IPv4-Interfaces.
• Eine bestimmte Serveradresse zeigt an, dass der Dienst an dieses Interface gebunden ist.
• 127.0.0.1:80 oder 127.0.0.1:443 akzeptiert nur lokale Anfragen.

Wenn die Anwendung absichtlich nur auf localhost erreichbar sein soll, stellen Sie sicher, dass der öffentlich erreichbare Reverse Proxy läuft und Anfragen an sie weiterleitet. Andernfalls passen Sie die Dienstkonfiguration so an, dass sie während einer genehmigten Wartung oder eines genehmigten Deployments auf dem vorgesehenen Interface lauscht.

4. Host- und Cloud-Firewall-Regeln prüfen

Prüfen Sie die Server-Firewall mit ufw status, iptables -L oder dem entsprechenden Befehl des Betriebssystems. Untersuchen Sie anschließend die Cloud-Security-Group, Network ACL oder Provider-Firewall, die dem erwarteten Server zugeordnet ist.

Stellen Sie sicher, dass eingehender Datenverkehr auf dem erforderlichen Port aus den entsprechenden Quellen erlaubt ist. Eine öffentliche Website benötigt möglicherweise Internetzugriff, während ein interner Dienst einen engeren, genehmigten Bereich verwenden sollte. Prüfen Sie IPv4- und IPv6-Regeln getrennt, wenn beide Record-Typen veröffentlicht sind. Erweitern Sie den Zugriff nicht stärker als nötig und nehmen Sie Firewall-Änderungen nur mit entsprechender Berechtigung vor.

5. Lokal und extern testen

Testen Sie auf dem Server den lokalen Listener und den konfigurierten Hostnamen getrennt. Ein lokaler Erfolg bestätigt nur, dass auf dem Rechner etwas antwortet; er beweist nicht, dass externe Clients den Port erreichen können.

Führen Sie nach der Korrektur von DNS, Dienst, Binding oder Firewall eine ausführliche curl -v-Anfrage an den betroffenen Hostnamen aus einem anderen Netzwerk oder von einem externen Rechner aus. Vergewissern Sie sich, dass die Anfrage die erwartete Adresse und den erwarteten Port erreicht und die Ablehnung nicht mehr auftritt.

6. Kürzlich vorgenommene Änderungen vergleichen

Wenn der Fehler nach einem Deployment, Neustart, Server-Neuaufbau, DNS-Update oder einer Firewall-Änderung begann, vergleichen Sie die aktuelle Konfiguration mit der zuletzt funktionierenden Version. Achten Sie insbesondere auf einen geänderten Port, einen fehlgeschlagenen Dienststart, ein reines Localhost-Binding, eine dem falschen Server zugeordnete Regel oder eine unvollständige IPv6-Konfiguration.

Vorbeugung und Überprüfung der Lösung

• Verwenden Sie einen Service Manager oder Process Supervisor, damit sich der Webdienst nach einem unerwarteten Ausfall wiederherstellen kann.
• Machen Sie die Konfigurationsvalidierung, etwa mit nginx -t oder apachectl configtest, vor jedem Reload oder Neustart zu einem erforderlichen Deployment-Check.
• Dokumentieren Sie die vorgesehenen Ports, Bind-Adressen, Firewall-Regeln, Security Groups und DNS-Records als funktionierende Referenzkonfiguration.
• Überwachen Sie den Dienst von außerhalb des Servers, statt sich ausschließlich auf lokale Health Checks zu verlassen.
• Prüfen Sie IPv4- und IPv6-Listener sowie Firewall-Regeln immer dann, wenn eine Domain sowohl A- als auch AAAA-Records besitzt.
• Dokumentieren Sie Infrastrukturänderungen, damit sich eine neue Ablehnung einem Deployment, Neuaufbau, DNS-Update oder einer Firewall-Änderung zuordnen lässt.

Häufig gestellte Fragen