WordPress "HTTP-Fehler" beim Bild-Upload: Ein Entscheidungsbaum, der die Ursache wirklich findet

“HTTP-Fehler” ist keine Ursache. Es ist das Eingeständnis des Medien-Uploaders, dass er deine Datei an den Server geschickt und eine Antwort zurückbekommen hat, die er nicht als Erfolg lesen konnte – und mindestens sechs völlig verschiedene Fehler erzeugen genau diese Meldung. Dass man dazwischen rät, ist der Grund, warum Leute einen halben Tag lang upload_max_filesize auf einer Website hochschrauben, deren eigentliches Problem eine Firewall-Regel ist.

Der schnellste Weg hinaus ist eine einzige Beobachtung, die die sechs Ursachen in zwei Gruppen teilt, und danach eine Prüfung pro Zweig.

Zuerst: die tatsächliche Antwort lesen

Öffne die Entwicklerwerkzeuge deines Browsers, geh auf den Tab “Netzwerk” und lade die Datei erneut hoch. Achte auf die Anfrage an async-upload.php. Was zurückkommt, ist deine Diagnose.

Was du siehst	Was es bedeutet	Weiter zu
403 oder 406, HTML-Körper	Firewall oder mod_security hat die Anfrage abgelehnt	Zweig A
500, leere Antwort oder abgeschnittener Körper	PHP ist abgestürzt oder mittendrin der Speicher ausgegangen	Zweig B
413	Anfragekörper hat ein Serverlimit überschritten	Zweig C
200, aber der Körper ist kein sauberes JSON	Ein Plugin oder Theme hat vor der Antwort etwas ausgegeben	Zweig D
Anfrage wird nie fertig / läuft in einen Timeout	Limit für die Ausführungszeit, meist bei großen Dateien	Zweig B

Dieser eine Blick räumt den Großteil der Ratschläge aus dem Internet für dich ab. Kommst du nicht an die Entwicklerwerkzeuge, schalte zuerst das Logging in der wp-config.php ein:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduziere den Upload und lies dann wp-content/debug.log. Eine Zeile mit einem fatalen Fehler benennt den Zweig unmissverständlich. Ist die Zeile schwer lesbar, füge sie in den Error-Log-Decoder ein – er ordnet die üblichen Fehlersignaturen dem zu, was wirklich kaputtgegangen ist.

Zweig A – eine Firewall- oder mod_security-Regel

Ein 403 mit einer HTML-Seite im Körper heißt, dass die Anfrage WordPress nie erreicht hat. Etwas davor – mod_security, Cloudflare, Wordfence, Sucuri oder das Regelwerk deines Hosters – hat den POST für bösartig gehalten.

Die Prüfung: Deaktiviere alle Sicherheits-Plugins vorübergehend und lade erneut hoch. Ändert das nichts, sitzt die Regel auf Serverebene, und dein Hoster muss im mod_security-Audit-Log nach dem Zeitstempel des fehlgeschlagenen Uploads sehen. Er kann die betreffende Regel-ID freigeben.

Sei ehrlich zu dir selbst, was die Ratschläge angeht, die du hier finden wirst. Schnipsel, die dir sagen, du sollst das in die .htaccess schreiben:

SecFilterEngine Off
SecFilterScanPOST Off

zielen auf mod_security 1.x, das praktisch ausgestorben ist. Auf einem modernen Server bewirken diese Direktiven entweder nichts oder werfen einen 500, der die Website weiter verschlechtert. Modernes mod_security nutzt SecRuleEngine, und die meisten Managed Hoster blockieren ohnehin, dass man es pro Verzeichnis überschreibt. Frag den Hoster; kopier nicht blind.

Zweig B – PHP-Speicher- oder Laufzeitlimits

Das ist der häufigste Zweig und der mit dem klarsten Erkennungszeichen: er tritt sprunghaft auf. Dieselbe Datei geht beim dritten Versuch durch, oder ein 2 MB großes Foto scheitert, während ein 6 MB großes PDF anstandslos hochlädt. Harte Konfigurationslimits scheitern jedes Mal gleich. Speicherfehler nicht, weil die verfügbare Menge davon abhängt, was der Server sonst gerade tut.

Warum ausgerechnet Bilder: WordPress speichert die Datei nicht einfach ab, sondern dekomprimiert sie in rohe Pixel, um jede Zwischengröße zu erzeugen – medium_large, alles was per add_image_size registriert ist, woocommerce_thumbnail, falls du einen Shop betreibst, dazu eine -scaled-Kopie, wenn das Bild über dem big_image_size_threshold liegt. Ein 12-Megapixel-JPEG belegt ein paar MB auf der Platte und rund 48 MB im Arbeitsspeicher, noch vor dem Puffer fürs Skalieren. Ein Limit von 128 MB ist schnell aufgebraucht.

Heb es in der wp-config.php an, oberhalb der “stop editing”-Zeile:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Der Haken dabei: WP_MEMORY_LIMIT kann nicht über das hinausgehen, was PHP selbst erlaubt. Deckelt dein Hoster memory_limit bei 128M, ist diese Konstante reine Dekoration. Prüfe den echten Wert unter Werkzeuge → Website-Zustand → Infos → Server, nicht in dem, was du geschrieben hast. Ist PHPs eigenes Limit die Obergrenze, kann nur der Hoster es verschieben.

Zweig C – Datei- und POST-Größenlimits

Sieh dir die tatsächlichen Zahlen unter Werkzeuge → Website-Zustand → Infos → Medienverarbeitung an. Zwei Einstellungen zählen, und die Leute ändern immer nur eine davon:

• upload_max_filesize – die Obergrenze für eine einzelne Datei.
• post_max_size – die Obergrenze für den gesamten Anfragekörper.

Überschreitet der komplette POST post_max_size, verwirft PHP die Anfrage, bevor WordPress auch nur eine Zeile ausführt. Es existiert nichts, was zurückgegeben werden könnte, der Uploader bekommt also eine unlesbare Antwort und meldet “HTTP-Fehler”. post_max_size sollte immer deutlich größer sein als upload_max_filesize.

Ein Hinweis, der sich lohnt: Überschreitet eine Datei nur upload_max_filesize, fängt der Uploader das meist schon im Browser ab und meldet, dass die Datei die maximale Uploadgröße überschreitet – eine deutlich klarere Meldung. Ein nacktes “HTTP-Fehler” deutet also häufiger auf post_max_size oder auf Zweig B hin als auf genau die Einstellung, die alle zuerst hochschrauben.

Wo du sie änderst, hängt von deinem Stack ab. Auf Apache mit mod_php funktioniert die .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Unter PHP-FPM, LiteSpeed oder NGINX – also bei den meisten modernen Hostern – bewirken diese Zeilen nichts und können einen 500 auslösen. Nutze stattdessen das PHP-Einstellungspanel des Hosters oder eine .user.ini-Datei. NGINX erzwingt zusätzlich sein eigenes client_max_body_size, das nur der Hoster anheben kann.

Zweig D – die Bildbibliothek (Imagick vs. GD)

WordPress bevorzugt ImageMagick, sobald die PHP-Erweiterung vorhanden ist, und fällt sonst auf GD zurück. Auf Shared Hosting ist ImageMagick häufig das Problem: Seine Policy-Konfigurationsdatei begrenzt Speicher, Festplattennutzung und Bildfläche pro Vorgang, und wenn eine Skalierung eines dieser Limits reißt, stirbt der Prozess ohne brauchbare Meldung. Typischerweise siehst du das bei großen Bildern, während kleine funktionieren – was wie Zweig B aussieht, es aber nicht ist.

Erzwinge GD, um die Theorie zu testen:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Pack das in die functions.php oder in ein kleines mu-Plugin, wiederhole den Upload und entferne es wieder, falls sich nichts ändert.

Die ehrliche Abwägung: GD ist nicht grundsätzlich besser. Es hält die komplette unkomprimierte Bitmap im Speicher von PHP, kann bei sehr großen Dateien also an memory_limit scheitern, wo ImageMagick – das teilweise außerhalb der PHP-Speicherzuteilung arbeitet – durchgelaufen wäre. Der Wechsel kann einen Fehler gegen einen anderen tauschen. Behandle ihn zuerst als Diagnose und erst danach als Lösung.

Zweig E – Rechte im Uploads-Verzeichnis

Bei Managed Hosting selten, direkt nach einer Migration oder einem manuellen Serverumzug häufig. Ist wp-content/uploads für den Benutzer des Webservers nicht beschreibbar, oder hat ein neu angelegter Jahres- bzw. Monatsordner den falschen Eigentümer geerbt, schlägt das Schreiben fehl.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Verzeichnisse sollten in der Regel 755 sein und dem Benutzer gehören, unter dem PHP läuft. Setze nicht 777, nur weil ein Forum das geraten hat – das behebt das Symptom, indem es den Ordner für jedes Konto auf dem Server beschreibbar macht, was auf Shared Hosting eine echte Angriffsfläche ist.

Zweig F – der Dateiname

Die billigste Prüfung auf der Liste, also mach sie früh, auch wenn sie am unwahrscheinlichsten ist. Benenne die Datei in schlichte Kleinbuchstaben, Ziffern und Bindestriche um – keine Umlaute, Apostrophe, Und-Zeichen, # oder nichtlateinischen Zeichen – und lade sie erneut hoch. Sonderzeichen lösen gelegentlich eine Sicherheitsregel aus oder scheitern an einem Dateisystem mit abweichender Zeichenkodierung. Zehn Sekunden, um es auszuschließen.

Was du nicht tun solltest

Fang nicht damit an, sämtliche Plugins zu deaktivieren. Das ist störend und testet nur Zweig A und Zweig D. Die Netzwerkantwort verrät dir in fünf Sekunden mehr.

Füge keine zufällige Handler-Zeile in die .htaccess ein. Die kursierenden Schnipsel mit einer SetHandler- oder AddHandler-Direktive setzen das PHP-Setup eines ganz bestimmten Hosters voraus. Auf dem falschen Stack legen sie die komplette Website mit einem 500 lahm.

Lass “beim zweiten Versuch ging’s” nicht als behoben durchgehen. Sprunghafter Erfolg ist die Signatur von Zweig B, und er kommt zurück, sobald der Server ausgelastet ist oder jemand etwas Größeres hochlädt.

Immer noch festgefahren?

Ist die Antwort ein sauberer 200 mit gültigem JSON und der Upload scheitert trotzdem, bricht es nach dem Eintreffen der Datei ab – meist wirft ein Plugin, das sich in die Verarbeitungskette für Anhänge einhängt, einen fatalen Fehler, oder ein Optimierungs-Plugin schickt eine eigene Anfrage an einen externen Dienst, die in einen Timeout läuft. Aktiviere WP_DEBUG_LOG, reproduziere den Fall und schicke den entstandenen fatalen Fehler durch den Error-Log-Decoder, um zu sehen, welche Datei und welcher Hook wirklich verantwortlich sind.