lỗi 413 Content Too Large: tìm hop giới hạn kích thước upload

lỗi 413 Content Too Large là mã HTTP mà một máy chủ trả về khi phần thân request, tức dữ liệu gửi lên như tệp upload hay JSON lớn, vượt giới hạn nó chịu nhận. Khó ở chỗ request đi qua nhiều hop: client, proxy, CDN, reverse proxy rồi mới tới ứng dụng, và hop nào cũng có thể đặt giới hạn riêng. ProxyVN dựng lab gồm một origin và ba proxy có giới hạn khác nhau, gửi ba cỡ body rồi ghi lại hop nào trả mã, để anh em biết đọc dấu vết gì trước khi đi sửa cấu hình.

Nhận diện lỗi 413 Content Too Large trong response thật

Mã, tên gọi và nghĩa trong RFC 9110

Tài liệu RFC 9110 định nghĩa mã 413 với tên Content Too Large. Các tài liệu cũ hơn gọi là Request Entity Too Large hoặc Payload Too Large, nên trong log của nginx, Apache hay thư viện cũ anh em vẫn gặp ba tên khác nhau cho cùng một mã. Nghĩa không đổi: máy chủ từ chối xử lý vì nội dung request lớn hơn mức nó sẵn sàng hoặc có khả năng xử lý.

RFC còn ghi máy chủ có thể đóng kết nối để ngăn client gửi tiếp. Nếu tình trạng chỉ là tạm thời, máy chủ nên gửi kèm header Retry-After cho biết bao lâu sau thử lại được. Trong thực tế đa số máy chủ trả 413 vì giới hạn cấu hình cố định, nên Retry-After hiếm khi xuất hiện.

Trang 413 Content Too Large trên MDN tóm tắt cùng nội dung và có ví dụ response mẫu. Đọc trang này một lần là đủ để biết mã thuộc nhóm lỗi phía client: request bị từ chối do chính nó, không phải do máy chủ hỏng.

Ba dạng 413 anh em hay gặp

• Trang HTML lỗi của nginx hoặc CDN: tiêu đề kiểu 413 Request Entity Too Large, có dòng tên phần mềm ở cuối trang. Dạng này cho biết hop trả lỗi là tầng web server hay CDN, ứng dụng chưa nhận được request.
• JSON lỗi của ứng dụng: thân response có trường thông báo giới hạn, ví dụ limit hay max_size. Dạng này cho biết request đã qua hết proxy và tới tận code xử lý.
• Không có response: client báo kết nối bị đóng hoặc bị reset giữa lúc đang gửi. Một số máy chủ trả 413 rồi đóng kết nối ngay, trong khi client còn đang đẩy body, nên client không kịp đọc mã.

Dạng thứ ba dễ bị đọc nhầm thành lỗi mạng hay lỗi proxy. Trong lab trên localhost, client vẫn đọc được 413 dù proxy không đọc body, vì hệ điều hành đệm đủ dữ liệu. Trên mạng thật với body vài trăm MB, tình huống reset dễ xảy ra hơn. Bài chưa tái hiện được reset trong lab nên chỉ ghi là khả năng cần nghĩ tới.

Đừng nhầm với lỗi timeout

Upload lớn qua proxy chậm thường gặp lỗi hết giờ chứ không phải 413. Nếu log ghi 408 hoặc 504, giới hạn đang nằm ở thời gian chờ. Bài lỗi 408 Request Timeout nói về trường hợp đó. Với 413, tăng timeout không giải quyết gì vì máy chủ đã từ chối dựa trên kích thước, thường trước khi đọc xong body.

Câu hỏi đầu tiên khi gặp 413 luôn là hop nào trả mã, chứ chưa phải sửa cấu hình ở đâu.

Tìm hop chặn upload khi gặp lỗi 413 Content Too Large

Mỗi hop có giới hạn riêng

Mỗi hop một giới hạn

Một request upload từ máy anh em tới ứng dụng có thể đi qua các tầng sau. Mỗi tầng tự đếm kích thước body và tự quyết định có từ chối hay không:

• Proxy chuyển tiếp ở phía client: proxy công ty hoặc proxy dịch vụ mà anh em cấu hình trong trình duyệt, script. Với URL https qua CONNECT, proxy này chỉ thấy luồng mã hóa nên không đếm được body theo request. Với URL http, proxy đọc được header Content-Length và có thể đặt giới hạn.
• CDN hoặc WAF: lớp đứng trước website. Nhiều CDN có giới hạn upload theo gói dịch vụ.
• Reverse proxy: nginx, Apache, HAProxy, Caddy hay bộ cân bằng tải của nhà cung cấp đám mây.
• Máy chủ ứng dụng và framework: IIS, Express, Flask, Django, Spring, mỗi nơi một giới hạn mặc định.

Vì vậy cùng một tệp có thể upload được qua đường này và bị 413 qua đường khác. Sửa giới hạn ở ứng dụng không có tác dụng nếu reverse proxy đứng trước đang chặn ở mức thấp hơn.

Giới hạn mặc định của vài phần mềm phổ biến

Bảng: Giới hạn mặc định của vài phần mềm phổ biến

Phần mềm	Thiết lập	Mặc định theo tài liệu	Mã trả về khi vượt
nginx	client_max_body_size	1m	413
Apache httpd	LimitRequestBody	1 GiB từ bản 2.4.54	413
IIS	maxAllowedContentLength	30000000 byte	404.13
Express body-parser	limit	100kb	413
Flask và Werkzeug	MAX_CONTENT_LENGTH	không giới hạn	413
Django	DATA_UPLOAD_MAX_MEMORY_SIZE	2,5 MB	400

Bảng này ghi mặc định theo tài liệu của từng phần mềm tại thời điểm viết. Bản đang chạy trên máy chủ có thể khác, nên luôn đọc cấu hình thật. Hai dòng cuối đáng để ý: IIS trả mã con 404.13 thay vì 413, còn Django trả 400. Nếu anh em chỉ tìm chữ 413 trong log thì sẽ bỏ sót hai trường hợp này.

Với nginx, thiết lập client_max_body_size đặt được ở khối http, server hoặc location. Một location upload riêng có thể có giới hạn khác phần còn lại của site, nên phải đọc đúng khối áp cho đường dẫn đang lỗi.

Phân biệt giới hạn body với giới hạn URL và header

Request có ba phần mà máy chủ đo kích thước riêng: dòng request chứa URL, khối header và phần thân. Mỗi phần vượt giới hạn cho ra một mã khác nhau:

• URL quá dài: mã 414, thường gặp khi nhồi tham số vào query string. Xem bài lỗi 414 URI Too Long.
• Header quá lớn: mã 431, thường do cookie phình to hoặc header tự thêm quá nhiều. Xem bài lỗi 431 Request Header Fields Too Large.
• Body quá lớn: mã 413, chủ đề của bài này.

Trong lab, cùng một origin trả 414 cho URL 9 KB, 431 cho header 17 KB và 413 cho body 2 MiB. Ba mã này hay bị gom chung thành "request quá to" trong các bài hỏi đáp, rồi người đọc đi sửa nhầm thiết lập. Bài lỗi 400 Bad Request có bảng các mã 4xx gần nhau nếu cần tra nhanh.

Dựng lab client, proxy, origin để tái lập lỗi 413 Content Too Large

Thành phần của lab

Lab chạy trên Windows 10 với Python 3.12.10 và requests 2.34.2. Origin và proxy là một tệp Python viết bằng socket thô, để kiểm soát từng byte đọc vào và ghi ra. Mỗi hop gắn header X-Hop vào response do chính nó tạo, còn proxy thêm header Via vào response chuyển tiếp từ origin. Nhờ hai header này, nhìn response là biết hop nào sinh ra mã.

Bốn đường đi được dựng:

• Đi thẳng tới origin, cổng 9510, origin giới hạn body 1 MiB.
• Proxy A, cổng 9511, giới hạn 512 KiB và trả 413 ngay khi đọc header Content-Length, không đọc body.
• Proxy B, cổng 9512, không giới hạn, chuyển hết cho origin.
• Proxy C, cổng 9513, cũng giới hạn 512 KiB, dùng để so với proxy A.

Tên miền upload.test trong URL không có thật trên Internet. Proxy tự chuyển request tới origin cục bộ, nên lab không gửi dữ liệu ra ngoài.

Ba cỡ body

