الخطأ 413 يأتي من خادم الويب لا من شفرتك. قُطع الطلب قبل أن يبلغ PHP، ولهذا لا يظهر شيء في سجلّ التطبيق، ولهذا لا يغيّر رفعُ upload_max_filesize وحده شيئًا.

Nginx

# in http, server or location
client_max_body_size 64M;

sudo nginx -t && sudo systemctl reload nginx

القيمة الافتراضية 1M. وهي الحدّ الذي يصطدم به الجميع تقريبًا أوّلًا.

وPHP، كلا القيمتين

; php.ini
upload_max_filesize = 64M
post_max_size = 68M       ; must exceed upload_max_filesize
memory_limit = 128M
max_execution_time = 300
يجب أن يكون post_max_size أكبر من upload_max_filesize، لأن الطلب يحمل الملفّ وبقيّة النموذج معه. اجعلهما متساويين، ويفشل ملفّ عند الحدّ بالضبط بلا أي رسالة مفيدة إطلاقًا.

وApache وLiteSpeed

# .htaccess
LimitRequestBody 67108864
php_value upload_max_filesize 64M
php_value post_max_size 68M

ثم تأكّد ممّا حُمِّل فعلًا

php -i | grep -E 'upload_max_filesize|post_max_size'   # the CLI, which may differ
# and from the web, in a temporary file:
# <?php echo ini_get('upload_max_filesize');
سطر الأوامر وخادم الويب يقرآن ملفَّي ini مختلفَين. تغييرٌ يظهر في php -i ولا يظهر في المتصفّح يعني أنك عدّلت الملفّ الخطأ — وافحص مجلّد تجمّعات PHP-FPM أيضًا.

وأعِد التحميل بعد كل تغيير

sudo systemctl reload php8.3-fpm nginx
على استضافة EGPHP تُضبَط هذه الحدود لكل خطة ويمكن رفعها من اللوحة. انظر أيضًا حدّ رفعٍ يتجاهل ملفّ php.ini الخاصّ بك.