err_connection_refused: Bedeutung, Ursachen und Lösungen – der vollständige Praxisleitfaden

Der Browser zeigt dir „ERR_CONNECTION_REFUSED“ und nichts lädt? Dann wird die Verbindung zum Zielserver aktiv abgelehnt oder von etwas auf deinem Weg dorthin blockiert. In diesem Leitfaden findest du eine klare Einordnung des Fehlers, alle häufigen Ursachen und eine systematische Schritt-für-Schritt-Anleitung für Windows, macOS, Linux, Android und typische Entwickler-Setups. Ziel: schnelle, reproduzierbare Fehlerbehebung – ohne Rätselraten.

Was „ERR_CONNECTION_REFUSED“ technisch wirklich bedeutet

Im Kern sagt der Fehler aus: Dein Browser versucht, eine TCP-Verbindung zum Ziel (z. B. 203.0.113.10:443) aufzubauen. Der Aufbau wird jedoch aktiv abgewiesen (typisch: ein TCP RST) oder scheitert so, dass der Browser es als „abgelehnt“ klassifiziert. Das unterscheidet sich vom klassischen Timeout (keine Antwort) oder HTTP-Fehlern (z. B. 404/500), denn hier kommt der Verbindungsaufbau gar nicht erst bis zur HTTP-Ebene.

Typische Meldungen
„Diese Website ist nicht erreichbar – 127.0.0.1 hat die Verbindung abgelehnt – ERR_CONNECTION_REFUSED“

Wichtig: Der Fehler ist meist client- oder netzwerkseitig bedingt (Firewall, Proxy, DNS, Browser, Add-ons, lokale Hosts-Datei). In selteneren Fällen ist ein Server- oder Host-Problem die Ursache (Dienst/Port nicht erreichbar, Firewall am Ziel blockt). Plattformunabhängig können alle Betriebssysteme betroffen sein – Windows, macOS, Linux sowie Android/iOS (über Chrome oder andere Chromium-basierte Browser).

Hinweis für Technik-Nerds: In Chromes internen Fehlercodes wird dieser Fall der Kategorie „Connection refused“ zugeordnet (historisch auch als Fehlercode 102 geführt). In allen Fällen gilt: Der Handshake bricht ab, bevor HTTP überhaupt sprechen kann.

So sieht der Fehler je nach Browser aus

Browser	Anzeige	Typische Zusatzhinweise
Google Chrome / Chromium	`ERR_CONNECTION_REFUSED`	„Diese Website ist nicht erreichbar“; häufig mit 127.0.0.1 hat die Verbindung abgelehnt bei lokalen Zielen
Mozilla Firefox	„Der Server unter … lehnt die Verbindung ab“	Hinweise auf mögliche Ursachen (Firewall/Proxy)
Microsoft Edge	„Hmm… diese Seite ist nicht erreichbar“ + Verbindungsfehler	Edge basiert auf Chromium, Fehlerbild ähnlich Chrome
Safari (macOS/iOS)	„Safari kann keine Verbindung zum Server aufbauen.“	Kein expliziter Code, Ursache identisch
Android (Chrome)	`ERR_CONNECTION_REFUSED`	Wie Desktop-Chrome; zusätzlich Einfluss von System-Apps/VPNs

Häufige Ursachen im Überblick

