Localhost Verbindung abgelehnt? ERR_CONNECTION_REFUSED beheben

Was bedeutet localhost Verbindung abgelehnt und was tun Sie zuerst?

Localhost Verbindung abgelehnt heißt: Ihr Browser erreicht einen Port auf Ihrem eigenen Rechner, aber dort nimmt keine Anwendung die Verbindung an. Der Server läuft nicht, lauscht auf einem anderen Port oder ist an eine andere Adresse gebunden. Prüfen Sie zuerst das Terminal, danach Adresse und Port.

Die folgende Reihenfolge geht von der häufigsten zur seltensten Ursache. Kurz gesagt: Erfahrungsgemäß lösen die ersten drei Schritte die meisten Fälle.

1. Sehen Sie im Terminal nach, in dem Sie die App gestartet haben. Bestätigen Sie, dass der Server läuft und nicht abgestürzt ist.
2. Vergleichen Sie den Port im Terminal mit dem Port in der Adressleiste.
3. Rufen Sie http://127.0.0.1:PORT auf und vergleichen Sie das Ergebnis mit localhost.
4. Achten Sie darauf, ob die Adresse mit http oder https beginnt.
5. Prüfen Sie, ob schon ein anderer Prozess den Port belegt.
6. Kontrollieren Sie bei Docker, WSL oder einer virtuellen Maschine die Portzuordnung.
7. Lassen Sie Firewall, Virenscanner und Browser Cache für den Schluss.

Dieser Artikel behandelt nur den einen Fehler localhost Verbindung abgelehnt. Für Nachbarthemen verlinken wir unsere anderen Anleitungen.

Was sagt die Fehlermeldung genau aus?

Ihr Browser sendet eine Verbindungsanfrage an Host und Port aus der Adressleiste. Das Betriebssystem sucht dann einen Prozess, der auf diesem Port lauscht. In der Praxis: Findet es keinen, lehnt es die Anfrage sofort ab. Der Browser zeigt daraufhin eine Meldung, die ERR_CONNECTION_REFUSED ähnelt. Der genaue Wortlaut ändert sich mit Browser und Version, deshalb suchen Sie am besten nach dem Fehlercode.

Dabei ist ein Unterschied wichtig. Konkret: Eine abgelehnte Verbindung bedeutet: Die Anfrage kam an, aber niemand hat die Tür geöffnet. Ein Timeout bedeutet dagegen, dass die Anfrage gar keine Antwort bekam. Anders gesagt: Suchen Sie eine Netzwerksperre, ist ein Timeout wahrscheinlicher. Eine Ablehnung ist fast immer ein Problem der Anwendung oder der Adresse.

Daher helfen weder ein Neustart des Routers noch das Leeren des DNS Caches. Kurz gesagt: Der Datenverkehr verlässt Ihren Rechner ohnehin nicht.

In welcher Reihenfolge diagnostizieren Sie localhost Verbindung abgelehnt?

Unser Vorgehen ist konkret: Prüfen Sie zuerst das, was am häufigsten die Ursache ist. Stützen Sie die Diagnose auf Ergebnisse, nicht auf Vermutungen. In der Praxis: Jeder Schritt kann den nächsten überflüssig machen.

Beispielszenario: Ein Kollege öffnet das Frontend Projekt und sieht, dass localhost die Verbindung ablehnt. Im Terminal steht keine Zeile, dass der Server gestartet ist. In diesem Fall sind Port, Adresse und Docker völlig egal, denn der Server läuft schlicht nicht.

• Terminal Ausgabe: Ist der Server gestartet oder hat er einen Fehler gemeldet und sich beendet?
• Portnummer: Ist der eingegebene Port der Port, auf dem die App lauscht?
• Lauschadresse: Lauscht die App nur auf IPv4, nur auf IPv6 oder auf beidem?
• Protokoll: Verwenden Sie http oder https?
• Konflikt: Belegt ein anderer Prozess den Port?
• Umgebung: Kommt Docker, WSL oder eine virtuelle Maschine dazwischen?

Zusammengefasst: Ändern Sie immer nur eine Variable und notieren Sie das Ergebnis. Konkret: Ändern Sie drei Dinge gleichzeitig, wissen Sie nicht, was geholfen hat.

Läuft der Server wirklich?

