WordPress «HTTP error» στη μεταφόρτωση εικόνας: ένα δέντρο αποφάσεων που όντως βρίσκει την αιτία

Το «HTTP error» δεν είναι αιτία. Είναι ο uploader πολυμέσων που παραδέχεται πως έστειλε το αρχείο σας στον διακομιστή και πήρε πίσω μια απάντηση που δεν μπόρεσε να ερμηνεύσει ως επιτυχία — και τουλάχιστον έξι άσχετες μεταξύ τους αποτυχίες παράγουν αυτές ακριβώς τις δύο λέξεις. Το ότι ο κόσμος μαντεύει ανάμεσά τους είναι ο λόγος που κάποιοι περνούν ένα απόγευμα αυξάνοντας το upload_max_filesize σε έναν ιστότοπο του οποίου το πραγματικό πρόβλημα είναι ένας κανόνας firewall.

Ο γρηγορότερος δρόμος είναι μία μόνο παρατήρηση που χωρίζει τις έξι αιτίες σε δύο ομάδες, και μετά ένας έλεγχος ανά κλαδί.

Πρώτα: διαβάστε την πραγματική απάντηση

Ανοίξτε τα εργαλεία προγραμματιστή του browser, πηγαίνετε στην καρτέλα Network και ανεβάστε ξανά το αρχείο. Προσέξτε το αίτημα προς το async-upload.php. Ό,τι επιστρέφει είναι η διάγνωσή σας.

Τι βλέπετε	Τι σημαίνει	Πηγαίνετε στο
403 ή 406, σώμα HTML	Firewall ή mod_security απέρριψε το αίτημα	Κλαδί Α
500, ή κενή απάντηση, ή κομμένο σώμα	Η PHP κατέρρευσε ή ξέμεινε από μνήμη στη μέση	Κλαδί Β
413	Το σώμα του αιτήματος ξεπέρασε όριο του διακομιστή	Κλαδί Γ
200, αλλά το σώμα δεν είναι καθαρό JSON	Ένα πρόσθετο ή θέμα τύπωσε έξοδο πριν την απάντηση	Κλαδί Δ
Το αίτημα δεν ολοκληρώνεται ποτέ / λήγει	Όριο χρόνου εκτέλεσης, συνήθως με μεγάλα αρχεία	Κλαδί Β

Αυτή η μία ματιά σάς γλιτώνει από τις περισσότερες συμβουλές που κυκλοφορούν στο διαδίκτυο. Αν δεν μπορείτε να φτάσετε στα εργαλεία του browser, ενεργοποιήστε πρώτα την καταγραφή στο wp-config.php:

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

Αναπαράγετε τη μεταφόρτωση και μετά διαβάστε το wp-content/debug.log. Μια γραμμή fatal error κατονομάζει το κλαδί ευθέως. Αν η γραμμή είναι δυσνόητη, επικολλήστε την στον αποκωδικοποιητή σφαλμάτων — αντιστοιχίζει τις συνηθισμένες υπογραφές fatal errors με αυτό που πραγματικά χάλασε.

Κλαδί Α — κανόνας firewall ή mod_security

Ένα 403 με σελίδα HTML στο σώμα σημαίνει ότι το αίτημα δεν έφτασε ποτέ στο WordPress. Κάτι μπροστά από αυτό — mod_security, Cloudflare, Wordfence, Sucuri ή το σετ κανόνων του ίδιου του παρόχου — έκρινε ότι το POST φαινόταν κακόβουλο.

Ο έλεγχος: απενεργοποιήστε προσωρινά κάθε πρόσθετο ασφαλείας και ανεβάστε ξανά. Αν δεν αλλάξει τίποτα, ο κανόνας βρίσκεται σε επίπεδο διακομιστή και χρειάζεστε τον πάροχό σας να κοιτάξει το audit log του mod_security για τη χρονική στιγμή της αποτυχημένης μεταφόρτωσης. Μπορούν να βάλουν σε λίστα επιτρεπόμενων το συγκεκριμένο ID κανόνα.

Να είστε ειλικρινείς με τον εαυτό σας για τις συμβουλές που θα βρείτε εδώ. Τα αποσπάσματα που σας λένε να ρίξετε αυτό μέσα στο .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

αφορούν το mod_security 1.x, το οποίο έχει σχεδόν εκλείψει. Σε σύγχρονο διακομιστή αυτές οι οδηγίες είτε δεν κάνουν τίποτα είτε προκαλούν ένα 500 που χειροτερεύει τον ιστότοπο. Το σύγχρονο mod_security χρησιμοποιεί το SecRuleEngine, και οι περισσότεροι διαχειριζόμενοι πάροχοι μπλοκάρουν έτσι κι αλλιώς τις παρακάμψεις του ανά φάκελο. Ρωτήστε τον πάροχο· μην επικολλάτε.

Κλαδί Β — όρια μνήμης ή χρόνου εκτέλεσης της PHP

