Was Localhost ist, und warum "es läuft auf Localhost" nicht die Beruhigung ist, nach der es klingt

Localhost ist der Name, den Ihr Rechner für sich selbst benutzt. Tippen Sie ihn in einen Browser, und die Anfrage erreicht nie ein Netzwerk: sie geht aus dem Browser, dreht innerhalb der Maschine um und kommt ein paar Mikrosekunden später bei dem an, was auf diesem Port lauscht.

Das ist die ganze Definition, und sie ist wirklich einfach. Nicht einfach ist, dass der Browser diese Adresse absichtlich anders behandelt als jede andere, in mehreren Punkten gleichzeitig. Eine von Localhost ausgelieferte Seite ist also nicht dieselbe Seite, die von einer Domain kommt, und in den Lücken dazwischen lebt eine bestimmte Sorte Fehler: der, der unsichtbar bleibt bis zu dem Moment, in dem Sie deployen.

localhost, 127.0.0.1 und das dritte, das niemand erwähnt

Diese werden austauschbar benutzt und sind nicht dasselbe.

127.0.0.1

Eine Adresse. Das IPv4-Loopback, fest verdrahtet als "diese Maschine". Keine Namensauflösung beteiligt

::1

Dieselbe Idee in IPv6, und eine andere Adresse. Ein Server, der nur auf IPv4 lauscht, lauscht hier nicht

localhost

Ein Name, der auf eines der beiden aufgelöst wird. Meist auf beide, und die Reihenfolge entscheidet die Maschine

0.0.0.0

Keine Adresse, die man besucht. Es heißt "lausche auf allen Schnittstellen", und das ist es, was einen Server vom Handy im selben WLAN erreichbar macht

Diese dritte Zeile ist die Quelle eines bestimmten, zermürbenden Nachmittags. localhost ist ein Hostname, und die Maschine löst ihn auf. Auf einem System, das IPv6 bevorzugt, wird localhost zu ::1, und ein Server, der nur an 127.0.0.1 gebunden ist, lauscht nicht auf ::1. Das Ergebnis ist eine abgelehnte Verbindung auf localhost und eine einwandfrei funktionierende Seite auf 127.0.0.1, was sich liest, als widerspräche die Maschine sich selbst. Tut sie nicht. Es sind zwei Adressen, und Ihr Server ist auf einer davon.

Warum der Browser hier seine eigenen Regeln beugt

Das ist der Teil, auf den es bei Fehlern ankommt, und die meisten Erklärungen zu Localhost lassen ihn ganz weg.

Browser verlangen einen sicheren Kontext für eine lange Liste von Fähigkeiten: Service Worker, die Clipboard-API, Geolokalisierung, Kamera und Mikrofon, Benachrichtigungen und mehr. Sicherer Kontext heißt normalerweise HTTPS. Aber Localhost gilt als potenziell vertrauenswürdig und bekommt die Ausnahme, weil der Verkehr die Maschine nie verlässt und nichts dazwischen ist, das mithören könnte.

Die Begründung ist stichhaltig und die Folge ist eine Falle. Alles auf dieser Liste funktioniert auf http://localhost und hört in dem Moment auf zu funktionieren, in dem derselbe Code von http://ihr-staging-rechner über einfaches HTTP ausgeliefert wird. Nichts in Ihrem lokalen Lauf hat Ihnen gesagt, dass die Funktion von einem sicheren Kontext abhängt, weil die Regel für Sie lokal ausgesetzt und überall sonst durchgesetzt wurde.

Die anderen Unterschiede, die alle in dieselbe Richtung zeigen

Localhost ist keine kleine Version der Produktion. Es ist eine andere Umgebung, die zufällig denselben Code ausführt, und fast jeder Unterschied schmeichelt Ihnen.

Es gibt kein Netzwerk. Keine Latenz, kein Paketverlust, kein wackeliges WLAN. Jede Race Condition, die davon abhängt, dass eine Anfrage nach einer anderen ankommt, löst sich lokal auf die schnelle Weise auf und für jemanden im Zug auf die andere. Ladeanzeigen, die niemand je sieht, sind meist das.