Die häufigste Ursache ist zugleich die einfachste. Der Server wurde nie gestartet oder ist nach dem Start abgestürzt. Der Browser zeigt dann genau diesen Fehler. Anders gesagt: Ein geschlossenes Terminal, ein Neustart des Rechners oder ein Fehler in einer Abhängigkeit können den Prozess beenden.

Gehen Sie zurück zu dem Fenster, in dem Sie die App gestartet haben. Eine rote Fehlermeldung, eine unbehandelte Ausnahme oder ein Befehl, der sofort zurückkehrt, zeigt: Der Server ist nicht aktiv. Viele Frameworks geben außerdem die Adresse aus, auf der sie lauschen. Kurz gesagt: Finden Sie diese Zeile nicht, liegt das Problem nicht im Browser.

Der Beobachtungsmodus bringt eine weitere Falle mit. Speichern Sie eine Datei, startet sich der Entwicklungsserver neu. In der Praxis: Enthält der neue Code einen Syntaxfehler, stirbt der Prozess. Die Adresse, die vor wenigen Sekunden funktionierte, lehnt dann plötzlich Verbindungen ab.

Sie können auch außerhalb des Browsers testen. Dieser Befehl zeigt, ob der Server antwortet:

curl -v http://127.0.0.1:3000

Dabei ist 3000 nur ein Beispielport, setzen Sie also Ihren eigenen ein. Konkret: Meldet der Befehl eine abgelehnte Verbindung, liegt das Problem auf der Serverseite. Erhalten Sie eine Antwort, sind Browser Cache oder Namensauflösung beteiligt.

Rufen Sie den richtigen Port auf?

Die zweithäufigste Ursache ist ein falscher Port. Anders gesagt: Frameworks verwenden unterschiedliche Standardports, und eine Projekteinstellung oder Umgebungsvariable kann sie ändern. Sie tippen aus Gewohnheit den alten Port, die App wartet aber auf dem neuen.

Die Startzeile im Terminal ist die zuverlässigste Quelle. Kurz gesagt: Kopieren Sie die Adresse von dort in den Browser. Kopieren schließt außerdem Tippfehler aus.

• Haben Sie dasselbe Projekt in zwei Terminals gestartet, hat die zweite Kopie womöglich automatisch einen anderen Port gewählt.
• Der Portwert in einer Umgebungsdatei überschreibt den Standardwert im Code.
• Ein altes Lesezeichen oder ein Verlaufseintrag kann auf einen Port zeigen, den niemand mehr nutzt.
• Eine Adresse von einem Kollegen kann auf Ihrem Rechner einem anderen Port entsprechen.

Außerdem unterscheiden sich bei einem Reverse Proxy der öffentliche Port und der Port der Anwendung. Lokal brauchen Sie meist den Port der Anwendung.

An welche Adresse ist die App gebunden: 127.0.0.1, 0.0.0.0 oder ::1?

Ein Server nimmt Verbindungen nur an der Adresse an, an die er gebunden ist. 127.0.0.1 ist die IPv4 Loopback Adresse Ihres eigenen Rechners. ::1 ist das IPv6 Gegenstück. 0.0.0.0 bedeutet alle IPv4 Schnittstellen.

Laut der Node.js Dokumentation lauscht ein Server ohne Host Angabe auf der unspezifizierten IPv6 Adresse, wenn IPv6 verfügbar ist, sonst auf der unspezifizierten IPv4 Adresse. Auf vielen Systemen deckt das Lauschen auf IPv6 auch IPv4 ab, allerdings ist dieses Verhalten nicht überall gleich. In der Praxis: Details finden Sie in der Node.js Dokumentation zu net.

Das praktische Ergebnis: Lauscht die App nur auf 127.0.0.1 und löst der Browser den Namen localhost zu ::1 auf, wird die Verbindung abgelehnt. Auch das Gegenteil kommt vor, denn die App lauscht nur auf ::1, während der Client IPv4 versucht.

Probieren Sie deshalb beide Adressen von Hand. Funktioniert http://127.0.0.1:PORT, aber http://localhost:PORT nicht, passen Namensauflösung und Lauschadresse nicht zusammen. Konkret: Die Lösung: Starten Sie die App so, dass sie auf IPv4 und IPv6 lauscht, oder schreiben Sie die Adresse ausdrücklich als 127.0.0.1.

Warum löst sich localhost zu einer IPv6 Adresse auf und warum geht das schief?

