Alexander LuftVon Alexander Luft
JTL Service Partner Gold · Ahrensfelde bei Berlin · 24. November 2025 · 5 Min. Lesezeit

CASE STUDY

0 Fehler

dbeS-Sync nach WAF-Fix

Artikelabgleich ausgefallen — und JTL war nicht das Problem

Juwelier / Schmuck-Versand

Auf einen Blick

  • ✓Der automatische Artikelabgleich (dbeS) zwischen JTL-Wawi und JTL-Shop übertrug keine Preise und Bestände mehr — obwohl alle JTL-Einstellungen unverändert waren und der dbeS-Dienst lief.
  • ✓Die Ursache lag nicht in JTL, sondern im Hosting: Die Web Application Firewall blockierte Bulk-Sync-Anfragen des dbeS-Connectors als verdächtig — nur bei großen Datenpaketen, nicht bei kleinen Änderungen.
  • ✓Wir werteten die WAF-Logs aus, identifizierten die blockierten Request-Muster und richteten gemeinsam mit dem Hosting-Anbieter gezielte Ausnahmeregeln ein. Seitdem läuft der Sync stabil.

Preise und Bestände im Shop — tagelang falsch

Ein Händler aus der Juwelier-Branche — Trauringe, Verlobungsringe, Goldschmuck, mehrere Marktplätze — meldete sich mit einem Problem ohne offensichtliche Ursache: Der automatische Artikelabgleich zwischen JTL-Wawi und dem JTL-Shop funktionierte nicht mehr zuverlässig. Preise wurden nicht übertragen, Bestände stimmten nicht, neue Produkte erschienen nicht im Shop.

Das Verwirrende: Die Einstellungen in JTL-Wawi und im Shop waren unverändert. Der dbeS-Dienst lief ohne Fehlermeldung. Nur vereinzelte Timeout-Einträge im Sync-Log deuteten auf ein Problem hin — aber kein klarer Fehler, keine auslösende Aktion.

Der Händler half sich wochenlang mit manuellen Korrekturen im Shop. Das band täglich Zeit und war fehleranfällig.

Die WAF — ein Schutzschild das zu scharf eingestellt war

Nach systematischer Diagnose fanden wir die Ursache nicht im JTL-System, sondern im Hosting: Die Web Application Firewall (WAF) des Servers hatte eine Regel aktiv, die bestimmte API-Anfragen des dbeS-Connectors als verdächtig einstufte und stillschweigend blockierte.

Das Muster war subtil. Nicht jede Sync-Anfrage wurde geblockt — nur solche mit größeren Datenpaketen, wie sie bei Bulk-Updates von Artikelpreisen oder Bestandsmengen entstehen. Kleine Änderungen kamen durch, große nicht. Das erklärte warum der Shop nicht komplett eingefroren war, sondern nur sporadisch falsche Daten zeigte.

WAF-Blocking taucht nicht in den JTL-Fehlerprotokollen auf. Der dbeS-Connector bekommt keine Antwort, schreibt einen Timeout ins Log — und gibt auf. In JTL sieht alles normal aus. Das macht diese Fehlerquelle so schwer zu finden.

Diagnose über die Logs — nicht über JTL

Der erste Schritt war ein Blick auf die WAF-Logs des Hosting-Anbieters — nicht auf JTL. Dort fanden sich die blockierten Requests: POST-Anfragen des dbeS-Connectors an den Shop-Endpunkt, abgewiesen mit HTTP 403, ohne Rückmeldung an den Absender.

Wir identifizierten die genauen Request-Muster: Payload-Größe, User-Agent-String des dbeS-Connectors, betroffene Endpunkte. Mit diesen Informationen haben wir gemeinsam mit dem Hosting-Anbieter gezielte Ausnahmeregeln (Whitelisting) für den dbeS-Connector eingerichtet — ohne die allgemeine WAF-Schutzfunktion zu deaktivieren.

Nach der Anpassung liefen alle Sync-Prozesse beim ersten Test vollständig durch. Kein einziger Timeout mehr.

Sync stabil — manuelle Korrekturen entfallen

Nach der WAF-Anpassung lief der Artikelabgleich beim ersten Test vollständig durch. Preise und Bestände werden seitdem in Echtzeit übertragen. Der wochenlange Workaround mit manuellen Shop-Korrekturen entfiel sofort.

Vorher

Sporadischer Sync-Ausfall

  • ✗Bulk-Updates von Preisen und Beständen kamen nicht an
  • ✗Nur Timeout-Einträge im Log — kein klarer Fehler
  • ✗Händler korrigierte Daten täglich manuell im Shop
  • ✗Ursache in JTL-Logs nicht sichtbar
Nachher

