خطای آپلود exceeds the upload_max_filesize

پاسخ کوتاه: خطای The uploaded file exceeds the upload_max_filesize directive in php.ini یعنی حجم فایلی که فرستاده‌اید از سقف upload_max_filesize در تنظیمات PHP بزرگ‌تر است. برای رفع آن باید این مقدار را افزایش دهید و همزمان post_max_size را دست‌کم برابر یا بزرگ‌تر از آن قرار دهید؛ محل اعمال تغییر بسته به نوع سرویس، کنترل‌پنل، فایل php.ini، فایل .user.ini یا .htaccess است.

چهار دایرکتیوی که با هم کار می‌کنند

اشتباه رایج این است که فقط upload_max_filesize را بالا می‌برند و انتظار دارند مشکل حل شود. در عمل PHP پیش از هر چیز کل بدنهٔ درخواست POST را می‌سنجد، بعد تک‌تک فایل‌ها را، و در ادامه حافظه و زمان اجرا هم می‌توانند جلوی کار را بگیرند.

قانونی که بیشتر موارد «تنظیم کردم ولی درست نشد» را توضیح می‌دهد این است: post_max_size باید بزرگ‌تر از upload_max_filesize باشد، چون علاوه بر خود فایل، سایر فیلدهای فرم و سرآیندهای چندبخشی هم در همان بدنه جای می‌گیرند. اگر post_max_size کوچک‌تر بماند، همان عدد کوچک‌تر سقف واقعی است. دایرکتیو max_file_uploads هم تعداد فایل در یک درخواست را محدود می‌کند و به‌طور پیش‌فرض روی ۲۰ است؛ در آپلود دسته‌جمعی تصاویر همین عدد گاهی مانع می‌شود.

کدام لایه بر لایهٔ دیگر اولویت دارد

مقدار نهایی هر دایرکتیو از چند لایه به دست می‌آید و هرچه لایه اختصاصی‌تر باشد، معمولاً برنده است. در میزبانی وب اشتراکی معمولاً فقط به دو لایهٔ پایینی دسترسی دارید و بقیه در اختیار مدیر سرور است:

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

• php.ini اصلی سرور — پایهٔ همه چیز.
• پیکربندی pool در PHP-FPM — با php_admin_value تنظیم می‌شود و لایه‌های پایین‌تر نمی‌توانند آن را بازنویسی کنند.
• php.ini یا .user.ini در سطح دامنه یا پوشه — رایج‌ترین محل تغییر در میزبانی اشتراکی.
• .htaccess — فقط زمانی کار می‌کند که PHP به‌صورت ماژول آپاچی (mod_php) اجرا شود.
• ini_set در کد — برای upload_max_filesize و post_max_size کار نمی‌کند، چون این دو از نوع PHP_INI_PERDIR هستند و باید پیش از اجرای اسکریپت تعیین شوند. در مقابل memory_limit و max_execution_time را می‌توان با ini_set() یا set_time_limit() تغییر داد، مگر آنکه مدیر سرور قفلشان کرده باشد.

محل تغییر بر اساس نوع سرویس شما

میزبانی اشتراکی با سی‌پنل

در سی‌پنل معمولاً از بخش MultiPHP INI Editor — که در پیکربندی آپاچی و PHP در سطح سرور هم به آن اشاره شده — دامنه را انتخاب می‌کنید و دو مقدار upload_max_filesize و post_max_size را ویرایش می‌کنید. اگر این بخش در دسترس نبود، ابزار Select PHP Version و زبانهٔ Options همان کار را انجام می‌دهد. هر دو ابزار بخشی از خود سی‌پنل هستند و اینکه کدام‌یک برای حساب شما فعال باشد را مدیر سرور از طریق WHM تعیین می‌کند؛ اگر سرور و لایسنس سی‌پنل در اختیار خودتان است، این دسترسی را خودتان تعیین می‌کنید.

میزبانی یا سرور با دایرکت‌ادمین

در دایرکت‌ادمین بسته به نسخه و تنظیمات مدیر سرور، ممکن است گزینهٔ مدیریت تنظیمات PHP در پنل کاربری در اختیارتان باشد. اگر چنین گزینه‌ای نبود، مطمئن‌ترین راه در حالت PHP-FPM ساخت فایل .user.ini در ریشهٔ سایت (معمولاً public_html) با این محتواست:

• upload_max_filesize = 64M
• post_max_size = 68M