Localhost ist ein Name, keine Adresse. Das Betriebssystem löst ihn über die Einträge der Hosts Datei auf, oft sowohl zu 127.0.0.1 als auch zu ::1. Anders gesagt: Welche Adresse der Client zuerst versucht, hängt vom Client und seiner Version ab.

Die Node.js Dokumentation erklärt, dass neuere Versionen die Reihenfolge des Betriebssystems beibehalten können. Ältere Versionen bevorzugten IPv4. Ziehen Sie ein Projekt auf eine neuere Node.js Version um, kann eine bisher funktionierende localhost Adresse also plötzlich Verbindungen ablehnen. Kurz gesagt: Prüfen Sie das aktuelle Verhalten in der Node.js Dokumentation zu dns.

Am einfachsten bestätigen Sie das, indem Sie beide Adressen vergleichen. Funktioniert IPv4 und localhost nicht, ist das die wahrscheinliche Ursache. In der Praxis: Hintergrundwissen zum Protokoll finden Sie in unserer Anleitung Was ist IPv6.

Sie können Ihr Netzwerk zudem mit dem kostenlosen IPv6 Test prüfen. Allerdings misst dieses Werkzeug die Verbindung nach außen, nicht den lokalen Loopback. Für lokale Probleme sehen Sie sich die Hosts Datei und die Lauschadresse Ihrer App an.

Was passiert, wenn Sie http und https bei localhost verwechseln?

Spricht Ihr Server nur einfaches http und Sie tippen https, scheitert die Verbindung oder Sie sehen einen Zertifikatsfehler. Oft zeigt der Browser dann ebenfalls die Meldung zur abgelehnten Verbindung. Konkret: Ein Port spricht nicht beide Protokolle.

Manche Entwicklungswerkzeuge aktivieren https standardmäßig, andere nicht. Ändern Sie eine Einstellung, ändert sich auch das Protokoll. Anders gesagt: Nutzen Sie die Adresse aus dem Terminal, statt sie von Hand zu tippen.

In der Adressleiste lauert noch eine Falle. Browser können sich beim Vervollständigen an frühere Besuche erinnern. Eine Adresse, die Sie letzte Woche mit https geöffnet haben, schlägt der Browser zum Beispiel erneut mit https vor, obwohl Ihre App jetzt mit http startet. Tippen Sie dann die vollständige Adresse samt Protokoll.

Brauchen Sie lokal eine gesicherte Verbindung, nutzen Sie ein Werkzeug, das ein Zertifikat für die lokale Entwicklung erzeugt. Kurz gesagt: Zu Zertifikaten im Produktivbetrieb lesen Sie unseren Beitrag Was ist ein SSL Zertifikat.

Belegt ein anderer Prozess den Port (EADDRINUSE)?

Zwei Prozesse können nicht gleichzeitig denselben Port abhören. Belegt schon ein Prozess den Port, meldet Ihre neue App beim Start einen Fehler wie EADDRINUSE und beendet sich. Öffnen Sie danach die Adresse, lehnt der Browser die Verbindung ab, weil niemand lauscht.

Es gibt zwei verschiedene Szenarien. In der Praxis: Im ersten hält ein alter Prozess den Port weiter, und der neue Server startet nie. Im zweiten hängt der alte Prozess, und der Browser spricht mit einer veralteten oder defekten App.

Lesen Sie die erste rote Zeile im Terminal. Konkret: Steht dort, dass der Port belegt ist, liegt das Problem bei einem anderen Prozess. Vielleicht haben Sie eine frühere Sitzung nicht geschlossen, und eine alte Kopie läuft im Hintergrund weiter.

Diese Fehlerklasse betrifft nicht nur Ihren Laptop. Anders gesagt: Im Produktivbetrieb verhindert ein Prozessmanager, dass derselbe Port doppelt gestartet wird. Wie das geht, erklärt unser Beitrag Was ist PM2 und wie verwalten Sie Node.js Anwendungen.

Wie finden Sie den Prozess, der einen Port belegt?

Das Betriebssystem kann jeden lauschenden Port samt Besitzer auflisten. Kurz gesagt: Die Befehle unterscheiden sich je nach System, die Logik bleibt gleich: Port wählen, Besitzer finden, Prozess bei Bedarf beenden.

• macOS und Linux: lsof -i :3000 zeigt den Prozess, der den Port hält, samt Nummer.
• Linux: ss -ltnp listet alle lauschenden TCP Ports auf.
• Windows: netstat -ano gibt in der letzten Spalte neben dem Port die Prozessnummer aus.

