Ephem-Cache: Edge-Caching Media-Heavy Localhost-Vorschauen mit Cloudflare Workers und Quick Tunnels

Einführung: Das Flaschenhalsproblem bei Remote-Frontend-Feedbackschleifen

Sie erstellen eine media-intensive Landingpage. Sie enthält hochauflösende WebP-Bilder, wiederholendes Hintergrundvideo und einige 3D-Assets. Alles fühlt sich sofort an auf Ihrem Laptop. Sie starten Ihren Dev-Server (Vite, Next.js oder ähnlich) und möchten, dass ein externer Designer, Produktmanager oder Kunde es live überprüft.

Der übliche Weg ist ein Tunnel. Tools wie ngrok, Localtunnel und Cloudflare Tunnel (cloudflared) öffnen einen lokalen Port auf einer öffentlichen URL. Das funktioniert gut für HTML- und API-Aufrufe. Bei großen Medien hat es jedoch eine strukturelle Schwäche: Jeder Byte jedes Assets verlässt Ihren Rechner über Ihre Upload-Leitung zu Hause oder im Büro, einmal pro Betrachter, pro Neuladen.

• Upload ist das Flaschenhals. Wenn drei Reviewer gleichzeitig den Link öffnen, konkurrieren sie um die gleiche Upstream-Verbindung. Ein 45 MB Video, das flüssig von Ihrer SSD streamt, stockt, wenn es drei Mal die Verbindung quert.
• Die Vorschau vermittelt ein falsches Bild von der Produktion. Stockende Videos und langsame Bilder lassen die Seite schlechter erscheinen, als die live geschaltete Seite sein wird. Sie erhalten Feedback zu Ihrer Upload-Geschwindigkeit statt zum Design.

Ephem-Cache ist der Name, den ich für ein kleines Muster verwende, das dieses Problem behebt. Ein Cloudflare Worker sitzt vor Ihrem Tunnel. Er ermöglicht es Cloudflare, die schweren, statischen Medien nach dem ersten Abruf zwischenzuspeichern, und leitet alles Dynamische (HTML, API-Aufrufe, WebSockets für Hot Reload) direkt an Ihren Rechner weiter.

Dieser Leitfaden behandelt die Architektur, einen funktionierenden Worker, die Einstellungen des dev-Servers, die sonst die Einrichtung stören, sowie die Grenzen und Sicherheitsaspekte, die Sie kennen sollten. Die Details wurden anhand der aktuellen Cloudflare-Dokumentation vom 14. Oktober 2026 geprüft. Ich habe absichtlich keine Benchmark-Zahlen aufgenommen, da die Ergebnisse von Ihrer Upload-Leitung, Ihren Dateien und den Standorten Ihrer Reviewer abhängen. Der Messabschnitt zeigt, wie Sie Ihre eigenen Werte ermitteln.

1. Die Architektur

[ Remote-Reviewer ]
        │
        ▼
[ Cloudflare Edge: Worker mit aktivierter Workers Caching ]
        │
        ├── Cache HIT ──► Aus Cloudflares Cache, Worker nicht ausgeführt
        │
        └── Cache MISS / dynamische Anfrage
                │
                ▼
        Worker leitet an Quick Tunnel URL weiter (trycloudflare.com)
                │
                ▼
        cloudflared ──► http://localhost:5173

Die Routing-Regeln sind einfach:

• Cachefähige Medien (Bilder, Videos, Fonts, 3D-Assets) geben einen Cache-Control-Header zurück, der Cloudflare erlaubt, sie zu speichern. Nach dem ersten Abruf können spätere Anfragen beantwortet werden, ohne dass Ihr Rechner involviert ist.
• Alles andere (HTML, API-Routen, HMR WebSockets, serverseitig gerenderte Seiten) wird mit no-store markiert und bei jeder Anfrage durchgeleitet.

Warum Workers Caching statt der Cache API

Frühere Versionen dieses Musters verwendeten caches.default (die Cache API) innerhalb des Workers. Die Cloudflare-Dokumentation beschreibt jetzt eine separate Funktion, Workers Caching, die besser für diesen Zweck geeignet ist:

	Cache API (caches.default)	Workers Caching