Instabile oder blockierte Internetverbindung: WLAN-Fehler, Router hängt, ISP-Probleme.
Firewall/Antivirus blockiert: Filtert oder sperrt den Zielhost/Port, auch lokal.
Proxy-/VPN-Fehlkonfiguration: Offline, falsche Adresse/Port, blockiert vom Zielserver.
Browser-Cache/-Cookies korrupt: Veraltete Einträge führen zu inkonsistenten Anfragen.
DNS-Probleme: Fehlerhafte Auflösung, ausgelaufener DNS-Cache, defekter Resolver.
Browser-Erweiterungen: Adblocker, Datenschutz- oder Security-Add-ons greifen ein.
Hosts-Datei: Domain auf 0.0.0.0/127.0.0.1 gemappt → Loopback/Blockade.
Lokaler Dienst läuft nicht: Dev-Server (Node/Apache/Nginx/PHP-FPM) gestoppt oder falscher Port.
TCP/IP-Stack beschädigt: Notwendig: Winsock/Stack-Reset.
Betriebssystem-/Router-Firewall: Port blockiert (Egress/Ingress), auch auf localhost möglich.
WordPress/Anwendungsfälle: Indirekte Effekte (Server überlastet/gestoppt, PHP-Timeouts), oft gemischt mit 502/504 – bei Dienstabsturz kann aber „refused“ erscheinen.

Kurzer Schnellcheck (2–5 Minuten)

Andere Website testen: Lädt z. B. wikipedia.org? Wenn ja, ist die Zielseite/Route problematisch.
Im Inkognito-Modus öffnen: Add-ons und Cache ausgeschlossen – funktioniert es jetzt?
VPN/Proxy ausschalten: Direkt ohne Umweg testen.
Netzwerk wechseln: Hotspot/Mobilfunk probieren. Funktioniert es dort, liegt’s am ursprünglichen Netz/ISP.
Router neu starten: Strom raus, 30 Sekunden warten, wieder einstecken.

Systematische Fehlerbehebung – Schritt für Schritt

1) Prüfe, ob die Website wirklich down ist

Rufe 2–3 andere Domains auf. Wenn alle scheitern, liegt es an deinem Gerät/Netz.
Frage eine andere Person im anderen Netz. Wenn dort erreichbar, liegt’s am Weg von dir zum Ziel.
Entwickler: curl -I https://deinezielseite.tld testen. Bei sofortigem „Connection refused“ ist oft Port/Firewall das Problem.

2) Verbindung und Router prüfen

WLAN trennen/neu verbinden, ggf. Ethernet-Kabel prüfen.
Router/Modem neu starten: Netzteil ziehen, 30 Sekunden warten, wieder einstecken.
Wenn via Hotspot funktioniert: kontaktiere deinen ISP oder prüfe Router-Firewall/Kindersicherung.

3) Browser-Cache und Cookies leeren (Chrome)

Cache-/Cookie-Korrosion kann merkwürdige Fehlerbilder erzeugen.

Chrome öffnen → Einstellungen → Datenschutz und Sicherheit → Browserdaten löschen.
Zwischengespeicherte Bilder und Dateien + Cookies und andere Websitedaten wählen.
Zeitraum: „Gesamte Zeit“ → Daten löschen.

Tipp: Alternativ nur für die betroffene Domain löschen (Schloss-Icon in der Adressleiste → Website-Einstellungen → Daten löschen), um Logins auf anderen Seiten zu behalten.

4) Proxy-/VPN-Einstellungen prüfen

Proxies und VPNs sind häufige Auslöser – besonders, wenn der Zielserver sie blockiert.

Windows: Systemsteuerung → Internetoptionen → Reiter „Verbindungen“ → LAN-Einstellungen → Proxyserver für LAN verwenden deaktivieren.
Windows 10/11 (modern): Einstellungen → Netzwerk & Internet → Proxy → Manuelle Proxy-Einrichtung aus.
macOS: Systemeinstellungen → Netzwerk → Aktive Verbindung → „Details“/„Weitere Optionen“ → Proxys → alle deaktivieren.
Android (WLAN): WLAN-Langdruck → Netzwerk bearbeiten → Erweitert → Proxy „Keine“.
VPN-Client komplett beenden/abmelden. Danach neu testen.

Siehe auch 502 bad gateway nginx: Der komplette Leitfaden für Ursachen, Diagnose und Lösungen

5) Antivirus/Firewall testweise deaktivieren

Security-Suiten filtern Verbindungen. Deaktiviere sie kurz, um die Ursache einzugrenzen.

