ERR_CONNECTION_REFUSED: Was es bedeutet und wie man es vollständig behebt

Der ERR_CONNECTION_REFUSED-Fehler bedeutet, dass Ihr Browser eine Verbindungsanfrage an einen Webserver gesendet hat und dieser Server sie aktiv abgelehnt hat – nicht ignoriert, sondern explizit den TCP-Handshake verweigert hat. Dies ist ein grundlegend anderer Fehlertyp als ein Timeout (ERR_CONNECTION_TIMED_OUT) oder ein DNS-Fehler (ERR_NAME_NOT_RESOLVED), und dieser Unterschied ist bei der Diagnose der Grundursache von enormer Bedeutung.

In der Praxis bedeutet die Chrome-Meldung "Diese Website ist nicht erreichbar. ERR_CONNECTION_REFUSED" eines von drei Dingen: Der Zielserver lauscht nicht auf dem angeforderten Port, eine Firewall oder Sicherheitsschicht sendet ein TCP-RST-Paket (Reset) zurück an Ihren Client, oder Ihr lokaler Netzwerk-Stack ist falsch konfiguriert und leitet die Anfrage falsch weiter, bevor sie den Server überhaupt erreicht. Herauszufinden, welche dieser drei Kategorien auf Ihre Situation zutrifft, ist der schnellste Weg zur Lösung.

Die TCP-Mechanik verstehen

Die meisten Browser-Fehlerbehebungsanleitungen behandeln ERR_CONNECTION_REFUSED als vages „Netzwerkproblem”. Das ist es nicht. Auf der TCP-Ebene bedeutet eine verweigerte Verbindung, dass der Server (oder ein Vermittler) als Antwort auf das SYN-Paket Ihres Browsers ein RST/ACK-Paket zurückgesendet hat. Dies ist eine explizite Ablehnung, kein stilles Verwerfen.

Dieser Unterschied hat eine praktische diagnostische Bedeutung: Würde die Verbindung von einer Firewall still verworfen, würden Sie ERR_CONNECTION_TIMED_OUT sehen. Eine verweigerte Verbindung bedeutet, dass etwas aktiv antwortet – was bedeutet, dass der Host auf Netzwerkebene erreichbar ist, der Dienst auf dem Zielport jedoch nicht verfügbar oder blockiert ist.

Häufige Ursachen auf Port-Ebene sind:

• Der Webserver-Prozess (Apache, Nginx, Node.js) ist abgestürzt oder gestoppt
• Der Server lauscht auf einem nicht standardmäßigen Port und die URL gibt diesen nicht an
• Eine hostbasierte Firewall (iptables, ufw, Windows Defender Firewall) lehnt Verbindungen auf Port 80 oder 443 ab
• Ein Reverse-Proxy (HAProxy, Nginx, Cloudflare) ist falsch konfiguriert und sendet RST-Pakete upstream zurück
• Die Anwendung hinter dem Proxy ist abgestürzt und lässt den Proxy ohne Backend, an das weitergeleitet werden könnte

Grundursachen: Eine strukturierte Übersicht

Clientseitige Ursachen

Serverseitige Ursachen

Schritt-für-Schritt-Diagnose- und Fehlerbehebungsanleitung

Schritt 1: Feststellen, ob das Problem global oder lokal ist

Bevor Sie lokale Einstellungen ändern, stellen Sie fest, ob die Website für alle oder nur für Sie nicht erreichbar ist. Verwenden Sie diese Tools:

• downforeveryoneorjustme.com — einfache Verfügbarkeitsprüfung
• isitdownrightnow.com — enthält Antwortzeitverlauf
• ping.pe — pingt das Ziel gleichzeitig von mehreren globalen Standorten aus

Wenn die Website von externen Knoten aus erreichbar ist, aber nicht von Ihrem Rechner, liegt das Problem lokal. Wenn sie global nicht erreichbar ist, liegt das Problem serverseitig und außerhalb Ihrer Kontrolle – wenden Sie sich an den Website-Administrator oder warten Sie.

Für Server-Administratoren, die ihre eigene Infrastruktur verwalten, erfordert eine global nicht erreichbare Website eine sofortige Untersuchung des Webserver-Prozesses, der Firewall-Regeln und des vorgelagerten Netzwerks. Wenn Sie eine VPS Hosting-Umgebung betreiben, überprüfen Sie zuerst die Prozessliste und die Firewall-Konfiguration Ihres Servers.

Schritt 2: Überprüfen, ob der Server tatsächlich lauscht (für Server-Administratoren)

Wenn Sie den betreffenden Server verwalten, melden Sie sich per SSH an und führen Sie Folgendes aus, um zu bestätigen, was auf welchen Ports lauscht:

sudo ss -tlnp | grep -E ':80|:443'