Scope	Lokal in einem Rechenzentrum. Inhalte werden nicht repliziert.	Hierarchisch: ein Cache in der Nähe des Besuchers plus ein übergeordnetes Tier, das Füllungen im Netzwerk zusammenfasst.
Funktioniert bei	Dokumentiert für benutzerdefinierte Domains (und Pages Functions).	Funktioniert auf workers.dev, Routen, benutzerdefinierten Domains und Service-Bindings.
Gleichzeitige Fehlversuche	Nicht zusammengefasst. Ein Burst kann Ihren Worker bei jeder Anfrage aufrufen.	Zusammengefasst: viele gleichzeitige Anfragen für einen Schlüssel rufen den Worker einmal pro Rechenzentrum auf.
Teilinhalte	cache.put schlägt bei einer 206-Antwort fehl, Sie müssen die vollständige Antwort selbst cachen.	Cloudflare entfernt Range, speichert die vollständige 200 und schneidet Bereiche selbst aus.
Löschen	cache.delete ist lokal in einem Rechenzentrum. Globales Löschen erfolgt über die Zonenlöschung.	ctx.cache.purge() im Worker, mit den in Abschnitt 5 genannten Optionen.

Diese Unterschiede sind hier relevant. Request-Collapsing verhindert, dass drei Reviewer drei Kopien eines 45 MB-Uploads beim ersten Laden auslösen. Native Range-Verarbeitung ist wichtig für vide-Wiedergabe. Das Fehlen einer benutzerdefinierten Domain vereinfacht die Einrichtung.

Workers Caching benötigt Wrangler 4.69.0 oder höher.

2. Einrichtung

Schritt 1: Dev-Server und Quick Tunnel starten

Starten Sie Ihren Dev-Server (Standardport von Vite ist 5173) und öffnen Sie in einem anderen Terminal einen Quick Tunnel:

cloudflared tunnel --url http://localhost:5173

cloudflared gibt eine zufällige https://<zufällige-wörter>.trycloudflare.com-URL aus. Für diesen Teil ist kein Cloudflare-Konto oder Domain erforderlich.

Kennen Sie die Grenzen der Quick Tunnels, bevor Sie darauf aufbauen. Cloudflare dokumentiert diese:

• Jeder Tunnel verarbeitet bis zu 200 gleichzeitige Anfragen. Darüber hinausgehende Anfragen erhalten einen HTTP 429.
• Server-Sent Events werden nicht unterstützt. WebSockets sind nicht in den unsupported features gelistet.
• Es gibt keine SLA- oder Uptime-Garantie, und die URL ändert sich bei jedem Neustart von cloudflared.
• Quick Tunnels werden nicht unterstützt, wenn eine config.yaml im .cloudflared-Verzeichnis vorhanden ist.

Die 200-Anfragen-Grenze ist ein weiterer Grund, zu cachen. Cache-Hits erreichen niemals den Tunnel.

Schritt 2: Fixieren Sie die Host-Prüfung Ihres Dev-Servers

Dieser Schritt ist leicht zu übersehen und die häufigste Ursache für eine leere Seite. Wenn der Worker eine Anfrage weiterleitet, ist der Host-Header der Tunnel-Hostname, nicht localhost. Moderne Dev-Server lehnen unbekannte Hosts ab.

Vite zeigt Blocked request. This host is not allowed.. Erlauben Sie die Tunnel-Domain in vite.config.ts:

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    // Ein führender Punkt erlaubt beliebige Subdomains von trycloudflare.com.
    allowedHosts: [".trycloudflare.com"],
  },
});

Vermeiden Sie allowedHosts: true. Das deaktiviert die Host-Prüfung vollständig, was den Dev-Server für DNS-Rebinding-Angriffe öffnet. Alternativ kann cloudflared den Header mit --http-host-header localhost:5173 umschreiben.

Next.js beschränkt seine dev-only Endpunkte, inklusive des HMR WebSocket bei /_next/webpack-hmr, auf Same-Origin-Anfragen. Fügen Sie den Hostnamen Ihrer Reviewer (den Hostname Ihres Workers) zu allowedDevOrigins in next.config.js hinzu. Außerdem sollten Sie auf Next.js 16.1.7 oder höher aktualisieren. CVE-2026-27977 beschreibt eine Schwachstelle in Versionen 16.0.1 bis 16.1.6, bei der next dev Origin: null WebSocket-Verbindungen akzeptieren konnte, obwohl allowedDevOrigins konfiguriert war. Da Sie einen Dev-Server öffentlich zugänglich machen, sollten Sie diese Sicherheitslücke schließen.