Ba cỡ body, ba đường đi

Ba cỡ được chọn để nằm ở ba vùng: 100 KiB nhỏ hơn mọi giới hạn, 700 KiB lớn hơn giới hạn proxy nhưng nhỏ hơn giới hạn origin, 2 MiB lớn hơn cả hai. Cách chia này buộc mỗi hop lộ ra ngưỡng của mình. Khi chẩn đoán hệ thống thật, anh em cũng nên chọn ba cỡ theo kiểu đó thay vì chỉ thử lại đúng tệp đang lỗi.

Đoạn client dưới đây gửi ba cỡ qua từng đường và in mã, X-Hop, Via. Đây là code lab của bài, chạy được với requests bản mới:

import requests
 
SIZES = {"100 KiB": 100 * 1024, "700 KiB": 700 * 1024, "2 MiB": 2 * 1024 * 1024}
ROUTES = {"thang origin": None, "proxy A": 9511, "proxy B": 9512}
 
for route, port in ROUTES.items():
    for name, n in SIZES.items():
        px = {"http": f"http://127.0.0.1:{port}"} if port else None
        url = "http://upload.test/upload" if port else "http://127.0.0.1:9510/upload"
        r = requests.post(url, data=b"x" * n, proxies=px, timeout=15)
        print(route, name, r.status_code, r.headers.get("X-Hop"), r.headers.get("Via"))

Kết quả chạy thật

Bảng: Kết quả chạy thật

Đường đi	100 KiB	700 KiB	2 MiB
Thẳng tới origin	200, origin	200, origin	413, origin
Proxy A giới hạn 512 KiB	200, origin, có Via	413, proxy, không Via	413, proxy, không Via
Proxy B không giới hạn	200, origin, có Via	200, origin, có Via	413, origin, có Via
Proxy C giới hạn 512 KiB	200, origin, có Via	413, proxy, không Via	413, proxy, không Via

Đọc bảng theo hàng: proxy A và C chặn từ 700 KiB, proxy B để lọt và origin chặn ở 2 MiB. Đọc theo cột: cùng một tệp 2 MiB bị 413 ở cả ba đường, nhưng hop trả mã khác nhau. Nếu chỉ nhìn mã, anh em không phân biệt được hai trường hợp đó.

Lần chạy này cũng thử curl 8.21.0 gửi tệp 700 KiB qua proxy A: curl nhận 413 và báo size_upload 716800 byte, nghĩa là curl đã đẩy xong body dù proxy không đọc. Trên localhost dữ liệu nằm trong bộ đệm socket nên không có lỗi kết nối. Nhật ký proxy ghi sự kiện 413-early với Content-Length 716800, xác nhận proxy quyết định chỉ dựa vào header.

Đối chiếu header, body và timeline của lỗi 413 Content Too Large

Header nói gì về hop trả lỗi

Đọc Via và Server

Trong hệ thống thật không có header X-Hop, nhưng có nhiều dấu vết tương tự. Các dấu vết nên đọc theo thứ tự:

• Header Server: nginx, cloudflare, Microsoft-IIS hay tên ứng dụng. Response do reverse proxy tạo thường mang tên reverse proxy.
• Header Via: proxy tuân chuẩn thêm Via khi chuyển tiếp response. Response do chính proxy tạo thường không có Via của nó, đúng như lab.
• Header riêng của CDN: mã định danh request, tên trung tâm dữ liệu. Có header này nghĩa là response đi qua CDN, chưa chắc do CDN tạo.
• Content-Type và thân response: HTML mẫu của phần mềm hay JSON của ứng dụng.

Không header nào là bằng chứng một mình. Một reverse proxy cấu hình trang lỗi riêng có thể trả JSON trông như của ứng dụng. Cần đối chiếu thêm log.

Log ở từng hop

Cách chắc nhất là tìm request trong log của từng tầng theo thời điểm và đường dẫn. Hop nào có dòng log ghi 413 mà tầng sau không có dòng tương ứng thì đó là hop chặn. Trong lab, proxy A ghi 413-early còn origin không có dòng nào cho cùng request. Với proxy B, proxy ghi forward 2097152 byte và origin ghi 413.

