TL;DR - Cách sửa nhanh
Bạn gặp lỗi này vì dữ liệu bạn đang gửi—thường là hình ảnh hoặc video lớn—vượt quá dung lượng mà PHP được cấu hình để chấp nhận. Để khắc phục, bạn cần tăng hai cài đặt cụ thể trong tệp php.ini của mình.
- Tìm tệp
php.inicủa bạn (thường nằm ở/etc/php/8.x/fpm/hoặc/etc/php/8.x/apache2/). - Thiết lập
post_max_size = 64M(hoặc bất kỳ dung lượng nào bạn cần). - Thiết lập
upload_max_filesize = 64M. - Khởi động lại web server (ví dụ:
sudo systemctl restart php-fpm).
Tại sao lỗi này lại có vẻ khác biệt
Thông báo lỗi đề cập đến "Unknown on line 0" vì một lý do cụ thể. PHP kích hoạt cảnh báo này trong giai đoạn khởi động request, trước khi nó bắt đầu thực thi script của bạn. Vào thời điểm code của bạn chạy bình thường, PHP đã nhận ra dữ liệu gửi đến quá lớn. Sau đó, nó sẽ xóa các biến siêu toàn cục $_POST và $_FILES để tự bảo vệ.
Nếu bạn thấy cảnh báo này, script của bạn sẽ hoạt động như thể người dùng đã gửi một form trống. Đây là một vấn đề gây ức chế thường gặp khi xây dựng tính năng tải lên tệp hoặc xử lý các chuỗi JSON lớn.
Các bước khắc phục chi tiết
1. Cập nhật php.ini (Cách tiêu chuẩn)
Chỉnh sửa cấu hình chính là cách tiếp cận đáng tin cậy nhất. Để tìm đúng tệp, hãy chạy lệnh php --ini trong terminal hoặc kiểm tra đường dẫn "Loaded Configuration File" trong trang phpinfo();.
; Ví dụ: Hỗ trợ tải lên 100MB
upload_max_filesize = 100M
post_max_size = 100M
Mẹo: post_max_size phải lớn hơn hoặc bằng upload_max_filesize. Nếu bạn đang tải lên cùng lúc bốn tệp 20MB, post_max_size của bạn cần ít nhất là 80MB, ngay cả khi upload_max_filesize chỉ là 25MB.
2. Cách xử lý cho Apache (.htaccess)
Người dùng shared hosting thường không thể can thiệp vào php.ini. Nếu nhà cung cấp dịch vụ cho phép ghi đè, hãy thêm các dòng sau vào tệp .htaccess trong thư mục gốc:
php_value upload_max_filesize 100M
php_value post_max_size 100M
3. Nginx và lỗi 413
Việc tăng giới hạn của PHP không phải lúc nào cũng đủ nếu bạn sử dụng Nginx làm reverse proxy. Nginx có giới hạn mặc định riêng là 1MB. Nếu một request vượt quá mức này, Nginx có thể chặn nó trước khi PHP kịp nhận diện, thường sẽ trả về lỗi "413 Request Entity Too Large".
Mở cấu hình site Nginx của bạn (ví dụ: /etc/nginx/sites-available/default) và thêm client_max_body_size vào khối server:
server {
client_max_body_size 100M;
...
}
Áp dụng các thay đổi bằng cách chạy lệnh sudo nginx -s reload.
Xác minh: Liệu nó đã thực sự hoạt động?
Đừng chỉ tin vào tệp cấu hình. Hãy xác minh các thiết lập đang thực thi bằng cách tạo một script PHP tạm thời:
<?php
echo "Giới hạn tải lên: " . ini_get('upload_max_filesize') . "<br>";
echo "Giới hạn Post: " . ini_get('post_max_size');
?>
Nếu các con số không khớp với thay đổi của bạn, có khả năng bạn đã chỉnh sửa nhầm tệp php.ini. Nhiều hệ thống duy trì các tệp cấu hình riêng biệt cho CLI (terminal) và web server (FPM/Apache).
Các lưu ý cuối cùng
Hãy chú ý đến memory_limit của bạn. Trong khi post_max_size xử lý dữ liệu thô, script của bạn vẫn có thể bị crash nếu nó cố gắng xử lý dữ liệu đó—chẳng hạn như thay đổi kích thước một hình ảnh độ phân giải cao—hoàn toàn trong bộ nhớ. Thông thường, memory_limit nên cao hơn post_max_size.
Quản lý các giá trị này trên các môi trường khác nhau có thể trở nên lộn xộn. Nếu bạn đang lưu trữ các cài đặt trong tệp YAML hoặc JSON để triển khai tự động, tôi khuyên bạn nên sử dụng YAML ↔ JSON Converter trên ToolCraft. Đó là một cách đơn giản để kiểm tra cú pháp và đảm bảo các script triển khai của bạn không bị lỗi do một tab hoặc dấu ngoặc thừa.
Lastly, tránh đặt các giới hạn này thành 2GB chỉ để cho "an toàn". Giới hạn cao khiến máy chủ của bạn dễ bị tấn công Từ chối dịch vụ (DoS). Kẻ tấn công có thể làm tràn ngập máy chủ của bạn bằng các request khổng lồ để làm cạn kiệt không gian đĩa hoặc bộ nhớ. Hãy chỉ đặt giá trị nhỏ nhất mà người dùng của bạn thực sự cần.