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

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

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

Verständnis der TCP-Level-Mechanik

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

Diese Unterscheidung hat eine praktische Diagnoseimplikation: Wenn die Verbindung von einer Firewall stillschweigend verworfen würde, würde ERR_CONNECTION_TIMED_OUT angezeigt. Eine abgelehnte Verbindung bedeutet, dass etwas aktiv antwortet — was bedeutet, dass der Host auf Netzwerkebene erreichbar ist, aber der Dienst auf dem Zielport nicht verfügbar oder blockiert ist.

Häufige Ursachen auf Port-Ebene sind:

• Der Webserver-Prozess (Apache, Nginx, Node.js) ist abgestürzt oder wurde beendet
• Der Server lauscht auf einem nicht standardmäßigen Port und die URL gibt ihn nicht an
• Eine Host-basierte 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 hinterlässt den Proxy ohne Backend zum Weiterleiten

Grundursachen: Eine strukturierte Übersicht

Client-seitige Ursachen

Server-seitige Ursachen

Schritt-für-Schritt-Diagnose- und Reparaturanleitung

Schritt 1: Bestimmen Sie, ob das Problem global oder lokal ist

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

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

Wenn die Website von externen Knoten erreichbar ist, aber nicht von Ihrem Computer, ist das Problem lokal. Wenn sie global nicht erreichbar ist, liegt das Problem auf der Serverseite und liegt außerhalb Ihrer Kontrolle — kontaktieren Sie den Site-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 Upstream-Netzwerks. Wenn Sie eine VPS Hosting-Umgebung betreiben, überprüfen Sie zunächst die Prozessliste und die Firewall-Konfiguration Ihres Servers.

Schritt 2: Überprüfen Sie, 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 auch, dass Ihre Firewall eingehende Verbindungen nicht 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 auch, ob die Upstream-Firewall oder die Sicherheitsgruppenregeln Ihres Hosting-Providers den Port am Netzwerk-Perimeter blockieren — dies ist getrennt von der Firewall auf Betriebssystemebene.

Schritt 3: Starten Sie Ihren Router neu und leeren Sie den lokalen Netzwerkzustand

Bei clientseitigen Problemen löscht ein Router-Neustart NAT-Tabellen, DHCP-Leases und alle vorübergehenden Routing-Fehler. Trennen Sie den Router 30 Sekunden lang ab und verbinden Sie ihn dann wieder. Dies ist besonders wirksam, wenn der Fehler plötzlich ohne Konfigurationsänderungen auftrat.

Schritt 4: DNS-Cache leeren

Ein veralteter DNS-Cache-Eintrag, der auf eine alte oder außer Betrieb genommene IP-Adresse verweist, ist eine der häufigsten Ursachen für ERR_CONNECTION_REFUSED auf der Clientseite. Der Server unter der zwischengespeicherten IP führt möglicherweise die Zielwebsite nicht mehr aus.

• Unter Windows:

ipconfig /flushdns

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

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Unter Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Nach dem Leeren überprüfen Sie, in welche IP-Adresse 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 unterschiedlich sind, ist die DNS-Propagation möglicherweise noch nicht abgeschlossen.

Schritt 5: Browser-Cache und Cookies löschen

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

• Windows/Linux: Strg + Umschalt + Entf
• macOS: Cmd + Umschalt + Entf

Stellen Sie den Zeitbereich auf Gesamter Zeitraum ein, aktivieren Sie Bilder und Dateien im Cache und Cookies und andere Website-Daten, 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 schnelleren Test ohne Datenlöschung öffnen Sie ein Inkognito-Fenster (Strg + Umschalt + N). Wenn die Website im Inkognito-Modus geladen wird, aber nicht in einem normalen Fenster, ist eine zwischengespeicherte Ressource oder eine Browser-Erweiterung der Schuldige.

Schritt 6: Proxy-Einstellungen überprü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 „Proxy-Server verwenden”, falls dies ohne Ihr Wissen aktiviert ist. Alternativ führen Sie dies von einer erhöhten Eingabeaufforderung aus:

netsh winhttp reset proxy

• Auf macOS

Gehen Sie zu Systemeinstellungen > Netzwerk, wählen Sie Ihre aktive Schnittstelle aus, klicken Sie auf Details und dann auf die Registerkarte Proxys, und deaktivieren Sie alle aktiven Proxy-Protokolle.

Nach dem Deaktivieren des Proxy testen Sie die Website. Wenn sie geladen wird, war Ihre Proxy-Konfiguration die Ursache. Konfigurieren Sie sie entweder korrekt neu oder entfernen Sie sie vollständig.

Schritt 7: Ändern Sie Ihren DNS-Resolver

Der Standard-DNS-Resolver Ihres ISP kann falsche Ergebnisse zurückgeben, einen Ausfall erleben oder bestimmte Domains aktiv blockieren. Der Wechsel zu einem öffentlichen Resolver beseitigt diese Variable.

Empfohlene öffentliche DNS-Resolver:

• Unter Windows (über PowerShell):

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

• Auf macOS:

Gehen Sie zu Systemeinstellungen > Netzwerk > [Ihre Schnittstelle] > 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 Host-basierte Firewalls fangen HTTPS-Traffic durch einen lokalen Proxy ab und können RST-Pakete ausstellen, wenn ihre Inspektions-Engine fehlschlägt oder wenn die Zieldomain auf einer Blockliste 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 Testen wieder.

Schritt 9: Testen Sie mit einem anderen Browser und Netzwerk

Testen Sie die URL in Firefox, Edge oder Safari. Wenn sie in einem anderen Browser geladen wird, 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 es über Mobilfunkdaten geladen wird, ist Ihr ISP oder Ihr Home-Router die Problemquelle.

