ERR_CONNECTION_REFUSED: Bedeutung und Lösung

2026-09-19

ERR_CONNECTION_REFUSED bedeutet, die Zielmaschine hat die TCP-Verbindung aktiv mit einem Reset-Paket abgelehnt, meist weil auf diesem Port nichts lauscht. Das Netzwerk hat einwandfrei funktioniert und eine Antwort geliefert, nur nicht die, die Ihr Browser wollte.

Was ERR_CONNECTION_REFUSED bedeutet

Eine TCP-Verbindung beginnt mit einem Handshake: Der Client sendet ein SYN-Paket, und der Server antwortet mit SYN-ACK, falls ein Prozess an diesen Port gebunden ist. Lauscht kein Prozess, sendet der Netzwerk-Stack des Betriebssystems stattdessen ein RST-Paket zurück und beendet den Versuch sofort. Dieses RST ist es, das in Chrome ERR_CONNECTION_REFUSED und in anderen Browsern das jeweilige Äquivalent erzeugt. Die Verbindung hat die Zielmaschine erreicht und ein klares Nein bekommen, was diesen Fehler von einer Zeitüberschreitung unterscheidet, bei der überhaupt nichts antwortet.

Die RST-Antwort kommt vom TCP-Stack des Kernels, nicht von irgendeinem Anwendungscode, weshalb sie innerhalb weniger Millisekunden ankommt statt nach mehreren Sekunden Warten. Das bedeutet auch, die Maschine selbst ist up und beantwortet Netzwerk-Traffic; an den konkreten Port, den die Anfrage angesteuert hat, ist einfach nichts gebunden. Diese Unterscheidung ist wichtig bei der Entscheidung, wo zuerst nachzusehen ist: Eine abgelehnte Verbindung deutet auf den Port und den Prozess dahinter hin, nicht auf die Stromversorgung des Servers oder seine Netzwerkanbindung.

Wie sich der Fehler zeigt

Chrome zeigt eine einfache Seite "This site can't be reached ... ERR_CONNECTION_REFUSED" ohne weitere Details. Firefox meldet "Unable to connect" und nennt den Host und Port, den es versucht hat. Die Kommandozeile liefert ein genaueres Bild:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused

Die Meldung nennt den genauen Port, den curl versucht hat, und meldet die Ablehnung innerhalb weniger Millisekunden, schnell genug, um eine Zeitüberschreitung auszuschließen. telnet host port oder nc -zv host port geben dieselbe Zeile "Connection refused" zurück.

Was ERR_CONNECTION_REFUSED verursacht

Auf dem Port lauscht nichts. Der Webserver, die Anwendung oder der Proxy, der an den Port gebunden sein sollte, läuft nicht.
Der Dienst hat gestoppt oder ist abgestürzt. Ein Prozess, der beendet wurde, wegen zu hohem Speicherverbrauch abgeschossen oder für Wartungsarbeiten gestoppt wurde, hinterlässt einen unbelegten Port.
Eine Firewall-Regel lehnt die Verbindung rundweg ab. Eine REJECT-Regel sendet dasselbe RST zurück, das ein geschlossener Port zurücksenden würde, von außen sieht das also identisch aus wie nichts Vorhandenes.
Der falsche Port steht in der URL. Ein Tippfehler, ein alter Favorit von vor einer Portänderung, oder ein Dienst, der auf einen anderen Port umgezogen ist, erzeugen alle diesen Fehler gegen den alten Port.
Ein lokaler Entwicklungsserver läuft nicht. Ein abgelehntes localhost:3000 bedeutet fast immer, dass der Dev-Server gestoppt wurde oder in dieser Terminal-Sitzung nie gestartet wurde.
Ein Proxy oder VPN ist falsch konfiguriert. Ein Proxy, der auf ein down gegangenes Backend zeigt, oder ein VPN-Client, der Anfragen auf einen Port umschreibt, den nichts bedient, lehnt die Verbindung in eigener Sache ab.
Das Port-Mapping eines Containers stimmt nicht mit der Anwendung darin überein. Ein Docker- oder Kubernetes-Dienst, dessen veröffentlichter Port vom Port abweicht, an den die Anwendung tatsächlich bindet, erzeugt diesen Fehler, obwohl der Prozess selbst läuft und gesund ist.

So finden Sie heraus, wer schuld ist

Lädt die Website gerade jetzt für andere Leute, oder lud sie vor einer Minute für Sie, liegt das Problem eher lokal: ein VPN, eine Proxy-Einstellung, oder eine Firewall-Regel auf Ihrer eigenen Maschine oder in Ihrem Netzwerk. Scheitert sie auf dieselbe Weise von einem Handy mit mobilen Daten, lehnt die Serverseite Verbindungen für alle ab. Eine HTTP- oder Port-Prüfung von mehreren Standorten gleichzeitig klärt das in einer Anfrage; melden Prüfpunkte in mehreren Ländern alle die abgelehnte Verbindung, liegt die Ursache am Server oder seiner Firewall, nicht an Ihrem Netzwerk.

So beheben Sie ERR_CONNECTION_REFUSED

Wenn Sie Besucher sind