Schritt 3: Erstellen Sie das Worker-Projekt

npm create cloudflare@latest ephem-cache-worker
cd ephem-cache-worker

Cloudflare empfiehlt jetzt wrangler.jsonc statt wrangler.toml für neue Projekte. Verwenden Sie diese Konfiguration:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "ephem-cache-preview",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-14",
  "cache": { "enabled": true },
  "vars": {
    "LOCAL_ORIGIN": "https://replace-me.trycloudflare.com"
  }
}

cache.enabled sorgt dafür, dass Cloudflare den Cache prüft, bevor der Worker ausgeführt wird. Das compatibility_date ist das heutige Datum, wie die Beispiele von Cloudflare nahelegen.

Schritt 4: Der Worker

Ersetzen Sie src/index.ts durch den folgenden Code. Er wurde syntaktisch geprüft, testen Sie ihn jedoch vor der Verwendung in Ihrem Projekt.

export interface Env {
  LOCAL_ORIGIN: string; // z.B. "https://zufällige-wörter.trycloudflare.com"
  PURGE_TOKEN?: string; // optionales Geheimnis für die Lösch-Endpoint
}

// Schwer, selten wechselnde Assets, die während einer Review-Sitzung gecached werden können.
// JS und CSS sind absichtlich ausgeschlossen (siehe Abschnitt 4).
const MEDIA =
  /\.(png|jpe?g|gif|webp|avif|svg|ico|mp4|webm|mov|woff2?|ttf|otf|glb|gltf|ktx2|hdr)$/i;

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise3Response3e {
    const url = new URL(request.url);

    // Optional: Cache dieses Workers bei Bedarf leeren.
    if (url.pathname === "/__ephem/purge"  request.method === "POST") {
      if (!env.PURGE_TOKEN || request.headers.get("x-purge-token") !== env.PURGE_TOKEN) {
        return new Response("Forbidden", { status: 403, headers: { "Cache-Control": "no-store" } });
      }
      const result = await ctx.cache.purge({ purgeEverything: true });
      return new Response(result.success ? "Purged" : "Purge fehlgeschlagen", {
        status: result.success ? 200 : 500,
        headers: { "Cache-Control": "no-store" },
      });
    }

    const isUpgrade = request.headers.get("Upgrade")?.toLowerCase() === "websocket";
    const isCacheableMedia =
      request.method === "GET"  !isUpgrade  MEDIA.test(url.pathname);

    // Leiten Sie die Anfrage an den Tunnel um.
    const target = new URL(request.url);
    const origin = new URL(env.LOCAL_ORIGIN);
    target.protocol = origin.protocol;
    target.host = origin.host;

    const upstreamReq = new Request(target, request);

    if (isCacheableMedia) {
      // Fordert immer die vollständige Datei an, damit der Cache eine
      // vollständige 200-Antwort speichert, niemals eine 304 oder Teilantwort.
      upstreamReq.headers.delete("If-None-Match");
      upstreamReq.headers.delete("If-Modified-Since");
      upstreamReq.headers.delete("Range");
    }

    let upstream: Response;
    try {
      upstream = await fetch(upstreamReq);
    } catch {
      return new Response("Ephem-Cache: Verbindung zum lokalen Tunnel fehlgeschlagen.", {
        status: 502,
        headers: { "Content-Type": "text/plain", "Cache-Control": "no-store" },
      });
    }

    // WebSocket-Upgrades (HMR) werden direkt durchgeleitet.
    if (isUpgrade || upstream.status === 101) return upstream;

    const res = new Response(upstream.body, upstream);
    if (isCacheableMedia  upstream.status === 200) {
      res.headers.set("Cache-Control", "public, max-age=3600");
    } else {
      res.headers.set("Cache-Control", "no-store");
    }
    return res;
  },
} erfüllt die ExportedHandler3cEnv3e-Schnittstelle;

Einige Designentscheidungen sind hier erklärungsbedürftig.

Alle nicht-Medien-Antworten sind explizit no-store. Mit aktiviertem Workers Caching wird eine 200-Antwort ohne Cache-Control-Header nach RFC 9111 heuristisch für 2 Stunden zwischengespeichert. Ohne explizites no-store könnten HTML- und API-Antworten veraltet aus dem Cache kommen.

