इमेज अपलोड पर WordPress "HTTP error": वह डिसीजन ट्री जो सचमुच वजह पकड़ता है

“HTTP error” कोई वजह नहीं है। यह media uploader का यह मान लेना है कि उसने आपकी फाइल सर्वर को भेजी और बदले में ऐसा जवाब मिला जिसे वह सफलता के रूप में नहीं समझ सका — और कम से कम छह अलग-अलग विफलताएँ बिल्कुल यही तीन शब्द पैदा करती हैं। इनके बीच अंदाजा लगाने की वजह से ही लोग पूरी दोपहर upload_max_filesize बढ़ाने में लगा देते हैं, जबकि असली समस्या firewall का कोई नियम होता है।

सबसे तेज रास्ता एक ऐसी जाँच है जो छह वजहों को दो समूहों में बाँट देती है, और फिर हर शाखा के लिए एक जाँच।

सबसे पहले: असली जवाब पढ़ें

अपने ब्राउज़र के डेवलपर टूल खोलें, Network टैब पर जाएँ, और फाइल दोबारा अपलोड करें। async-upload.php वाली request पर नजर रखें। जो भी वापस आता है, वही आपकी डायग्नोसिस है।

आपको क्या दिखता है	इसका मतलब	कहाँ जाएँ
403 या 406, HTML बॉडी के साथ	firewall या mod_security ने request ठुकरा दी	शाखा A
500, या खाली जवाब, या अधूरी बॉडी	PHP क्रैश हो गया या बीच में मेमोरी खत्म हो गई	शाखा B
413	request बॉडी सर्वर की किसी लिमिट से बड़ी थी	शाखा C
200, लेकिन बॉडी साफ JSON नहीं है	किसी plugin या theme ने जवाब से पहले कुछ छाप दिया	शाखा D
request पूरी ही नहीं होती / टाइम आउट	execution time की लिमिट, आमतौर पर बड़ी फाइलों के साथ	शाखा B

यह एक नजर ही इंटरनेट पर मौजूद ज्यादातर सलाह को आपके लिए बाहर कर देती है। अगर आप ब्राउज़र टूल तक नहीं पहुँच सकते, तो पहले wp-config.php में लॉगिंग चालू करें:

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

अपलोड दोबारा करके देखें, फिर wp-content/debug.log पढ़ें। fatal error वाली लाइन सीधे शाखा का नाम बता देती है। अगर लाइन उलझी हुई लगे, तो उसे error log decoder में पेस्ट करें — यह आम fatal सिग्नेचरों को असली गड़बड़ी से जोड़कर दिखाता है।

शाखा A — firewall या mod_security का नियम

बॉडी में HTML पेज के साथ आया 403 बताता है कि request WordPress तक पहुँची ही नहीं। उससे पहले बैठी कोई चीज — mod_security, Cloudflare, Wordfence, Sucuri, या आपके होस्ट का अपना नियम-सेट — ने तय कर लिया कि यह POST संदिग्ध है।

जाँच यह है: किसी भी सिक्योरिटी plugin को अस्थायी रूप से निष्क्रिय करें और दोबारा अपलोड करें। अगर इससे कुछ नहीं बदलता, तो नियम सर्वर स्तर पर है, और आपको अपने होस्ट से कहना होगा कि वे फेल हुए अपलोड के टाइमस्टैम्प पर mod_security का audit log देखें। वे उस खास rule ID को whitelist कर सकते हैं।

यहाँ आपको जो सलाह मिलेगी, उसके बारे में खुद से ईमानदार रहें। वे स्निपेट जो आपसे .htaccess में यह डालने को कहते हैं:

SecFilterEngine Off
SecFilterScanPOST Off

mod_security 1.x के लिए हैं, जो लगभग खत्म हो चुका है। आधुनिक सर्वर पर ये directives या तो कुछ नहीं करतीं या 500 फेंककर साइट और बिगाड़ देती हैं। आधुनिक mod_security SecRuleEngine इस्तेमाल करता है, और ज्यादातर मैनेज्ड होस्ट वैसे भी इसे per-directory ओवरराइड करने से रोकते हैं। होस्ट से पूछें; पेस्ट न करें।

