127.0.0.1:57573 Localhost-Port: Leitfaden und Fehlerbehebung
Führe ein kleines Flask-Skript aus. Füge `http://127.0.0.1:57573` in den Browser ein. Es gibt zwei Möglichkeiten: Entweder wird die Seite geladen, oder das Terminal leuchtet rot auf mit der Fehlermeldung `ECONNREFUSED` und der Browser zeigt das traurige Symbol für einen getrennten Stecker an.
Beide Ergebnisse sind nicht mysteriös. Die Adresse besteht aus zwei Teilen: 127.0.0.1 ist die IPv4-Loopback-Adresse, und 57573 ist ein Port, den das Betriebssystem fast zufällig aus seinem Pool an Hochports ausgewählt hat. Diese Anleitung erklärt beide Teile. Wir untersuchen, warum so viele lokale Server einen solchen Port verwenden, und gehen die sechs häufigsten Fehlerquellen durch, bevor die Verbindung hergestellt wird. Am Ende wissen Sie, wie Sie einen Dienst an die richtige Schnittstelle binden, welche Dienste tatsächlich auf einem Port lauschen, Portkonflikte und Firewall-Sperren beheben und den lokalen Server absichern, bevor Sie ihn öffentlich zugänglich machen.
Was 127.0.0.1:57573 in einfachen Worten bedeutet
Drei Teile. Die IP-Adresse 127.0.0.1 ist die IPv4-Loopback-Adresse. Der Doppelpunkt bedeutet „und auf diesem Port“. 57573 ist der Port selbst; er liegt im hohen Portbereich, der von keinem weit verbreiteten Dienst dauerhaft belegt wird.
Verbinde dich damit, und der Kernel leitet das Paket direkt zurück an deinen lokalen Rechner. Keine Netzwerkkarte. Kein Switch. Keine Umleitung über irgendeine Leitung. Die Adresse ermöglicht es einem Prozess, mit anderen Prozessen auf demselben Host zu kommunizieren, ohne Daten für ein externes Netzwerk preiszugeben. Genau das ist der Sinn von Loopback.
Die Reservierung ist älter als die meisten Entwickler, die sie nutzen. RFC 1122, Abschnitt 3.2.1.3, sperrte 1989 den gesamten Adressblock 127.0.0.0/8 mit allen 16.777.216 Adressen dauerhaft. Das IANA IPv4 Special-Purpose Address Registry, geregelt durch RFC 6890 und aktualisiert durch RFC 8190, kennzeichnet denselben Block als nicht weiterleitbar, nicht global routingfähig und protokollgebunden reserviert. Jeder Prozess, der auf 127.0.0.1 lauscht, empfängt nur Datenverkehr vom eigenen Host. Alle eingehenden Pakete mit einer 127er-Quelladresse werden stillschweigend verworfen. Netzwerkexperten bezeichnen diese Pakete als „Marsianer“.
„Localhost“ ist lediglich der benutzerfreundliche Hostname für dasselbe. Öffnen Sie die Datei „/etc/hosts“ unter macOS oder Linux bzw. „C:\Windows\System32\drivers\etc\hosts“ unter Windows. Dort finden Sie im oberen Bereich die Zeile „127.0.0.1 localhost“.
Die Loopback-Adresse: Wie localhost zu Ihrem Rechner weitergeleitet wird
127.0.0.1 ist die bekannteste Adresse. Sie ist aber nicht die einzige. Der gesamte Adressblock 127.0.0.0/8 mit über 16 Millionen Adressen bildet eine Schleife. Unter Linux kann man 127.42.42.42 anpingen. Es funktioniert. Die meisten von uns verwenden aus Gewohnheit 127.0.0.1, aber der größere Block ist wichtig, wenn man iptables-Regeln liest oder ein gehärtetes Image prüft. (Es gibt seit Jahren einen Entwurf in der IETF, der vorschlägt, den größten Teil von 127/8 für Unicast-Anfragen freizugeben. Er wurde nicht angenommen.)
Die IPv6-Seite ist schlanker. Nur eine Adresse, `::1`, definiert in RFC 4291. Kein /8. Keine Reserveadressen. Wenn Ihr Dienst nur an `::1` gebunden ist, erhält jeder, der versucht, 127.0.0.1 zu erreichen, keine Antwort und umgekehrt. Auf einem modernen Linux-System und macOS wird `localhost` zu beiden Adressen aufgelöst, daher versucht der Browser normalerweise zuerst `::1`, scheitert und greift dann auf die IPv6-Adresse zurück. Dies ist als kleine, aber spürbare Verzögerung wahrnehmbar. Legen Sie im Skript eine Adresse fest, und die Mehrdeutigkeit verschwindet.
Der Kernel verarbeitet Loopback-Pakete über eine virtuelle Schnittstelle. Unter Linux heißt diese `lo`, unter macOS `lo0`. Die Befehle `ip link show` und `ifconfig lo0` zeigen sie an. Derselbe Firewall-Stack, der den gesamten übrigen Datenverkehr überwacht, überwacht auch Loopback-Pakete. Daher kann eine aggressive Firewall-Konfiguration den lokalen Datenverkehr beeinträchtigen. Mehr dazu in späteren Abschnitten.
Für die Entwicklung gilt: 127.0.0.1 ist die sicherste Schnittstelle. Nichts außerhalb Ihres Rechners kann darauf zugreifen. Container und VMs haben ihre eigene Loopback-Schnittstelle, getrennt vom Hostsystem. Genau das ist es, was die meisten Entwickler zum ersten Mal verwirrt, wenn sie erwarten, dass 127.0.0.1 innerhalb eines Docker-Containers auf magische Weise einen Dienst auf dem Laptop erreichen kann.
Warum Port 57573? Erläuterung der IANA-Portnummernbereiche
Port 57573 ist nichts Besonderes. Das Betriebssystem oder das Framework hat ihn belegt, weil er frei war. Um zu verstehen, warum eine so große Portnummer so häufig vorkommt, muss man sich ansehen, wie die IANA den 16-Bit-Portbereich aufteilt. Das gesamte Schema ist in RFC 6335 und der IANA-Registry für Dienstnamen und Transportprotokoll-Portnummern beschrieben.
| Reichweite | IANA-Name | Beispiele |
|---|---|---|
| 0–1023 | System / bekannte Ports | 22 SSH, 80 HTTP, 443 HTTPS, 53 DNS |
| 1024–49151 | Benutzer-/registrierte Ports | 3306 MySQL, 5432 Postgres, 8080 alt-HTTP |
| 49152–65535 | Dynamisch / privat / ephemer | Automatisch vom Betriebssystem zugewiesen, nie bei der IANA registriert |
Der von der IANA empfohlene Bereich für dynamische Ports liegt zwischen 49152 und 65535. Die tatsächliche Nutzung von Kerneln weicht jedoch häufig davon ab. Linux verwendet standardmäßig den Bereich 32768–60999 (`sysctl net.ipv4.ip_local_port_range`). Windows nutzt seit Vista den Bereich 49152–65535. In der XP-Ära wurde der Bereich 1025–5000 verwendet, ein enger Bereich, der unter Last zu einer Überlastung der Ports und damit zu bekannten Ausfällen führte. macOS hält sich an die IANA-Spezifikation. Port 57573 liegt in jedem modernen Standardbereich. Dies erklärt, warum er so häufig in Entwicklerprotokollen auftaucht.
Wenn Ihr Code in Flask `app.run(port=0)` oder in Node.js `server.listen(0)` aufruft, wählt das Betriebssystem einen beliebigen freien Port aus seinem lokalen dynamischen Bereich. Auf einem Linux-Laptop liegt dieser Bereich zwischen 32768 und 60999. Port 57573 ist dabei ein guter Richtwert. Dasselbe gilt für Tools mit automatischer Portzuweisung: Vite (das 2022 absichtlich standardmäßig 127.0.0.1 verwendet, um zu verhindern, dass Entwickler Server über das WLAN von Cafés verbreiten), webpack-dev-server, VS Code Live Server, Jupyter, Selenium-Treiberbrücken, Playwright und der Node.js-Debugger `--inspect=0`. Sie alle fragen den Kernel nach einem freien, hohen Port und verwenden diesen.
Wenn also Port 57573 in einem Stack-Trace auftaucht, ist die unspektakuläre Erklärung fast immer richtig. Entweder hat ein Prozess diesen Port absichtlich belegt, oder ein Framework hat nach einem beliebigen freien Port gefragt, und der Kernel hat diesen ausgewählt. An Port 57573 selbst ist nichts auszusetzen. Die meisten lokalen Test- und Entwicklungsumgebungen behandeln den gesamten hohen Portbereich als sichere, isolierte Umgebung, da kein öffentlicher Dienst davon abhängt.
Bindung eines Servers an 127.0.0.1 vs 0.0.0.0 vs ::1
Wählt man das falsche Bindungsziel, treten seltsame Fehler auf. Drei Definitionen, die man sich merken sollte.
127.0.0.1 bindet ausschließlich die IPv4-Loopback-Adresse. Erreichbar von demselben Rechner mit jedem IPv4-Client. Von außerhalb niemals.
::1 bindet nur die IPv6-Loopback-Schnittstelle. Gleiches Prinzip, aber nur für IPv6-Clients auf demselben Rechner.
0.0.0.0 bindet alle IPv4-Schnittstellen des Systems. Jeder, der eine Verbindung zu Ihrem Rechner herstellt, kann ihn erreichen, einschließlich Telefone im selben WLAN, VPN-Partner und (mit Portweiterleitung) das öffentliche Internet.
Für die tägliche Entwicklung sollten Sie 127.0.0.1 binden. Dies ist die einzige Schnittstelle, bei der Firewalls, VPN-Richtlinien und versehentliche Offenlegung keine Probleme mehr darstellen. Flask, FastAPI und Express verwenden sie standardmäßig.
Meiner Erfahrung nach gibt es drei Hauptgründe, warum Nutzer die IP-Adresse 0.0.0.0 verwenden: Tests auf einem Smartphone im LAN, Tests innerhalb eines Docker-Containers oder das Befolgen einer Anleitung, deren Autor die falsche Standardeinstellung kopiert hat. Für jeden dieser Fälle gibt es eine sicherere Vorgehensweise. Bei LAN-Tests sollte man die IP-Adresse an das spezifische LAN binden und eine temporäre Firewall-Regel hinzufügen. Bei Docker-Tests bindet man die IP-Adresse 0.0.0.0 innerhalb des Containers, veröffentlicht sie aber auf dem Host mit `docker run -p 127.0.0.1:8080:8080 …`. Bei Anleitungen sollte man die Zeile mit 0.0.0.0 ignorieren und die IP-Adresse auf 127.0.0.1 festlegen, es sei denn, es gibt einen triftigen Grund dafür.
Ein unspektakulärer Flask-Codeausschnitt zeigt die sichere Standardeinstellung:
```
from flask import Flask
app = Flask(__name__)
@app.route("/")
def index():
return "Hallo, localhost!"
if __name__ == "__main__":
app.run(host="127.0.0.1", port=57573)
```
Port 57573 wird mit netstat, lsof und ss untersucht.
Irgendetwas lauscht auf Port 57573, und Sie haben keine Ahnung, was. Der Befehl hängt von Ihrem Betriebssystem ab. Prägen Sie sich diese kurze Liste ein, und Sie werden sie jahrelang verwenden.
| Betriebssystem / Shell | Befehl | Anmerkungen | |
|---|---|---|---|
| Linux (modern) | `ss -tlnp \ | grep :57573` | Ersetzt netstat. Zeigt den Prozess an, wenn Sie das Programm als Root ausführen. |
| Linux (Legacy) | `netstat -tlnp \ | grep :57573` | net-tools lässt sich möglicherweise nicht auf kleinen Images installieren. |
| macOS | `lsof -i :57573` | Gleiches gilt auch für Linux. Beinhaltet Prozess und Benutzer. | |
| Windows cmd | `netstat -ano \ | findstr :57573` | Die Spalte „PID“ ist dem Task-Manager zugeordnet. |
| Windows PowerShell | `Get-NetTCPConnection -LocalPort 57573` | Sauberer, skriptfähig |
Typische Linux-Ausgabe:
```
$ ss -tlnp | grep 57573
LISTEN 0 4096 127.0.0.1:57573 0.0.0.0:* users:(("python3",pid=18432,fd=4))
```
Sechs Felder, von links nach rechts: Status, Sendewarteschlange, Empfangswarteschlange, Lokale Adresse, Peer-Adresse, der Prozess (in diesem Fall PID 18432). Unter Unix: `kill 18432`. In PowerShell: `Stop-Process -Id 18432`. Fertig. Falls Sie lediglich den Port wiederherstellen wollten, ist dies die vollständige Lösung.
Was passiert, wenn gar nichts angezeigt wird? Dann lauscht kein Server, was an sich schon eine nützliche Information ist. Die Browserfehlermeldung „Verbindung abgelehnt“ bedeutet in der Regel genau das: Ihr Server ist nicht erreichbar. Er ist beim Start abgestürzt oder konnte die eingegebene Adresse nicht erreichen.
Häufige Verbindungsfehler und ihre Bedeutung
Sechs Dinge. Das ist die vollständige Liste der Fehler, die unter 127.0.0.1:57573 angezeigt werden. Lesen Sie die Fehlermeldung und wählen Sie einen Bucket aus.
Die Meldungen `EADDRINUSE`, „Adresse wird bereits verwendet“ oder „Port 57573 ist bereits belegt“ bedeuten alle dasselbe: Eine andere Anwendung nutzt den Port. Die Befehle aus dem vorherigen Abschnitt zeigen Ihnen, welche Anwendung das ist. Beenden Sie diese Anwendung oder verwenden Sie einfach einen anderen Port für Ihren Dienst. Tools wie netstat oder lsof erledigen das mit nur einer Zeile.
Die Fehlermeldung „ECONNREFUSED“, die freundlichere Bezeichnung für „Verbindung abgelehnt“, bedeutet: TCP erreichte den Kernel, aber es wurde keine Verbindung hergestellt. Ihr Server ist beim Start abgestürzt oder konnte keine Verbindung herstellen. Schauen Sie sich das Terminal an, in dem Sie ihn gestartet haben. Der Stacktrace ist dort zu finden.
Die Meldungen „ETIMEDOUT“ und „Verbindungstimeout“ bedeuten, dass Pakete unbemerkt verloren gehen. Auf der IP-Adresse 127.0.0.1 sollte dies eigentlich nie vorkommen. Wenn es doch passiert, ist eine Firewall-Regel, ein VPN-Agent oder ein Endpoint-Protection-Tool die Ursache. Deaktivieren Sie diese nacheinander, versuchen Sie es erneut und wiederholen Sie den Vorgang.
Die Fehlermeldung „EACCES“ („Zugriff verweigert“) erscheint, wenn Sie versuchen, ohne Root-Rechte eine Verbindung zu einem Port unterhalb von 1024 herzustellen. Verwenden Sie einen höheren Port wie 57573 oder führen Sie die Binärdatei als Root aus. Diese dritte Option ist nicht verfügbar.
Die Fehlermeldung „EAI_NONAME“ und andere DNS-Fehler bedeuten, dass der Hostname nicht aufgelöst werden konnte. Die Hosts-Datei sollte „localhost“ auf 127.0.0.1 abbilden. Ein VPN-Client hat dies möglicherweise überschrieben. Ein Systemadministrator könnte ein fehlerhaftes Image ausgeliefert haben. Öffnen Sie die Hosts-Datei. Stellen Sie sicher, dass „127.0.0.1 localhost“ die erste Zeile ohne Kommentar ist.
Und noch ein tückischer Fehler: Nach einem ordnungsgemäßen Herunterfahren blockiert der Kernel den Socket für etwa zwei Minuten im TIME_WAIT-Zustand. Startet man den Server schnell neu, erscheint die Meldung „Adresse wird bereits verwendet“, obwohl niemand lauscht. Drei Lösungsansätze: abwarten, `SO_REUSEADDR` in der Bind-Konfiguration setzen oder einfach einen anderen Port verwenden. Die meisten von uns wählen Letzteres.
Lies die Fehlermeldung. Wähle den entsprechenden Bucket aus. Wende die Korrektur an. Der gesamte Vorgang dauert in der Regel weniger als eine Minute.
Firewall-Einstellungen, die Port 57573 blockieren
Loopback-Verkehr ist theoretisch immer erlaubt. In der Praxis verhindern Firewall-Regeln dies jedoch manchmal. Die üblichen Verdächtigen im Jahr 2026:
- Die macOS-Anwendungsfirewall ist so konfiguriert, dass eingehende Verbindungen blockiert werden. Fügen Sie die Anwendung, die Port 57573 belegt, unter Systemeinstellungen → Netzwerk → Firewall zur Zulassungsliste hinzu.
- Es liegt ein Profilkonflikt in der Windows Defender Firewall vor. Ein neues Entwicklertool fordert Sie auf, den Zugriff zu erlauben. Sie klicken reflexartig auf „Abbrechen“. Der Zugriff wird stillschweigend blockiert. Öffnen Sie `wf.msc`, entfernen Sie die Verweigerungsregel und bestätigen Sie die Abfrage beim nächsten Mal.
- Linux ufw oder iptables mit verschärften Standardrichtlinien. `ufw status verbose` listet die Regeln auf. `ufw allow from 127.0.0.1` öffnet die Loopback-Schnittstelle explizit. Die meisten Distributionen erlauben `lo` standardmäßig bereits, einige gehärtete Images jedoch nicht.
- Ein VPN- oder Zero-Trust-Agent eines Unternehmens fängt den Datenverkehr ab. Manche Agenten leiten lokale Verbindungen über einen Userspace-Listener weiter und verändern unbemerkt die Loopback-Verbindung. Deaktivieren Sie den Agenten für eine Minute, um dies zu bestätigen.
- Antivirus- oder Endpunktschutz. EDR-Produkte blockieren manchmal Entwickler-Binärdateien, die an hohe Ports binden, bis sie auf die Whitelist gesetzt werden.
In jeder verwalteten Unternehmensumgebung ist damit zu rechnen, dass mindestens einer dieser Fehler auftritt. Die Diagnose erfolgt wie folgt: Überprüfen Sie Ihre Firewall-Einstellungen und führen Sie anschließend `curl http://127.0.0.1:57573` in derselben Shell aus, mit der der Server gestartet wurde. Funktioniert Curl, aber der Browser nicht? Dann verwenden Sie die falsche Schnittstelle (oft `::1` statt 127.0.0.1) oder eine Richtlinie für den privaten Netzwerkzugriff ist aktiv. Schlägt auch Curl fehl? Dann fängt der Kernel oder die Firewall das Paket ab, bevor es Ihren Code erreicht. Webentwickler und Netzwerkadministratoren tauschen diese Tipps in internen Wikis aus, da die Symptome identisch erscheinen, bis man sie zweimal erlebt hat.
Localhost in Docker, WSL und GitHub Codespaces
Drei Stellen, an denen localhost sich nicht mehr so verhält, wie Sie es erwarten.
Zuerst zu Docker. Innerhalb eines Containers ist 127.0.0.1 die Loopback-Adresse des Containers , nicht Ihre. Wenn also auf Ihrem Laptop ein Dienst unter 127.0.0.1:57573 läuft, kann der Container diesen Dienst unter derselben Adresse nicht erreichen. Niemals. Das Host-Gateway befindet sich woanders: `host.docker.internal` unter macOS und Windows, eine Bridge-IP unter Linux. Für die umgekehrte Richtung (Container-Dienst, Host-Aufrufer) ist ein Publish-Flag erforderlich. Beispiel: `docker run -p 127.0.0.1:57573:57573 my-image`. Lässt man das `-p` weg, existiert der Port außerhalb des Containers nicht.
WSL2 hat seine Eigenheiten. Der gespiegelte Netzwerkmodus (optional unter Windows 11 22H2 und höher über `[wsl2] networkingMode=mirrored`) teilt den Netzwerk-Stack des Hosts mit der WSL-VM. In diesem Modus antwortet ein Dienst unter 127.0.0.1:57573 innerhalb von WSL unter Windows an derselben Adresse. Der Standard-NAT-Modus leitet Ports weiterhin weiter, jedoch nur für `localhost`-Strings, nicht immer für die direkte Adresse 127.0.0.1. Hierbei gibt es einen bekannten schwerwiegenden Fehler, der unter Microsoft WSL #40169 dokumentiert ist. Der gespiegelte Modus blockiert stillschweigend große Bereiche hoher Ports. Bindungsversuche an 127.0.0.1 schlagen dann mit `WinError 10013` fehl, was Python hilfreicherweise als `PermissionError` meldet. Wenn sich ein Port unter Windows ohne ersichtlichen Grund nicht binden lässt, sollte dies zuerst überprüft werden.
GitHub Codespaces und VS Code Remote SSH funktionieren in die entgegengesetzte Richtung. Sie leiten Ihre Ports automatisch weiter. Starten Sie einen Server in einem Codespace auf 127.0.0.1:57573, und der Editor öffnet einen Tunnel, der diesen Port unter einer eindeutigen github.dev-URL bereitstellt. Der Browser-Tab auf Ihrem Laptop kommuniziert mit dieser URL, nicht mit 127.0.0.1, und die Anfrage wird über den Tunnel zurück in den Workspace geleitet.
Der Endpunktname sieht also gleich aus. Der tatsächliche Pfad, den das Paket nimmt, ist in jeder Umgebung jedoch völlig unterschiedlich. Fünf Minuten, die man damit verbringt, die jeweilige Umgebung zu ermitteln, ersparen einem zwanzig Minuten, in denen man auf die Fehlermeldung „Verbindung abgelehnt“ starrt.
HTTPS auf Localhost: Bewährte Verfahren für die sichere lokale Entwicklung
Moderne Browser und viele APIs bestehen selbst bei lokaler Entwicklung auf HTTPS. Service Worker, Geolocation, die Zwischenablage-API und alle als „Secure“ gekennzeichneten Cookies funktionieren nicht über unverschlüsseltes HTTP. Eine Ausnahme bildet 127.0.0.1, das der Browser bereits als sicheren Kontext behandelt. Diese Ausnahme deckt die meisten gelegentlichen Entwicklungsanwendungen ab. Für alle anderen Anwendungen sollte TLS lokal verwendet werden.
Das mit Abstand beste Tool ist mkcert von Filippo Valsorda. Führen Sie es einmal mit `mkcert -install` und anschließend mit `mkcert localhost 127.0.0.1 ::1` aus. Sie erhalten dann ein `localhost+2.pem`-Zertifikat und einen Schlüssel. Richten Sie Ihren Entwicklungsserver auf dieses Zertifikatspaar ein. Der Browser zeigt ein sauberes Vorhängeschloss ohne Warnung an, da mkcert eine lokale Stammzertifizierungsstelle in Ihrem System und den Firefox-Truststores installiert hat. Let's Encrypt kann kein gültiges Zertifikat für `127.0.0.1` ausstellen, da keine Domain zur Validierung vorhanden ist. Daher ist eine lokale Zertifizierungsstelle die Standardlösung.
Einige weitere Muster, die es wert sind, bekannt zu sein:
- Für automatisierte Tests kann ein Magic-DNS-Dienst (z. B. `nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`) verwendet werden, um eine IP-Adresse in einen echten Hostnamen wie `127.0.0.1.nip.io` umzuwandeln. Let's Encrypt oder ZeroSSL können diese zertifizieren, und `localhost.direct` stellt sogar ein vorab ausgestelltes Wildcard-Zertifikat bereit.
- Binden Sie Ihren Dienst an 127.0.0.1, nicht an 0.0.0.0, damit das Zertifikat (das `127.0.0.1` abdeckt) auch tatsächlich übereinstimmt.
- Entwicklerzertifikate sollten nicht in Git gespeichert werden. mkcert speichert sie standardmäßig im Arbeitsverzeichnis. Fügen Sie das Zertifikatspaar daher umgehend zu `.gitignore` hinzu.
- Die lokale Zertifizierungsstelle sollte alle paar Monate ausgetauscht werden. `mkcert -uninstall` entfernt sie.
- Wenn Sie sich hinter einem firmeninternen MITM-Proxy befinden, müssen Sie damit rechnen, dass dieser Ihre Zertifikate austauscht. Deaktivieren Sie den Proxy auf `127.0.0.1`, sofern Ihre Tools dies unterstützen.
Browser haben eine wichtige Sonderregel. Gemäß der W3C-Spezifikation für sichere Kontexte gelten `http://127.0.0.1`, `http://localhost` und `http://[::1]` als „potenziell vertrauenswürdig“. Dadurch kann eine HTTPS-Seite diese Adressen aufrufen, ohne eine Blockierung gemischter Inhalte auszulösen. Diese Ausnahme gilt speziell für die lokale Entwicklung.
Localhost ist keine Sicherheitsgrenze im üblichen Sinne. Browser können durch DNS-Rebinding dazu gebracht werden, Localhost von beliebigen Websites aus zu erreichen. Dabei löst eine bösartige Website ihren Hostnamen auf 127.0.0.1 auf und ermöglicht es JavaScript auf der Seite des Angreifers, mit lokalen Diensten unter dem Ursprung der ursprünglichen Website zu kommunizieren. Der Zoom-CVE-Fall von 2019 (CVE-2019-13450) ist ein Paradebeispiel. Zoom installierte einen versteckten Webserver auf `localhost:19421` unter macOS, sodass Meeting-Links die Desktop-App starten konnten und jede Website Daten von diesem Server abrufen konnte, um den Benutzer mit eingeschalteter Kamera zwangsweise in ein Meeting einzubinden. Rund 4 Millionen Macs waren betroffen, zusätzlich zu dreizehn White-Label-Clients, die auf derselben Engine basierten. Chrome 142, veröffentlicht Ende 2025, ersetzte den älteren Ansatz des privaten Netzwerkzugriffs durch den lokalen Netzwerkzugriff. Öffentliche Seiten benötigen nun eine explizite Berechtigungsanfrage, bevor sie Loopback- oder private Adressen erreichen können. Dies macht die meisten Tricks, die die Singularity-Software der NCC Group automatisiert hat, unbrauchbar. Ein Straiker-Advisory aus dem Jahr 2025 dokumentierte denselben Angriff auf lokal laufende Model Context Protocol-Server (LLM). Diese Angriffsfläche wächst rasant, da Entwickler immer mehr LLM-Agenten auf Loopback-Schnittstellen betreiben. Binden Sie daher strikt an 127.0.0.1, fordern Sie eine Authentifizierung an, prüfen Sie den `Origin`-Header und vermeiden Sie Wildcard-CORS in Entwickler-APIs. Diese vier Maßnahmen decken die meisten dieser Angriffe ab.
Tipps zur Fehlerbehebung und eine kurze Diagnose-Checkliste
Wenn 127.0.0.1:57573 nicht antwortet, gehen Sie diese kurze Liste durch, bevor Sie tieferliegende Magie vermuten.
1. Prüfen Sie, ob der Server tatsächlich läuft. Schauen Sie im Terminal nach, wo Sie ihn gestartet haben. Falls er abgestürzt ist, befindet sich dort der Stacktrace.
2. Prüfen Sie, ob die Adresse 127.0.0.1 und nicht 0.0.0.0 oder ::1 allein gebunden ist. Die meisten Frameworks geben die Bindungsadresse beim Start aus. Lesen Sie die entsprechende Zeile.
3. Versuchen Sie in derselben Shell `curl -v http://127.0.0.1:57573`. Funktioniert Curl? Dann liegt das Problem im Browser, nicht auf dem Server.
4. Ermitteln Sie, wem der Port gehört. Linux: `ss -tlnp | grep :57573`. macOS: `lsof -i :57573`. Windows: `netstat -ano | findstr :57573`.
5. Ist der falsche Prozess dafür zuständig? Beenden Sie diesen und starten Sie Ihren Server neu.
6. Hört gar nichts zu? Schauen Sie im Startprotokoll nach. `EACCES` bedeutet, dass ein privilegierter Port verwendet wird. `EADDRINUSE` bedeutet in der Regel, dass die Wartezeit (TIME_WAIT) veraltet ist.
7. Versuchen Sie es mit IPv6. `curl http://[::1]:57573`. Wenn entweder `127.0.0.1` oder `::1` funktioniert, das andere aber nicht, ist Ihr Dienst Single-Stack.
8. Versuchen Sie einen anderen Port: Verwenden Sie `--port 12345` (oder einen anderen Port) und laden Sie die Seite neu. Funktioniert es mit dem neuen Port? Dann liegt ein Portkonflikt vor.
9. Beenden Sie VPN, Antivirus und Endpoint-Agenten für eine Minute. Wenn Port 57573 antwortet, hat einer dieser Dienste den Datenverkehr verursacht.
10. Neustart des Computers oder zumindest der Netzwerkschnittstelle. Das hilft fast nie. Es behebt jedoch veraltete Verbindungen und einen blockierten Firewall-Zustand, wenn nichts anderes mehr hilft.
Bei den meisten Entwicklungsproblemen decken die ersten vier Schritte zur Fehlerbehebung die Ursache des Verbindungsfehlers auf. Die restlichen Schritte decken die wirklich ungewöhnlichen Fälle ab, in denen eine IPv6-Inkompatibilität, veraltete Sockets oder eine blockierende Firewall den eigentlichen Fehler verschleiern. Lesen Sie die Fehlermeldung und arbeiten Sie dann die Liste ab.
Ein Hinweis zu Plisio: Bei der Integration der Webhooks eines Krypto-Zahlungsanbieters benötigt das Gateway eine öffentliche URL, an die es POST-Anfragen senden kann. Plisio-Rechnungen akzeptieren eine `callback_url` in der API-Payload, und das System sendet Statusaktualisierungen per POST an diesen Endpunkt. Ihr lokaler Server unter 127.0.0.1:57573 ist definitionsgemäß nicht über das öffentliche Internet erreichbar. Die gängigste Lösung ist daher ein Tunnel. Im Jahr 2026 sind typische Optionen ngrok (Personal 8 $/Monat, Pro 20 $/Monat), Cloudflare Tunnel (kostenlos für bis zu 50 Benutzer im Zero-Trust-Modus) und Tailscale Funnel (kostenlos für den persönlichen Gebrauch, kostenpflichtige Teams ab 6 $/Benutzer/Monat). Jeder dieser Dienste benötigt einen öffentlichen Hostnamen und leitet den Datenverkehr an die Adresse 127.0.0.1:57573 Ihres Laptops weiter. Die Python-, PHP- und Node-SDKs von Plisio enthalten einen `validate_callback`-Helper, der den HMAC-SHA1-`verify_hash` über den geordneten JSON-Body überprüft, sodass derselbe Handler, sobald der Tunnel eingerichtet ist, in der Entwicklungsumgebung und in der Produktionsumgebung identisch funktioniert.
