خطای 413 در وردپرس هنگام آپلود فایل یعنی یکی از لایه‌های دریافت درخواست، اندازه بدنه را بیش از سقف مجاز دیده است. ابتدا مشخص کنید پاسخ از CDN یا پراکسی می‌آید، از Nginx است یا درخواست به PHP و وردپرس رسیده؛ سپس محدودیت همان لایه را متناسب با نیاز اصلاح کنید. افزایش memory_limit به‌تنهایی، سقف اندازه درخواست را تغییر نمی‌دهد.
این راهنما برای بارگذاری تصویر، فایل یا بسته افزونه‌ای است که با پیام Content Too Large، Payload Too Large یا Request Entity Too Large متوقف می‌شود. اگر فایل کوچک هم شکست می‌خورد، موضوع ممکن است مجوز، نوع فایل یا اجرای PHP باشد. اندازه واقعی فایل و کد پاسخ را ثبت کنید تا یک خطای متفاوت را با تغییر سقف آپلود دنبال نکنید.
پیش از هر تغییر، یک آزمون کوچک و تکرارپذیر بگیرید
یک فایل مجاز و بی‌خطر کوچک و سپس نمونه‌ای نزدیک به حجم مشکل‌دار را در همان بخش سایت امتحان کنید. نوع فایل و مسیر بارگذاری باید یکسان باشد. اگر تصویر کوچک موفق است اما فایل بزرگ‌تر 413 می‌دهد، اندازه درخواست سرنخ قوی‌تری است. اگر هر دو خطا دارند، متن پیام و گزارش سرویس را هم بررسی کنید؛ نام خطا در رابط کاربری همیشه کد واقعی پاسخ نیست.
در ابزار توسعه مرورگر، بخش Network را قبل از ارسال باز کنید و درخواست شکست‌خورده را ببینید. کد وضعیت، نشانی، زمان و متن پاسخ را ثبت کنید. داده فرم ممکن است حاوی اطلاعات خصوصی باشد؛ هنگام ارسال تصویر برای پشتیبانی، بخش‌های غیرضروری را بپوشانید. برای این بررسی نیازی به انتشار فایل شخصی یا تکرار بارگذاری ده‌ها فایل حجیم ندارید.
| لایه | محدودیت مرتبط | چه کسی بررسی کند؟ |
|---|---|---|
| CDN، WAF یا پراکسی بیرونی | اندازه بدنه مجاز همان سرویس | مدیر سرویس و مستندات پلن |
| Nginx | client_max_body_size | مدیر وب‌سرور یا میزبان |
| PHP | upload_max_filesize و post_max_size | مدیر PHP یا پنل هاست |
| وردپرس یا افزونه | سیاست برنامه و محدودیت سایت | مدیر سایت یا توسعه‌دهنده |
| فضای موقت و سهمیه | فضا، inode یا مجوز نوشتن | مدیر میزبان؛ این خطا لزوماً 413 نیست |
۱. تعیین کنید کدام لایه درخواست را رد کرده است
متن صفحه و هدر پاسخ می‌تواند سرنخ بدهد، اما همیشه منشأ خطا را قطعی مشخص نمی‌کند. زمان درخواست را با لاگ پراکسی و وب‌سرور تطبیق دهید. اگر ردشدن پیش از رسیدن به PHP رخ داده باشد، تغییر تنظیمات وردپرس در همان مرحله اثری ندارد. در هاست اشتراکی، این مقایسه معمولاً به کمک پشتیبانی نیاز دارد.
از پشتیبانی بخواهید بگوید درخواست تا کدام لایه رسیده و سقف مؤثر آن مسیر چقدر است. اگر سایت پشت CDN است، محدودیت همان سرویس و پلن را از مستندات رسمی ببینید؛ یک عدد ثابت برای همه ارائه‌دهندگان معتبر نیست. تغییر عمومی DNS یا کنارزدن محافظت سایت، اولین آزمون لازم برای پیدا کردن یک سقف اندازه نیست.
۲. در Nginx، محدودیت مسیر واقعی را بررسی کنید
دستور client_max_body_size اندازه مجاز بدنه درخواست را کنترل می‌کند و می‌تواند در زمینه http، server یا location قرار بگیرد. بنابراین تغییر در یک بلوک نامرتبط ممکن است روی مسیر آپلود شما اثری نگذارد. در تنظیمات دارای include، مقدار مؤثر و بلوک انتخاب‌شده برای همان دامنه و مسیر را مشخص کنید؛ محل فایل‌ها در همه نصب‌ها یکسان نیست.
نمونه زیر فقط یک مقدار آموزشی است. آن را بر اساس بزرگ‌ترین درخواست مجاز و حاشیه لازم انتخاب کنید و در زمینه صحیح نصب خودتان قرار دهید. برای یک نیاز کوچک، برداشتن کامل سقف منطقی نیست. قرار دادن صفر بررسی اندازه را در Nginx غیرفعال می‌کند و راه‌حل پیش‌فرض این راهنما نیست.
client_max_body_size 40m;پیش از تغییر، نسخه‌ای از تنظیمات فعلی داشته باشید. پس از ویرایش، مدیر سرور باید صحت پیکربندی را آزمایش کند. در نصب رایج دارای systemd، پس از موفقیت آزمون می‌توان reload مناسب سرویس را انجام داد. اگر آزمون خطا دارد، اول همان خطا را اصلاح کنید و سرویس فعال را با تنظیم نامعتبر جایگزین نکنید.
sudo nginx -t
sudo systemctl reload nginxدو فرمان بالا را با این ترتیب و فقط پس از بررسی موفقیت فرمان نخست اجرا کنید. راه‌اندازی مجدد کل VPS برای تغییر یک محدودیت، معمولاً دامنه اختلال بیشتری ایجاد می‌کند. در هاست مدیریت‌شده، ویرایش فایل‌های تولیدشده توسط پنل ممکن است بازنویسی شود؛ از روش رسمی همان پنل استفاده کنید.
۳. سقف PHP را با اندازه کل درخواست هماهنگ کنید
upload_max_filesize سقف هر فایل را مشخص می‌کند و post_max_size به مجموع داده POST مربوط است. اندازه درخواست می‌تواند از اندازه فایل بیشتر باشد، چون فرم و سربار انتقال هم دارد. به همین دلیل برابر قراردادن دو عدد، همیشه حاشیه کافی برای بارگذاری نزدیک سقف ایجاد نمی‌کند. مقادیر باید با محدودیت لایه‌های بیرونی و نیاز برنامه هماهنگ باشند.
upload_max_filesize = 32M
post_max_size = 40Mاین اعداد نمونه‌اند و نسخه مناسب همه سایت‌ها نیستند. تنظیم مؤثر PHP وب را در بخش مجاز پنل یا اطلاعات محیط وردپرس بررسی کنید. خروجی php -i در ترمینال ممکن است مربوط به PHP خط فرمان با فایل تنظیمات دیگری باشد. یک تغییر موفق در CLI الزاماً محدودیت PHP-FPM یا پردازش وب را تغییر نداده است.
memory_limit، زمان اجرا و محدودیت ورودی نیز ممکن است برای پردازش بعد از دریافت فایل مطرح شوند، اما با سقف حجم درخواست یکسان نیستند. اگر آپلود موفق شده ولی تولید بندانگشتی خطا می‌دهد، وارد مرحله پردازش تصویر شده‌اید. به‌جای بالا بردن همه اعداد، لاگ و مصرف همان عملیات را بررسی کنید.
۴. در وردپرس و هاست اشتراکی چه کار کنیم؟
عدد حداکثر آپلود نمایش‌داده‌شده در بخش رسانه را ببینید، اما آن را تضمین عبور از CDN و وب‌سرور ندانید. در پنل هاست، بخش تنظیمات PHP دامنه صحیح و نسخه فعال آن را انتخاب کنید. اگر اجازه تغییر ندارید، درخواست دقیق به میزبان بدهید: نشانی مسیر، نوع فایل، حجم تقریبی، ساعت آزمون و کد 413 را بفرستید.
افزونه‌ای که فقط سقف گزارش‌شده وردپرس را تغییر می‌دهد نمی‌تواند همه لایه‌های بالادستی را اصلاح کند. دست‌کاری functions.php با قطعه کد ناشناخته نیز جای تنظیم صحیح میزبان نیست. برای فایل‌های قابل فشرده‌سازی، کاهش حجم منطقی یا استفاده از ابزار رسمی انتقال فایل می‌تواند مسیر مناسب‌تری باشد، ولی باید با روش نصب و پردازش برنامه سازگار باشد.
۵. اگر هنوز مشکل باقی است، خطاهای مشابه را جدا کنید
درخواستی که به زمان‌پایان می‌رسد یا پاسخ 502 و 504 می‌گیرد ممکن است به منابع، ارتباط upstream یا مدت پردازش مربوط باشد. فایل غیرمجاز نیز می‌تواند پیام متفاوتی در خود وردپرس ایجاد کند. هر بار کد تازه و مرحله توقف را بررسی کنید؛ رفع 413 شاید فقط اجازه دهد به خطای بعدی که قبلاً پنهان بوده برسید.
فضای دیسک، inode، فضای موقت PHP و سهمیه حساب نیز روی ذخیره فایل اثر دارند. وجود فضای آزاد در یک پارتیشن، سلامت مسیر موقت روی پارتیشن دیگر را ثابت نمی‌کند. اگر پیام مربوط به نوشتن فایل یا فضای ذخیره‌سازی است، آن را با افزایش client_max_body_size دنبال نکنید؛ گزارش همان مسیر و مجوزها لازم است.
آزمون نهایی: هم فایل مجاز و هم سقف محافظتی را بررسی کنید
پس از تغییر، یک فایل مجاز زیر سقف موردنظر را در همان مسیر بارگذاری کنید. نمایش فایل و در صورت نیاز پردازش بعدی را بررسی کنید. در محیط آزمایشی می‌توانید ردشدن نمونه کمی بالاتر از سقف را هم بسنجید تا معلوم شود محدودیت محافظتی هنوز کار می‌کند. این آزمون را با فایل بی‌خطر و تعداد محدود انجام دهید.
مقادیر قبلی و جدید، محل تغییر و نتیجه را ثبت کنید. اگر چند دامنه روی همان سرور دارید، مراقب اثر تنظیم سراسری باشید. برای یک سایت، تغییر محدود در زمینه مناسب معمولاً کنترل‌پذیرتر است. بعد از رفع نیز لاگ و مصرف فضای موقت را در بار واقعی دنبال کنید تا مشکل از صرفاً «آپلود شد» فراتر بررسی شود.
برای رسیدگی تنظیمات میزبان از مدیریت سایت و سرور آفاق هاست استفاده کنید. انتخاب هاست لینوکس نیز باید بر اساس حجم و شیوه واقعی پردازش فایل باشد، نه فقط یک عدد بزرگ برای سقف آپلود.
پرسش‌های رایج درباره خطای 413
آیا افزایش حافظه PHP خطای 413 را رفع می‌کند؟
به‌تنهایی خیر. ابتدا لایه‌ای را که بدنه درخواست را رد می‌کند مشخص کنید و سقف همان لایه را اصلاح کنید.
چرا فایل ۳۲ مگابایتی با سقف POST برابر ۳۲ مگابایت رد می‌شود؟
بدنه درخواست شامل فایل و داده‌های دیگر فرم است. سقف مجموع درخواست باید حاشیه مناسب داشته باشد و محدودیت لایه‌های قبلی هم بررسی شود.
آیا برای رفع مشکل باید محدودیت را نامحدود کنم؟
خیر. اندازه موردنیاز را مشخص کنید و سقف کنترل‌شده بگذارید. حذف عمومی محدودیت، علت و نیاز واقعی را روشن نمی‌کند.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.