Είναι το πιο συχνό κλαδί και αυτό με το καθαρότερο σημάδι: είναι διακοπτόμενο. Το ίδιο αρχείο ανεβαίνει με την τρίτη προσπάθεια, ή μια φωτογραφία 2MB αποτυγχάνει ενώ ένα PDF 6MB περνά χωρίς πρόβλημα. Τα σταθερά όρια ρυθμίσεων αποτυγχάνουν πανομοιότυπα κάθε φορά. Οι αποτυχίες μνήμης όχι, γιατί το πόση μνήμη είναι διαθέσιμη εξαρτάται από το τι άλλο κάνει ο διακομιστής.

Γιατί συμβαίνει ειδικά με τις εικόνες: το WordPress δεν αποθηκεύει απλώς το αρχείο, το αποσυμπιέζει σε ωμά pixel για να δημιουργήσει κάθε ενδιάμεσο μέγεθος — medium_large, ό,τι έχει δηλωθεί με add_image_size, το woocommerce_thumbnail αν έχετε κατάστημα, συν ένα αντίγραφο -scaled αν η εικόνα ξεπερνά το big_image_size_threshold. Ένα JPEG 12 megapixel πιάνει λίγα MB στον δίσκο και περίπου 48MB στη μνήμη, πριν καν μετρήσουμε τον buffer της αλλαγής μεγέθους. Ένα όριο 128MB εξαφανίζεται γρήγορα.

Αυξήστε το στο wp-config.php, πάνω από τη γραμμή «stop editing»:

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

Το πραγματικό κόστος: το WP_MEMORY_LIMIT δεν μπορεί να ξεπεράσει αυτό που επιτρέπει η ίδια η PHP. Αν ο πάροχός σας βάζει ταβάνι 128M στο memory_limit, αυτή η σταθερά είναι διακοσμητική. Ελέγξτε την πραγματική τιμή στο Εργαλεία → Υγεία ιστότοπου → Πληροφορίες → Διακομιστής, όχι σε ό,τι γράψατε εσείς. Αν η οροφή είναι το όριο της ίδιας της PHP, μόνο ο πάροχος μπορεί να τη μετακινήσει.

Κλαδί Γ — μέγεθος αρχείου και όρια POST

Δείτε τους πραγματικούς αριθμούς στο Εργαλεία → Υγεία ιστότοπου → Πληροφορίες → Διαχείριση πολυμέσων. Δύο ρυθμίσεις έχουν σημασία και ο κόσμος αλλάζει πάντα μόνο τη μία:

• upload_max_filesize — το ταβάνι για ένα μεμονωμένο αρχείο.
• post_max_size — το ταβάνι για ολόκληρο το σώμα του αιτήματος.

Αν το συνολικό POST ξεπερνά το post_max_size, η PHP απορρίπτει το αίτημα πριν εκτελέσει το WordPress έστω μία γραμμή κώδικα. Δεν υπάρχει τίποτα να επιστραφεί, οπότε ο uploader παίρνει μια απάντηση που δεν ερμηνεύεται και λέει «HTTP error». Το post_max_size πρέπει πάντα να είναι άνετα μεγαλύτερο από το upload_max_filesize.

Μια επιφύλαξη που αξίζει να γνωρίζετε: όταν ένα αρχείο ξεπερνά μόνο το upload_max_filesize, ο uploader συνήθως το πιάνει μέσα στον browser και λέει ότι το αρχείο υπερβαίνει το μέγιστο μέγεθος μεταφόρτωσης — σαφέστερο μήνυμα. Άρα ένα σκέτο «HTTP error» δείχνει συχνότερα προς το post_max_size ή προς το Κλαδί Β παρά προς τη ρύθμιση που όλοι αυξάνουν πρώτη.

Το πού τα αλλάζετε εξαρτάται από τη στοίβα σας. Σε Apache με mod_php, το .htaccess λειτουργεί:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Σε PHP-FPM, LiteSpeed ή NGINX — δηλαδή στη συντριπτική πλειονότητα της σύγχρονης φιλοξενίας — αυτές οι γραμμές δεν κάνουν τίποτα και μπορεί να προκαλέσουν 500. Χρησιμοποιήστε τον πίνακα ρυθμίσεων PHP του παρόχου ή ένα αρχείο .user.ini. Ο NGINX επιβάλλει επίσης το δικό του client_max_body_size, το οποίο μόνο ο πάροχος μπορεί να αυξήσει.

Κλαδί Δ — η βιβλιοθήκη επεξεργασίας εικόνας (Imagick ή GD)

Το WordPress προτιμά το ImageMagick όταν υπάρχει η αντίστοιχη επέκταση PHP και επιστρέφει στη GD αλλιώς. Σε κοινόχρηστους διακομιστές το ImageMagick είναι συχνά το πρόβλημα: το αρχείο πολιτικής του περιορίζει μνήμη, δίσκο και επιφάνεια ανά λειτουργία, και όταν μια αλλαγή μεγέθους χτυπήσει σε ένα από αυτά τα όρια, η διεργασία πεθαίνει χωρίς χρήσιμο μήνυμα. Συνήθως θα το δείτε σε μεγάλες εικόνες ενώ οι μικρές δουλεύουν — που μοιάζει με το Κλαδί Β αλλά δεν είναι.