Windows Defender Firewall: Systemsteuerung → System und Sicherheit → Windows Defender Firewall → Windows Defender Firewall ein- oder ausschalten. Teste danach erneut.
Drittanbieter-Suiten: Aus Kontextmenü/Tray temporär deaktivieren (Zeitfenster kurz halten). Wenn der Aufruf dann funktioniert, richte Ausnahmen für Browser/Zieladresse/Port ein.
Linux (UFW): sudo ufw status prüfen, temporär: sudo ufw disable (nur zum Test!), danach wieder enable.

Wichtig: Lasse Sicherheitssoftware nicht dauerhaft deaktiviert. Ziel ist, die Ursache zu identifizieren und dann Regeln korrekt zu konfigurieren.

6) DNS-Cache leeren und DNS-Server wechseln

Falsche DNS-Einträge führen dich zur falschen IP – dort kann die Verbindung verweigert werden.

DNS-Cache leeren

Windows (CMD als Administrator): ipconfig /flushdns
macOS: sudo killall -HUP mDNSResponder (Passwort nötig)
Linux (systemd-resolved): sudo systemd-resolve --flush-caches
Chrome-Hostcache: In aktuellen Versionen: chrome://dns öffnen → Host cache löschen.

DNS-Server wechseln (z. B. testweise auf öffentliche Resolver):

Cloudflare: 1.1.1.1 und 1.0.0.1
Google: 8.8.8.8 und 8.8.4.4

Stelle sie auf Adapter-/WLAN-Ebene ein (Windows: Adaptereigenschaften → IPv4 → DNS manuell; macOS: Netzwerk → DNS). Danach Verbindung trennen/neu aufbauen.

7) Erweiterungen/Plugins prüfen

Deaktiviere Add-ons (Adblocker, Privacy, Security, Proxy-Manager) testweise:

Chrome → chrome://extensions → Schalter nacheinander aus.
Nach jedem Schritt Seite neu laden. Schuldige Erweiterung dann entfernen oder konfigurieren.
Inkognito-Modus (ohne Add-ons) ist ein schneller Gegencheck.

8) TCP/IP-Stack zurücksetzen (Windows)

Beschädigte Netzwerkstacks können hartnäckige Verbindungsfehler erzeugen. Führe in einer administrativen Eingabeaufforderung aus:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Starte Windows danach neu.

9) Hosts-Datei prüfen

Wenn eine Domain auf 0.0.0.0 oder 127.0.0.1 gemappt ist, führt der Aufruf zu einer lokalen Adresse – das Resultat ist oft „verweigert“.

Windows: C:\Windows\System32\drivers\etc\hosts
macOS/Linux: /etc/hosts

Suche nach der betroffenen Domain. Kommentiere verdächtige Zeilen testweise mit # aus, speichere und teste erneut.

10) Chrome-spezifisches Verhalten rund um localhost

Seit Chrome-Versionen der 40er-Ära werden .localhost-Namen als Loopback-Sonderfall behandelt und auf 127.0.0.1 (IPv4) bzw. ::1 (IPv6) abgebildet. Greifst du auf subdomain.localhost:3000 zu, aber auf dem Port lauscht kein Dienst, resultiert typischerweise ERR_CONNECTION_REFUSED. Entwickler empfinden das teils als „Blockade“ von localhost-Subdomains – faktisch scheitert der Handshake, wenn lokal nichts bereitsteht oder Sicherheitsregeln dazwischenfunken.

Merke: Sieh immer zuerst nach, ob dein lokaler Dienst auf dem erwarteten Port lauscht (siehe Entwickler-Abschnitt unten).

11) Betriebssystem- und Router-Firewalls/Kinderschutz

Viele Router (und Unternehmensgeräte) filtern Ports/Ziele. Prüfe:

Router-UI: Jugendschutz, Blocklisten, Portfilter.
Enterprise-Proxy/Firewall (z. B. Zscaler, FortiGate): Zustimmung/Anmeldung nötig?
Mobile Provider: Manchmal sind bestimmte Ports (z. B. 25 SMTP) gesperrt.