Haben Sie die Prozessnummer, prüfen Sie im Task Manager oder in der Aktivitätsanzeige, zu welcher Anwendung sie gehört. Beenden Sie keinen Systemprozess, den Sie nicht kennen. In der Praxis: Ist es Ihr eigener alter Entwicklungsserver, dürfen Sie ihn schließen.

Alternativ starten Sie Ihre App auf einem anderen Port. Die meisten Frameworks lesen den Port aus einer Umgebungsvariable oder einer Kommandozeilenoption. Konkret: So sind Sie wieder arbeitsfähig, bevor Sie den Konflikt lösen. Für eine dauerhafte Lösung klären Sie, warum der alte Prozess am Leben blieb.

Warum kommt localhost Verbindung abgelehnt bei Docker vor?

Bei Docker läuft die App in einem Container mit eigenem Netzwerkraum. Anders gesagt: Ihr Browser läuft dagegen auf dem Host. Die Brücke dazwischen ist die Portfreigabe. Kurz gesagt: Ohne sie lehnt localhost die Verbindung ab.

Die Docker Dokumentation erklärt, dass Sie beim Start des Containers einen Port veröffentlichen müssen, um ihn vom Host zu erreichen. Die allgemeine Form koppelt einen Host Port mit einem Container Port:

docker run -p 8080:3000 image-name

In diesem Beispiel öffnen Sie im Browser 8080, während der Container innen auf 3000 lauscht. In der Praxis: Details finden Sie in der Docker Dokumentation zur Portveröffentlichung.

• Die Zeile EXPOSE in einer Dockerfile veröffentlicht den Port nicht. Sie dokumentiert ihn nur.
• Lauscht die App im Container nur auf 127.0.0.1, erreichen Anfragen von außen sie nie. Die App muss auf allen Schnittstellen lauschen.
• Die Zuordnung laufender Container sehen Sie in der Spalte für Ports in der Ausgabe von docker ps.

Sind Sie neu bei Docker, beginnen Sie mit unserem Docker Container Leitfaden. Für Datenbank Container zeigt unsere Anleitung zu PostgreSQL und MySQL in Docker dieselbe Portlogik.

Wie verhält sich localhost in WSL und virtuellen Maschinen?

Bei WSL oder einer virtuellen Maschine läuft Ihre App in einem anderen Betriebssystem. Konkret: Der Browser läuft meist auf dem Hostsystem. Localhost zeigt also auf den Rechner, auf dem der Browser läuft, nicht auf den, auf dem die App läuft.

Manche Konfigurationen leiten Ports aus der virtuellen Umgebung automatisch an den Host weiter. Andere tun das nicht, und Sie müssen die eigene IP Adresse der virtuellen Maschine verwenden. Anders gesagt: Das Verhalten hängt von Version, Netzwerkmodus und Einstellungen ab. Prüfen Sie deshalb die offizielle Dokumentation Ihrer Umgebung.

• Kontrollieren Sie die Adresse, auf der die App in der virtuellen Umgebung lauscht.
• Prüfen Sie den Netzwerkmodus der virtuellen Maschine, etwa Bridge, NAT oder nur Host.
• Legen Sie bei Bedarf in den Einstellungen der virtuellen Maschine eine Portweiterleitung an.
• Öffnen Sie den Browser testweise innerhalb der virtuellen Umgebung. Funktioniert es dort, liegt das Problem an der Netzwerkbrücke.

Dasselbe gilt für einen entfernten Server. Läuft die App auf einem Server und Sie öffnen localhost auf Ihrem eigenen Rechner, fragen Sie die falsche Maschine. Kurz gesagt: Nutzen Sie die echte Adresse des Servers oder richten Sie einen gesicherten Tunnel zur Portweiterleitung ein.

Was unterscheidet Node.js, Python und PHP Server bei diesem Fehler?

Der Browser zeigt für alle dieselbe Meldung. Der Unterschied liegt in der Standard Lauschadresse und in der Startmeldung. Lesen Sie deshalb die Dokumentation Ihres eigenen Frameworks.

Manche lokalen Entwicklungsserver lauschen aus Sicherheitsgründen nur auf der Loopback Adresse. In der Praxis: Andere lauschen auf allen Schnittstellen, damit weitere Geräte im Netzwerk zugreifen können. Verhält sich dasselbe Projekt auf zwei Rechnern unterschiedlich, ist dieser Standard oft der Grund.

