Einschränkungen von Headless Chrome: Häufige Probleme in der Produktion

Headless Chrome ist einfach zu starten, aber schwer im Produktivbetrieb zu betreiben. Lokal funktioniert alles, aber im Container stürzt der Browser plötzlich ab, in der CI-Umgebung laufen die Tests mal so, mal so, und der Dienst, der fremde Links rendert, wird zu einem Sicherheitsrisiko. Dieser Artikel sammelt typische Probleme und Lösungsansätze: von /dev/shm in Docker bis zum Schutz vor SSRF und dem Tracing von Abstürzen in Playwright. Wie alles im Inneren funktioniert, erfahren Sie im Artikel „Wie Headless Chrome funktioniert“.

⚡ Kurz gesagt: Wo Headless Chrome am häufigsten kaputtgeht

Bei der Arbeit mit Headless Chrome ist es wichtig, nicht nur die Browsereinstellungen, sondern auch die Besonderheiten der Umgebung zu berücksichtigen, in der er ausgeführt wird. Ich würde zuerst die Speichernutzung, den Lebenszyklus von Prozessen und die Containerparameter überprüfen. Genau diese Aspekte sollten zuerst diagnostiziert werden, wenn der Browser instabil läuft oder sich in der Produktion anders verhält als lokal.

📚 Inhalt des Artikels

• Was genau schränkt der Headless-Modus ein
• Speicher, Prozesse und Ressourcen
• Timeouts und instabile Tests
• Docker und CI: /dev/shm und Sandbox
• Schriftarten und Rendering-Abweichungen
• Komplexe Seiten, Authentifizierung und Sitzungen
• Wenn man Sie nicht reinlässt: legale Optionen
• Sicherheit: SSRF beim Rendern fremder URLs
• Tracing und Debugging: Playwright Trace Viewer
• Checkliste für die Produktion
• Häufig gestellte Fragen (FAQ)
• Schlussfolgerungen
• Quellen

🧠 Was genau schränkt der Headless-Modus ein

Heute ist der neue Headless-Modus derselbe Chrome ohne sichtbare Fenster, daher hängen die meisten „Einschränkungen“ nicht mit dem Browser selbst zusammen, sondern mit der Umgebung, in der er ausgeführt wird: Container, Speicher, Benutzerrechte, Netzwerk. Eine gesonderte Geschichte ist chrome-headless-shell: Dies ist eine leichtere Version mit weniger Abhängigkeiten und laut Entwicklerbeschreibung weniger „authentisch“ als ein vollwertiger Chrome. Der Unterschied zwischen den Modi wird ausführlich im Artikel „Wie Headless Chrome funktioniert“ behandelt. Unten betrachten wir, was in der Praxis kaputtgeht. In jedem Abschnitt ist das Schema dasselbe: Symptom, Ursache, Lösungsoptionen.

💾 Speicher, Prozesse und Ressourcen

Symptom: Mit der Zeit verbraucht der Dienst immer mehr Speicher, Chrome-Prozesse sammeln sich im System an.

Ursachen:

• Zombie-Prozesse. Die Playwright-Dokumentation empfiehlt, den Container mit dem Flag --init zu starten, um das besondere Verhalten von Prozessen mit PID=1 zu vermeiden, die häufige Ursache für Zombie-Prozesse sind.
• Nicht geschlossene Browser. Zu den häufigsten Fehlerursachen in Docker gehören Browser-Leaks: Jeder Start von launch() erstellt einen vollwertigen Chrome, der geschlossen werden muss.

Was tun:

• Schließen Sie den Browser im finally-Block, auch wenn die Aufgabe fehlgeschlagen ist.
• Behalten Sie einen langlebigen Browser und erstellen Sie für jede Aufgabe einen separaten Kontext, anstatt jedes Mal einen neuen Browser zu starten.
• Begrenzen Sie die Parallelität und starten Sie den Browser periodisch neu (z. B. nach einer bestimmten Anzahl von Aufgaben). Wählen Sie die konkreten Grenzen durch Messungen unter Ihrer Last.
• Legen Sie Speicherlimits für den Container fest und überwachen Sie diese in der Überwachung.