Nếu không có quyền đọc log của CDN hay reverse proxy, có thể gửi thẳng tới origin bằng địa chỉ nội bộ, như hàng đầu của bảng lab. Mã thay đổi khi bỏ một hop ra khỏi đường đi là bằng chứng hop đó có giới hạn riêng.

Content-Length hay chunked

Hop đọc Content-Length có thể từ chối ngay khi thấy header, chưa nhận byte body nào. Với body gửi kiểu chunked, hop không biết trước tổng kích thước nên phải đếm dần và chỉ từ chối khi đã nhận quá ngưỡng. Lab gửi 2,5 MiB kiểu chunked qua proxy B: proxy ghi forward 2621440 byte, origin đọc tới khi vượt 1 MiB rồi trả 413.

Khác biệt này ảnh hưởng tới timeline. Với Content-Length, 413 đến gần như ngay lập tức. Với chunked, 413 đến sau khi đã đẩy được một phần dữ liệu, tốn băng thông và thời gian. Bài lỗi 411 Length Required cùng loạt bài mã lỗi giải thích sâu hơn về hai cách đóng khung body này.

Timeline giúp tách 413 với lỗi đường truyền

Đo thời gian từ lúc gửi tới lúc nhận byte đầu của response. 413 do cấu hình thường đến rất nhanh so với thời gian cần để đẩy hết body. Nếu response đến sau đúng một khoảng cố định như 60 giây, nghi ngờ timeout. Nếu kết nối đứt ở một mốc dữ liệu cố định như 100 MB, nghi ngờ giới hạn của một hop đóng kết nối thay vì trả mã.

Đo bằng curl

curl có biến định dạng cho phép in mã, số byte đã gửi và các mốc thời gian trong một dòng. Lệnh dưới gửi tệp qua proxy và in kết quả, phần header response được ghi ra tệp riêng để đọc Server và Via:

curl -s -o resp.txt -D head.txt -x http://127.0.0.1:9511 --data-binary @big.bin -w "%{http_code} up=%{size_upload} ttfb=%{time_starttransfer} total=%{time_total}\n" http://upload.test/upload

Giá trị up cho biết curl đã đẩy bao nhiêu byte trước khi nhận response. Nếu up nhỏ hơn cỡ tệp nhiều mà vẫn có mã 413, hop đã trả lỗi giữa lúc đang nhận. Nếu up bằng cỡ tệp, hop đã nhận hết hoặc hệ điều hành đã đệm hết, như trong lab localhost. So ttfb với total giúp biết response đến ngay sau khi gửi xong hay còn phải chờ xử lý.

Ghi dòng kết quả này cho cả ba cỡ body và mỗi đường đi. Một bảng chín dòng như vậy thường đủ để chỉ ra hop chặn mà không cần đọc thêm gì.

Sửa lỗi 413 Content Too Large đúng điều kiện và chạy đối chứng

Sửa ở hop đã xác định

Khi biết hop chặn, sửa đúng thiết lập của hop đó và chỉ trong phạm vi cần. Với nginx, nên đặt client_max_body_size lớn hơn trong location upload thay vì nâng cho cả server. Với Express, đặt limit riêng cho route nhận tệp. Với IIS, sửa maxAllowedContentLength trong requestFiltering của site. Nâng giới hạn toàn cục mở cửa cho request lớn ở mọi đường dẫn, kể cả các đường dẫn không cần, và làm máy chủ dễ bị đánh bằng request khổng lồ.

Hop sau cũng phải đủ lớn. Nếu nâng nginx lên 50 MB mà Express vẫn 100 KB, lỗi chỉ dịch từ tầng nginx sang tầng ứng dụng. Lab cho thấy đúng điều này: bỏ giới hạn ở proxy B thì 700 KiB qua được, còn 2 MiB vẫn 413 ở origin.

Khi không có quyền sửa máy chủ

Phần lớn trường hợp dùng proxy để crawl hay gọi API, anh em không sở hữu máy chủ đích. Lúc đó chỉ có các hướng sau:

• Giảm kích thước body: nén ảnh, bỏ trường thừa trong JSON, gửi ít bản ghi hơn mỗi lần.
• Chia nhỏ: gửi theo lô, mỗi lô dưới ngưỡng. Với API, đọc tài liệu xem có giới hạn số bản ghi mỗi request không.
• Dùng giao thức upload chia phần: nhiều dịch vụ lưu trữ có API upload nhiều phần hoặc upload tiếp tục được, mỗi phần là một request nhỏ.
• Đổi đường đi: nếu hop chặn là proxy phía client, ví dụ proxy công ty chặn upload lớn, đi qua đường khác được phép. Chỉ làm khi chính sách cho phép.

Đổi sang một proxy dịch vụ khác không giải quyết 413 do máy chủ đích trả. Proxy chỉ đổi đường đi và địa chỉ IP, còn giới hạn kích thước nằm ở máy chủ.

Chạy đối chứng trước và sau

Sau khi sửa, chạy lại đúng bộ ba cỡ body qua đúng đường đi đã lỗi. Kết quả mong đợi phải khớp với ngưỡng mới. Ví dụ nâng giới hạn proxy A lên 1 MiB thì 700 KiB phải thành 200 với Via, còn 2 MiB phải là 413 từ origin. Nếu 2 MiB thành 200 luôn, nghĩa là ngưỡng origin cũng đã đổi, cần biết vì sao.

Đối chứng nên kiểm cả nội dung body tới nơi. Lab ghi sha256 của body ở client và ở origin, ví dụ 8b77ec70310a4f69 cho tệp 100 KiB ở cả hai đầu. Hai giá trị khớp nghĩa là không hop nào cắt hay đổi dữ liệu.

Giữ bằng chứng

Lưu lại các dòng sau cho mỗi lần chẩn đoán: thời điểm, đường đi, cỡ body, mã, header Server và Via, dòng log ở hop chặn, thiết lập trước và sau. Khi người khác gặp lại lỗi, họ đọc bảng này thay vì làm lại từ đầu.

413 chỉ nói body quá lớn với một hop nào đó. Header Via, log từng tầng và phép thử bỏ bớt hop mới nói được hop đó là ai.

Gửi lại request sau lỗi 413 Content Too Large: khi nào nên và khi nào dừng

Gửi lại nguyên request không có tác dụng

413 do cấu hình là trạng thái cố định. Gửi lại đúng body đó qua đúng đường đi sẽ nhận lại 413, tốn thêm băng thông mỗi lần. Script crawl hay đồng bộ dữ liệu nên coi 413 là lỗi dừng, ghi lại và chuyển sang hướng xử lý khác.

Cần lưu ý một số thư viện HTTP có danh sách mã thử lại mặc định chứa 413. Ví dụ thư viện Got và Ky của Node.js, hay lớp kết nối của conda, đưa 413 vào danh sách thử lại cùng 408, 429 và nhóm 5xx. Các thư viện này thường dựa vào Retry-After để quyết định. Khi máy chủ không gửi Retry-After, anh em nên kiểm cấu hình thư viện để khỏi gửi lại vô ích nhiều lần.

Khi có Retry-After

Nếu response 413 có Retry-After, máy chủ đang báo giới hạn là tạm thời, ví dụ dung lượng xử lý đang đầy. Đợi đúng khoảng ghi trong header rồi thử lại một lần. Nếu vẫn 413, coi như giới hạn cố định.

Tính an toàn của request trước khi gửi lại

Request upload thường là POST hoặc PUT. PUT ghi đè tài nguyên ở một địa chỉ cố định nên gửi lại an toàn hơn. POST tạo mới có thể tạo bản ghi trùng nếu lần trước thực ra đã được xử lý một phần. Với 413 trả sớm trước khi đọc body, phía máy chủ chưa xử lý gì. Nhưng với 413 trả sau khi đọc chunked một phần, nên kiểm xem ứng dụng có lưu phần đã nhận không trước khi gửi lại. Nếu API hỗ trợ khóa idempotency trong header, dùng nó cho mọi request tạo mới.

Kết hợp với lỗi khác

Request chia nhỏ để tránh 413 sẽ nhiều request hơn và dễ chạm giới hạn tần suất. Khi đó máy chủ trả 429. Bài lỗi 429 nói về cách giãn nhịp. Lô nhỏ cũng phải chạy tuần tự hoặc có độ trễ hợp lý, không bắn song song hết một lúc.

Lỗi 413 Content Too Large khi đi qua proxy dịch vụ