Diagnose-Tools für Fortgeschrittene

Port- und Dienstverfügbarkeit prüfen

Windows (PowerShell): Test-NetConnection deinedomain.tld -Port 443
Linux/macOS:
- nc -zv deinedomain.tld 443 (Netcat)
- curl -v https://deinedomain.tld (zeigt TLS-Handshakeschritt)
- traceroute/tracert zur Pfadanalyse

Achtung: ping sagt wenig über TCP-Ports aus; ICMP kann erlaubt, der Port 443 aber dennoch blockiert oder „refused“ sein.

Lokale Listener prüfen (wenn du selbst etwas betreibst)

Windows: netstat -ano | findstr LISTENING und Port/Prozess-ID prüfen
Linux: ss -lntp oder sudo lsof -i :3000
macOS: lsof -i :3000 (oder anderer Port)

Stimmt der Port? Lauscht der Dienst auf 127.0.0.1, ::1 oder 0.0.0.0? IPv4/IPv6-Mismatch ist ein Klassiker: Browser verbindet auf ::1, dein Dienst lauscht aber nur auf 127.0.0.1 – Ergebnis: ERR_CONNECTION_REFUSED.

Entwickler-Fokus: Lokale und serverseitige Spezialfälle

Lokalentwicklung (localhost, 127.0.0.1, ::1)

Dienst läuft nicht: Starte z. B. npm run dev, docker compose up, apachectl start, systemctl start nginx.
Falscher Port: App auf 3000, Browser auf 5173? Prüfe die Portangabe in der URL.
IPv4/IPv6: Teste explizit http://127.0.0.1:PORT und http://[::1]:PORT.
Port belegt: Ein anderes Programm blockiert den Port → Prozess finden (siehe oben) und beenden oder Port ändern.
Docker: Port-Mapping korrekt? ports: - "8080:80" richtig gesetzt, Container lauscht auf 0.0.0.0?
Lokale Firewall: Erlaube eingehende/ausgehende Verbindungen auf den Entwicklungsports.
Chrome-Hostcache: Bei häufigen Rebinds: chrome://dns → Host-Cache löschen.

Siehe auch err_ssl_version_or_cipher_mismatch: Ursachen, Diagnose und Lösungen für Admins und Nutzer

WordPress & PHP

Bei WordPress sieht man direkt eher HTTP-Fehler (500/502/504) als eine abgelehnte Verbindung. Indirekt kann „refused“ auftreten, wenn:

Webserver (Nginx/Apache) oder PHP-FPM abstürzen/gestoppt werden (z. B. Ressourcenlimit erreicht).
Firewall auf dem Server Ports schließt.
Ein Security-Plugin IPs blockt.
Reverse-Proxy (z. B. Cloudflare/NGINX) Backend nicht mehr erreichen kann → Frontend zeigt „refused“ bei Direktzugriff.

Lösungen: Server-Dienste prüfen (systemctl status nginx / apache2 / php-fpm), Error-Logs ansehen, Plugins testweise deaktivieren (SFTP: Ordner wp-content/plugins umbenennen), Theme auf Standard zurücksetzen, Ressourcenlimits erhöhen, Firewall-Regeln (z. B. UFW/iptables/Cloudfirewall) anpassen.

Unternehmensnetzwerke, Captive Portals, Sicherheits-Gateways

Captive Portals: In Hotels/Flughäfen zuerst Anmeldeseite öffnen. Ohne Login blockt das Netz häufig alle externen Ports.
Unternehmens-Proxys: Verlangen Authentifizierung. Falsch konfiguriert → „refused“. Setze die Proxy-URL/Port korrekt, oder trage Ausnahmen ein.
Layer-7-Security: Kategorien/Blocklisten können Domains hart sperren (RST). Ein Test via Mobilhotspot entlarvt solche Fälle schnell.

Probleme zielgerichtet erkennen: Symptome → Ursachen → Maßnahmen

