ERR_CONNECTION_REFUSED: Was der Fehler bedeutet & wie du ihn behebst

Advertisement
Was ist ERR_CONNECTION_REFUSED?
ERR_CONNECTION_REFUSED ist ein Chrome-Fehler, der erscheint, wenn dein Browser den Server der Website erreicht, der Server die Verbindung aber aktiv verweigert. Auf Netzwerkebene hat dein Computer eine TCP-Verbindungsanfrage (SYN) an die IP-Adresse und den Port des Servers geschickt – und statt sie anzunehmen, hat der Server (oder eine Firewall davor) mit einem Reset-Paket (RST) geantwortet, das sinngemäß sagt: „Hier redet niemand mit dir.“
Das unterscheidet ERR_CONNECTION_REFUSED grundlegend von DNS-Fehlern wie DNS_PROBE_FINISHED_NXDOMAIN. Bei einem DNS-Fehler wurde der Domainname nie in eine IP-Adresse aufgelöst. Bei ERR_CONNECTION_REFUSED hat DNS einwandfrei funktioniert – dein Browser weiß genau, wo der Server steht – aber die Maschine unter dieser Adresse hat sich geweigert, die Tür zu öffnen.
Die Ablehnung bedeutet meist eines von drei Dingen: Auf dem Port lauscht kein Dienst (der Webserver ist down oder abgestürzt), eine Firewall weist Traffic auf diesem Port ab, oder dein Gerät verbindet sich mit einer völlig falschen IP-Adresse – zum Beispiel durch einen veralteten DNS-Cache oder einen defekten Proxy.
So sieht der Fehler in anderen Browsern aus
Jeder Browser meldet eine abgelehnte Verbindung anders, aber die zugrunde liegende TCP-Zurückweisung ist identisch.
| Browser | Fehlermeldung |
|---|---|
| Google Chrome | Die Website ist nicht erreichbar – [Seite] hat die Verbindung abgelehnt. ERR_CONNECTION_REFUSED |
| Microsoft Edge | Hmm… auf diese Seite kann nicht zugegriffen werden – [Seite] hat die Verbindung abgelehnt. |
| Mozilla Firefox | Fehler: Verbindung fehlgeschlagen – Firefox kann keine Verbindung zu dem Server aufbauen. |
| Safari | Safari kann keine Verbindung zum Server herstellen |
| Brave / Opera | Die Website ist nicht erreichbar – ERR_CONNECTION_REFUSED |
Chromium-basierte Browser (Chrome, Edge, Brave, Opera) zeigen alle den rohen Code ERR_CONNECTION_REFUSED an. Firefox und Safari formulieren es in Alltagssprache, aber die Ursache und die Lösungen sind exakt dieselben.
Häufige Ursachen für ERR_CONNECTION_REFUSED
Ungefähr in der Hälfte der Fälle liegt das Problem auf der Serverseite, in der anderen Hälfte funkt etwas auf deinem Gerät oder in deinem Netzwerk dazwischen. Hier sind die häufigsten Ursachen, von der häufigsten zur seltensten.
Der Server der Website ist down – Der Webdienst (nginx, Apache, Node.js) ist abgestürzt, startet gerade neu oder wurde gestoppt. Die Maschine ist online, aber auf Port 80/443 antwortet nichts.
Firewall blockiert den Port – Eine Firewall auf dem Server, in deinem Netzwerk oder auf deinem Gerät weist Verbindungen zu diesem Port ab.
Falsch konfigurierte Proxy-Einstellungen – Dein System leitet den Traffic über einen Proxy-Server, der offline oder unerreichbar ist. Das ist eine der häufigsten Ursachen auf Client-Seite.
Veralteter DNS-Cache – Die Seite ist auf einen neuen Server umgezogen, aber dein zwischengespeicherter DNS-Eintrag zeigt noch auf die alte IP-Adresse, wo nichts mehr lauscht.
VPN- oder Antivirus-Störung – Sicherheitssoftware fängt die Verbindung ab und lehnt sie ab, oder der VPN-Exit-Server erreicht die Seite nicht.
Browser-Erweiterungen – Werbeblocker, Datenschutz-Erweiterungen oder mit Malware infizierte Extensions können Verbindungen zu bestimmten Hosts blockieren.
Hosts-Datei-Override – Die Domain ist in deiner Hosts-Datei auf eine falsche IP gemappt (oft 127.0.0.1), sodass sich dein Browser mit deinem eigenen Rechner verbindet – der ablehnt.
Nichts lauscht auf localhost – Für Entwickler: Der lokale Dev-Server läuft nicht, ist abgestürzt oder an einen anderen Port gebunden als den, den du geöffnet hast.
Router-Problem – Ein Router oder Modem mit Aussetzern verstümmelt Verbindungen, bis er neu gestartet wird.
Lösung 1: Prüfe, ob die Seite für alle down ist
Bevor du etwas an deinem Gerät änderst, finde heraus, ob das Problem auf der Serverseite liegt – wenn die Seite für alle down ist, hilft keine lokale Lösung.
Der sauberste Test läuft über einen anderen Netzwerkpfad. Öffne die Seite auf deinem Smartphone über mobile Daten (WLAN aus). Schlägt sie auch dort fehl, lehnt der Server selbst die Verbindungen ab und du kannst nur warten, bis der Betreiber der Seite das Problem behebt.
Du kannst den Server auch direkt mit diesen DNS-Robot-Tools testen:
[Port-Checker](/port-checker) – Gib die Domain der Seite ein und teste Port 443 (HTTPS) und Port 80 (HTTP). Zeigen beide „geschlossen“, ist der Webserver für alle down oder per Firewall gesperrt, nicht nur für dich.
[Ping-Test](/ping) – Prüft, ob die Servermaschine überhaupt antwortet. Funktioniert Ping, aber die Ports sind zu, läuft die Maschine – nur der Webdienst ist tot.
[HTTP-Headers-Checker](/http-headers) – Sendet eine echte HTTP-Anfrage von den Servern von DNS Robot. Bekommt er eine Antwort, während dein Browser keine bekommt, liegt das Problem lokal an deinem Gerät oder Netzwerk.
Advertisement
Lösung 2: Starte Router und Gerät neu
Der Klassiker als erster Schritt – aus gutem Grund: Ein Neustart leert die Verbindungstabelle des Routers, den DNS-Cache und jeden fehlerhaften NAT-Zustand, der abgelehnte Verbindungen verursachen kann.
Trenne deinen Router (und das Modem, falls separat) vom Strom, warte 30 Sekunden, stecke ihn wieder ein und gib ihm 2–3 Minuten, um sich vollständig zu verbinden. Starte auch deinen Computer oder dein Smartphone neu, um dessen Netzwerk-Stack zurückzusetzen, und probiere die Seite dann erneut.
Lösung 3: Leere Browser-Cache und Cookies
Chrome kann einen defekten Redirect, einen alten HSTS-Eintrag oder Cookies zwischengespeichert haben, die dich zu einem toten Server lenken. Das Löschen erzwingt eine komplett frische Verbindung.
Öffne Chrome → klicke auf das Drei-Punkte-Menü → Browserdaten löschen
Zeitraum → wähle Gesamte Zeit
Setze Häkchen bei „Cookies und andere Websitedaten“ und „Bilder und Dateien im Cache“
Klicke auf Daten löschen, starte Chrome neu und probiere die Seite erneut
Lösung 4: Deaktiviere Proxy-Einstellungen
Ein falsch konfigurierter oder toter Proxy ist eine der häufigsten Ursachen für ERR_CONNECTION_REFUSED auf allen Websites gleichzeitig. Wenn dein System den Traffic über einen Proxy leitet, den es nicht mehr gibt – oft ein Überbleibsel eines alten VPN, einer Schul-/Firmenkonfiguration oder von Malware – wird jede Verbindung abgelehnt.
Windows: Öffne Einstellungen → Netzwerk & Internet → Proxy. Schalte unter „Manuelle Proxyeinrichtung“ „Proxyserver verwenden“ aus und deaktiviere auch „Einstellungen automatisch erkennen“, falls du keinen Firmen-Proxy nutzt.
macOS: Öffne Systemeinstellungen → Netzwerk → WLAN → Details → Proxies. Entferne die Häkchen bei allen Protokollen in der Liste (Web-Proxy HTTP, Sicherer Web-Proxy HTTPS, SOCKS-Proxy), sofern deine Organisation keinen verlangt, und klicke auf OK.
Chrome nutzt die Proxy-Einstellungen des Betriebssystems – starte den Browser nach der Änderung also neu und teste erneut.
Lösung 5: Leere deinen DNS-Cache
Ist die Website kürzlich auf einen neuen Server umgezogen, kann dein zwischengespeicherter DNS-Eintrag noch auf die alte IP-Adresse zeigen – wo nichts mehr lauscht, also wird die Verbindung abgelehnt. Das Leeren des Caches zwingt dein Gerät, die aktuelle Adresse nachzuschlagen.
# Windows (Command Prompt as Administrator)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cacheLeere nach dem Flush auch Chromes eigenen DNS-Cache unter chrome://net-internals/#dns und die Socket-Pools unter chrome://net-internals/#sockets – Chrome führt beide getrennt vom Betriebssystem. Die komplette Anleitung findest du in unserem Ratgeber So leerst du den DNS-Cache auf jedem Betriebssystem.
Auf welche IP die Domain aktuell auflöst, prüfst du mit dem DNS-Lookup von DNS Robot – zeigt nslookup in deinem Terminal eine andere IP als das globale Ergebnis, war dein Cache das Problem.
Advertisement
Lösung 6: Wechsle zu einem öffentlichen DNS-Server
Liefert der DNS-Server deines Internetanbieters veraltete Einträge, hilft das Leeren des Caches nicht – du holst dir nur dieselbe veraltete IP erneut. Der Wechsel zu einem schnellen öffentlichen Resolver bringt dir aktuelle Einträge und beschleunigt das Surfen oft insgesamt.
| Anbieter | Primärer DNS | Sekundärer DNS | Am besten für |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Geschwindigkeit und Datenschutz |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | Zuverlässigkeit |
| Quad9 | 9.9.9.9 | 149.112.112.112 | Malware-Blockierung |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | Inhaltsfilterung |
Windows: Einstellungen → Netzwerk & Internet → deine Verbindung → DNS-Serverzuweisung bearbeiten → Manuell → IPv4 einschalten → 1.1.1.1 und 1.0.0.1 eintragen → Speichern.
macOS: Systemeinstellungen → Netzwerk → WLAN → Details → DNS → 1.1.1.1 und 1.0.0.1 hinzufügen, alte Einträge entfernen → OK.
Nicht sicher, welcher Resolver an deinem Standort am schnellsten ist? Führe den DNS-Geschwindigkeitstest von DNS Robot aus – er benchmarkt Cloudflare, Google, Quad9 und weitere in Sekunden über deine eigene Verbindung.
Lösung 7: Deaktiviere vorübergehend VPN, Antivirus und Firewall
VPNs, Antivirus-Webschutz und Firewalls sitzen alle zwischen deinem Browser und dem Internet, und jede dieser Komponenten kann Verbindungen ablehnen. HTTPS-Scanning-Funktionen von Antivirenprogrammen sind ein häufiger Übeltäter: Sie leiten deinen verschlüsselten Traffic über einen lokalen Dienst, und wenn dieser Dienst kaputtgeht, wird jede HTTPS-Seite abgelehnt.
Teste in dieser Reihenfolge: Trenne das VPN und lade neu. Deaktiviere dann für eine Minute das Webschutz-Modul des Antivirus und lade neu. Schalte zuletzt kurz die Firewall aus (Windows Defender Firewall oder macOS-Firewall) und lade neu.
Lädt die Seite, nachdem du eine der Komponenten deaktiviert hast, aktiviere sie wieder und richte eine Ausnahme für die Seite ein – oder wechsle den VPN-Serverstandort – statt den Schutz auszulassen.
Lösung 8: Teste Erweiterungen im Inkognito-Modus
Werbeblocker, Datenschutz-Tools und VPN-Erweiterungen können Verbindungen zu bestimmten Hosts stillschweigend blockieren. Der schnelle Test: Öffne die Seite in einem Inkognito-Fenster (Strg+Umschalt+N / Cmd+Umschalt+N), in dem die meisten Erweiterungen standardmäßig deaktiviert sind.
Lädt die Seite im Inkognito-Modus, ist eine Erweiterung die Ursache. Gehe zu chrome://extensions, deaktiviere alle und aktiviere sie einzeln wieder, bis der Fehler zurückkehrt – das ist der Schuldige. Entferne ihn oder nimm die Seite aus seinen Filtern aus.
Lösung 9: Prüfe deine Hosts-Datei
Deine Hosts-Datei überschreibt DNS für bestimmte Domains. Ist die Seite dort auf 127.0.0.1, 0.0.0.0 oder eine alte Server-IP gemappt, verbindet sich dein Browser mit dieser Adresse – und wird abgelehnt. Übrig gebliebene Entwicklungs-Einträge und Adblock-Hosts-Listen sind die üblichen Verdächtigen.
# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts
# macOS / Linux:
sudo nano /etc/hosts
# Look for lines containing the domain, e.g.:
# 127.0.0.1 example.com ← forces the connection to your own PC
# 203.0.113.7 example.com ← forces an old server IP
# Delete the offending line, save, then flush DNS.Advertisement
Localhost lehnt die Verbindung ab (für Entwickler)
Localhost refused to connect oder ERR_CONNECTION_REFUSED auf 127.0.0.1 zu sehen, gehört für jeden Entwickler zum Initiationsritus. Es bedeutet: Auf deinem Rechner nimmt nichts Verbindungen auf dem angefragten Port an. Die üblichen Gründe:
Der Dev-Server läuft nicht – Du hast ihn nie gestartet, oder er ist abgestürzt. Prüfe das Terminal, in dem
npm run dev,rails soderpython manage.py runserverlaufen sollte.Falscher Port – Der Server ist auf einem anderen Port gestartet (z. B. 3001, weil 3000 belegt war) und du öffnest den alten. Lies die Startzeile im Log, die den gebundenen Port nennt.
An ein anderes Interface gebunden – Der Server ist an
0.0.0.0oder die interne IP eines Containers gebunden, du rufst aberlocalhostauf – oder umgekehrt. Docker-Port-Mappings (-p 3000:3000) müssen zu dem Port passen, auf dem die App im Container lauscht.Firewall oder Sicherheitssoftware – Lokale Firewalls können sogar Loopback-Ports blockieren; auf Firmenrechnern ist das verbreitet.
HTTPS statt HTTP – Du öffnest https://localhost:3000, aber der Dev-Server spricht nur reines HTTP. Probiere explizit http://.
# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000
# Windows (PowerShell):
netstat -ano | findstr :3000
# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.Wenn du prüfen musst, ob ein Port auf deinem öffentlichen Server aus dem Internet erreichbar ist (nicht nur von der Maschine selbst), nutze den Port-Checker von DNS Robot – er testet die Verbindung von außerhalb deines Netzwerks, also genau das, was deine Besucher tatsächlich erleben.
Für Website-Betreiber: Deine Seite lehnt Verbindungen ab
Melden Besucher ERR_CONNECTION_REFUSED auf deiner eigenen Website, ist der Server online (DNS löst auf, die Maschine antwortet wahrscheinlich auf Ping), aber der Webdienst nimmt keine Verbindungen an. Arbeite diese Checkliste durch:
Läuft der Webserver-Prozess? Verbinde dich per SSH und prüfe:
systemctl status nginx(oder apache2, caddy). Ein abgestürzter Prozess nach einem fehlgeschlagenen Reload oder ein Out-of-Memory-Kill ist Ursache Nummer 1. Neu starten:sudo systemctl restart nginx.Lauscht er auf den richtigen Ports? Führe
ss -tlnp | grep -E ':80|:443'aus. Lauscht nichts auf 443, wurde deine TLS-Konfiguration nicht geladen – prüfenginx -tauf Konfigurationsfehler.Ist die Firewall offen? Prüfe
ufw statusoder die Security Group deines Cloud-Anbieters. Die Ports 80 und 443 müssen eingehendes TCP von 0.0.0.0/0 erlauben.Hat sich deine Server-IP geändert? Vergleiche deinen DNS-A-Record mit der tatsächlichen IP des Servers per DNS-Lookup. Nach einer Migration schickt ein alter A-Record Besucher zur vorherigen Maschine.
Teste von außen – Nutze den Port-Checker für die Ports 80 und 443 und den HTTP-Headers-Checker, um zu bestätigen, dass dein Server echte Anfragen aus dem öffentlichen Internet beantwortet.
So überprüfst du, ob die Lösung funktioniert hat
Bestätige nach jeder Lösung die Verbindung auf Netzwerkebene, statt nur die Seite neu zu laden – so weißt du, ob sich der Port tatsächlich geöffnet hat.
# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected
# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed
# Then confirm what IP you're actually connecting to:
nslookup example.comOder überspring das Terminal: Gib Domain und Port in den Port-Checker von DNS Robot ein und erhalte sofort eine Offen/Geschlossen-Antwort aus einem externen Netzwerk. Ist der Port von außen offen, aber dein Browser zeigt weiterhin ERR_CONNECTION_REFUSED, sitzt der Blocker auf deinem Gerät – geh die Lösungen zu Proxy, VPN, Antivirus und Hosts-Datei oben noch einmal durch.
Ist der Port offen – oder lehnt der Server wirklich ab?
Der kostenlose Port-Checker von DNS Robot testet jede Domain und jeden Port in Sekunden aus einem externen Netzwerk. Sieh sofort, ob die Ports 80/443 einer Seite offen, geschlossen oder gefiltert sind – die definitive Antwort auf „Ist die Seite für alle down oder nur für mich?“
Testen Port CheckerAdvertisement
Häufig gestellte Fragen
Es bedeutet, dass dein Browser den Server der Website erreicht hat, der Server die TCP-Verbindung auf diesem Port aber aktiv abgelehnt hat. Die DNS-Auflösung hat funktioniert – der Browser kennt die IP des Servers – aber nichts hat die Verbindung angenommen: Der Webdienst ist down, eine Firewall hat sie abgewiesen, oder dein Gerät hat sich über einen veralteten Cache oder Proxy mit der falschen Adresse verbunden.