⏱️ Timeouts und instabile Tests

Symptom: Tests laufen lokal und fallen in der CI durch, der Screenshot wird vor dem Erscheinen des Inhalts gemacht.

Ursache: Der Code verlässt sich auf die Zeit und nicht auf den Zustand der Seite. In der CI ist die Ressourcenausstattung geringer, und die Seite lädt langsamer.

🐳 Docker und CI: /dev/shm und Sandbox

Das Problem mit /dev/shm

Symptom: Chrome läuft auf Ihrem Computer stabil, stürzt aber im Container zufällig ab oder meldet, dass es nicht verfügbar ist. Eine Analyse beschreibt genau solche "zufälligen" Abstürze nur in Docker.

Ursache: Laut Puppeteer-Dokumentation (archivierte Version) weist Docker standardmäßig nur 64 MB Shared Memory /dev/shm einem Container zu, und Chrome nutzt diese intensiv.

So überprüfen Sie:

docker exec <container> df -h /dev/shm

Wenn die Größe 64 MB beträgt und während des Absturzes fast alles belegt ist, ist die Diagnose bestätigt.

Lösungsvarianten

Beispiel für Docker Compose:

services:
  renderer:
    image: my-renderer
    init: true
    shm_size: "2gb"
    mem_limit: 4g

Beispiel für Kubernetes:

spec:
  containers:
    - name: renderer
      image: my-renderer
      resources:
        limits:
          memory: "4Gi"
      volumeMounts:
        - name: dshm
          mountPath: /dev/shm
  volumes:
    - name: dshm
      emptyDir:
        medium: Memory
        sizeLimit: 2Gi

Kubernetes unterstützt solche speicherbasierten Volumes, und ihre Standardgröße hängt vom Speicher des Knotens ab, daher ist es ratsam, sizeLimit explizit anzugeben. Daten in solchen Volumes verbrauchen den Speicher des Pods, daher muss die Größe in das Container-Limit passen.

Der Wert von 2 GB in den Beispielen ist eine Schätzung. Wählen Sie Ihren eigenen basierend auf Messungen: Er hängt von der Anzahl der Tabs und der Komplexität der Seiten ab.

Sandbox und Benutzer

Der häufige Rat "fügen Sie --no-sandbox hinzu" löst das Startproblem, entfernt aber einen wichtigen Schutz. Es wird beschrieben, dass das Playwright-Image standardmäßig als Root läuft, was die Chromium-Sandbox deaktiviert, die mit Root nicht verfügbar ist. Für nicht vertrauenswürdige Websites wird ein separater Benutzer zusammen mit einem seccomp-Profil empfohlen. Offizielles Startbeispiel für Java:

docker run -it --rm --init --ipc=host --user pwuser \
  --security-opt seccomp=seccomp_profile.json \
  mcr.microsoft.com/playwright/java:<version>-noble /bin/bash

Die Dokumentation besagt auch, dass ein seccomp_profile.json-Profil zum Starten von Chromium mit Sandbox erforderlich ist, und dieses Image wird nicht für den Besuch nicht vertrauenswürdiger Websites empfohlen. Ersetzen Sie die Versionsnummer des Images durch die aktuelle aus der Dokumentation.

🔤 Schriftarten und Rendering-Unterschiede

Symptom: Der Text auf dem Server sieht anders aus als lokal, in PDFs erscheinen "Quadrate" anstelle von Zeichen.

Ursache: Das minimale Image enthält nicht die erforderlichen Schriftarten. Im Dockerfile aus der Puppeteer-Dokumentation werden Schriftarten für die wichtigsten Zeichensätze (Chinesisch, Japanisch, Arabisch, Hebräisch, Thai) separat installiert.

Was zu tun ist:

• Installieren Sie die Schriftarten für die von Ihnen benötigten Sprachen (für einen mehrsprachigen Blog sind dies mindestens Kyrillisch, Lateinisch und bei Bedarf CJK).
• Geben Sie die Fenstergröße explizit an (z. B. --window-size in der CLI), damit das Ergebnis nicht von den Standardwerten abhängt.
• Fixieren Sie das Image und die Chrome-Version. Unterschiedliche Versionen können unterschiedliche Ergebnisse liefern.
• Überprüfen Sie für PDF die Druckstile (@media print): Sie können sich von der Bildschirmdarstellung unterscheiden.