शाखा B — PHP की मेमोरी या execution लिमिट

यह सबसे आम शाखा है और इसकी पहचान सबसे साफ है: यह रुक-रुककर होती है। वही फाइल तीसरी कोशिश में चढ़ जाती है, या 2MB की फोटो फेल हो जाती है जबकि 6MB की PDF आराम से चली जाती है। सख्त कॉन्फ़िगरेशन लिमिट हर बार एक जैसी फेल होती है। मेमोरी की विफलताएँ नहीं, क्योंकि कितनी मेमोरी उपलब्ध है यह इस पर निर्भर करता है कि सर्वर और क्या कर रहा है।

इमेज के साथ ही ऐसा क्यों: WordPress सिर्फ फाइल स्टोर नहीं करता, वह हर बीच के साइज को बनाने के लिए उसे कच्चे पिक्सल में खोलता है — medium_large, add_image_size से रजिस्टर किया गया हर साइज, दुकान चलाते हैं तो woocommerce_thumbnail, और अगर इमेज big_image_size_threshold से बड़ी है तो एक -scaled कॉपी भी। 12-मेगापिक्सल की JPEG डिस्क पर कुछ MB की होती है और मेमोरी में करीब 48MB की — resize बफर से पहले ही। 128MB की लिमिट जल्दी गायब हो जाती है।

इसे wp-config.php में, “stop editing” लाइन के ऊपर बढ़ाएँ:

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

असली कीमत यह है: WP_MEMORY_LIMIT उससे ज्यादा नहीं जा सकता जितना PHP खुद इजाजत देता है। अगर आपका होस्ट memory_limit को 128M पर बाँध रखा है, तो यह constant सिर्फ दिखावा है। असली मान Tools → Site Health → Info → Server में देखें, उसमें नहीं जो आपने लिखा है। अगर PHP की अपनी लिमिट ही छत है, तो उसे सिर्फ होस्ट बढ़ा सकता है।

शाखा C — फाइल साइज और post की लिमिट

असली आँकड़े Tools → Site Health → Info → Media Handling में देखें। दो सेटिंग्स मायने रखती हैं और लोग हमेशा सिर्फ एक बदलते हैं:

• upload_max_filesize — एक अकेली फाइल की सीमा।
• post_max_size — पूरी request बॉडी की सीमा।

अगर पूरा POST post_max_size से बड़ा है, तो WordPress का कोई कोड चलने से पहले ही PHP request फेंक देता है। लौटाने को कुछ बचता ही नहीं, इसलिए uploader को ऐसा जवाब मिलता है जिसे वह पढ़ नहीं सकता और वह कह देता है “HTTP error”। post_max_size हमेशा upload_max_filesize से ठीक-ठाक बड़ा होना चाहिए।

एक बात जान लेने लायक है: जब फाइल सिर्फ upload_max_filesize से बड़ी होती है, तो uploader आमतौर पर उसे ब्राउज़र में ही पकड़ लेता है और कहता है कि फाइल अधिकतम अपलोड साइज से बड़ी है — यानी ज्यादा साफ मैसेज। इसलिए सूखा “HTTP error” ज्यादातर post_max_size या शाखा B की तरफ इशारा करता है, न कि उस सेटिंग की तरफ जिसे सब सबसे पहले बढ़ाते हैं।

इन्हें कहाँ बदला जाए, यह आपके स्टैक पर निर्भर करता है। mod_php वाले Apache पर .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 भी लागू करता है, जिसे सिर्फ होस्ट बढ़ा सकता है।

शाखा D — image editor लाइब्रेरी (Imagick बनाम GD)

PHP एक्सटेंशन मौजूद होने पर WordPress ImageMagick को प्राथमिकता देता है और न होने पर GD पर लौटता है। शेयर्ड होस्ट पर ImageMagick अक्सर ही समस्या होता है: उसकी policy कॉन्फ़िगरेशन फाइल हर ऑपरेशन के लिए मेमोरी, डिस्क और एरिया सीमित कर देती है, और जब resize इनमें से किसी सीमा से टकराता है तो प्रोसेस बिना कोई काम का मैसेज दिए मर जाता है। यह आमतौर पर बड़ी इमेज पर दिखता है जबकि छोटी चल जाती हैं — जो देखने में शाखा B जैसा लगता है, पर है नहीं।

