JTL-Connector bricht mit HTTP 504 ab: Warum das selten an PHP liegt

Auf einen Blick

• ✓Ein 504 wird vom Proxy ausgestellt, nicht von PHP. Nginx wartet standardmäßig 60 Sekunden auf eine Antwort von PHP-FPM (`fastcgi_read_timeout`), Apache im Regelfall ebenfalls 60 Sekunden (`Timeout`, von `ProxyTimeout` übernommen), unabhängig davon, was `max_execution_time` in PHP erlaubt.
• ✓JTL dokumentiert in der offiziellen Connector-FAQ ausschließlich PHP-Werte (`memory_limit` mindestens 128 MB, `max_execution_time` mindestens 120 Sekunden, `upload_max_filesize` mindestens 32 MB). Zur Proxy-Ebene sagt die Doku nichts. Genau diese Lücke führt dazu, dass Nutzer den PHP-Wert erhöhen und sich fragen, warum der 504 bleibt.
• ✓Ohne Server-Zugriff hilft ein anderer Hebel: In der JTL-Wawi lässt sich unter Plattformen > Verkaufskanäle > Verbindung die Paketgröße pro Upload- und Import-Paket verkleinern. Kleinere Pakete bedeuten kürzere Einzel-Requests, die seltener über den Proxy-Timeout laufen.

Als JTL Service Partner Gold richtet die Vlarom E-Commerce Agentur den Connector für WooCommerce-, Shopware- und Shopify-Shops ein und übernimmt den Support, wenn der Abgleich stockt. Die Verwechslung von PHP-Timeout und Proxy-Timeout ist in unseren Connector-Support-Fällen einer der häufigsten Gründe, warum eine bereits erhöhte `max_execution_time` das eigentliche Problem nicht löst. Der zuständige Wert liegt schlicht auf einer anderen Ebene, die JTL in der eigenen Shopkonfiguration für den JTL-Connector nicht erwähnt. In der Praxis der Vlarom E-Commerce Agentur ist genau das der Punkt, an dem die Fehlersuche sonst hängen bleibt. Aktuell diskutiert das auch ein frischer Thread im JTL-Forum unter dem Stichwort „Gateway Timeout 504″ beim Shopware-Connector: ein bislang unbeantworteter Nutzerbericht, kein bestätigter Fall, aber ein Beleg dafür, dass das Thema gerade wieder aufkommt.

Zwei völlig getrennte Uhren laufen bei jedem Connector-Sync mit: eine in PHP, eine im Webserver davor. Beide haben eigene Default-Werte, und keiner beeinflusst den anderen:

„`fastcgi_read_timeout 60s;`“ — Default-Wert laut offizieller nginx-Dokumentation zum fastcgi-Modul für die Wartezeit, bis nginx selbst einen 504 an den Client ausliefert, unabhängig vom PHP-Limit.

Die vier Werte im Überblick, mit Quelle:

• →PHP `max_execution_time`: 30 Sekunden (Default): Laut PHP-Dokumentation ist 30 Sekunden der Standardwert; über die Kommandozeile ausgeführt gilt 0 (unbegrenzt). Läuft das Skript länger, bricht PHP selbst ab. Das erzeugt für sich genommen noch keinen HTTP-Statuscode 504.
• →nginx `fastcgi_read_timeout`: 60 Sekunden (Default): Die Zeit, die nginx auf eine Antwort von PHP-FPM wartet, bevor es selbst mit 504 antwortet. Läuft unabhängig davon, wie hoch max_execution_time in PHP gesetzt ist.
• →Apache `Timeout` / `ProxyTimeout`: 60 Sekunden in der Standardkonfiguration: `ProxyTimeout` hat laut Apache-mod_proxy-Dokumentation keinen eigenen festen Wert, sondern übernimmt den Wert der globalen `Timeout`-Direktive, in der Standard-Konfiguration 60 Sekunden.
• →JTL-Mindestanforderung PHP: 128 MB / 120 s / 32 MB: Die offizielle JTL-Connector-FAQ zu den PHP-Einstellungen setzt mindestens 128 MB `memory_limit`, mindestens 120 Sekunden `max_execution_time` und mindestens 32 MB `upload_max_filesize` voraus und nennt ausdrücklich nur diese drei PHP-Werte, keine Proxy-Einstellung.

Selbst wenn `max_execution_time` korrekt auf 120 Sekunden steht, kann nginx nach seinen eigenen 60 Sekunden längst mit 504 geantwortet haben. Genau diesen Zusammenhang nennt keine offizielle JTL-Quelle. Die PHP-Empfehlung von JTL allein reicht dann nicht. Die Proxy-Ebene muss separat angepasst werden. (Stand der genannten Werte: 21.09.2026.)

PHP-Timeout und Proxy-Timeout haben nichts miteinander zu tun außer der zeitlichen Nähe. Wer nur eine Ebene anpasst, behebt bestenfalls die Hälfte des Problems.

primary

PHP-Ebene: max_execution_time regelt nur den PHP-Prozess

max_execution_time bestimmt, wie lange ein PHP-Skript laufen darf, bevor PHP es selbst beendet. Läuft der Connector-Sync länger, meldet PHP im Error-Log eine Zeile wie ‚Maximum execution time of X seconds exceeded‘, eine klare, PHP-eigene Fehlermeldung.

Wichtig: Der PHP-Abbruch durch max_execution_time erzeugt für sich genommen keinen HTTP 504. Was der Client am Ende sieht, entscheidet der Proxy davor (nginx oder Apache), je nachdem, ob er noch innerhalb seines eigenen Timeout-Fensters auf eine — dann fehlerhafte — PHP-Antwort wartet oder selbst schon abgebrochen hat.