Symptom	Wahrscheinliche Ursache	Schnelle Maßnahme
Nur eine bestimmte Seite zeigt „refused“	Server-/Firewall-Regel, Blockliste, DNS-Auflösung fehlerhaft	DNS-Cache leeren, VPN/Proxy aus, andere Netzwerke testen, Betreiber kontaktieren
Alle Seiten betroffen	Netzwerk/Router, Security-Suite, DNS-Resolver kaputt	Router-Neustart, Firewall/AV testen, DNS wechseln
Nur im Büro, zu Hause geht’s	Unternehmens-Proxy/Firewall	Proxy korrekt einrichten, IT kontaktieren
Nur mit VPN, ohne VPN ok	VPN-Endpunkt blockiert/Rate-Limit, Split-Tunnel falsch	VPN wechseln/abschalten, Split-Tunneling prüfen
Nur lokal (127.0.0.1) „refused“	Dienst läuft nicht, falscher Port/IPv6	Dienst starten, Listener/Port prüfen (`lsof`/`ss`)

Android, iOS und mobile Besonderheiten

Android (Chrome)

Flugmodus ein/aus, WLAN wechseln, Mobile Daten an/aus.
Chrome → Einstellungen → Datenschutz → Browserdaten löschen (Cache/Cookies).
VPN-/Adblocker-Apps temporär deaktivieren.
WLAN-Proxy prüfen: Netzwerkeinstellungen → Proxy „Keine“.

iOS (Safari/Chrome)

WLAN aus/an, Netzwerke „Dieses Netzwerk ignorieren“ und neu verbinden.
VPN/Content-Filter-Profile temporär deaktivieren.
Bei Safari: Einstellungen → Safari → Verlauf und Websitedaten löschen.

Vertiefung: Wie Browser, DNS und Proxies zusammenspielen

Der Weg einer HTTPS-Anfrage verläuft vereinfacht so:

DNS-Resolution: Domain → IP-Adresse
TCP-Handshake zum Ziel-IP:Port (typ. 443)
TLS-Handshake (Serverzertifikat, ALPN, SNI)
HTTP/2 oder HTTP/3 (QUIC) → eigentliche Anfrage

„Connection refused“ entsteht vor oder während Schritt 2. Ursachen:

Kein Listener: Zielhost lauscht nicht auf dem Port; OS sendet RST → abgelehnt.
Firewall-Policy: Paket aktiv abgelehnt (oder gefiltert → Timeout statt „refused“).
Proxy-Interferenz: Proxy offline/falsch → lokaler Connect scheitert.
Falscher DNS-Eintrag: Du kontaktierst die falsche IP, auf der nichts lauscht.

Profi-Tipp: HTTP-Fehler (4xx/5xx) bedeuten: TCP/TLS klappte. ERR_CONNECTION_REFUSED hingegen: Du kommst gar nicht bis zur HTTP-Schicht. Das hilft bei der Eingrenzung.

Checkliste: Von „keine Ahnung“ zu „Problem gelöst“

Andere Sites testen → Allgemeines vs. spezifisches Problem unterscheiden.
Inkognito testen → Add-ons/Cache ausschließen.
VPN/Proxy aus → Direktverbindung prüfen.
DNS-Cache leeren + DNS-Server wechseln.
Router neu starten, anderes Netzwerk probieren.
Firewall/AV testweise aus → ggf. Ausnahmen definieren.
Hosts-Datei prüfen → falsche Einträge entfernen.
TCP/IP-Reset (Windows) oder Netzwerkdienste neu starten (Linux/macOS).
Entwickler: Lauscht mein Dienst wirklich? Port/IPv4/IPv6 checken.
Wenn alles scheitert: ISP/Hoster/IT-Support kontaktieren, Traces/Netlogs bereitstellen.

Beispiele: Befehle und Aktionen auf einen Blick