🧩 Komplexe Seiten, Authentifizierung und Sitzungen

• iframe, Shadow DOM, Pop-ups, Dateidownloads. Verschiedene Bibliotheken behandeln diese unterschiedlich. Bevor Sie ein Tool auswählen, prüfen Sie auf Ihren Seiten, ob die Arbeit mit solchen Elementen in der Dokumentation von Puppeteer, Playwright oder Selenium bequem ist.
• Authentifizierung. Melden Sie sich nicht in jeder Aufgabe neu an. Playwright ermöglicht das Speichern des Sitzungszustands und dessen Wiederverwendung. Speichern Sie solche Dateien als Geheimnisse: sie enthalten Cookies.
• Isolation. Ein separater Kontext pro Aufgabe verhindert, dass Cookies und Speicher einer Aufgabe in eine andere gelangen.
• Geheimnisse in Protokollen und Screenshots. Geben Sie keine Token in die Konsole aus und speichern Sie keine Screenshots von Seiten mit privaten Daten, wenn es nicht notwendig ist.

🚧 Wenn Sie nicht reingelassen werden: legale Optionen

Websites haben das Recht, automatisierten Zugriff zu beschränken. Wenn Ihr Headless-Client Ablehnungen erhält, ist das ein Grund, zu verhandeln, anstatt sich zu tarnen. Was legal funktioniert:

• Nutzen Sie die offizielle API, falls vorhanden.
• Bitten Sie den Website-Betreiber, Ihren Client zur Whitelist hinzuzufügen.
• Identifizieren Sie den Client ehrlich: ein verständlicher User-Agent mit Kontaktdaten.
• Halten Sie sich an Ratenbegrenzungen und Nutzungsbedingungen der Website.
• Testen Sie auf Ihren eigenen Umgebungen (Staging), nicht auf fremden Produktionssystemen.

Die Datei robots.txt ist kein Autorisierungsmechanismus, aber respektieren Sie sie: mehr über robots.txt. Und wie solcher Traffic für den Website-Betreiber aussieht, erfahren Sie im Artikel "Verdächtiger Traffic in GA4".

🛡️ Sicherheit: SSRF beim Rendern fremder URLs

Wenn Ihr Dienst Adressen in einem Headless Chrome öffnet, die Benutzer eingeben (Screenshots, PDFs, Link-Vorschauen), schaffen Sie einen klassischen SSRF-Vektor (Server-Side Request Forgery). OWASP beschreibt SSRF als Missbrauch einer Anwendung, um auf das interne oder externe Netzwerk oder die Maschine selbst zuzugreifen. In unserem Fall übernimmt Ihr Browser die Rolle der "Anwendung", und die Anfragen kommen aus Ihrem Netzwerk.

Warum ein Browser riskanter ist als ein herkömmlicher HTTP-Client. Dies ist meine Schlussfolgerung aus der Funktionsweise von Chrome (OWASP spricht nicht über Browser): Der Browser folgt selbst Weiterleitungen, lädt Unterressourcen und führt Skripte einer fremden Seite aus, die ebenfalls auf Adressen in Ihrem Netzwerk zugreifen können. Daher reicht die Überprüfung der eingegebenen URL allein nicht aus.

OWASP unterscheidet zwei Fälle. Im ersten Fall sollte die Anwendung nur auf bekannte vertrauenswürdige Adressen zugreifen, und hier passt eine Whitelist. Im zweiten Fall soll sie auf beliebige externe Adressen zugreifen, und eine Whitelist ist nicht verfügbar. Ein Dienst zum Rendern fremder URLs gehört meist zum zweiten Fall.

Schutzvarianten

Minimale Liste, die in Variante B blockiert wird

Gemäß der OWASP-Tabelle:

Beispiel für Adressprüfung in Java (Skelett)

