خطای «HTTP error» هنگام آپلود تصویر در وردپرس: درخت تصمیمی که واقعاً جواب می‌دهد

«HTTP error» یک علت نیست. اعترافِ آپلودر رسانه است به اینکه فایل شما را به سرور فرستاده و پاسخی گرفته که نتوانسته آن را به‌عنوان موفقیت بخواند — و دست‌کم شش خرابی بی‌ارتباط، دقیقاً همین یک پیام را تولید می‌کنند. حدس زدن میان آن‌ها همان دلیلی است که باعث می‌شود کسی یک بعدازظهر را صرف بالا بردن upload_max_filesize سایتی کند که مشکل واقعی‌اش یک قانون فایروال است.

سریع‌ترین راه خروج، یک مشاهده واحد است که این شش علت را به دو گروه تقسیم می‌کند، و بعد یک بررسی برای هر شاخه.

اول: پاسخ واقعی را بخوانید

ابزار توسعه‌دهنده مرورگر را باز کنید، به تب Network بروید و فایل را دوباره آپلود کنید. مراقب درخواست به async-upload.php باشید. هرچه برمی‌گردد، همان تشخیص شماست.

چیزی که می‌بینید	یعنی چه	برو به
403 یا 406 با بدنه HTML	فایروال یا mod_security درخواست را رد کرده است	شاخه A
500، یا پاسخ خالی، یا بدنه ناقص	PHP وسط کار از کار افتاده یا حافظه‌اش تمام شده است	شاخه B
413	بدنه درخواست از یک محدودیت سرور فراتر رفته است	شاخه C
200، اما بدنه JSON تمیز نیست	یک افزونه یا قالب پیش از پاسخ، خروجی چاپ کرده است	شاخه D
درخواست هیچ‌وقت تمام نمی‌شود / تایم‌اوت می‌شود	محدودیت زمان اجرا، معمولاً با فایل‌های بزرگ	شاخه B

همین یک نگاه، بیشتر توصیه‌های موجود در اینترنت را برای شما کنار می‌گذارد. اگر به ابزار مرورگر دسترسی ندارید، اول ثبت لاگ را در wp-config.php روشن کنید:

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

آپلود را دوباره انجام دهید، سپس wp-content/debug.log را بخوانید. یک خط خطای مهلک، شاخه را صریحاً نام می‌برد. اگر آن خط پیچیده بود، در رمزگشای لاگ خطا جای‌گذاری‌اش کنید — امضاهای رایج خطاهای مهلک را به چیزی که واقعاً خراب شده نگاشت می‌کند.

شاخه A — یک قانون فایروال یا mod_security

کد 403 همراه با یک صفحه HTML در بدنه یعنی درخواست اصلاً به وردپرس نرسیده است. چیزی جلوتر از آن — mod_security، Cloudflare، Wordfence، Sucuri یا مجموعه قوانین خود هاست — تصمیم گرفته که این درخواست POST مشکوک به نظر می‌رسد.

بررسی: هر افزونه امنیتی را موقتاً غیرفعال کنید و دوباره آپلود کنید. اگر چیزی عوض نشد، قانون در سطح سرور است و باید از هاست بخواهید لاگ ممیزی mod_security را برای زمان دقیق آپلود ناموفق ببیند. آن‌ها می‌توانند شناسه همان قانون مشخص را در فهرست مجاز بگذارند.

با خودتان درباره توصیه‌هایی که اینجا پیدا می‌کنید صادق باشید. تکه‌کدهایی که می‌گویند این را در .htaccess بریزید:

SecFilterEngine Off
SecFilterScanPOST Off

مربوط به mod_security نسخه ۱ هستند که تقریباً منقرض شده است. روی یک سرور امروزی این دستورها یا هیچ کاری نمی‌کنند یا خطای 500 می‌دهند و سایت را بدتر می‌کنند. mod_security امروزی از SecRuleEngine استفاده می‌کند و بیشتر هاست‌های مدیریت‌شده به‌هرحال جلوی بازنویسی آن در سطح پوشه را می‌گیرند. از هاست بپرسید؛ کورکورانه جای‌گذاری نکنید.

شاخه B — محدودیت حافظه یا زمان اجرای PHP

این رایج‌ترین شاخه است و روشن‌ترین نشانه را دارد: نامنظم است. همان فایل در تلاش سوم آپلود می‌شود، یا یک عکس ۲ مگابایتی شکست می‌خورد در حالی که یک PDF شش مگابایتی به‌راحتی بالا می‌رود. محدودیت‌های سخت پیکربندی هر بار یکسان شکست می‌خورند. شکست‌های حافظه این‌طور نیستند، چون مقدار حافظه در دسترس به کارهای دیگری که سرور مشغولشان است بستگی دارد.

چرا مشخصاً تصویرها: وردپرس فقط فایل را ذخیره نمی‌کند، بلکه آن را به پیکسل خام باز می‌کند تا همه اندازه‌های میانی را بسازد — medium_large، هر اندازه‌ای که با add_image_size ثبت شده، woocommerce_thumbnail اگر فروشگاه دارید، به‌علاوه یک نسخه -scaled اگر تصویر از big_image_size_threshold بزرگ‌تر باشد. یک JPEG دوازده‌مگاپیکسلی روی دیسک چند مگابایت است و در حافظه تقریباً ۴۸ مگابایت، آن هم پیش از بافر تغییر اندازه. یک محدودیت ۱۲۸ مگابایتی خیلی زود تمام می‌شود.

آن را در wp-config.php و بالای خط «stop editing» بالا ببرید:

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