• Akzeptiert der Startbefehl eine Adressoption, schreiben Sie die Adresse ausdrücklich hinein.
• Übergeben Sie Port und Adresse über Umgebungsvariablen, bestätigen Sie anhand der Terminal Ausgabe, dass die App sie liest.
• Debug Modus und Produktionsmodus lauschen eventuell auf verschiedenen Adressen, notieren Sie also den gestarteten Modus.
• Betreiben Sie mehrere Projekte, geben Sie jedem einen eigenen Port.

Öffnet ein Kollege denselben Code zum Beispiel ohne Probleme, vergleichen Sie die Node.js oder Python Versionen beider Rechner. Konkret: Ein Versionsunterschied kann die Namensauflösung verändern. So erkennen Sie schnell, dass die Ursache in der Umgebung liegt und nicht im Code.

Was ändert sich mit einem Reverse Proxy wie Nginx?

Ein Reverse Proxy leitet eingehende Anfragen an die dahinter liegende App weiter. Anders gesagt: Ist die App ausgefallen, liefert der Proxy meist eine Antwort im Stil von 502. Ist der Proxy selbst aus, zeigt der Browser wieder eine abgelehnte Verbindung.

Lokal brauchen Sie selten einen Proxy. Bauen Sie dennoch ein produktionsnahes Setup, testen Sie beide Ebenen getrennt. Gehen Sie zuerst direkt auf den Port der App, danach auf den Port des Proxys. Kurz gesagt: Die Ebene, auf der der Fehler beginnt, ist die Problemebene.

Die Backend Adresse in der Proxy Konfiguration muss also exakt zur echten Lauschadresse der App passen. Leitet der Proxy zum Beispiel an 127.0.0.1 weiter, während die App nur auf ::1 lauscht, wird die Anfrage abgelehnt. Einen ähnlichen Fall im Betrieb beschreiben wir in unserem Beitrag zum 502 Bad Gateway Fehler.

Wie sieht eine Diagnose in drei Minuten aus? Ein Beispielszenario

Der folgende Ablauf ist ein reines Beispielszenario und kein echter Kundenfall. Er zeigt, wie die Reihenfolge in der Praxis funktioniert.

Ein Entwickler öffnet das Projekt und sieht, dass localhost die Verbindung ablehnt. Zunächst schaut er ins Terminal und sieht die Startzeile des Servers. Der Server läuft, also muss die Ursache woanders liegen.

Danach vergleicht er den Port im Terminal mit der Adressleiste, und beide stimmen überein. In der Praxis: Anschließend ruft er per curl die Adresse 127.0.0.1 auf und bekommt eine Antwort. Dann probiert er localhost, und die Verbindung wird abgelehnt.

Das Ergebnis ist eindeutig: Localhost löst sich zu einer IPv6 Adresse auf, die App lauscht aber nur auf IPv4. Der Entwickler schreibt die Adresse als 127.0.0.1 und arbeitet weiter. Konkret: Für eine dauerhafte Lösung trägt er die Lauschadresse in die Startkonfiguration ein. Der ganze Vorgang dauert wenige Minuten, und niemand ändert wahllos Einstellungen.

Können Firewall oder Virenscanner die Verbindung blockieren?

Ja, aber seltener, als Sie vielleicht denken. Anders gesagt: Loopback Verkehr bleibt in der Regel außerhalb der Firewall. Manche Sicherheitslösungen in Unternehmen schränken lokale Ports dennoch ein.

Deshalb steht dieser Schritt bei localhost Verbindung abgelehnt weit hinten in der Liste. Stellen Sie zuerst sicher, dass App und Adresse stimmen. Danach verdächtigen Sie die Sicherheitssoftware.

• Sehen Sie in den Protokollen der Sicherheitssoftware nach blockierten Verbindungen.
• Fragen Sie auf einem verwalteten Gerät die IT Abteilung nach der Richtlinie.
• Statt die Firewall abzuschalten, legen Sie eine Regel für Ihren Entwicklungsserver an.
• Schalten Sie sie für einen Test ab, aktivieren Sie sie sofort nach dem Test wieder.

Auch Browser Erweiterungen können den Zugriff auf lokale Adressen stören. Kurz gesagt: Probieren Sie ein privates Fenster ohne Erweiterungen. Funktioniert es dort, ist eine Erweiterung die Ursache.