Es gibt kein CDN, keinen Proxy, keinen Load Balancer. Die Komprimierung, das Caching, das Umschreiben von Headern und das Puffern von Anfragen, die vor der Produktion sitzen, fehlen alle. Eine Antwort, die lokal funktioniert, kann von etwas dazwischen umgeformt werden, bevor ein echter Nutzer sie sieht.

Das Dateisystem ist wahrscheinlich nicht zwischen Groß- und Kleinschreibung unterscheidend. Auf macOS und Windows sind Logo.svg und logo.svg dieselbe Datei. Auf der Linux-Maschine, auf die Sie deployen, nicht, und der Import, der auf jedem Entwicklerrechner funktionierte, wird in der Produktion ein 404.

Cookies verhalten sich anders. localhost wird von Browsern bei sicheren Cookies sonderbehandelt, und es hat keine registrierbare Domain, sodass SameSite und das Verhalten über Subdomains hinweg, das Sie lokal nie durchspielen, in der Produktion sofort durchgespielt wird.

Sie sind ein einziger Nutzer. Keine Nebenläufigkeit, kein Verbindungspool unter Druck, kein Cache, den eine andere Anfrage schon aufgewärmt hat.

Jeder davon macht den lokalen Lauf leichter als den echten. Das ist das Muster, das zu bemerken sich lohnt: Localhost scheitert nicht anders, es scheitert weniger, und genau das macht “es läuft auf Localhost” zu einem schwachen Signal statt zu einer Beruhigung.

Was der Satz tatsächlich bedeutet

Wenn jemand sagt, etwas funktioniere lokal und nicht in der Produktion, hat er keine Aussage über den Code gemacht. Er hat eine Aussage über zwei Umgebungen gemacht, und die nützliche Frage ist, welcher Unterschied verantwortlich ist.

Das ist eine kurze Liste, und es ist jedes Mal dieselbe: die Ausnahme beim sicheren Kontext, das fehlende Netzwerk, die fehlenden Zwischenstationen, die Schreibweise von Dateinamen, der Gültigkeitsbereich von Cookies, und Last. Ein Fehler, der beim Deploy auftaucht und lokal nicht, ist fast immer einer dieser sechs, und sie zu kennen macht aus “läuft auf meiner Maschine” statt eines Vorwurfs eine Checkliste.

Es ist auch der Grund, warum es eine Staging-Umgebung gibt, und warum auch sie nie ganz eine Kopie ist.

Herausfinden, welcher es war

Das Schwierige an einem Umgebungsfehler ist, dass Sie ihn aus der Umgebung heraus, in der Sie sind, nicht sehen können. Die Person, die auf ihn trifft, ist auf der anderen Seite, mit einer Seite, die nicht funktioniert, und ohne Möglichkeit, Ihnen zu sagen warum, und Ihre Maschine beharrt weiter darauf, dass alles in Ordnung ist.

Die Konsole ist der Ort, an dem sich ein Fehler beim sicheren Kontext meldet, und das Netzwerkprotokoll ist der Ort, an dem das Umschreiben durch einen Proxy, ein 404 auf eine Datei, die es lokal gibt, oder ein nie gesendetes Cookie alle auftauchen. Erfasst auf der Maschine, auf der es tatsächlich kaputtging, beantworten diese beiden die Frage, die Ihre eigene Maschine nicht beantworten kann.

In einem Absatz

Localhost ist der Name Ihres Rechners für sich selbst, aufgelöst zu 127.0.0.1 oder ::1, und ein Server, der an eines davon gebunden ist, lauscht nicht auf dem anderen, was die ganze Erklärung dafür ist, dass localhost eine Verbindung ablehnt, die 127.0.0.1 annimmt. Wichtiger noch: Browser behandeln es selbst über einfaches HTTP als sicheren Kontext, also funktionieren Service Worker, die Zwischenablage, Geolokalisierung und die Kamera lokal und können in dem Moment aufhören, in dem derselbe Code von irgendwo sonst über HTTP kommt. Rechnen Sie das fehlende Netzwerk dazu, die fehlenden Proxys und CDNs, ein Dateisystem ohne Groß-und-Klein-Unterscheidung, anderen Cookie-Gültigkeitsbereich und eine Last von genau eins, und Localhost ist keine kleine Produktion: es ist eine Umgebung, die weniger scheitert, weshalb “es läuft auf Localhost” für sich genommen nichts eingrenzt.