Tệp nhỏ gửi được nhưng tệp lớn thất bại là một dấu hiệu đáng kiểm tra về giới hạn kích thước. Trước khi thay proxy, hãy đo dung lượng của cả yêu cầu gửi đi, không chỉ kích thước tệp trên ổ đĩa.
413 có nghĩa gì?
413 Content Too Large cho biết nội dung yêu cầu quá lớn đối với bên xử lý. Định nghĩa nằm ở RFC 9110. Đổi IP không tự thay đổi giới hạn đó.
Chuẩn bị phép thử an toàn
Dùng tệp không chứa dữ liệu riêng tư, cùng định dạng với tác vụ thật. Ghi kích thước theo byte, loại nội dung, cách gửi và mã phản hồi. Multipart có phần bao quanh; mã hóa base64 cũng làm dữ liệu lớn hơn. Vì vậy cần phân biệt kích thước tệp và kích thước request body.
- Thử một tệp nhỏ trong môi trường được phép.
- Tăng kích thước theo vài mức đã giới hạn, không gửi hàng loạt để dò.
- Giữ nguyên client, endpoint, tài khoản và định dạng.
- Đối chiếu nhật ký của ứng dụng với gateway để xác định yêu cầu đến lớp nào.
Kiểm tra giới hạn ở đâu?
Đối chiếu tài liệu endpoint, bộ phân tích body của ứng dụng, reverse proxy, dịch vụ biên và khả năng của tuyến proxy. Không giả định mọi lớp có cùng hạn mức. Nếu lớp đầu tiên từ chối, chỉnh lớp sau sẽ không có tác dụng.
Ví dụ minh họa
Giả sử một API nhận tệp trực tiếp, còn client mới đóng gói tệp trong JSON có base64. Yêu cầu mới lớn hơn, dù tệp nguồn không đổi. Đội phát triển cần đối chiếu hợp đồng API và cách đóng gói, thay vì lập tức mua proxy khác hoặc tăng giới hạn toàn hệ thống.
Chọn cách xử lý
Giảm dung lượng, dùng upload nhiều phần hoặc đường upload riêng chỉ khi dịch vụ hỗ trợ. Nếu quản lý hệ thống và cần tăng giới hạn, đánh giá bộ nhớ, timeout, xác thực và hạn mức lưu trữ trước; áp dụng cho route phù hợp rồi kiểm tra lại. Không chia tệp tùy ý nếu API không có cơ chế ghép và kiểm tra tính toàn vẹn.
Điều không nên làm
Không gửi lại nguyên tệp bị từ chối liên tục. Không bỏ giới hạn toàn cục để giải quyết một yêu cầu. Khi cần hỗ trợ, gửi kích thước và request ID đã che thông tin nhạy cảm, không gửi tệp khách hàng. Đọc thêm kiểm thử API qua proxy để giữ điều kiện thử nhất quán.