یک نکتهٔ مهم: PHP محتوای .user.ini را کش می‌کند و به‌طور پیش‌فرض تا ۳۰۰ ثانیه مقدار قدیمی را نگه می‌دارد، پس بلافاصله نتیجه را نبینید نگران نشوید. اگر روی سرور خودتان لایسنس دایرکت‌ادمین دارید، می‌توانید همین مقادیر را در سطح pool یا php.ini سراسری هم تنظیم کنید.

وقتی دسترسی روت دارید

روی سرور مجازی یا سرور اختصاصی، ابتدا فایل پیکربندی فعال را پیدا کنید:

php --ini

توجه کنید که خروجی این دستور مربوط به SAPI خط فرمان است و ممکن است با فایلی که وب‌سرور استفاده می‌کند فرق داشته باشد؛ برای وب باید به php.ini مربوط به FPM یا آپاچی نگاه کنید. پس از ویرایش، سرویس PHP-FPM را بازراه‌اندازی کنید (نام سرویس بسته به توزیع و نسخه فرق می‌کند، مثلاً php8.1-fpm یا php-fpm):

systemctl restart php-fpm

روش .htaccess و محدودیت آن

خط php_value upload_max_filesize 64M در .htaccess فقط با mod_php معنا دارد. اگر PHP روی سرور شما به‌شکل FPM یا CGI اجرا شود، آپاچی این دستور را نمی‌شناسد و کل سایت با خطای ۵۰۰ از کار می‌افتد. پیش از افزودن آن، از یک نسخهٔ پشتیبان فایل مطمئن شوید تا در صورت بروز خطا بتوانید سریع برگردید.

گلوگاه‌هایی که اصلاً به PHP مربوط نیستند

• Nginx: دایرکتیو client_max_body_size سقف جداگانه‌ای دارد و رد شدن از آن خطای «۴۱۳ Request Entity Too Large» می‌دهد، نه پیام PHP. روی VPS یا سرور اختصاصی که خودتان مدیر آن هستید، این مقدار را باید جداگانه در کانفیگ Nginx تغییر دهید.
• CDN یا فایروال میانی: بیشتر سرویس‌های واسط سقف حجم درخواست خودشان را دارند و این مقدار بین سرویس‌دهنده‌ها متفاوت است؛ مستندات همان سرویس را ببینید.
• ModSecurity یا قواعد امنیتی سرور که درخواست‌های بزرگ را مسدود می‌کنند.
• فضای دیسک یا سهمیهٔ حساب: اگر پارتیشن موقت پر باشد یا upload_tmp_dir قابل نوشتن نباشد، آپلود بدون دلیل روشن شکست می‌خورد.
• وردپرس شبکه‌ای (Multisite): در تنظیمات شبکه یک سقف مستقل برای حجم فایل وجود دارد که جدا از PHP اعمال می‌شود.

چطور مطمئن شویم تغییر اعمال شده است

ساده‌ترین راه در وردپرس، مسیر «ابزارها ← سلامت سایت ← اطلاعات ← سرور» است که مقادیر واقعی PHP را نشان می‌دهد؛ این خطا هم یکی از موارد فهرست‌شده در خطاهای رایج وردپرس است. روش عمومی‌تر، ساخت یک فایل موقت با تابع phpinfo() و باز کردن آن در مرورگر است؛ بلافاصله بعد از بررسی این فایل را حذف کنید، چون اطلاعات حساسی از پیکربندی سرور را فاش می‌کند. اگر به هیچ‌کدام از این لایه‌ها دسترسی ندارید، از پشتیبانی سرویس میزبانی وب خود بخواهید مقادیر را برای دامنه‌تان تغییر دهد.

چه عددی منطقی است

سقف را متناسب با نیاز واقعی سایت تعیین کنید، نه بی‌نهایت. مقدار بسیار بزرگ یعنی اتصال‌های طولانی‌تر، مصرف بیشتر دیسک موقت و سطح حملهٔ گسترده‌تر برای فرم‌های آپلود. برای فایل‌های واقعاً حجیم، انتقال با FTP یا SFTP یا مدیر فایل کنترل‌پنل هم پایدارتر است و هم به این محدودیت‌ها برنمی‌خورد. اگر مرتب با فایل‌های بزرگ کار می‌کنید، بهتر است max_execution_time و max_input_time را هم متناسب افزایش دهید تا آپلود نیمه‌کاره رها نشود.