Bestätigen Sie URL und Port. Prüfen Sie auf einen Tippfehler, einen alten Favoriten, oder einen Link, der noch auf einen außer Betrieb genommenen Port zeigt.
Deaktivieren Sie Ihr VPN oder Ihren Proxy und laden Sie neu. Lädt die Website danach, ist die VPN- oder Proxy-Konfiguration die Ursache; prüfen Sie deren Einstellungen oder kontaktieren Sie, wer sie verwaltet.
Probieren Sie ein anderes Netzwerk, etwa mobile Daten statt WLAN, um eine lokale Firewall- oder Router-Regel auszuschließen.
Warten Sie und versuchen Sie es erneut. Ist der Website-Betreiber gerade beim Deployen oder Neustarten eines Dienstes, ist der Port vielleicht nur für wenige Sekunden unbelegt.

Wenn Sie die Website betreiben

Bestätigen Sie, dass der Prozess läuft und an den erwarteten Port gebunden ist:
```
ss -ltnp | grep :443
netstat -tlnp | grep :443
```
Ein leeres Ergebnis bedeutet, es lauscht nichts; starten Sie den Dienst oder korrigieren Sie seinen konfigurierten Port.
Prüfen Sie den Dienststatus und die Logs:
```
systemctl status nginx
journalctl -u nginx -n 50
```
Eine abgestürzte oder fehlgeschlagene Unit taucht hier auf, oft mit dem Grund, warum sie beendet wurde.
Prüfen Sie die Firewall auf eine REJECT-Regel am Port:
```
iptables -L -n | grep REJECT
ufw status verbose
```
Eine REJECT-Regel sieht von außen identisch aus wie ein geschlossener Port, dieser Schritt wird also leicht übersehen.
Bestätigen Sie, dass der Dienst auf der richtigen Schnittstelle lauscht. Ein an 127.0.0.1 statt 0.0.0.0 gebundener Server lehnt jede Verbindung ab, die von außerhalb der Maschine kommt, obwohl er aus einer lokalen Shell einwandfrei funktioniert.
Starten Sie den Dienst neu, sobald die Konfiguration korrigiert ist, und bestätigen Sie mit demselben ss-Befehl, dass der Port wieder belegt ist, bevor Sie das Problem als gelöst betrachten.

So beugen Sie ERR_CONNECTION_REFUSED vor

Ein abgestürzter Dienst oder eine versehentliche Firewall-Regel zeigen sich meist zuerst als abgelehnte Verbindungen statt als Alarm vom Server selbst, da ein nicht laufender Prozess sein eigenes Versagen nicht melden kann. Regelmäßiges Port-Monitoring erkennt das innerhalb von Minuten, indem es sich genau wie ein Besucher von außerhalb des Netzwerks verbindet, und sendet einen Alarm per E-Mail, SMS, Sprachanruf, Slack, Telegram und weiteren Kanälen, sobald eine Prüfung scheitert.

Häufig gestellte Fragen

Ist ERR_CONNECTION_REFUSED dasselbe wie eine mich blockierende Firewall?

Kann sein. Eine Firewall-REJECT-Regel erzeugt dieselbe RST-Antwort wie ein geschlossener Port, die beiden sehen vom Browser aus also identisch aus. Eine DROP-Regel verhält sich anders und erzeugt stattdessen eine Zeitüberschreitung.

Warum passiert das nur auf localhost?

Fast immer, weil der lokale Dev-Server in diesem Terminal nicht läuft, gestoppt wurde, oder beim Start wegen eines Code- oder Konfigurationsfehlers abgestürzt ist. Prüfen Sie das Terminal, in dem Sie ihn normalerweise starten, auf eine Fehlermeldung.

Kann ein VPN ERR_CONNECTION_REFUSED verursachen?

Ja. Ein VPN, das Traffic über einen Proxy oder ein Gateway leitet, kann Verbindungen im Namen des Gateways ablehnen, falls dessen eigenes Backend down ist, obwohl der eigentliche Zielserver gesund ist.

Bedeutet ERR_CONNECTION_REFUSED, dass die Website für alle down ist?

Nicht zwingend. Testen Sie von einem zweiten Netzwerk aus oder führen Sie eine Prüfung von mehreren Standorten aus, bevor Sie das schließen. Eine einzelne falsch konfigurierte Firewall-Regel oder ein lokales VPN können denselben Fehler erzeugen, während die Website für alle anderen einwandfrei funktioniert.

Was ist der Unterschied zwischen abgelehnt und zurückgesetzt?

Abgelehnt bedeutet, der Verbindungsversuch kam nie zustande; das Ziel hat ihn sofort zurückgewiesen. Zurückgesetzt bedeutet, die Verbindung wurde aufgebaut und funktionierte, und wurde dann mitten im Verlauf abgebrochen, meist durch etwas weiter entlang des Pfads.

Wie finde ich heraus, welcher Prozess lauschen sollte?

Prüfen Sie die eigenen Start-Logs der Anwendung und deren Konfiguration auf den Port, an den sie binden soll. Läuft der Prozess, ist aber an einen anderen Port gebunden als den, den die URL verwendet, aktualisieren Sie entweder die URL oder die Konfiguration, damit beide übereinstimmen, und bestätigen Sie dann mit ss -ltnp, dass der Port jetzt wie erwartet belegt ist.