WebSocket-Upgrades werden unverändert zurückgegeben. Cloudflare dokumentiert, dass WebSocket-Upgrade-Anfragen Workers Caching umgehen und immer den Worker aufrufen. Die Upgrade-Antwort unverändert zurückzugeben, ermöglicht Hot Reload.

Bedingungs- und Range-Header werden bei Medien entfernt. Dev-Server antworten auf bedingte Anfragen mit 304, was keinen Body zum Zwischenspeichern hat. Cloudflare entfernt auch Range, bevor der Worker aufgerufen wird, und liefert den gewünschten Ausschnitt aus der vollständigen zwischengespeicherten Antwort. Der Worker muss Byte-Ranges also nicht selbst implementieren. Wenn ein Worker eine eigene 206 zurückgibt, speichert Cloudflare sie nicht.

Der Worker bleibt klein. Er leitet nur Anfragen weiter und setzt Header. Sowohl im kostenlosen als auch im kostenpflichtigen Plan stehen hierfür Subrequests und CPU-Zeit zur Verfügung.

Schritt 5: Mit der aktuellen Tunnel-URL bereitstellen

Da sich die Tunnel-URL bei jeder Sitzung ändert, übergeben Sie sie beim Deployment, anstatt die Datei zu bearbeiten:

npx wrangler secret put PURGE_TOKEN        # optional
npx wrangler deploy --var LOCAL_ORIGIN:https://ihr-aktueller-tunnel.trycloudflare.com

wrangler deploy akzeptiert --var key:wert als Alternative zum vars-Block in Ihrer Konfiguration. Der Wert des Flags hat Vorrang, wenn beide gesetzt sind. Ein praktischer Nebeneffekt: Standardmäßig ist die Worker-Version Teil des Cache-Schlüssels, sodass jeder Deployment eine kalte Cache-Startphase hat. Eine neue Review-Sitzung erbt keine Assets von einer alten.

Fassen Sie beide Befehle in ein Paket-Skript, sodass eine neue Sitzung mit einem Befehl gestartet wird.

3. Das Cache-Verhalten

Das Wissen um den Cache-Schlüssel und die Überspring-Regeln spart Stunden an Verwirrung:

• Der Schlüssel ist der Einstiegspunkt, der Pfad plus Query-String und (standardmäßig) die Worker-Version. Der Hostname ist nicht Teil des Schlüssels. ?a=1&b=2 und ?b=2&a=1 sind unterschiedliche Schlüssel. Request-Header wie User-Agent und Cookie partitionieren den Cache nur, wenn Sie Vary setzen.
• Nur GET und HEAD werden gecacht. Andere Methoden erreichen immer Ihren Worker.
• Automatisches Überspringen: Eine Antwort mit Set-Cookie, eine Anfrage mit Authorization-Header (es sei denn, die Antwort ist explizit public), oder eine Antwort mit private oder no-store wird nicht normal gecacht.
• Cf-Cache-Status zeigt, was passiert ist. MISS bedeutet, Ihr Worker wurde ausgeführt und die Antwort gespeichert. HIT bedeutet, Cloudflare hat ohne Worker-Aktion geantwortet. BYPASS bedeutet, das Caching wurde übersprungen.
• Die erste Ansicht ist nicht schneller. Eine kalte Anfrage für ein großes Video muss den vollen Weg von Ihrem Rechner zurücklegen. Workers Caching speichert die volle Antwort, daher zahlt der erste Besucher für die gesamte Datei. Wärmen Sie den Cache vor der Review auf, indem Sie die Seite einmal öffnen.
• Größenlimits: Die Limits für CDN-Cache gelten: 512 MB pro Objekt bei Free, Pro und Business, 5 GB bei Enterprise. Größere Assets werden nicht gecacht.

4. Invalidierung: Was cachen, und wie lange

Lokale Dateien ändern sich ständig, daher ist das Risiko veralteter Assets groß. Der Ansatz:

1. Cache Medien, nicht Code. Quell-Dateien im Dev-Server behalten stabile Namen, während sich deren Inhalte ändern. Vite behandelt diese gut, indem es Source-Module-Anfragen bedingt (304) macht, während vorbundelte Abhängigkeiten im Browser max-age=31536000,immutable haben. .js und .css hinter einem Edge-Cache von einer Stunde zu verstecken, würde hauptsächlich Verwirrung stiften, daher lassen wir sie im Regex weg.
2. Kurzzeit-TTL verwenden. Eine Stunde ist ein Anfang. Reduzieren Sie max-age, wenn Designer Bilder während der Review austauschen.
3. Auf Wunsch löschen. Der optionale Endpunkt im Worker ruft ctx.cache.purge({ purgeEverything: true }) auf: curl -X POST https://<Ihr-Worker-Host>/__ephem/purge -H "x-purge-token: $PURGE_TOKEN"

purge akzeptiert auch tags und pathPrefixes. Workers Caching ist privat für Ihren Worker, und Zone-weit Löschungen im Dashboard oder via API betreffen es nicht. Purges unterliegen den Limits des Free-Tiers. 4. Neu bereitstellen, um zu resetten. Da die Worker-Version Teil des Schlüssels ist, ist wrangler deploy selbst eine vollständige Invalidierung. 5. Vorschau eines Produktions-Builds für finale Reviews. Wenn Sie vite build ausführen und die Ausgabe mit vite preview bereitstellen, tragen Asset-Dateinamen Content-Hashes, sodass geänderte Dateien automatisch neue URLs erhalten. Dann können Sie js|css|mjs zum Regex hinzufügen.

5. Das Ergebnis selbst messen

Anstatt Zahlen zu zitieren, die von einer spezifischen Konfiguration abhängen, messen Sie Ihre eigenen:

# 1. Erste Anfrage: erwarten Sie Cf-Cache-Status: MISS
curl -sI https://<worker-host>/media/hero.mp4 | grep -i cf-cache-status

# 2. Zweite Anfrage: erwarten Sie HIT
curl -sI https://<worker-host>/media/hero.mp4 | grep -i cf-cache-status

# 3. Vergleichen Sie die Download-Zeit mit der Tunnel-URL direkt
curl -s -o /dev/null -w "worker: %{time_total}s  %{size_download} bytes\n" https://<worker-host>/media/hero.mp4
curl -s -o /dev/null -w "tunnel: %{time_total}s  %{size_download} bytes\n" https://<your-tunnel>.trycloudflare.com/media/hero.mp4

Für ein realistisches Bild führen Sie den Vergleich auf einem Rechner in der Region Ihrer Reviewer durch, oder bitten Sie einen Reviewer, die Network-Tab im DevTools zu öffnen und eine HAR-Datei zu teilen. Beobachten Sie Ihre Upload-Leitung, während zwei oder drei Personen die Seite laden. Die zwischengespeicherte Version sollte nach dem ersten Abruf kaum noch Traffic verursachen.

6. Grenzen, Bedingungen und Kosten

• Workers Free-Plan: 100.000 Anfragen pro Tag, 10 ms CPU pro Anfrage und 50 Subrequests pro Anfrage. Ein Streaming-Proxy verbraucht wenig CPU. Mit aktiviertem Caching werden jedoch alle Anfragen an den Worker, inklusive Cache-Hits, berechnet.
• Cloudflares Bedingungen für große Dateien: Cloudflare erklärt, dass sich die Bedingungen geändert haben, sodass Videos und andere große Dateien über das CDN bereitgestellt werden können, wenn sie bei Cloudflare-Services wie Stream, Images oder R2 gehostet werden. Videos und große Dateien außerhalb von Cloudflare bleiben auf dem CDN eingeschränkt. Ein Tunnel zu Ihrem Laptop ist eine externe Quelle. Prüfen Sie die aktuellen service-spezifischen Bedingungen, bevor Sie große Videos durch dieses Setup routen, und beschränken Sie es auf kurze Review-Sitzungen. Für permanente Medien hosten Sie die Dateien in R2.
• Kein SLA. Quick Tunnels sind ein Test-Tool. Für alles, worauf Sie angewiesen sind, verwenden Sie einen benannten Cloudflare Tunnel.

7. Sicherheitsüberlegungen

Dieses Muster setzt eine noch nicht veröffentlichte Seite ins öffentliche Internet, daher sind einige Punkte vorsichtig zu behandeln.