static boolean isPublic(InetAddress a) {
    if (a.isAnyLocalAddress() || a.isLoopbackAddress() || a.isLinkLocalAddress()
            || a.isSiteLocalAddress() || a.isMulticastAddress()) {
        return false;
    }
    byte[] b = a.getAddress();
    if (b.length == 16 && (b[0] & 0xFE) == 0xFC) return false;               // fc00::/7
    if (b.length == 4 && (b[0] & 0xFF) == 100 && (b[1] & 0xC0) == 64) return false; // 100.64.0.0/10
    return true;
}

// Lösen Sie alle Adressen des Hosts auf und lehnen Sie ab, wenn auch nur eine nicht öffentlich ist
for (InetAddress a : InetAddress.getAllByName(host)) {
    if (!isPublic(a)) throw new SecurityException("Verbotene Adresse: " + a);
}

Dies ist nur ein Anfang, kein vollständiger Schutz. OWASP warnt, dass die Überprüfung von DNS-Antworten allein nicht vor DNS-Rebinding schützt: Zwischen der Überprüfung und der Verbindung kann sich die Adresse ändern. Der Client muss sich nur mit der überprüften Adresse verbinden, und eine wiederholte, nicht abgeschlossene DNS-Abfrage zwischen Überprüfung und Verbindung kann den Schutz umgehen. Deshalb ist Netzwerktrennung (Variante C) die obligatorische zweite Ebene: Sie funktioniert unabhängig davon, was DNS zurückgibt.

Zusätzliche Maßnahmen für Headless-Browser

• Erlauben Sie nur http und https. OWASP erinnert daran, dass SSRF nicht auf HTTP beschränkt ist, und nennt Schemas wie file:// und gopher://.
• Fangen Sie Anfragen im Browser selbst ab. In Playwright gibt es dafür page.route() und context.route(): Sie können Anfragen an verbotene Hosts ablehnen, einschließlich Unterressourcen und Weiterleitungen. Das Abfangen sieht jedoch die URL, nicht die tatsächliche IP-Adresse, daher ergänzt es die Netzwerktrennung, ersetzt sie aber nicht. (Überprüfen Sie die API in der Dokumentation Ihrer Version.)
• Öffnen Sie den Debugging-Port nicht nach außen (--remote-debugging-port): Er gibt die vollständige Kontrolle über den Browser.
• Isolieren Sie den Prozess. Ein separater Container ohne Geheimnisse und ohne Zugriff auf interne Datenbanken, ein nicht privilegierter Benutzer, begrenzte Zeit und Größe der Aufgabe.
• Deaktivieren Sie die Sandbox nicht für Seiten, die Sie nicht kontrollieren.

🔧 Tracing und Debugging: Playwright Trace Viewer

Das Schwierigste an instabilen Abstürzen ist, dass sie nicht reproduzierbar sind. Der Trace Viewer von Playwright löst dieses Problem, indem er aufzeichnet, was passiert ist. Der Playwright Trace Viewer ist ein grafisches Werkzeug, mit dem Sie aufgezeichnete Traces nach Abschluss des Skripts untersuchen können. Er zeigt eine Zeitleiste von Aktionen mit Screenshots, DOM-Schnappschüssen für jede Aktion, Quellcode, Aktionsprotokoll, Fehler, Konsole und Netzwerkanfragen.

Optionen für die Tracing-Aufzeichnung

Option C: Tracing in einem eigenen Dienst (Node.js)

const context = await browser.newContext();
await context.tracing.start({ screenshots: true, snapshots: true, sources: true });
const page = await context.newPage();
try {
  await page.goto(url);
  // ...Arbeit mit der Seite
  await context.tracing.stop();                       // Erfolg: Datei nicht speichern
} catch (e) {
  await context.tracing.stop({ path: `trace-${jobId}.zip` });  // Fehler: speichern
  throw e;
} finally {
  await context.close();
}

Dasselbe in Java

BrowserContext context = browser.newContext();
context.tracing().start(new Tracing.StartOptions()
    .setScreenshots(true).setSnapshots(true).setSources(true));
Page page = context.newPage();
try {
    page.navigate(url);
    // ...Arbeit mit der Seite
    context.tracing().stop();
} catch (RuntimeException e) {
    context.tracing().stop(new Tracing.StopOptions()
        .setPath(Paths.get("trace-" + jobId + ".zip")));
    throw e;
} finally {
    context.close();
}