Interessieren Sie Firewall Konzepte auf dem Server, lesen Sie Was ist die CSF Firewall. In der Praxis: Für die lokale Entwicklung brauchen Sie sie selten.

Kann die Hosts Datei den Namen localhost zerstört haben?

Ja, das ist möglich. Das Betriebssystem ordnet den Namen localhost über die Hosts Datei der Loopback Adresse zu. Konkret: Haben Sie die Datei von Hand bearbeitet oder hat ein Werkzeug sie geändert, zeigt der Name eventuell auf eine unerwartete Adresse.

Die Datei enthält normalerweise eine IPv4 Zeile und eine IPv6 Zeile für localhost. Fehlt eine davon, versucht der Client womöglich jedes Mal die falsche Adresse. Anders gesagt: Schickt eine andere Zeile den Namen auf eine fremde IP, erreicht die Anfrage Ihren eigenen Rechner nie.

• Öffnen Sie die Datei und lesen Sie jede Zeile, in der localhost steht.
• Prüfen Sie, ob derselbe Name in mehr als einer Zeile definiert ist.
• Stellen Sie auskommentierte Einträge wieder her.
• Schließen Sie nach einer Änderung den Browser komplett und öffnen Sie ihn neu.

Allerdings steht diese Ursache weit unten in der Liste. Stimmen Terminal, Port und Lauschadresse und funktioniert 127.0.0.1, ist die Hosts Datei der nächste Ort zum Nachsehen. Kurz gesagt: Auch ein VPN oder ein lokales DNS Werkzeug kann dieses Verhalten verändern.

Wie wirken Browser Cache und HSTS auf einen localhost Fehler?

Ein Browser merkt sich manchmal eine frühere Antwort oder Weiterleitung. Hat er für localhost einmal eine dauerhafte Weiterleitung auf https gesehen, öffnet er die Adresse womöglich nicht mehr über http. In der Praxis: Das Ergebnis ist eine Verbindung, die weiterhin abgelehnt wird.

HSTS weist den Browser an, eine Seite nur über https anzusprechen. Hat dieselbe Adresse diesen Header einmal gesendet, stellt der Browser spätere http Anfragen selbst auf https um. Konkret: Die Details lesen Sie in der MDN Dokumentation zu HSTS.

• Probieren Sie dieselbe Adresse in einem privaten Fenster. Funktioniert sie dort, sind Cache oder eine gespeicherte Richtlinie die Ursache.
• Testen Sie einen anderen Browser.
• Löschen Sie die Websitedaten nur für localhost.
• Bleibt der HSTS Eintrag bestehen, löschen Sie den localhost Eintrag im Bereich der Domain Sicherheitsrichtlinien des Browsers.
• Senden Sie in der lokalen Entwicklung den HSTS Header gar nicht erst.

Die Cache Ursache bei localhost Verbindung abgelehnt ist selten, aber verwirrend, wenn sie auftritt. Sehen Terminal und curl sauber aus und der Browser lehnt trotzdem ab, verdächtigen Sie diesen Eintrag.

Welches Symptom deutet auf welche Ursache?

Die folgende Tabelle beschleunigt die Diagnose. Suchen Sie Ihr Symptom und führen Sie die erste Prüfung aus. Anders gesagt: Die Reihenfolge geht von der wahrscheinlichsten zur unwahrscheinlichsten Ursache.

Wie unterscheidet sich dieser Fehler von CORS, Timeout und Speicherfehlern?

Manche Fehler sehen ähnlich aus, haben aber andere Lösungen. Sie müssen sie auseinanderhalten, damit Sie nicht an die falsche Tür klopfen.

• Verbindung abgelehnt: Die Anfrage kam an, aber niemand lauscht. Dieser Artikel behandelt genau das.
• Timeout: Die Anfrage bekam keine Antwort. Das deutet auf ein Netzwerk, Routing oder Firewall Problem hin.
• CORS Fehler: Der Server antwortete, aber der Browser blockierte eine Anfrage über Ursprungsgrenzen hinweg. Lesen Sie dazu unseren Beitrag CORS Fehler beheben.
• Speicherfehler: Der Server stürzte ab, weil der Arbeitsspeicher nicht reichte. Hier hilft unsere Anleitung zu JavaScript heap out of memory.