इस अंदाजे को जाँचने के लिए GD को जबरन चालू करें:

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

इसे functions.php में या एक छोटे mu-plugin में डालें, अपलोड दोबारा करें, और अगर कुछ न बदले तो हटा दें।

ईमानदार समझौता यह है: GD हर हाल में बेहतर नहीं है। वह पूरी बिना-कंप्रेस की बिटमैप PHP की मेमोरी में रखता है, इसलिए बहुत बड़ी फाइलों पर वह memory_limit से टकरा सकता है, जबकि ImageMagick — जो कुछ काम PHP के आवंटन के बाहर करता है — सफल हो जाता। यह बदलाव एक विफलता के बदले दूसरी दे सकता है। इसे पहले डायग्नोसिस मानें, इलाज बाद में।

शाखा E — uploads डायरेक्टरी की permissions

मैनेज्ड होस्टिंग पर दुर्लभ, लेकिन माइग्रेशन या मैनुअल सर्वर बदलाव के तुरंत बाद आम। अगर wp-content/uploads पर वेब सर्वर यूजर के लिए लिखने की अनुमति नहीं है, या नए बने साल/महीने वाले सबफोल्डर को गलत मालिक मिल गया, तो लिखना फेल हो जाता है।

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

डायरेक्टरी आमतौर पर 755 होनी चाहिए और उसका मालिक वही यूजर जिस पर PHP चलता है। 777 सिर्फ इसलिए न सेट करें कि किसी फोरम ने कहा था — वह लक्षण इस तरह ठीक करता है कि फोल्डर सर्वर के हर अकाउंट के लिए लिखने योग्य हो जाता है, जो शेयर्ड होस्टिंग पर सचमुच का खतरा है।

शाखा F — फाइल का नाम

इस सूची की सबसे सस्ती जाँच, इसलिए इसे जल्दी कर लें भले ही इसकी संभावना सबसे कम हो। फाइल का नाम बदलकर सिर्फ छोटे अंग्रेजी अक्षर, अंक और हाइफन रखें — कोई मात्रा वाला अक्षर, apostrophe, ampersand, # या गैर-लैटिन अक्षर नहीं — और दोबारा अपलोड करें। खास अक्षर कभी-कभी किसी सिक्योरिटी नियम से टकरा जाते हैं या बेमेल एन्कोडिंग वाले फाइल सिस्टम पर टूट जाते हैं। हटाने में दस सेकंड।

क्या नहीं करना है

हर plugin बंद करने से शुरुआत न करें। यह काम में बाधा डालता है और सिर्फ शाखा A और शाखा D को जाँचता है। नेटवर्क का जवाब पाँच सेकंड में इससे ज्यादा बता देता है।

कोई भी .htaccess handler लाइन यूँ ही न जोड़ें। जो स्निपेट SetHandler या AddHandler directive जोड़ते हैं, वे किसी खास होस्ट के PHP सेटअप को मानकर चलते हैं। गलत स्टैक पर वे 500 के साथ पूरी साइट गिरा देते हैं।

“दोबारा कोशिश में चल गया” को ठीक होना न मानें। रुक-रुककर मिलने वाली सफलता शाखा B की पहचान है, और सर्वर के व्यस्त होते ही या किसी के बड़ी फाइल चढ़ाते ही यह लौट आएगी।

फिर भी अटके हुए हैं?

अगर जवाब साफ 200 है और JSON भी सही है, फिर भी अपलोड फेल हो रहा है, तो गड़बड़ फाइल पहुँचने के बाद हो रही है — आमतौर पर attachment-प्रोसेसिंग चेन में हुक हुआ कोई plugin fatal फेंक रहा होता है, या कोई optimizer plugin किसी बाहरी सेवा को अपनी request भेजकर टाइम आउट हो रहा होता है। WP_DEBUG_LOG चालू करें, समस्या दोबारा पैदा करें, और निकली हुई fatal error को error log decoder में चलाकर देखें कि असल में कौन-सी फाइल और कौन-सा hook जिम्मेदार है।