هزینه واقعی: مقدار WP_MEMORY_LIMIT نمی‌تواند از چیزی که خود PHP اجازه می‌دهد بیشتر شود. اگر هاست شما memory_limit را روی ۱۲۸ مگابایت بسته باشد، این ثابت صرفاً تزئینی است. مقدار واقعی را در ابزارها ← سلامت سایت ← اطلاعات ← سرور ببینید، نه در چیزی که خودتان نوشته‌اید. اگر سقف واقعی محدودیت خود PHP باشد، فقط هاست می‌تواند آن را جابه‌جا کند.

شاخه C — محدودیت حجم فایل و حجم درخواست

عددهای واقعی را در ابزارها ← سلامت سایت ← اطلاعات ← مدیریت رسانه ببینید. دو تنظیم اهمیت دارند و مردم همیشه فقط یکی را عوض می‌کنند:

• upload_max_filesize — سقف یک فایل واحد.
• post_max_size — سقف کل بدنه درخواست.

اگر کل درخواست POST از post_max_size فراتر برود، PHP درخواست را پیش از اجرای هر کدی توسط وردپرس دور می‌ریزد. چیزی برای برگرداندن وجود ندارد، پس آپلودر یک پاسخ غیرقابل‌خواندن می‌گیرد و می‌گوید «HTTP error». مقدار post_max_size باید همیشه با فاصله‌ای راحت بزرگ‌تر از upload_max_filesize باشد.

یک نکته که دانستنش می‌ارزد: وقتی فایلی فقط از upload_max_filesize فراتر می‌رود، آپلودر معمولاً همان‌جا در مرورگر آن را می‌گیرد و می‌گوید فایل از حداکثر حجم مجاز بزرگ‌تر است — پیامی روشن‌تر. پس یک «HTTP error» خشک‌وخالی بیشتر به post_max_size یا به شاخه B اشاره دارد تا به تنظیمی که همه اول از همه بالا می‌برند.

اینکه کجا باید تغییرشان دهید به پشته سرور شما بستگی دارد. روی 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 خودش را هم اعمال می‌کند که فقط هاست می‌تواند بالا ببرد.

شاخه D — کتابخانه ویرایش تصویر (Imagick در برابر GD)

وردپرس وقتی افزونه PHP مربوط به ImageMagick موجود باشد آن را ترجیح می‌دهد و در غیر این صورت به GD برمی‌گردد. روی هاست‌های اشتراکی، ImageMagick اغلب خودش مشکل است: فایل پیکربندی سیاستش حافظه، دیسک و مساحت هر عملیات را محدود می‌کند و وقتی یک تغییر اندازه به یکی از این حدها بخورد، پردازه بدون پیام مفیدی می‌میرد. معمولاً این را روی تصویرهای بزرگ می‌بینید در حالی که تصویرهای کوچک کار می‌کنند — که شبیه شاخه 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

روی هاست مدیریت‌شده نادر است، اما درست بعد از یک مهاجرت یا جابه‌جایی دستی سرور رایج است. اگر wp-content/uploads برای کاربر وب‌سرور قابل نوشتن نباشد، یا زیرپوشه تازه‌ساخته‌شده سال/ماه مالک اشتباهی به ارث برده باشد، نوشتن شکست می‌خورد.

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

پوشه‌ها معمولاً باید 755 باشند و مالکشان همان کاربری باشد که PHP با آن اجرا می‌شود. فقط چون یک انجمن گفته، دسترسی را 777 نگذارید — این کار نشانه را با قابل‌نوشتن کردن پوشه برای همه حساب‌های روی سرور رفع می‌کند، که روی هاست اشتراکی یک افشای واقعی است.

شاخه F — نام فایل

ارزان‌ترین بررسی این فهرست است، پس زود انجامش دهید، حتی با اینکه کم‌احتمال‌ترین است. نام فایل را به حروف کوچک انگلیسی، عدد و خط تیره تغییر دهید — بدون حروف مصوت‌دار، آپاستروف، علامت &، # یا نویسه‌های غیرلاتین — و دوباره آپلود کنید. نویسه‌های خاص گاهی یک قانون امنیتی را فعال می‌کنند یا روی فایل‌سیستمی با کدگذاری ناهماهنگ خراب می‌شوند. ده ثانیه وقت می‌برد تا کنار گذاشته شود.

چه کارهایی نکنید

با غیرفعال کردن همه افزونه‌ها شروع نکنید. هم مخل است و هم فقط شاخه A و شاخه D را می‌آزماید. پاسخ شبکه در پنج ثانیه بیشتر به شما می‌گوید.

یک خط handler تصادفی به .htaccess اضافه نکنید. تکه‌کدهایی که دست‌به‌دست می‌شوند و دستور SetHandler یا AddHandler اضافه می‌کنند، پیکربندی PHP یک هاست خاص را فرض گرفته‌اند. روی پشته اشتباه، کل سایت را با خطای 500 پایین می‌آورند.

«با تلاش دوباره کار کرد» را به‌عنوان رفع‌شدن نپذیرید. موفقیت نامنظم امضای شاخه B است و همان لحظه‌ای که سرور شلوغ شود یا کسی فایل بزرگ‌تری آپلود کند برمی‌گردد.

هنوز گیر کرده‌اید؟

اگر پاسخ یک 200 تمیز با JSON معتبر است و آپلود باز هم شکست می‌خورد، خرابی بعد از رسیدن فایل رخ می‌دهد — معمولاً افزونه‌ای که به زنجیره پردازش پیوست وصل شده و خطای مهلک می‌دهد، یا یک افزونه بهینه‌سازی که درخواست خودش را به یک سرویس بیرونی می‌فرستد و تایم‌اوت می‌شود. WP_DEBUG_LOG را روشن کنید، مشکل را بازتولید کنید و خطای مهلک حاصل را در رمزگشای لاگ خطا بیندازید تا ببینید کدام فایل و کدام هوک واقعاً مسئول است.