Plattform	Aktion	Befehl/Schritt
Windows	DNS-Cache leeren	`ipconfig /flushdns` (CMD als Admin)
Windows	TCP/IP-Stack reset	`netsh winsock reset` + `netsh int ip reset`
Windows	Porttest	`Test-NetConnection deinedomain.tld -Port 443`
macOS	DNS-Cache leeren	`sudo killall -HUP mDNSResponder`
macOS/Linux	Porttest	`nc -zv host 443` oder `curl -v https://host`
Linux	DNS-Cache leeren	`sudo systemd-resolve --flush-caches`
Chrome	Host-Cache	`chrome://dns` → Host cache löschen
Alle	Erweiterungen prüfen	`chrome://extensions` → nacheinander deaktivieren
Entwickler	Listener finden	`ss -lntp` (Linux), `lsof -i :PORT` (macOS), `netstat -ano` (Windows)

Sonderfall: Wenn nur bestimmte Ports betroffen sind

Manche Provider/Firewalls blockieren gezielt Ports (SMTP 25, alternative HTTP-Ports wie 8080/8443). Teste

nc -zv deinedomain.tld 80
nc -zv deinedomain.tld 443
nc -zv deinedomain.tld 8080

Wenn 80/443 funktionieren, aber 8080 „refused“, ist Port 8080 geblockt oder der Dienst laucht dort nicht.

Fehler vermeiden: Best Practices

Saubere Netzwerkkonfiguration: DNS-Server bewusst setzen, Proxy nur wenn nötig.
Weniger ist mehr bei Add-ons: Nur Notwendiges aktivieren, regelmäßig aufräumen.
Regelmäßiger Geräte-/Router-Neustart: Schlitzende Stacks werden so bereinigt.
Hosts-Datei nicht missbrauchen: Temporäre Einträge nach Tests wieder entfernen.
Entwickler: Einheitliche Ports, Docker-Compose sauber mappen, IPv4/IPv6 berücksichtigen, Logs prüfen.

Siehe auch Excel wenn wert in spalte vorhanden dann – Ein umfassender Leitfaden zur effizienten Datensuche

Fazit

ERR_CONNECTION_REFUSED bedeutet: Die Verbindung wurde aktiv abgelehnt oder durch deine lokale/Netzwerkumgebung unterbunden – der HTTP-Dialog beginnt gar nicht erst. In der Praxis sind es meist Konfigurationsdetails wie Proxy/VPN, DNS oder Security-Software; seltener serverseitige Probleme. Wenn du strukturiert vorgehst – Verbindung testen, Cache/DNS leeren, VPN/Proxy/FW prüfen, Hosts-Datei und TCP/IP-Stack säubern und bei Bedarf mit Port-Tools nachmessen – löst du den Fehler in den meisten Fällen innerhalb weniger Minuten. Entwickler sollten zusätzlich sicherstellen, dass ihre lokalen Dienste tatsächlich lauschen (richtiger Port, richtiges Interface, keine Portkollision) und Chrome-spezifische Besonderheiten rund um .localhost kennen. So bekommst du deine Verbindung zuverlässig wieder ans Laufen – ohne Trial-and-Error-Marathon.

FAQ: Häufige Fragen zu ERR_CONNECTION_REFUSED

Was heißt „ERR_CONNECTION_REFUSED“ konkret?

Dein Browser versucht, eine TCP-Verbindung zum Server aufzubauen. Das Ziel (oder etwas auf dem Weg) lehnt diese Verbindung ab oder blockt sie so, dass der Browser „verweigert“ meldet. Es ist kein HTTP-Fehler, sondern ein Verbindungsfehler auf niedrigerer Ebene.

Ist das ein Problem auf meiner Seite oder beim Server?

Meist lokal oder im Netzwerk (Firewall, Proxy, DNS, Add-ons). Seltener ist der Zielserver nicht erreichbar oder lauscht nicht auf dem gewählten Port. Prüfe zuerst andere Websites und teste in einem anderen Netzwerk, um die Richtung einzugrenzen.

Warum sehe ich oft „127.0.0.1 hat die Verbindung abgelehnt“?