Die Beispiele sind vereinfacht und wurden nicht kompiliert. Prüfen Sie das Verhalten von stop() ohne Pfad (Aufzeichnung wird verworfen) und die genauen Klassennamen in der Dokumentation Ihrer Playwright-Version.

Wie man Tracing anzeigt

• Lokal: npx playwright show-trace trace.zip.
• Im Browser: trace.playwright.dev — eine statisch gehostete Version des Viewers. Sie können auch eine URL eines Tracings übergeben, das in einem zugänglichen Speicher hochgeladen wurde.
• Typische Analysereihenfolge: Öffnen Sie das Trace eines Absturzes, finden Sie die Aktion, bei der er abgestürzt ist, vergleichen Sie die DOM-Schnappschüsse davor und danach, und sehen Sie sich dann die Konsole und das Netzwerk an.

Sicherheit von Tracings

Tracings enthalten Seiten- und Netzwerkaktivitätsschnappschüsse und können daher persönliche Daten, Tokens und Cookies enthalten (dies ist meine Warnung, sie ist nicht direkt in der Dokumentation aufgeführt). Veröffentlichen Sie sie nicht öffentlich, begrenzen Sie die Speicherfrist und den Zugriff, und maskieren Sie sensible Felder für Seiten mit privaten Daten oder zeichnen Sie gar kein Tracing auf.

Wenn Sie Playwright nicht verwenden

• Für Chrome gibt es Debugging im Headless-Modus: starten Sie den Browser mit einem Remote-Debugging-Port und verbinden Sie sich mit DevTools. Halten Sie den Port für das externe Netzwerk geschlossen.
• Das Minimum für jedes Werkzeug: ein Screenshot und ein Protokoll der Konsole und des Netzwerks bei einem Fehler, eine Aufgaben-ID in jedem Logeintrag.
• Puppeteer hat ein eigenes Chrome-Tracing, aber es ist für die Leistungsanalyse gedacht und nicht für die schrittweise Reproduktion von Aktionen wie bei Playwright. Details finden Sie in der Dokumentation.

✅ Checkliste für die Produktion

• ☐ Der Container wird mit --init (oder init: true in Compose) gestartet.
• ☐ /dev/shm ist erhöht (--shm-size, --ipc=host oder speicherbasierter emptyDir) und mit dem Speicherlimit abgestimmt.
• ☐ Der Browser läuft als Nicht-Root-Benutzer, die Sandbox ist nicht deaktiviert.
• ☐ Der Browser wird in finally geschlossen, die Parallelität ist begrenzt, es gibt einen Neustart nach N Aufgaben.
• ☐ Schriftarten für die benötigten Sprachen sind installiert, die Fenstergröße ist explizit angegeben.
• ☐ Versionen von Chrome und der Bibliothek sind fixiert.
• ☐ Wartezeiten erfolgen basierend auf dem Seitenstatus, nicht auf sleep.
• ☐ Für fremde URLs: Allowlist oder Denylist, IP-Prüfung nach DNS, nur http/https, Weiterleitungen auf interne Adressen verboten.
• ☐ Der Browser läuft im Netzwerk ohne Zugriff auf interne Dienste, Cloud-Metadaten sind geschützt (IMDSv2).
• ☐ Der Debugging-Port ist nicht nach außen geöffnet.
• ☐ Tracing oder Screenshot wird bei einem Absturz aufgezeichnet, die Speicherfrist wird von der Datenschutzrichtlinie gesteuert.
• ☐ Metriken sind vorhanden: Rendering-Zeit, Fehler, Neustarts.

❓ Häufig gestellte Fragen (FAQ)

Warum stürzt Headless Chrome in Docker ab?

Die häufigsten Gründe: geringe Größe von /dev/shm (standardmäßig 64 MB), Ausführung als Root, was die Sandbox deaktiviert, Speichermangel und Zombie-Prozesse. Beginnen Sie mit df -h /dev/shm im Container und den Flags --init und --shm-size.

Warum läuft der Test lokal, stürzt aber in CI ab?

