رفع خطای 413 Request Entity Too Large در وردپرس؛ آموزش NGINX و PHP

اگر هنگام آپلود قالب، افزونه، فایل رسانه‌ای یا بکاپ در وردپرس با خطای 413 Request Entity Too Large روبه‌رو می‌شوید، مشکل معمولاً از خود وردپرس نیست. این خطا یعنی یکی از لایه‌های جلوی درخواست — اغلب NGINX و گاهی محدودیت‌های PHP یا کنترل‌پنل — اندازه درخواست را بیشتر از حد مجاز تشخیص داده و آن را رد کرده است.

راه درست این نیست که چند مقدار را کورکورانه روی 1G بگذارید. ابتدا باید مشخص کنید درخواست در کدام لایه متوقف می‌شود، سپس فقط همان سقف را به اندازه منطقی افزایش دهید و بعد از تغییر، کانفیگ را تست کنید.

خلاصه راه‌حل 413 در وردپرس

1. اندازه فایل و مسیر آپلود را مشخص کنید.
2. اگر NGINX دارید، مقدار client_max_body_size را بررسی کنید.
3. در PHP، upload_max_filesize و post_max_size را با هم هماهنگ کنید.
4. قبل از Reload، کانفیگ NGINX را با nginx -t تست کنید.
5. PHP-FPM و NGINX را Reload کنید.
6. با یک فایل کمی کوچک‌تر و کمی بزرگ‌تر از سقف جدید تست کنید تا مطمئن شوید محدودیت همان چیزی است که انتظار دارید.

طبق مستندات رسمی NGINX، مقدار پیش‌فرض client_max_body_size برابر 1m است و اگر بدنه درخواست از سقف تعریف‌شده بزرگ‌تر باشد، NGINX پاسخ 413 برمی‌گرداند.

سناریوی واقعی: چرا آپلود 200 مگابایت شکست می‌خورد؟

فرض کنید می‌خواهید یک فایل بکاپ 200 مگابایتی را در وردپرس آپلود کنید. در PHP مقدار upload_max_filesize=256M است، اما NGINX هنوز روی 100M محدود شده. در این حالت درخواست اصلاً به PHP و وردپرس نمی‌رسد و NGINX آن را با 413 رد می‌کند.

برعکس، اگر NGINX روی 256M باشد ولی post_max_size در PHP فقط 64M باشد، ممکن است دیگر 413 نبینید اما آپلود در PHP شکست بخورد یا داده‌های $_POST و $_FILES مطابق انتظار در دسترس نباشند.

پیش‌نیازها و احتیاط قبل از تغییر

• دسترسی SSH با کاربر دارای sudo یا دسترسی کنترل‌پنل هاست.
• دانستن نوع وب‌سرور: NGINX، Apache یا ترکیبی مثل NGINX Reverse Proxy + Apache.
• دانستن نسخه PHP و سرویس PHP-FPM فعال.
• تهیه نسخه پشتیبان از فایل کانفیگی که قرار است تغییر کند.

اگر سایت روی هاست اشتراکی است و به کانفیگ اصلی وب‌سرور دسترسی ندارید، تغییرات باید از طریق کنترل‌پنل یا پشتیبانی میزبان انجام شود. برای آشنایی با ساختار کنترل‌پنل‌ها، مقاله راهنمای WHM و cPanel را ببینید.

مرحله 1: بفهمید خطا از کدام لایه است

بررسی Header و لاگ وب‌سرور

اگر به سرور دسترسی دارید، هم‌زمان با تکرار آپلود، لاگ NGINX را مشاهده کنید:

sudo tail -f /var/log/nginx/error.log

در بسیاری از نصب‌ها برای درخواست بزرگ، پیامی شبیه زیر خواهید دید:

client intended to send too large body

این نشانه قوی است که محدودیت NGINX قبل از PHP فعال شده است.

پیدا کردن کانفیگ مؤثر NGINX

برای دیدن کانفیگ نهایی و Includeهای فعال:

sudo nginx -T 2>&1 | grep -n "client_max_body_size"

اگر چند مقدار می‌بینید، Context مهم است. این Directive می‌تواند در سطح http، server یا location تعریف شود و مقدار نزدیک‌تر به Location موردنظر می‌تواند رفتار نهایی را تعیین کند.