Schauen Sie deshalb in den Netzwerk Tab und ins Terminal, nicht nur auf den ersten Satz im Browser. Kurz gesagt: Hat der Server nie geantwortet, ist der Kampf mit CORS Zeitverschwendung. Kam eine Antwort, ist die Suche nach einer abgelehnten Verbindung falsch.

Für allgemeine Gewohnheiten empfehlen wir außerdem unseren Beitrag Debugging Techniken für Entwickler.

Welche Gewohnheiten verhindern diesen Fehler dauerhaft?

Sehen Sie localhost Verbindung abgelehnt einmal im Monat, liegt das Problem im Setup und nicht bei Ihnen. In der Praxis: Ein paar kleine Gewohnheiten beenden die meisten Wiederholungen.

• Schreiben Sie die Portnummer in die Projektdokumentation und in die Beispiel Umgebungsdatei, damit alle denselben Wert nutzen.
• Geben Sie Adresse und Port in der Startmeldung des Servers aus.
• Legen Sie die Lauschadresse ausdrücklich fest, statt dem Standard zu vertrauen.
• Beenden Sie laufende Entwicklungsserver, wenn Sie fertig sind.
• Halten Sie bei Docker die Portzuordnung in einer Konfigurationsdatei und nicht nur in der Kommandozeile.
• Nutzen Sie im Team dieselbe Node.js Version, das verringert Unterschiede bei der Namensauflösung.

Zudem löst eine kurze Checkliste für jeden neuen Entwickler das Problem schon am ersten Tag. Dieselbe Logik gilt beim Wechsel in die Produktion. Konkret: Bringen Sie eine Node.js Anwendung auf einen Linux Server, folgen Sie unserer Anleitung zum Node.js Deployment mit Nginx und systemd.

Wie lautet die letzte Checkliste, wenn bisher nichts geholfen hat?

Haben Sie alle Schritte angewendet und der Fehler bleibt, wiederholen Sie die Liste von vorn und der Reihe nach. Meistens wurde ein Schritt zu schnell abgehakt.

1. Bestätigen Sie im Terminal, dass der Server ohne Fehler läuft.
2. Prüfen Sie, ob der eingegebene Port zum Port im Terminal passt.
3. Rufen Sie mit curl die Adresse 127.0.0.1 auf.
4. Probieren Sie die Adresse localhost gesondert und vergleichen Sie die Ergebnisse.
5. Achten Sie darauf, ob die Adresse http oder https verwendet.
6. Finden Sie den Prozess, der den Port belegt.
7. Kontrollieren Sie die Zuordnung bei Docker, WSL oder der virtuellen Maschine.
8. Testen Sie ein privates Fenster und einen anderen Browser.
9. Lesen Sie die Protokolle der Sicherheitssoftware.

Es hilft außerdem, das Gefundene während der Arbeit aufzuschreiben. Anders gesagt: Notieren Sie, welche Adresse und welchen Port Sie genutzt haben und welche Antwort kam. So müssen Sie beim nächsten Mal, wenn localhost die Verbindung ablehnt, dieselben Schritte nicht neu überlegen. Kurz gesagt: Auch Ihre Kollegen profitieren von diesen Notizen.

Haben Sie weiterhin keine Lösung, sammeln Sie Fehlermeldung, Terminal Ausgabe und Ihre Umgebung an einem Ort. Zusammen erleichtern diese drei Angaben einer anderen Person die Hilfe erheblich.

Wann sollten Sie bei Problemen mit der Entwicklungsumgebung professionelle Hilfe holen?

Für ein einmaliges Portproblem brauchen Sie keine Hilfe von außen. In der Praxis: Wiederholen sich solche Unterbrechungen in Ihrem Team jedoch oft, kann die Ursache im Prozess liegen. Unübliche Setups, undokumentierte Ports und Umgebungen, in denen jeder anders arbeitet, kosten Zeit.

Wir von Talha Aslan und Team legen bei individuellen Softwareprojekten Wert auf reproduzierbare Entwicklungsumgebungen. Konkret: Möchten Sie Umfang und Budget für Ihr Projekt sehen, können Sie auf unserer Seite zur individuellen Softwareentwicklung ein Angebot anfordern.

Hinweis: Dieser Artikel ist eine allgemeine Diagnose Anleitung. In Firmennetzwerken oder auf verwalteten Geräten können andere Sicherheitsrichtlinien gelten, fragen Sie dann Ihre IT Abteilung.