Normalerweise aufgrund von Zeitabhängigkeiten und Umgebungsunterschieden: weniger Ressourcen, andere Schriftarten, langsameres Netzwerk. Ersetzen Sie sleep durch das Warten auf einen Zustand und aktivieren Sie trace: 'on-first-retry', um zu sehen, was genau passiert ist.

Wie viel Speicher wird benötigt?

Es gibt keine universelle Zahl: Sie hängt von den Seiten und der Anzahl der Tabs ab. Messen Sie den Verbrauch bei Ihren Aufgaben, fügen Sie einen Puffer hinzu und legen Sie ein Containerlimit fest. Der Speicher in /dev/shm ist in diesem Limit enthalten.

Ist es sicher, von Benutzern eingegebene URLs zu rendern?

Nur unter Schutz vor SSRF: Adressprüfung, Netzwerkk isolation, Schutz von Cloud-Metadaten und Beschränkung von Schemas. Ohne dies wird der Browser in Ihrem Netzwerk zu einem Eintrittspunkt für einen Angreifer.

Kann man --no-sandbox verwenden?

Technisch ja, aber es verringert die Sicherheit, daher ist es besser, den Browser als Nicht-Root-Benutzer mit einem entsprechenden seccomp-Profil auszuführen. Für Seiten, die Sie nicht kontrollieren, sollten Sie die Sandbox nicht deaktivieren.

🏁 Schlussfolgerungen

• 🔹 Die meisten Probleme mit Headless Chrome hängen mit der Umgebung zusammen und nicht mit dem Browser selbst: Container, Speicher, Rechte, Netzwerk.
• 🔹 Für /dev/shm gibt es mehrere Optionen: --shm-size, --ipc=host, speicherbasierter emptyDir, und --disable-dev-shm-usage sollte als letztes Mittel verwendet werden.
• 🔹 Es ist besser, die Sandbox zu konfigurieren (Nicht-Root und seccomp), als sie zu deaktivieren.
• 🔹 Wenn Sie fremde URLs rendern, wird SSRF zum Hauptrisiko, und eine einzelne Prüfung der eingegebenen Adresse schließt es nicht aus: Netzwerkk isolation ist erforderlich.
• 🔹 Playwright Trace Viewer ermöglicht es Ihnen, Abstürze nachträglich zu analysieren: zeichnen Sie Tracing bei Abstürzen auf und speichern Sie sie als sensible Daten.
• 🔹 Fixieren Sie Versionen, messen Sie den Verbrauch und automatisieren Sie die Checkliste, dann wird die Produktion mit einem Headless-Browser vorhersehbar.

📖 Lesen Sie auch

• Wie Headless Chrome funktioniert
• Verdächtiger Traffic in GA4: Wie Bots mit Headless-Browsern sich als Menschen ausgeben und wie man sie erkennt
• Robots.txt: Der vollständige Leitfaden für SEO und Website-Optimierung
• Wie man einen Bot von einem echten Benutzer unterscheidet: Der vollständige Leitfaden mit Log-Beispielen

📎 Quellen

• Chrome for Developers: Headless mode
• Chrome for Developers: Headless Chrome shell
• Chrome for Developers: Debug in Headless mode
• Playwright (Java): Docker
• Playwright: Trace Viewer
• Playwright: Authentication
• Playwright: Auto-waiting
• Playwright: Archivierte Beschreibung des Docker-Images (Root und Sandbox)
• Puppeteer: Troubleshooting (archivierte Version)
• Puppeteer: Diskussion über --disable-dev-shm-usage
• Browserless: Puppeteer in Docker ohne Abstürze
• DEV: WebdriverIO mit Headless Chrome in Docker
• Kubernetes KEP-1967: Größe von speicherbasierten Volumes
• Huawei Cloud: Ändern der Größe von /dev/shm
• OWASP: Server-Side Request Forgery Prevention Cheat Sheet
• RFC 9309: Robots Exclusion Protocol

Wichtig: Versionen von Chrome, Playwright-Images und API-Bibliotheken ändern sich. Überprüfen Sie die aktuelle Dokumentation vor der Verwendung. Das Material ist aktuell im Oktober 2026.