413 Request Entity Too Large — Vì sao sửa rồi vẫn lỗi

Có bao nhiêu lớp giới hạn?

Bảng này là phần cốt lõi. Hiểu nó là bạn tự xử lý được gần như mọi trường hợp.

Sửa ở Nginx

Với Nginx đây là lớp bạn chạm đầu tiên, vì mặc định 1 MB còn nhỏ hơn một tấm ảnh chụp bằng điện thoại hiện nay.

Thêm chỉ thị client_max_body_size. Nó đặt được trong khối http (toàn máy chủ), khối server (một site) hoặc khối location (một đường dẫn) — ví dụ 64m hoặc 128m, theo đúng nhu cầu thật.

Luôn kiểm tra bằng "nginx -t" trước khi reload. Khởi động lại khi tệp cấu hình sai cú pháp sẽ khiến dịch vụ không lên và website sập ngay lập tức.

Một cái bẫy: nếu chỉ thị xuất hiện ở nhiều nơi, khối cụ thể hơn sẽ thắng. Nếu bạn đã nâng ở http mà không thấy đổi, hãy tìm giá trị cũ còn sót trong khối server hoặc location xử lý đường dẫn tải lên.

Sửa ở PHP — và cái bẫy hầu như ai cũng dính

PHP có hai thiết lập phải đổi cùng nhau, và đây chính là chỗ người ta hay sửa thiếu nhất.

upload_max_filesize giới hạn từng tệp riêng lẻ. post_max_size giới hạn toàn bộ phần thân request. Quy tắc là post_max_size phải lớn hơn upload_max_filesize, vì request còn mang theo dữ liệu biểu mẫu bên cạnh tệp.

Và nếu biểu mẫu tải lên nhiều tệp cùng lúc, post_max_size phải phủ được tổng của tất cả, không phải chỉ tệp lớn nhất. Người đặt cả hai là 50 MB rồi tải ba tệp 20 MB vẫn sẽ gặp lỗi.

Đổi ở đâu: php.ini nếu bạn có quyền, còn không thì .user.ini hoặc .htaccess tùy host cho phép. Nếu chạy PHP-FPM, bạn phải khởi động lại php-fpm chứ không chỉ reload máy chủ web — chi tiết này là lý do nhiều người tin rằng chỉnh sửa của mình bị bỏ qua.

Kiểm chứng giá trị đã có hiệu lực bằng phpinfo() hoặc "php -i" thay vì đoán. Hệ thống thường có nhiều tệp php.ini, và tệp thực sự được nạp có thể không phải tệp bạn vừa sửa.

Cái bẫy Cloudflare

Nếu website chạy qua proxy Cloudflare thì còn một giới hạn nữa hoàn toàn không nằm trên máy chủ của bạn.

Gói miễn phí giới hạn kích thước request khoảng 100 MB, các gói trả phí có trần riêng. Bất kỳ thứ gì lớn hơn đều bị từ chối trước khi tới được bạn, nghĩa là chỉnh bao nhiêu ở phía máy chủ cũng vô ích.

Xác nhận rất dễ: tải lên trực tiếp vào máy chủ, bỏ qua Cloudflare, bằng cách tạm trỏ tên miền tới IP thật trong tệp hosts. Nếu thành công thì Cloudflare chính là bên giới hạn.

Cách xử lý thực tế là đừng gửi tệp lớn qua proxy — dùng một subdomain riêng đã tắt proxy cho việc tải lên, hoặc để trình duyệt tải thẳng lên object storage. Với tệp thực sự lớn thì đó vốn đã là kiến trúc tốt hơn.

Đã đổi hết mà vẫn lỗi? Kiểm tra những điều này

• Bạn khởi động lại nhầm dịch vụ. Sửa php.ini cần restart php-fpm; sửa nginx.conf cần reload nginx. Làm cái này mà quên cái kia là chuyện cực kỳ phổ biến.
• Giá trị cũ còn sống trong một khối cụ thể hơn. Bạn nâng client_max_body_size ở http, nhưng khối location xử lý tải lên vẫn giữ giá trị gốc.
• Tệp bạn sửa không phải tệp đang được nạp. Xem phpinfo() để biết đường dẫn tệp cấu hình đang dùng và giá trị hiện tại — host rất hay ghi đè ở nơi khác.
• Ứng dụng có giới hạn riêng. WordPress, DirectAdmin và nhiều framework áp giới hạn độc lập với máy chủ.
• Việc tải lên hết thời gian chứ không bị từ chối vì kích thước. Nếu vượt max_execution_time hoặc max_input_time bạn sẽ nhận một lỗi khác — thường là 504 hoặc trang trắng — trông như thể cách sửa không hiệu quả.

Nếu dùng shared hosting và không đổi được

Nói thẳng, vì đây là giới hạn mà cấu hình không giải quyết được.

Trên shared hosting bạn thường chỉnh được phía PHP qua .user.ini hoặc .htaccess, nhưng client_max_body_size là chỉ thị cấp máy chủ dùng chung cho mọi khách hàng, nên nhà cung cấp không mở cho sửa. Nếu host chặn ở 8 MB thì đó là trần.

Bạn có ba lựa chọn. Nhờ nhà cung cấp nâng giúp — một số nơi sẽ làm. Đổi hẳn cách tải lên, đưa tệp lên object storage hoặc qua SFTP rồi để ứng dụng đi lấy. Hoặc chuyển sang VPS nơi mọi tệp cấu hình đều là của bạn.

Với tệp thực sự lớn thì lựa chọn thứ hai thường tốt nhất bất kể bạn dùng hosting gì, vì đẩy hàng trăm megabyte qua một request HTTP duy nhất vốn đã mong manh dù đặt giới hạn cao đến đâu.