Proxy HTTP với URL http và URL https

Với URL bắt đầu bằng http, client gửi request đầy đủ cho proxy, proxy đọc được header và có thể đặt giới hạn body. Với URL https, client gửi lệnh CONNECT để mở đường hầm, sau đó toàn bộ request nằm trong luồng mã hóa. Proxy không biết Content-Length hay body lớn bao nhiêu theo từng request, chỉ đếm được tổng byte của đường hầm.

Hệ quả: khi gọi URL https qua proxy dịch vụ và nhận 413, mã đó gần như chắc là do máy chủ đích hoặc tầng phía trước máy chủ đích tạo, không phải proxy. Muốn kiểm, chạy cùng request đi thẳng không qua proxy, nếu được phép, và so mã.

Proxy SOCKS5

SOCKS5 chỉ chuyển byte, không đọc HTTP. Nó không tạo ra mã 413 trong mọi trường hợp. Nếu đổi từ proxy HTTP sang SOCKS5 mà hết 413, nguyên nhân là proxy HTTP ở giữa có giới hạn, thường gặp với proxy công ty hơn proxy dịch vụ.

Biến môi trường và đường đi bị lẫn

Một lỗi hay gặp khi chẩn đoán: script tưởng đi thẳng nhưng thực ra đi qua proxy công ty do biến HTTP_PROXY đặt sẵn trên máy. Kiểm biến môi trường và danh sách bỏ qua trước khi kết luận về đường đi. Bài no_proxy là gì giải thích cách loại một địa chỉ khỏi proxy, còn bài định dạng proxy giúp đọc đúng chuỗi proxy trong biến.

Quy trình chẩn đoán lỗi 413 Content Too Large từng bước

Các bước

• Bước 1: ghi lại request lỗi: phương thức, URL, cỡ body, có Content-Length hay chunked, đi qua proxy nào.
• Bước 2: đọc response: mã chính xác, kể cả mã con như 404.13, header Server, Via, header của CDN, thân response.
• Bước 3: kiểm đó là body chứ không phải URL hay header. Nếu mã là 414 hay 431 thì đổi hướng.
• Bước 4: thử ba cỡ body quanh ngưỡng nghi ngờ để tìm ngưỡng thật.
• Bước 5: bỏ bớt từng hop nếu có thể: đi thẳng tới origin, bỏ proxy phía client. Ghi mã ở mỗi đường.
• Bước 6: đọc log của hop nghi ngờ để xác nhận.
• Bước 7: sửa ở hop đã xác định, hoặc giảm và chia nhỏ body nếu không có quyền sửa.
• Bước 8: chạy lại bộ ba cỡ, so sha256 body ở hai đầu, lưu bảng trước và sau.

Bảng tra nhanh

Bảng: Bảng tra nhanh

Dấu hiệu	Hop khả nghi	Việc nên làm
Trang HTML có tên nginx	Reverse proxy nginx	Đọc client_max_body_size của location
Mã 404.13	IIS	Đọc requestFiltering của site
JSON có trường limit	Ứng dụng	Đọc giới hạn của framework
Mã 400 với upload lớn ở Django	Ứng dụng Django	Đọc DATA_UPLOAD_MAX_MEMORY_SIZE
Có header CDN, trang lỗi của CDN	CDN	Đọc giới hạn upload theo gói
Kết nối đóng giữa chừng, không mã	Hop đóng sớm	So log, thử cỡ nhỏ hơn
Chỉ lỗi qua proxy HTTP, URL http	Proxy chuyển tiếp	Thử đi thẳng hoặc SOCKS5

Lỗi ghi nhận trong lúc chẩn đoán

Chẩn đoán dễ sai nhất khi thử với tệp khác cỡ tệp thật, hoặc thử trên môi trường khác đường đi thật. Luôn ghi lại đúng đường đi đã lỗi và giữ nguyên nó khi thử.

Lỗi 413 Content Too Large trong crawl và gọi API hàng loạt

Gửi biểu mẫu tìm kiếm lớn

Một số trang tìm kiếm nhận danh sách mã sản phẩm qua POST. Khi danh sách quá dài, máy chủ trả 413. Cách xử lý là chia danh sách thành nhiều lần gửi, ghép kết quả ở phía client. Ghi rõ cỡ lô đã thử và cỡ lô an toàn vào cấu hình của script.