• Gecachte Treffer umgehen Ihren Worker. Jede Prüfung im Worker (Token, Passwort) läuft nur bei Cache-Miss. Sobald eine Mediendatei gecacht ist, kann jeder, der die URL kennt, sie abrufen. Verwenden Sie dieses Muster nicht für vertrauliche oder embargo-geschützte Assets.
• Die Tunnel-URL ist ebenfalls öffentlich. Wer die zufällige trycloudflare.com-Adresse kennt, kann direkt auf Ihren Dev-Server zugreifen, ohne den Worker zu passieren. Cloudflare beschreibt eine --allowed-mail-Option für Quick Tunnels, die Besucher zur Eingabe eines Einmal-PINs zwingt. Dieses Gate würde auch die Anfragen des Workers herausfordern, daher ist es nicht kompatibel mit dieser Architektur. Eine praktische Alternative ist, dass der Worker einen geheimen Header zu seinen Upstream-Anfragen hinzufügt und Anfragen ohne diesen ablehnt, z.B. in einem kleinen Vite-Plugin: // vite.config.ts (Auszug) const guard = { name: "ephem-guard", configureServer(server) { server.middlewares.use((req, res, next) => { if (req.headers["x-ephem-secret"] !== process.env.EPHEM_SECRET) { res.statusCode = 403; return res.end("Forbidden"); } next(); }); }, };

Dies betrifft nur plain HTTP-Anfragen. Halten Sie das Geheimnis außerhalb Ihres Repositories.

• Lecken Sie keine Geheimnisse in Bundles. Alles im client-seitigen Code, inklusive Umgebungsvariablen, die vom Framework gebündelt werden, landet in Dateien, die Besucher lesen können. Halten Sie Datenbank-URLs und private API-Schlüssel serverseitig.
• Halten Sie Host-Whitelist eng. Verwenden Sie .trycloudflare.com anstelle, Host-Prüfungen zu deaktivieren.
• Nach der Review alles abbauen. Stoppen Sie cloudflared, löschen Sie den Worker (npx wrangler delete) oder löschen Sie zumindest den Cache und rotieren Sie PURGE_TOKEN, falls Sie ihn geteilt haben.

Fazit

Ein lokaler Tunnel ist die schnellste Methode, unfertige Arbeiten zu zeigen, aber er macht Ihre Upload-Verbindung zum Liefernetzwerk für jedes Bild und Video. Ein kleiner Cloudflare Worker mit Workers Caching vor dem Tunnel verschiebt den wiederholten Datenverkehr für große Medien auf Cloudflares Cache und lässt Ihren Rechner nur die erste Anfrage pro Datei sowie den dynamischen Traffic bedienen.

Das Muster hat echte Einschränkungen: Die erste Ansicht ist immer noch langsam, gecachte Dateien sind effektiv öffentlich, Quick Tunnels haben keine Uptime-Garantie, und Cloudflares Bedingungen beschränken große extern gehostete Dateien auf seinem CDN. Innerhalb dieser Grenzen macht es Remote-Reviews von medienintensiven Seiten deutlich weniger abhängig von Ihrer Upload-Geschwindigkeit. Beginnen Sie mit einer kurzen Session, prüfen Sie Cf-Cache-Status bei einigen Assets und messen Sie den Unterschied bei Ihren eigenen Dateien.

Quellen

• Cloudflare Docs: Quick Tunnels
• Cloudflare Docs: Workers Cache Übersicht
• Cloudflare Docs: Workers Cache Konfiguration
• Cloudflare Docs: Workers Cache Schlüssel
• Cloudflare Docs: Cache löschen und invalidieren
• Cloudflare Docs: Begrenzungen für Workers Cache
• Cloudflare Docs: Cache API
• Cloudflare Docs: Wie der Cache funktioniert
• Cloudflare Docs: Limits für Workers
• Cloudflare Docs: Wrangler-Befehle
• Cloudflare Docs: Wrangler-Konfiguration
• Cloudflare Blog: Abschied von Abschnitt 2.8 und Begrüßung der neuen Cloudflare-Nutzungsbedingungen
• Vite: Dependency Pre-Bundling
• Vite: Warum Vite
• Quasar: Öffnen eines Dev-Servers für die Öffentlichkeit (allowedHosts)
• Parallel Works: Tunneling-Framework für Dev-Server (Next.js allowedDevOrigins)
• CVE-2026-27977 (Next.js dev HMR WebSocket origin check)