Schritt 10: Überprüfen Sie auf SSL/TLS-Konfigurationsprobleme (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 meldet, anstatt einen Zertifikatsfehler zu melden. Verwenden Sie Folgendes zum Testen von der Befehlszeile aus:

curl -vI https://yourdomain.com

Suchen Sie nach der TLS-Handshake-Phase in der ausführlichen Ausgabe. Ein Fehler hier deutet auf ein Zertifikat- oder Cipher-Suite-Problem hin. Sie können auch mit Folgendem testen:

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

Wenn Ihr SSL-Zertifikat abgelaufen oder falsch konfiguriert ist, behebt das Erneuern oder Ersetzen das Problem. Stellen Sie sicher, dass Ihre SSL-Zertifikate gültig, ordnungsgemäß verkettet und auf der richtigen Server-Schnittstelle installiert sind.

ERR_CONNECTION_REFUSED vs. Ähnliche Browser-Fehler

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

Erweiterte Randfälle und Fallstricke

1) IPv6 vs. IPv4 Auflösungskonflikte:

Wenn eine Domain zu einer IPv6-Adresse aufgelöst wird, aber Ihr Netzwerk IPv6 nicht ordnungsgemäß unterstützt, kann Chrome versuchen, eine IPv6-Verbindung herzustellen, die abgelehnt wird, und dann nicht schnell auf IPv4 zurückfallen. Das vorübergehende Deaktivieren von IPv6 auf dem Netzwerkadapter kann dies bestätigen. Unter Linux können Sie IPv4 mit curl -4 https://example.com erzwingen.

2) Cloudflare oder CDN-Caching veralteter Origin-Fehler:

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

3) Localhost-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 Port als erwartet gebunden ist. Führen Sie ss -tlnp | grep node (oder den relevanten Prozess) aus, um zu bestätigen, was tatsächlich abhört.

4) E-Mail-Server-Port-Konflikte:

Wenn Sie Email Hosting auf demselben Server wie Ihre Webanwendung ausführen, 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 gebunden werden kann.

5) Einschränkungen beim Shared Hosting:

In Shared Web Hosting Umgebungen kann eine Verbindungsverweigerung darauf hindeuten, dass der Server des Hosting-Providers überlastet ist, das Konto gesperrt wurde oder die DNS der Domain noch nicht auf die korrekte gemeinsame IP verweist. Überprüfen Sie Ihr Hosting-Kontrollpanel auf Kontostatus und DNS-Konfiguration.

Praktische Entscheidungsmatrix: Welche Lösung zuerst anwenden

Verwenden Sie diese Checkliste zur effizienten Triage:

• Fehler erscheint auf allen Websites gleichzeitig — Überprüfen Sie zuerst die Proxy-Einstellungen und VPN/Firewall-Konfiguration
• Fehler erscheint nur auf einer bestimmten Domain — Überprüfen Sie, ob die Website global nicht erreichbar ist; leeren Sie dann den DNS-Cache
• Fehler erscheint nur in Chrome, nicht in anderen Browsern — Löschen Sie den Chrome-Cache, deaktivieren Sie Erweiterungen oder erstellen Sie ein neues Chrome-Profil
• Fehler erscheint nur in Ihrem Netzwerk, nicht bei Mobilfunkdaten — Starten Sie den Router neu; überprüfen Sie DNS auf ISP-Ebene oder Firewall
• Fehler erscheint nach einer Serverkonfigurationsänderung — Überprüfen Sie den Status des Webserver-Prozesses, Port-Bindungen und Firewall-Regeln auf dem Server
• Fehler erscheint intermittierend unter Last — Untersuchen Sie Ressourcenerschöpfung (Dateideskriptoren, Speicher, Verbindungslimits) auf dem Server
• Fehler erscheint nur bei HTTPS, nicht bei HTTP — Untersuchen Sie die SSL-Zertifikatsgültigkeit und TLS-Konfiguration
• Fehler erschien nach Änderung der DNS-Einstellungen — Machen Sie DNS-Änderungen rückgängig und leeren Sie den Cache; überprüfen Sie, ob der neue Resolver erreichbar ist

Häufig gestellte Fragen

1) 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 ablehnt. ERR_CONNECTION_TIMED_OUT bedeutet, dass innerhalb des Timeout-Zeitraums keine Antwort empfangen wurde – die Pakete wurden stillschweigend verworfen. Eine abgelehnte Verbindung erscheint schneller und zeigt eine aktive Ablehnung an, während ein Timeout auf eine Routing- oder Firewall-DROP-Regel hindeutet.

2) Kann ERR_CONNECTION_REFUSED durch ein abgelaufenes SSL-Zertifikat verursacht werden?

Indirekt ja. In einigen Serverkonfigurationen 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 abhört, obwohl die zugrunde liegende Ursache ein Zertifikatsproblem ist.

3) 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 zeigen auf eine alte IP-Adresse, auf der kein Dienst läuft, oder die Website wurde heruntergefahren. Verwenden Sie curl -v https://thatdomain.com von einem anderen Netzwerk oder Server aus, um die Ursache zu isolieren.

4) Wie behebe ich ERR_CONNECTION_REFUSED auf localhost?

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

5) Behebt das Leeren des DNS-Speichers immer ERR_CONNECTION_REFUSED?

Nur wenn die Grundursache ein veralteter DNS-Cache-Eintrag ist, der auf eine IP-Adresse zeigt, auf der der Dienst nicht mehr läuft. Wenn der Server ausfällt, die Firewall die Verbindung blockiert oder der Proxy falsch konfiguriert ist, hat das Leeren des DNS-Speichers keine Auswirkung. 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.