API nhận dữ liệu hàng loạt

API nhập dữ liệu hay đồng bộ thường có giới hạn cỡ request ghi trong tài liệu. Đọc tài liệu trước, đặt cỡ lô thấp hơn giới hạn đó một khoảng, vì body sau khi mã hóa JSON và nén có thể lớn hơn ước tính. Đo cỡ body thật trong code trước khi gửi, ghi vào log cùng mã trả về.

Upload ảnh và tệp

Script đăng ảnh hay tệp nên kiểm cỡ tệp trước khi gửi và nén nếu cần. Nhiều dịch vụ ghi rõ giới hạn tệp trong giao diện. Gửi tệp lớn hơn giới hạn chỉ tốn băng thông proxy, nhất là khi gói proxy tính theo dung lượng.

Chọn proxy khi xử lý lỗi 413 Content Too Large

Proxy không đổi giới hạn của máy chủ

Nhắc lại cho rõ: proxy không nâng giới hạn upload của máy chủ đích. Vai trò của proxy trong bài này là một hop cần loại trừ khi chẩn đoán, và là đường đi ổn định khi upload lớn đã chạy đúng cỡ.

Băng thông và độ ổn định

Upload lớn qua proxy cần kết nối không đổi IP giữa chừng. Proxy xoay đổi IP theo từng request phù hợp với lô nhỏ hơn là một tệp lớn kéo dài nhiều phút. Proxy IP tĩnh giúp máy chủ đích nhận một nguồn cố định trong suốt lượt upload chia phần.

ProxyVN có proxy dân cư tĩnh, datacenter và proxy xoay, hỗ trợ HTTP và SOCKS5, cấp tài khoản user và mật khẩu hoặc xác thực theo IP. Cần một đường đi cố định để chạy lại bộ ba cỡ body ở trên, anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi so mã qua proxy với mã khi đi thẳng.

Tài khoản và định dạng

Khi đặt proxy vào script upload, kiểm định dạng chuỗi proxy và ký tự đặc biệt trong mật khẩu. Proxy sai tài khoản trả 407 chứ không phải 413. Bài sửa lỗi 407 giải thích mã đó.

Câu hỏi thường gặp về lỗi 413 Content Too Large

Payload Too Large và Content Too Large có khác nhau không?

Không khác. Đó là hai tên của cùng mã 413 qua các phiên bản tài liệu HTTP. RFC 9110 dùng tên Content Too Large.

Tăng timeout có sửa được 413 không?

Không. 413 là quyết định dựa trên kích thước. Timeout chỉ liên quan khi lỗi là 408 hoặc 504.

Vì sao tệp nhỏ hơn giới hạn của ứng dụng vẫn bị 413?

Chia nhỏ thay vì gửi lại

Vì một hop đứng trước có giới hạn thấp hơn. Trong lab, tệp 700 KiB dưới giới hạn 1 MiB của origin vẫn bị proxy A chặn ở 512 KiB.

Body nén gzip có giúp tránh 413 không?

Có thể, nếu máy chủ nhận body nén và đo kích thước trước khi giải nén. Nhiều máy chủ không nhận request nén, cần đọc tài liệu API trước.

Proxy SOCKS5 có tự sinh 413 không?

Không. SOCKS5 không đọc HTTP nên không tạo mã HTTP nào.

Giới hạn của bài

Lab chạy trên localhost với origin và proxy tự viết, không thử nginx, IIS hay CDN thật. Giới hạn mặc định trong bảng lấy từ tài liệu của từng phần mềm, chưa kiểm trên bản đang chạy. Chưa tái hiện được trường hợp kết nối bị reset khi máy chủ trả 413 sớm.

Lỗi 413 Content Too Large và những điều cần nhớ

lỗi 413 Content Too Large nghĩa là một hop trên đường đi thấy body vượt giới hạn của nó. Tìm hop đó bằng header Via, Server, log từng tầng và phép thử bỏ bớt hop, rồi mới sửa đúng thiết lập hoặc chia nhỏ body. Cần đường đi proxy ổn định để đối chứng khi gặp lỗi 413 Content Too Large, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.