برای درک بهتر ساختار کانفیگ NGINX، آموزش تنظیمات و بهینه‌سازی وب‌سرور NGINX نیز مرتبط است.

مرحله 2: افزایش امن client_max_body_size در NGINX

برای یک سایت وردپرسی که به آپلود فایل‌های حداکثر 256 مگابایت نیاز دارد، می‌توانید در بلاک server سایت مقدار زیر را قرار دهید:

server {
    server_name example.com www.example.com;

    client_max_body_size 256M;

    # سایر تنظیمات سایت
}

قرار دادن مقدار در server معمولاً بهتر از افزایش سراسری در http است، چون سقف را فقط برای همان Virtual Host بالا می‌برد.

قبل از Reload حتماً Syntax را تست کنید

sudo nginx -t

خروجی سالم معمولاً شامل این دو پیام است:

syntax is ok
test is successful

فقط بعد از موفق بودن تست:

sudo systemctl reload nginx

از restart غیرضروری استفاده نکنید. Reload در حالت معمول کانفیگ جدید را با اختلال کمتر اعمال می‌کند.

مرحله 3: محدودیت‌های PHP را هماهنگ کنید

برای آپلود فایل بزرگ، فقط upload_max_filesize کافی نیست. طبق PHP Manual، مقدار post_max_size باید از upload_max_filesize بزرگ‌تر باشد. همچنین PHP توصیه می‌کند memory_limit در حالت عمومی از post_max_size بزرگ‌تر در نظر گرفته شود.

نمونه منطقی برای فایل حداکثر 256M:

upload_max_filesize = 256M
post_max_size = 280M
memory_limit = 512M

نیازی نیست همه سایت‌ها این مقادیر را داشته باشند؛ سقف را بر اساس کاربرد واقعی انتخاب کنید.

فایل php.ini فعال را پیدا کنید

روی CLI:

php --ini

اما توجه کنید PHP CLI و PHP-FPM ممکن است فایل‌های پیکربندی متفاوتی داشته باشند. برای دیدن تنظیمات PHP-FPM می‌توانید بسته به توزیع و نسخه PHP از این روش‌ها کمک بگیرید:

php-fpm8.4 -i | grep -E "Loaded Configuration|upload_max_filesize|post_max_size"

نام باینری ممکن است روی سرور شما متفاوت باشد.

Reload کردن PHP-FPM

مثلاً برای PHP 8.4 روی Ubuntu/Debian:

sudo systemctl reload php8.4-fpm

سپس وضعیت سرویس را بررسی کنید:

systemctl is-active php8.4-fpm

خروجی مورد انتظار:

active

اگر با نسخه PHP یا سازگاری آن در وردپرس مشکل دارید، مقاله رفع خطای عدم تطابق نسخه PHP در وردپرس را مطالعه کنید.

مرحله 4: اگر Apache دارید چه کار کنید؟

خطای 413 فقط مخصوص NGINX نیست، اما دستور client_max_body_size مخصوص NGINX است. روی Apache یا هاست‌های مدیریت‌شده ممکن است محدودیت از PHP، WAF، Reverse Proxy، CDN یا سیاست سرویس‌دهنده اعمال شود.

اگر معماری شما NGINX جلوی Apache دارد، بالا بردن محدودیت Apache یا PHP به‌تنهایی مشکل را حل نمی‌کند؛ لایه جلویی باید ابتدا درخواست را بپذیرد.

مرحله 5: WordPress را هم بررسی کنید

بعد از اعمال تنظیمات، در پنل وردپرس به رسانه ← افزودن بروید و مقدار «حداکثر اندازه پرونده برای بارگذاری» را ببینید. اگر هنوز سقف قدیمی نمایش داده می‌شود، تنظیم PHP مؤثر نشده یا کنترل‌پنل/Pool دیگری در حال سرویس‌دهی است.

برای تست دقیق‌تر از WP-CLI:

wp eval 'echo ini_get("upload_max_filesize") . PHP_EOL; echo ini_get("post_max_size") . PHP_EOL;'

این تست مقدارهایی را نشان می‌دهد که PHP مورد استفاده وردپرس واقعاً می‌بیند.

تست نهایی: مطمئن شوید واقعاً 413 رفع شده است

پس از تغییر، سه تست انجام دهید:

1. یک فایل کوچک مثلاً 5MB آپلود کنید؛ باید بدون خطا انجام شود.
2. یک فایل نزدیک سقف، مثلاً 240MB برای سقف 256M، تست کنید.
3. در محیط آزمایشی یک فایل کمی بزرگ‌تر از سقف بفرستید تا مطمئن شوید محدودیت امنیتی هنوز وجود دارد و بی‌نهایت نشده است.

هم‌زمان لاگ‌ها را بررسی کنید:

sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u nginx --since "10 minutes ago"

خطاهای رایج هنگام رفع 413

1. تغییر php.ini ولی خطا همچنان 413 است

احتمالاً NGINX قبل از PHP درخواست را رد می‌کند. ابتدا client_max_body_size مؤثر را با nginx -T پیدا کنید.

2. تغییر client_max_body_size ولی آپلود هنوز شکست می‌خورد

اگر دیگر 413 ندارید، محدودیت بعدی احتمالاً PHP، WordPress، افزونه آپلود/بکاپ، WAF یا سرویس واسط است. post_max_size و upload_max_filesize را از Runtime واقعی بررسی کنید.

3. nginx -t خطا می‌دهد

Reload نکنید. شماره خطا و فایل کانفیگ را اصلاح کنید و دوباره nginx -t بزنید. این مهم‌ترین نقطه Recovery قبل از اعمال کانفیگ خراب است.

4. مقدار را 0 یا چند گیگابایت گذاشته‌ام؛ آیا بهتر است؟

خیر. حذف یا بسیار بزرگ کردن محدودیت بدون نیاز واقعی می‌تواند مصرف پهنای باند، دیسک موقت و منابع پردازشی را در برابر درخواست‌های بزرگ افزایش دهد. سقف را متناسب با کاربرد سایت تعیین کنید.

Rollback؛ اگر بعد از تغییر مشکل ایجاد شد

قبل از ویرایش از فایل سایت نسخه پشتیبان بگیرید:

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak

اگر کانفیگ جدید مشکل داشت:

sudo cp /etc/nginx/sites-available/example.com.bak /etc/nginx/sites-available/example.com
sudo nginx -t && sudo systemctl reload nginx

برای PHP نیز مقدارهای قبلی را برگردانید و PHP-FPM را Reload کنید.

نکات امنیتی و Performance

• سقف آپلود را فقط به‌اندازه نیاز واقعی افزایش دهید.
• اگر فقط یک سایت یا یک Location به فایل بزرگ نیاز دارد، محدودیت را سراسری بالا نبرید.
• آپلودهای بسیار بزرگ را در صورت امکان خارج از PHP و با روش‌های chunked/object storage مدیریت کنید.
• بعد از تغییر، مصرف دیسک موقت، Timeout و لاگ خطا را زیر نظر بگیرید.
• اگر 413 در لایه CDN/WAF ایجاد می‌شود، تغییر NGINX روی Origin ممکن است هیچ اثری نداشته باشد.

چه زمانی ارتقای هاست یا VPS منطقی است؟

اگر مرتب با فایل‌های حجیم، بکاپ‌های بزرگ یا عملیات سنگین وردپرس کار می‌کنید و محدودیت‌ها از سطح سرویس اشتراکی اعمال می‌شوند، داشتن دسترسی بیشتر به تنظیمات وب‌سرور و PHP می‌تواند مدیریت را ساده‌تر کند. برای سایت‌های وردپرسی معمولی، پلن‌های هاست وان‌سرور مرتبط‌اند؛ برای سناریوهایی که به کنترل کامل NGINX/PHP نیاز دارند، VPS وان‌سرور انتخاب متناسب‌تری است.

جمع‌بندی

برای رفع اصولی خطای 413 در وردپرس، اول مشخص کنید کدام لایه درخواست را رد می‌کند. در NGINX، client_max_body_size عامل مستقیم و رایج است؛ در PHP نیز post_max_size باید بزرگ‌تر از upload_max_filesize تنظیم شود. بعد از هر تغییر، nginx -t، Reload سرویس‌ها، Runtime PHP و یک آپلود واقعی را بررسی کنید. این روش هم مشکل را حل می‌کند و هم از باز کردن بی‌دلیل محدودیت‌های سرور جلوگیری می‌کند.