warning

Proxy-Ebene: nginx, Apache und Co. haben ihre eigene Uhr

nginx (`fastcgi_read_timeout`, Default 60 Sekunden) und Apache (`Timeout`/`ProxyTimeout`, in der mitgelieferten Standardkonfiguration ebenfalls 60 Sekunden) warten nur eine begrenzte Zeit auf die Antwort von PHP-FPM. Läuft diese Zeit ab, liefert der Proxy selbst den 504 aus, ganz unabhängig davon, was in der php.ini steht.

Für LiteSpeed-Hosting gilt: Der Webserver kennt eigene, separat konfigurierbare Timeout-Parameter je External App. Ein einheitlicher Standardwert lässt sich dafür allerdings nicht seriös benennen, weil die Werte vHost-spezifisch gesetzt werden. Hier hilft nur der direkte Blick in die eigene Konfiguration oder die Nachfrage beim Hoster.

highlight

Diagnose: Wo steht der Fehler?

Erster Schritt ist immer das PHP-Error-Log. Steht dort eine konkrete Meldung wie ‚Maximum execution time exceeded‘ oder ‚Allowed memory size exhausted‘, hat PHP den Prozess selbst beendet. Das ist die PHP-Ebene, und `max_execution_time` beziehungsweise `memory_limit` sind die richtige Stellschraube.

Steht im PHP-Error-Log dagegen nichts, obwohl der Client trotzdem eine 504-Seite bekommt, ist das ein starkes Indiz für die Proxy-Ebene: Der Webserver hat abgebrochen, bevor PHP überhaupt fertig geloggt hat oder antworten konnte. In dem Fall bringt eine weitere Erhöhung von `max_execution_time` nichts. Es braucht `fastcgi_read_timeout` (nginx) oder `Timeout`/`ProxyTimeout` (Apache), beziehungsweise Rücksprache mit dem Hoster, wenn kein direkter Zugriff besteht.

Paketgröße drosseln, wenn der Server-Zugriff fehlt

Ein im JTL-Forum dokumentierter, als gelöst markierter Fall zu ‚504 Timeout bei Übertragung von Kategorien‘ zeigt den Lösungsansatz, den wir auch in eigenen Projekten einsetzen: die Paketanzahl beziehungsweise Paketgröße in der Connector-Konfiguration der Wawi verkleinern. Kleinere Pakete bedeuten kürzere Einzel-Requests, die seltener über den Proxy-Timeout laufen, ein Hebel, den JTL selbst anbietet (Plattformen > Verkaufskanäle > Verbindung), aber nicht im Timeout-Kontext dokumentiert.

Nicht jeder 504 ist ein Server-Problem

Der Shopify-Connector bekam mit Version 2.1.10 (28.07.2026) einen Fix, den JTL selbst so beschreibt: ‚ein Fehler behoben, der bei größeren Variationskombinationen zu Zeitüberschreitungen und Verbindungsabbrüchen führen konnte.‘ Das ist ein von JTL bestätigter Beleg dafür, dass Timeout-Ursachen auch im Connector-Code selbst liegen können. Bevor du Stunden in Server-Konfiguration investierst, lohnt ein Blick in den aktuellen Connector-Changelog der jeweiligen Plattform.

Diese Schritte bauen aufeinander auf und trennen bewusst zwischen den Ebenen, damit du nicht an der falschen Stelle nachjustierst.

Prüfe zuerst, ob PHP selbst eine Fehlermeldung geloggt hat (‚Maximum execution time exceeded‘, ‚Allowed memory size exhausted‘). Findest du einen dieser Einträge, bist du auf der PHP-Ebene. Weiter mit Schritt 2. Findest du nichts, obwohl der Client trotzdem 504 sieht, ist das ein starkes Indiz für die Proxy-Ebene. Weiter mit Schritt 3.

Stelle memory_limit auf mindestens 128 MB, max_execution_time auf mindestens 120 Sekunden und upload_max_filesize auf mindestens 32 MB. Das sind die von JTL selbst dokumentierten Minimalwerte. Details und Hintergrund dazu in Feature.json und PHP-Einstellungen optimieren.

Bei nginx: `fastcgi_read_timeout` in der Server- oder Location-Konfiguration prüfen (Default 60 Sekunden) und auf einen zur PHP-Laufzeit passenden Wert erhöhen. Bei Apache: `Timeout` beziehungsweise `ProxyTimeout` prüfen (Default ebenfalls 60 Sekunden). Hast du keinen direkten Zugriff auf diese Konfiguration, ist das eine Anfrage an den Hoster, nicht an PHP.

Unter Plattformen > Verkaufskanäle > Verbindung lassen sich Paketgröße pro Upload-Paket, pro Import-Paket, Paketgröße Bilder und maximale Megabyte pro Paket separat einstellen. Kleinere Werte erzeugen mehr, aber kürzere Einzel-Requests, ein Hebel, der unabhängig von der Server-Konfiguration funktioniert. Grundlagen zur Connector-Einrichtung stehen in JTL-Connector-Fehler lösen.

Bevor du weiter an Server-Werten drehst, lohnt ein Blick in den offiziellen Changelog der jeweiligen Plattform (WooCommerce, Shopware 6, Shopify). Timeout-Ursachen lagen in der Vergangenheit auch im Connector-Code selbst und wurden mit einem Update behoben, nicht mit einer Server-Einstellung.