0 Sync-Fehler

  • ✓Alle dbeS-Sync-Anfragen laufen fehlerfrei durch
  • ✓Preise und Bestände in Echtzeit übertragen
  • ✓Keine manuellen Korrekturen mehr nötig
  • ✓WAF-Schutz bleibt vollständig aktiv

Die Lektion

dbeS-Probleme beginnen nicht immer in JTL

WAF-Blocking ist eine der versteckteren Fehlerquellen bei JTL dbeS-Sync-Problemen — taucht nicht in den JTL-Fehlerprotokollen auf und wird deshalb oft als letztes geprüft — oder gar nicht. Wer seinen dbeS-Sync unzuverlässig erlebt und die üblichen JTL-Verdächtigen ausgeschlossen hat, sollte die Firewall-Konfiguration des Servers prüfen. Besonders bei Hosting-Wechseln oder nach WAF-Updates des Anbieters kann sich dieses Problem neu einschleichen.

Häufige Fragen

Der dbeS-Abgleich (Datenbankabgleich) ist die Sync-Verbindung zwischen JTL-Wawi und dem JTL-Shop, die beide Systeme dauerhaft im Gleichgewicht hält. Er überträgt in beide Richtungen: Neue Bestellungen aus dem Shop kommen in die Wawi, aktualisierte Artikel, Preise, Bestände und Kategoriendaten gehen aus der Wawi in den Shop zurück. Der JTL-Worker läuft automatisch im Hintergrund. Fällt er aus, stehen Preise und Bestände im Shop still. Oft ohne sichtbare Fehlermeldung in der Wawi-Oberfläche.

Das charakteristische Merkmal ist die fehlende Fehlermeldung in JTL: Preise und Bestände sind im Shop falsch oder veraltet, der Abgleich in der Wawi läuft aber anscheinend durch, ohne eine Warnung zu werfen. Eine WAF (Web Application Firewall) oder modSecurity blockiert die Sync-Requests am Server, bevor sie JTL überhaupt erreichen. JTL bekommt dabei keine Antwort auf seine Anfrage und protokolliert das nicht als eigenen Fehler. In unseren Projekten sehen wir genau dieses Muster: Die Synchronisation erscheint erfolgreich, aber die Daten aktualisieren sich nicht.

Die Diagnose läuft über die Server-Logs, nicht über JTL-eigene Logs. Der relevante Ort ist das Apache- oder Nginx-Error-Log auf dem Webserver des Shops, kombiniert mit den WAF- bzw. modSecurity-Logs des Hosters. Dort erscheinen blockierte Requests als HTTP-403-Einträge mit Verweis auf den /dbeS/-Pfad. JTL-interne Logs zeigen diese Ebene nicht, weil der Block vor dem PHP-Einstiegspunkt stattfindet. Direkt prüfen lässt sich das zusätzlich, indem man die dbeS-Endpoint-URL im Browser aufruft. Ein HTTP-403 dort bestätigt den Verdacht sofort.

Der saubere Weg ist eine gezielte Ausnahmeregel (Whitelist) in der WAF-Konfiguration, kein Abschalten der gesamten Firewall. Den /dbeS/-Pfad oder die Server-IP der JTL-Wawi-Installation trägt man als vertrauenswürdige Quelle ein. Bei Cloudflare geht das über eine Firewall-Ausnahmeregel für die dbeS-Dateien; bei Plesk und aktivierter modSecurity über eine entsprechende Rule-Exclusion. Eine weitere Option ist ein Hosts-File-Eintrag auf dem Wawi-Server, damit der Sync-Traffic den Cloudflare-Proxy umgeht und direkt auf die Server-IP trifft. Der Hoster oder der direkte Serverzugang ist dafür in jedem Fall nötig. Diese Einstellung liegt nicht in JTL.

Nach jeder WAF- oder Hosting-Konfigurationsänderung einen manuellen Abgleich in der Wawi auslösen und die Server-Logs direkt danach prüfen. So ist ein frischer Block sofort sichtbar, bevor er sich unbemerkt aufbaut. Wer Cloudflare einsetzt, sollte den /dbeS/-Ordner dauerhaft aus der Caching-Konfiguration ausnehmen. Cloudflare darf diesen Pfad weder cachen noch über Sicherheitsstufen schärfer behandeln als den restlichen Traffic. Als JTL Service Partner Gold sehen wir regelmäßig, dass WAF-Anpassungen nach Shop-Updates oder Hosting-Migrationen stillschweigend zurückgesetzt werden. Ein kurzer Log-Check nach solchen Ereignissen spart wochenlange manuelle Preiskorrekturen.

dbeS-Sync-Problem analysieren lassen

Wenn euer JTL-Artikelabgleich unzuverlässig läuft und die Ursache unklar ist — Wir diagnostizieren das systematisch, auch wenn es nicht an JTL liegt. Ruf uns an unter +49 30 91473862, schreib an info@vlarom.de oder nutze unser Kontaktformular.