So testest du deine lokale Website auf einem echten Smartphone?

Wenn du eine Website lokal entwickelst, findet die erste Vorschau meistens im Browser auf demselben Computer statt. Das ist nützlich, beantwortet aber eine sehr praktische Frage nicht vollständig: Wie fühlt sich die Website auf einem echten Smartphone an?

In der nativen App-Entwicklung ist ein solcher Ablauf normal. Bei iOS-Projekten arbeitet man typischerweise mit Xcode, Simulatoren und Tests auf echten Geräten. Bei Android gehören Android Studio, Emulatoren sowie USB- oder Wireless-Debugging oft selbstverständlich zum Entwicklungsprozess.

Webentwicklung beginnt häufig lockerer: localhost öffnen, das Browserfenster kleiner ziehen, vielleicht den Responsive-Modus in den DevTools verwenden und weitermachen. Das ist bequem, kann aber echte mobile Probleme bis spät im Projekt verstecken. Ein besserer Web-Workflow macht Tests auf echten Geräten zu einem normalen Teil der lokalen Entwicklung.

Diese Anleitung gilt nicht nur für Django. Die Methode funktioniert für die meisten lokalen Web-Stacks: Django, Laravel, Rails, Express, Vite, Next.js, Flask, FastAPI und viele andere.

Die Grundidee ist einfach:

1. Die lokale Netzwerk-IP des Computers finden.
2. Den Entwicklungsserver auf 0.0.0.0 starten, nicht nur auf 127.0.0.1.
3. Falls das Framework Host-Validierung nutzt, den LAN-Host erlauben.
4. Auf dem Smartphone http://COMPUTER_IP:PORT/ öffnen.

In diesem Artikel ist Django das getestete Beispielprojekt, aber die Netzwerkmethode ist framework-unabhängig.

Die fertige Smartphone-URL in diesem Setup lautet:

http://192.168.1.113:8000/

Deine IP-Adresse wird wahrscheinlich anders sein, aber die Methode bleibt gleich.

1. Die lokale Netzwerk-IP des Computers finden

Das Smartphone kann nicht 127.0.0.1 verwenden, um den Entwicklungsserver auf deinem Computer zu erreichen. Auf dem Smartphone bedeutet 127.0.0.1 das Smartphone selbst.

Der erste Schritt ist daher, die LAN-IP-Adresse des Computers zu finden.

Unter Windows PowerShell:

Get-NetIPAddress -AddressFamily IPv4 |
  Where-Object { $_.IPAddress -notlike '127.*' -and $_.IPAddress -notlike '169.254*' } |
  Select-Object InterfaceAlias, IPAddress, PrefixLength

In diesem Projekt war die passende Netzwerkschnittstelle:

Ethernet 3    192.168.1.113    /24

Das bedeutet: Wenn das Smartphone im selben Netzwerk ist, sollte es diese Adresse verwenden:

http://192.168.1.113:8000/

2. Den Entwicklungsserver an 0.0.0.0 binden

Viele Entwicklungsserver binden standardmäßig an 127.0.0.1. Dadurch werden nur Verbindungen vom selben Computer akzeptiert.

Für Tests auf dem Smartphone muss der Server auf allen Netzwerk-Interfaces lauschen:

0.0.0.0

Der Unterschied ist entscheidend:

127.0.0.1:8000   nur der Computer selbst
0.0.0.0:8000     Zugriff aus dem lokalen Netzwerk möglich

Der genaue Befehl hängt vom Framework ab.

Für das Django-Beispielprojekt:

$env:DJANGO_ALLOWED_HOSTS="127.0.0.1,localhost,192.168.1.113"
python manage.py runserver 0.0.0.0:8000

Bei anderen Stacks sieht der Befehl anders aus, aber die Idee ist dieselbe:

# Vite / React / Vue / Svelte
npm run dev -- --host 0.0.0.0

# Next.js
next dev -H 0.0.0.0

# Express
app.listen(3000, "0.0.0.0")

# Laravel
php artisan serve --host=0.0.0.0 --port=8000

# Rails
bin/rails server -b 0.0.0.0

# Flask
flask run --host=0.0.0.0

# FastAPI
uvicorn main:app --host 0.0.0.0 --port 8000

Andere Tools, dasselbe Netzwerkprinzip.

3. Host-Validierung im Framework beachten