Επιβάλετε τη GD για να δοκιμάσετε τη θεωρία:

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

Βάλτε το στο functions.php ή σε ένα μικρό mu-plugin, ξαναδοκιμάστε τη μεταφόρτωση και αφαιρέστε το αν δεν αλλάξει τίποτα.

Ο ειλικρινής συμβιβασμός: η GD δεν είναι αντικειμενικά καλύτερη. Κρατά ολόκληρο το ασυμπίεστο bitmap στη μνήμη της PHP, οπότε σε πολύ μεγάλα αρχεία μπορεί να χτυπήσει στο memory_limit εκεί όπου το ImageMagick — που δουλεύει εν μέρει εκτός της μνήμης της PHP — θα τα είχε καταφέρει. Η αλλαγή μπορεί να ανταλλάξει τη μία αποτυχία με μια άλλη. Δείτε την πρώτα ως διαγνωστικό και δεύτερον ως λύση.

Κλαδί Ε — δικαιώματα στον φάκελο uploads

Σπάνιο στη διαχειριζόμενη φιλοξενία, συχνό αμέσως μετά από μετεγκατάσταση ή χειροκίνητη μεταφορά διακομιστή. Αν ο φάκελος wp-content/uploads δεν είναι εγγράψιμος από τον χρήστη του web server, ή αν ένας νεοδημιουργημένος υποφάκελος έτους/μήνα κληρονόμησε λάθος ιδιοκτήτη, η εγγραφή αποτυγχάνει.

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

Οι φάκελοι πρέπει τυπικά να είναι 755 και να ανήκουν στον χρήστη υπό τον οποίο τρέχει η PHP. Μη βάζετε 777 επειδή σας το είπε κάποιο φόρουμ — διορθώνει το σύμπτωμα κάνοντας τον φάκελο εγγράψιμο από κάθε λογαριασμό του διακομιστή, που σε κοινόχρηστη φιλοξενία είναι πραγματική έκθεση.

Κλαδί Ζ — το όνομα του αρχείου

Ο φθηνότερος έλεγχος της λίστας, οπότε κάντε τον νωρίς παρότι είναι ο λιγότερο πιθανός. Μετονομάστε το αρχείο σε απλά πεζά λατινικά γράμματα, αριθμούς και παύλες — χωρίς τόνους, αποστρόφους, σύμβολα και, # ή μη λατινικούς χαρακτήρες — και ανεβάστε το ξανά. Οι ειδικοί χαρακτήρες ενεργοποιούν περιστασιακά κανόνα ασφαλείας ή σκοντάφτουν σε σύστημα αρχείων με ασύμβατη κωδικοποίηση. Δέκα δευτερόλεπτα για να το αποκλείσετε.

Τι να μην κάνετε

Μην ξεκινάτε απενεργοποιώντας όλα τα πρόσθετα. Είναι ενοχλητικό και ελέγχει μόνο το Κλαδί Α και το Κλαδί Δ. Η απάντηση στο δίκτυο σάς λέει περισσότερα σε πέντε δευτερόλεπτα.

Μην προσθέτετε τυχαία γραμμή handler στο .htaccess. Τα αποσπάσματα που κυκλοφορούν και προσθέτουν οδηγία SetHandler ή AddHandler προϋποθέτουν τη ρύθμιση PHP ενός συγκεκριμένου παρόχου. Σε λάθος στοίβα ρίχνουν ολόκληρο τον ιστότοπο με ένα 500.

Μη δέχεστε το «δούλεψε με τη δεύτερη προσπάθεια» ως λύση. Η διακοπτόμενη επιτυχία είναι η υπογραφή του Κλαδιού Β, και θα επιστρέψει τη στιγμή που ο διακομιστής θα έχει φόρτο ή κάποιος θα ανεβάσει κάτι μεγαλύτερο.

Κολλήσατε ακόμα;

Αν η απάντηση είναι καθαρό 200 με έγκυρο JSON και η μεταφόρτωση εξακολουθεί να αποτυγχάνει, η βλάβη είναι μετά την άφιξη του αρχείου — συνήθως ένα πρόσθετο συνδεδεμένο στην αλυσίδα επεξεργασίας συνημμένων που ρίχνει fatal error, ή ένα πρόσθετο βελτιστοποίησης που στέλνει δικό του αίτημα σε εξωτερική υπηρεσία και λήγει ο χρόνος. Ενεργοποιήστε την WP_DEBUG_LOG, αναπαράγετε το πρόβλημα και περάστε το fatal error που θα προκύψει από τον αποκωδικοποιητή σφαλμάτων για να δείτε ποιο αρχείο και ποιο hook ευθύνονται πραγματικά.