Wenn die Ausgabe für Port 80 oder 443 leer ist, läuft Ihr Webserver-Prozess nicht. Starten Sie ihn neu:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Überprüfen Sie außerdem, ob Ihre Firewall eingehende Verbindungen blockiert:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Wenn Port 443 blockiert ist, erlauben Sie ihn:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Für Administratoren, die Dedicated Servers betreiben, überprüfen Sie außerdem, ob die vorgelagerte Firewall oder die Sicherheitsgruppenregeln Ihres Hosting-Anbieters den Port am Netzwerkperimeter blockieren – dies ist von der Firewall auf Betriebssystemebene getrennt.

Schritt 3: Router neu starten und lokalen Netzwerkzustand zurücksetzen

Bei clientseitigen Problemen löscht ein Router-Neustart NAT-Tabellen, DHCP-Leases und vorübergehende Routing-Fehler. Trennen Sie den Router 30 Sekunden lang vom Strom und schließen Sie ihn dann wieder an. Dies ist besonders wirksam, wenn der Fehler plötzlich ohne Konfigurationsänderungen aufgetreten ist.

Schritt 4: DNS-Cache leeren

Ein veralteter DNS-Cache-Eintrag, der auf eine alte oder stillgelegte IP-Adresse verweist, ist eine der häufigsten Ursachen für ERR_CONNECTION_REFUSED auf der Clientseite. Der Server unter der gecachten IP betreibt die Zielwebsite möglicherweise nicht mehr.

Unter Windows:

ipconfig /flushdns

Unter macOS (Ventura, Sonoma und die meisten modernen Versionen):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Unter Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Überprüfen Sie nach dem Leeren, zu welcher IP die Domain jetzt aufgelöst wird:

nslookup example.com
# or
dig +short example.com

Vergleichen Sie dies mit der bekannten IP der Website. Wenn sie abweichen, ist die DNS-Propagierung möglicherweise noch im Gange.

Schritt 5: Browser-Cache und Cookies löschen

Navigieren Sie in Google Chrome zu chrome://settings/clearBrowserData oder verwenden Sie die Tastenkombination:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Setzen Sie den Zeitraum auf Gesamte Zeit, aktivieren Sie Bilder und andere Dateien im Cache und Cookies und andere Websitedaten, und klicken Sie dann auf Daten löschen. Starten Sie Chrome vollständig neu (nicht nur den Tab), bevor Sie erneut testen.

Für einen schnellen Test ohne Datenlöschung öffnen Sie ein Inkognito-Fenster (Ctrl + Shift + N). Wenn die Website im Inkognito-Modus lädt, aber nicht in einem normalen Fenster, ist eine gecachte Ressource oder eine Browser-Erweiterung die Ursache.

Schritt 6: Proxy-Einstellungen prüfen und deaktivieren

Ein falsch konfigurierter oder nicht funktionierender Proxy-Server ist eine häufige Ursache für ERR_CONNECTION_REFUSED auf allen Websites gleichzeitig. Chrome verwendet standardmäßig die System-Proxy-Einstellungen.

Unter Windows:

Navigieren Sie zu Einstellungen > System > Proxy und deaktivieren Sie „Proxyserver verwenden”, wenn es ohne Ihr Wissen aktiviert ist. Alternativ führen Sie dies in einer erhöhten Eingabeaufforderung aus:

netsh winhttp reset proxy

Unter macOS:

Gehen Sie zu Systemeinstellungen > Netzwerk, wählen Sie Ihr aktives Interface, klicken Sie auf Details, dann auf den Tab Proxys, und deaktivieren Sie alle aktiven Proxy-Protokolle.

Testen Sie die Website nach dem Deaktivieren des Proxys. Wenn sie lädt, war Ihre Proxy-Konfiguration die Ursache. Konfigurieren Sie sie entweder korrekt neu oder entfernen Sie sie vollständig.

Schritt 7: DNS-Resolver wechseln

Der Standard-DNS-Resolver Ihres ISP gibt möglicherweise falsche Ergebnisse zurück, hat einen Ausfall oder blockiert aktiv bestimmte Domains. Der Wechsel zu einem öffentlichen Resolver eliminiert diese Variable.

Empfohlene öffentliche DNS-Resolver:

Unter Windows (über PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

Unter macOS:

Gehen Sie zu Systemeinstellungen > Netzwerk > [Ihr Interface] > Details > DNS, entfernen Sie vorhandene Einträge und fügen Sie 1.1.1.1 und 1.0.0.1 hinzu.

Unter Linux (systemd-resolved):

Bearbeiten Sie /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Starten Sie dann den Resolver neu:

sudo systemctl restart systemd-resolved

Schritt 8: Firewall und Antivirus vorübergehend deaktivieren

Einige Antivirus-Produkte und hostbasierte Firewalls fangen HTTPS-Datenverkehr über einen lokalen Proxy ab und können RST-Pakete senden, wenn ihre Inspektions-Engine versagt oder wenn die Zieldomain auf einer Sperrliste steht. Das vorübergehende Deaktivieren (nur zu Diagnosezwecken) bestätigt, ob sie die Ursache sind.

Wenn das Deaktivieren der Sicherheitssoftware den Fehler behebt, fügen Sie eine spezifische Ausnahme für die Zieldomain hinzu, anstatt die Software deaktiviert zu lassen. Aktivieren Sie sie sofort nach dem Test wieder.

Schritt 9: Mit einem anderen Browser und Netzwerk testen

Testen Sie die URL in Firefox, Edge oder Safari. Wenn sie in einem anderen Browser lädt, ist das Problem Chrome-spezifisch – wahrscheinlich ein beschädigtes Profil, eine fehlerhafte Erweiterung oder eine Chrome-spezifische Proxy-Einstellung. Versuchen Sie, ein neues Chrome-Profil zu erstellen, um das Problem zu isolieren.

Wenn die Website in allen Browsern fehlschlägt, wechseln Sie zu einem mobilen Hotspot. Wenn sie über mobile Daten lädt, ist Ihr ISP oder Heimrouter die Ursache des Problems.

Schritt 10: SSL/TLS-Konfigurationsprobleme prüfen (Server-Administratoren)

Ein falsch konfiguriertes SSL-Zertifikat kann dazu führen, dass der Server abstürzt oder TLS-Verbindungen ablehnt, was Chrome in einigen Grenzfällen als ERR_CONNECTION_REFUSED statt als Zertifikatsfehler meldet. Verwenden Sie Folgendes zum Testen über die Befehlszeile:

curl -vI https://yourdomain.com

Achten Sie auf die TLS-Handshake-Phase in der ausführlichen Ausgabe. Ein Fehler hier weist auf ein Zertifikats- oder Cipher-Suite-Problem hin. Sie können auch testen mit:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Wenn Ihr SSL-Zertifikat abgelaufen oder falsch konfiguriert ist, behebt die Erneuerung oder der Austausch das Problem. Stellen Sie sicher, dass Ihre SSL Certificates gültig, ordnungsgemäß verkettet und auf dem richtigen Server-Interface installiert sind.

ERR_CONNECTION_REFUSED vs. ähnliche Browser-Fehler

Das Verständnis, wie sich dieser Fehler von verwandten Fehlern unterscheidet, verhindert Fehldiagnosen:

Erweiterte Grenzfälle und Fallstricke

IPv6- vs. IPv4-Auflösungskonflikte: Wenn eine Domain zu einer IPv6-Adresse aufgelöst wird, Ihr Netzwerk IPv6 jedoch nicht ordnungsgemäß unterstützt, versucht Chrome möglicherweise eine IPv6-Verbindung, die abgelehnt wird, und fällt dann nicht schnell genug auf IPv4 zurück. Das vorübergehende Deaktivieren von IPv6 am Netzwerkadapter kann dies bestätigen. Unter Linux können Sie IPv4 mit curl -4 https://example.com erzwingen.

Cloudflare oder CDN cacht veraltete Origin-Fehler: Wenn eine Website Cloudflare verwendet und der Origin-Server ausfällt, kann Cloudflare eine Zeit lang eine gecachte Version bereitstellen und dann 521-Fehler (Origin hat Verbindung abgelehnt) oder 522-Fehler zurückgeben, die Chrome je nach Proxy-Weiterleitung des Fehlers als ERR_CONNECTION_REFUSED anzeigen kann.

Lokale Entwicklungsumgebungen: Entwickler sehen häufig ERR_CONNECTION_REFUSED beim Zugriff auf localhost:3000 oder Ähnliches. Die Ursache ist fast immer, dass der Entwicklungsserver-Prozess nicht läuft, abgestürzt ist oder an 127.0.0.1 auf einem anderen als dem erwarteten Port gebunden ist. Führen Sie ss -tlnp | grep node (oder den relevanten Prozess) aus, um zu bestätigen, was tatsächlich lauscht.

E-Mail-Server-Port-Konflikte: Wenn Sie Email Hosting auf demselben Server wie Ihre Webanwendung betreiben, stellen Sie sicher, dass Port-Konflikte zwischen SMTP (25, 587), IMAP (993) und HTTP/HTTPS (80, 443) nicht dazu führen, dass der Webserver nicht binden kann.

Shared-Hosting-Einschränkungen: In Shared Web Hosting-Umgebungen kann eine Verbindungsverweigerung darauf hinweisen, dass der Server des Hosting-Anbieters überlastet ist, das Konto gesperrt wurde oder die DNS-Einträge der Domain noch nicht auf die korrekte gemeinsame IP verweisen. Überprüfen Sie Ihr Hosting-Kontrollpanel auf Kontostatus und DNS-Konfiguration.

Praktische Entscheidungsmatrix: Welche Lösung zuerst anwenden

Verwenden Sie diese Checkliste für eine effiziente Triage:

• Fehler erscheint auf allen Websites gleichzeitig — Zuerst Proxy-Einstellungen und VPN/Firewall-Konfiguration prüfen
• Fehler erscheint nur auf einer bestimmten Domain — Prüfen, ob die Website global nicht erreichbar ist; dann DNS-Cache leeren
• Fehler erscheint nur in Chrome, nicht in anderen Browsern — Chrome-Cache leeren, Erweiterungen deaktivieren oder ein neues Chrome-Profil erstellen
• Fehler erscheint nur in Ihrem Netzwerk, nicht über mobile Daten — Router neu starten; ISP-seitigen DNS oder Firewall prüfen
• Fehler erscheint nach einer Server-Konfigurationsänderung — Webserver-Prozessstatus, Port-Bindungen und Firewall-Regeln auf dem Server prüfen
• Fehler erscheint sporadisch unter Last — Ressourcenerschöpfung (Dateideskriptoren, Arbeitsspeicher, Verbindungslimits) auf dem Server untersuchen
• Fehler erscheint nur bei HTTPS, nicht bei HTTP — Gültigkeit des SSL-Zertifikats und TLS-Konfiguration untersuchen
• Fehler erschien nach Änderung der DNS-Einstellungen — DNS-Änderungen rückgängig machen und Cache leeren; überprüfen, ob der neue Resolver erreichbar ist

FAQ

Was ist der Unterschied zwischen ERR_CONNECTION_REFUSED und ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED bedeutet, dass der Server (oder eine Firewall) aktiv ein TCP-Reset-Paket gesendet hat und die Verbindung sofort abgelehnt hat. ERR_CONNECTION_TIMED_OUT bedeutet, dass innerhalb des Timeout-Zeitraums keine Antwort empfangen wurde – die Pakete wurden still verworfen. Eine verweigerte Verbindung erscheint schneller und weist auf eine aktive Ablehnung hin, während ein Timeout auf eine Routing- oder Firewall-DROP-Regel hindeutet.

Kann ERR_CONNECTION_REFUSED durch ein abgelaufenes SSL-Zertifikat verursacht werden?

Indirekt ja. In einigen Server-Konfigurationen führt ein abgelaufenes oder falsch konfiguriertes SSL-Zertifikat dazu, dass der Webserver-Prozess beim Start fehlschlägt oder beim Verarbeiten von TLS-Verbindungen abstürzt, was dazu führt, dass kein Listener auf Port 443 vorhanden ist. Chrome meldet dann ERR_CONNECTION_REFUSED, weil nichts lauscht, obwohl die eigentliche Ursache ein Zertifikatsproblem ist.

Warum erscheint ERR_CONNECTION_REFUSED nur auf einer bestimmten Website?

Wenn der Fehler auf eine einzelne Domain beschränkt ist, sind die wahrscheinlichsten Ursachen: Der Webdienst des Zielservers ist abgestürzt, die Firewall des Servers blockiert Ihren IP-Bereich, die DNS-Einträge der Domain verweisen auf eine alte IP-Adresse, unter der kein Dienst läuft, oder die Website wurde abgeschaltet. Verwenden Sie curl -v https://thatdomain.com von einem anderen Netzwerk oder Server, um die Ursache zu isolieren.

Wie behebe ich ERR_CONNECTION_REFUSED auf localhost?

Der Anwendungsserver läuft nicht oder ist an einen anderen Port als den angeforderten gebunden. Bestätigen Sie, was lauscht, mit ss -tlnp unter Linux/macOS oder netstat -ano | findstr :PORT unter Windows. Starten Sie den Anwendungsserver-Prozess und stellen Sie sicher, dass er an 0.0.0.0 oder 127.0.0.1 auf dem erwarteten Port gebunden ist.

Behebt das Leeren des DNS-Caches immer ERR_CONNECTION_REFUSED?

Nur wenn die Grundursache ein veralteter DNS-Cache-Eintrag ist, der auf eine IP-Adresse verweist, unter der der Dienst nicht mehr läuft. Wenn der Server ausgefallen ist, die Firewall die Verbindung blockiert oder der Proxy falsch konfiguriert ist, hat das Leeren des DNS-Caches keine Wirkung. Verwenden Sie dig oder nslookup, um die DNS-Auflösung vor und nach dem Leeren zu überprüfen und zu bestätigen, ob DNS tatsächlich das Problem war.