Einige Frameworks akzeptieren LAN-Anfragen sofort, sobald der Server auf 0.0.0.0 läuft. Andere prüfen zusätzlich den Host.

Django ist eines der strengeren Beispiele. Es prüft den eingehenden Host-Header. Wenn das Smartphone http://192.168.1.113:8000/ öffnet, sieht Django:

Host: 192.168.1.113:8000

Wenn dieser Host nicht erlaubt ist, kann Django die Anfrage ablehnen.

Statt eine einzelne IP fest in settings.py einzutragen, wurde das Django-Beispielprojekt so angepasst, dass erlaubte Hosts aus einer Umgebungsvariable gelesen werden:

import os
from pathlib import Path

ALLOWED_HOSTS = [
    host.strip()
    for host in os.environ.get("DJANGO_ALLOWED_HOSTS", "127.0.0.1,localhost").split(",")
    if host.strip()
]

Das hält das Projekt flexibel. Heute ist die IP 192.168.1.113; morgen kann sie anders sein.

Wenn du ein anderes Framework verwendest, suche nach den entsprechenden Einstellungen:

• allowed hosts
• trusted hosts
• host header validation
• dev server host allowlist
• CORS- oder Origin-Einstellungen, falls das Smartphone eine separate API aufruft

Die Namen unterscheiden sich, aber der Grund ist derselbe: Das Framework muss dem Host vertrauen, den dein Smartphone verwendet.

4. Prüfen, ob der Server wirklich lauscht

Nach dem Start des Servers solltest du prüfen, ob er nicht nur an localhost gebunden ist.

Unter Windows:

Get-NetTCPConnection -LocalPort 8000

Das Ergebnis sollte ungefähr so aussehen:

LocalAddress    LocalPort    State
0.0.0.0         8000         Listen

In diesem Projekt wurde bestätigt, dass der Server hier lauscht:

0.0.0.0:8000

Das bedeutet: LAN-Verbindungen können den Prozess erreichen, sofern die Firewall sie zulässt.

5. Das Host-Verhalten testen

Da das Beispielprojekt Django verwendet, wurde das Host-Verhalten direkt getestet.

Der erste Test beweist, dass ein LAN-Host die Startseite rendern kann, wenn er erlaubt ist:

@override_settings(ALLOWED_HOSTS=["192.168.1.113"])
def test_lan_host_can_render_homepage_when_allowed(self):
    response = self.client.get(
        reverse("services:service_list"),
        HTTP_HOST="192.168.1.113:8000",
    )

    self.assertEqual(response.status_code, 200)
    self.assertContains(response, "Professional Cleaning Services")

Der zweite Test beweist das Gegenteil: Derselbe Host wird abgelehnt, wenn er nicht erlaubt ist.

@override_settings(ALLOWED_HOSTS=["127.0.0.1"])
def test_lan_host_is_rejected_when_not_allowed(self):
    response = self.client.get(
        reverse("services:service_list"),
        HTTP_HOST="192.168.1.113:8000",
    )

    self.assertEqual(response.status_code, 400)

Damit ist die Sicherheitsgrenze im Django-Beispiel dokumentiert. Die Smartphone-URL funktioniert nur, wenn der LAN-Host ausdrücklich erlaubt ist.

In einem anderen Framework würdest du dieses Verhalten anders testen. Du könntest zum Beispiel prüfen, ob der Dev-Server auf der LAN-URL antwortet, ob die API den Origin akzeptiert oder ob eine Host-Allowlist die LAN-IP enthält.

6. Die Testsuite ausführen

Nach dem Hinzufügen der LAN-Host-Tests wurde die vollständige Testsuite ausgeführt:

python manage.py test

Ergebnis:

Found 13 test(s).
System check identified no issues (0 silenced).
.............
----------------------------------------------------------------------
Ran 13 tests in 0.834s

OK

Das Beispielprojekt hat damit automatisierte Abdeckung für das normale Website-Verhalten und für den Zugriff über das lokale Netzwerk.

7. Localhost, LAN und TCP-Zugriff prüfen

Zuerst wurde der lokale Computer geprüft:

Invoke-WebRequest -UseBasicParsing http://127.0.0.1:8000/

Ergebnis:

localhost status=200 contains=True

Dann wurde die LAN-IP vom selben Computer aus geprüft:

Invoke-WebRequest -UseBasicParsing http://192.168.1.113:8000/

Ergebnis:

lan status=200 contains=True

Zum Schluss wurde der TCP-Port geprüft:

Test-NetConnection -ComputerName 192.168.1.113 -Port 8000

Ergebnis:

TcpTestSucceeded: True

An diesem Punkt lauscht der Entwicklungsserver auf dem richtigen Interface, das Beispiel-Framework erlaubt den LAN-Host, und der Port antwortet.

8. Die Website auf dem Smartphone öffnen

Öffne auf einem Smartphone im selben WLAN oder lokalen Netzwerk:

http://192.168.1.113:8000/

Wenn die Seite geöffnet wird, siehst du dieselbe lokale Website auf einem echten mobilen Gerät.

Falls sie nicht geöffnet wird, prüfe diese Punkte:

• Smartphone und Computer sind im selben Netzwerk.
• Der Entwicklungsserver läuft auf 0.0.0.0, nicht nur auf 127.0.0.1.
• Das Framework erlaubt die LAN-IP des Computers als Host, falls es Host-Validierung nutzt.
• Die Windows Firewall erlaubt eingehenden Zugriff auf den Prozess oder Port.
• Das Netzwerk ist privat/vertraut und kein isoliertes Gast-WLAN.
• Falls das Frontend eine separate API aufruft, muss auch diese API vom Smartphone erreichbar sein.

9. Warum das wichtig ist

Der Responsive-Modus im Browser ist hilfreich, bleibt aber eine Annäherung. Ein echtes Smartphone kann Details zeigen, die Desktop-Browser-Tools übersehen:

• Größe von Touch-Zielen
• echtes Font-Rendering
• mobile Browser-Oberfläche
• Netzwerklatenz
• Scroll-Verhalten
• Layout-Probleme rund um Sticky Header oder Formulare
• Verhalten der echten Gerätetastatur

LAN-Zugriff macht es möglich, die lokale Website vor dem Deployment auf einem echten Gerät zu testen. Das ist eine kleine Setup-Änderung, verbessert aber das Feedback deutlich.

Damit nähert sich Webentwicklung der Testdisziplin an, die in der mobilen App-Entwicklung bereits erwartet wird. Du brauchst kein Xcode oder Android Studio, um eine Website auf dem Smartphone zu testen, aber du brauchst einen lokalen Testpfad für echte Geräte. Den Entwicklungsserver vom eigenen Smartphone aus zu öffnen, liefert genau diesen Pfad mit sehr wenig Aufwand.

Das ist besonders während aktiver Entwicklung nützlich:

• Du erkennst mobile Abstands- und Layout-Probleme, bevor der Kunde sie sieht.
• Du testest Navigation, Buttons, Formulare und Sticky Header mit echter Touch-Eingabe.
• Du siehst, ob das Design innerhalb der mobilen Browser-Oberfläche weiterhin gut wirkt.
• Du prüfst, ob lokale API-Aufrufe und Frontend-Verhalten außerhalb des Desktop-Browsers funktionieren.
• Du kannst echte Screenshots für Dokumentation, QA oder Kundenupdates erstellen.

Entscheidend ist das Timing. Mobile Testing sollte kein finaler Polishing-Schritt sein. Es sollte stattfinden, während die Website noch gebaut wird.

10. Was, wenn der Kunde nicht im selben Netzwerk ist?

Die LAN-Methode hat eine klare Grenze: 192.168.1.113 ist eine private Netzwerkadresse. Sie funktioniert nur für Geräte im selben lokalen Netzwerk.

Wenn ein Kunde nicht in deinem WLAN oder lokalen Netzwerk ist, kann er diese Adresse nicht öffnen:

http://192.168.1.113:8000/

Für einen entfernten Kunden brauchst du einen öffentlichen oder geteilten Zugriffsweg. Es gibt mehrere gängige Optionen.

Option 1: Temporärer Tunnel

Für eine schnelle Demo kannst du ein Tunneling-Tool wie Ngrok, Cloudflare Tunnel, Tailscale Funnel oder LocalTunnel verwenden.

Die Idee:

local port 8000 -> public HTTPS tunnel URL -> Kundenbrowser

Beispiel:

ngrok http 8000

Der Kunde erhält eine URL wie:

https://example-subdomain.ngrok-free.app

Das ist meistens der schnellste Weg, lokale Arbeit einem entfernten Kunden zu zeigen. Es eignet sich gut für kurze Demos, Design Reviews und schnelle Feedbackrunden.

Nutze es vorsichtig:

• Den Tunnel nur so lange offen lassen, wie er gebraucht wird.
• Keine echten Secrets oder Produktionsdaten freigeben.
• HTTPS-Tunnel-URLs bevorzugen.
• Basic Authentication aktivieren, wenn das Tool sie unterstützt.

Option 2: Privates Netzwerk oder VPN

Wenn du Remote-Zugriff ermöglichen willst, ohne die Website öffentlich zu machen, kannst du private Netzwerktools wie Tailscale, ZeroTier oder ein klassisches VPN verwenden.

Der Kunde tritt einem kontrollierten privaten Netzwerk bei und öffnet deinen Entwicklungsserver über diese private Route.

Das ist sicherer als ein öffentlicher Tunnel, erfordert aber, dass der Kunde etwas installiert oder konfiguriert.

Es funktioniert gut, wenn:

• der Kunde technisch genug ist,
• Zugriff auf genehmigte Personen beschränkt bleiben soll,
• das Projekt nicht öffentlich erreichbar sein darf,
• wiederholte private Reviews nötig sind.

Option 3: Staging Deployment

Für Kundenfreigaben, QA und realistische Tests ist Staging meistens die professionellste Option.

Statt deinen Laptop freizugeben, deployest du das Projekt in eine Staging-Umgebung:

Git repository -> staging server -> staging URL -> Kundenreview

Beispiel:

https://staging.example.com

Eine Staging-Umgebung ist besser, wenn:

• der Kunde wiederholt Zugriff braucht,
• mehrere Personen die Website prüfen,
• echtes HTTPS- und Domain-Verhalten benötigt wird,
• Deployment-Logs wichtig sind,
• eine stabile URL gebraucht wird,
• der Review-Prozess Tage oder Wochen dauern kann.

Für dieses Projekt wäre eine Managed Platform mit PostgreSQL und Umgebungsvariablen ein guter Staging-Zielort.

Option 4: Router Port Forwarding

Technisch kannst du deinen Computer direkt freigeben, indem du Router Port Forwarding einrichtest.

Das bedeutet meistens:

public router IP -> forwarded port -> local computer -> dev server

Für Kundendemos ist das in der Regel die unattraktivste Option.

Gründe, es zu vermeiden:

• Heim- oder Büro-IPs können sich ändern,
• HTTPS ist nicht automatisch vorhanden,
• Firewall-Regeln können fragil sein,
• dein Computer muss online bleiben,
• der Entwicklungsserver wird direkter exponiert,
• ein offener Port wird leicht vergessen.

Nutze stattdessen einen Tunnel, ein privates Netzwerk oder ein Staging Deployment.

Entscheidungstabelle

Die Faustregel ist einfach: LAN-Zugriff für deine eigenen Geräte, Tunnel für schnelle Remote-Demos und Staging für ernsthafte Kundenreviews.

Fazit

Damit eine lokale Website auf dem Smartphone geöffnet werden kann, müssen drei Dinge stimmen:

1. Die LAN-IP des Computers muss bekannt sein.
2. Der Entwicklungsserver muss auf 0.0.0.0 lauschen.
3. Das Framework muss den LAN-Host erlauben, falls es Hosts validiert.

In diesem Projekt lautet die funktionierende Smartphone-URL:

http://192.168.1.113:8000/

Das Setup wurde mit Framework-Tests, HTTP-Checks und einem TCP-Port-Check verifiziert. Django war das getestete Beispiel, aber die Methode gilt breit für lokale Webentwicklung.

Für Kunden außerhalb deines Netzwerks reicht die LAN-URL nicht aus. Nutze einen temporären Tunnel für schnelle Demos, ein privates Netzwerk für kontrollierten Zugriff oder ein Staging Deployment für professionelle Kundenreviews.

Evidence

• Lokale Netzwerk-IP wurde als 192.168.1.113 erkannt
• Der Entwicklungsserver wurde auf 0.0.0.0:8000 gestartet
• Das Django-Beispielprojekt erlaubte 127.0.0.1, localhost und 192.168.1.113
• Localhost-Anfrage gab 200 zurück
• LAN-IP-Anfrage gab 200 zurück
• TCP-Test zu 192.168.1.113:8000 war erfolgreich
• Testsuite bestanden: 13 Tests
• Optionen für Remote-Kundenzugriff wurden konzeptionell dokumentiert: Tunnel, VPN/privates Netzwerk, Staging Deployment und Production Deployment