Weil deine Anfrage auf die lokale Loopback-Adresse geht (z. B. über Hosts-Datei, .localhost-Namen oder absichtlich bei der Entwicklung). Wenn auf dem Port nichts lauscht oder die Firewall blockt, entsteht der Fehler.

Hilft das Leeren von Cache und Cookies wirklich bei einem Verbindungsfehler?

Überraschend oft ja, weil fehlerhafte Cookies/Service Worker/Cache-Zustände Requests verändern können (z. B. Redirect-Schleifen über Proxies). Es ist ein schneller, risikoarmer Schritt, den du früh probieren solltest.

Muss ich meinen Antivirus dauerhaft ausschalten?

Nein. Deaktiviere ihn nur kurz zum Test. Wenn es dann funktioniert, richte gezielte Ausnahmen für Browser, Domains oder Ports ein. Sicherheitssoftware dauerhaft auszuschalten ist keine Lösung.

Wie setze ich unter Windows den Netzwerk-Stack zurück?

CMD als Administrator öffnen und nacheinander ausführen:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns

Danach neustarten.

Wie ändere ich meinen DNS-Server am schnellsten?

Windows: Adapter-Eigenschaften → Internetprotokoll Version 4 (TCP/IPv4) → Eigenschaften → Folgende DNS-Serveradressen verwenden → z. B. 1.1.1.1 und 1.0.0.1. macOS: Systemeinstellungen → Netzwerk → Aktive Verbindung → DNS → „+“ neue Server eintragen.

Kann ein VPN „ERR_CONNECTION_REFUSED“ verursachen?

Ja. Der VPN-Endpunkt kann den Zielserver blockieren oder falsch routen. Schalte das VPN testweise aus oder wechsle den Exit-Server. Prüfe auch Split-Tunneling-Einstellungen.

Ich entwickle lokal und sehe den Fehler. Was nun?

Prüfe, ob dein Dienst läuft und auf dem richtigen Port lauscht. Nutze lsof -i :PORT (macOS/Linux) oder netstat -ano (Windows). Teste zusätzlich mit curl -v http://127.0.0.1:PORT. Achte auf IPv4/IPv6 (127.0.0.1 vs. ::1) und Portkollisionen (Docker/Node).

Firefox zeigt keinen Code, Chrome schon – ist das wichtig?

Nein. Die Darstellung unterscheidet sich pro Browser. Der zugrunde liegende Fehler (Verbindungsaufbau abgelehnt) bleibt derselbe.

Kann ein PHP-Timeout „ERR_CONNECTION_REFUSED“ auslösen?

Direkt eher nicht (das erzeugt typischerweise 504 Gateway Timeout). Indirekt schon, wenn der Webserver oder PHP-FPM wegen Überlast/Absturz gar nicht mehr lauschen – dann verweigert das System die Verbindung auf dem Port.

Warum hilft „Router neu starten“ so oft?

Weil NAT-Tabellen, interne Firewalls, DNS-Forwarder oder Caches hängen können. Ein Neustart räumt auf und sorgt für eine saubere Netzwerkinitialisierung.

Was ist mit Chrome und .localhost-Subdomains?

Chrome behandelt .localhost als Sonderfall (Loopback). Wenn lokal kein Dienst auf dem Zielport/Interface lauscht oder Sicherheitsregeln greifen, endet der Verbindungsversuch häufig mit ERR_CONNECTION_REFUSED. Für Entwickler heißt das: Erst Listener/Port/IPv4/IPv6 prüfen, dann weiter debuggen.

Wann sollte ich meinen ISP oder Hoster kontaktieren?

Wenn der Fehler nur in deinem Heimnetz auftritt (anderes Netz funktioniert), und du lokale Ursachen (DNS, Firewall, Proxy, Cache) ausgeschlossen hast. Beim Hoster, wenn Port-Checks zeigen, dass der Zielserver nicht lauscht oder eine Server-Firewall blockiert.