Lỗi 400 Bad Request là gì? Cách khắc phục

Lỗi 400 Bad Request là gì?

400 Bad Request là mã trạng thái HTTP cho biết máy chủ đã nhận được yêu cầu của bạn nhưng sẽ không xử lý nó vì bản thân yêu cầu có điểm gì đó không đúng. Chuẩn HTTP (RFC 9110, mục 15.5.1) định nghĩa đây là trường hợp máy chủ không thể hoặc không muốn xử lý một yêu cầu "do điều gì đó được xem là lỗi phía máy khách", chẳng hạn cú pháp sai, khung thông điệp không hợp lệ hoặc định tuyến yêu cầu mang tính lừa đảo.

Khác với lỗi 500, nghĩa là máy chủ bị hỏng, lỗi 400 chỉ thẳng vào yêu cầu: URL, header, cookie hoặc dữ liệu mà trình duyệt hay ứng dụng của bạn đã gửi. Trang web thường vẫn hoạt động bình thường với mọi người khác.

Đó là tin tốt cho người truy cập, vì cách khắc phục thường nằm ở phía bạn và chỉ mất một phút: một đường link gõ sai hoặc một cookie bị hỏng là nguyên nhân của hầu hết lỗi 400.

Lỗi 400 trông như thế nào

Thông báo phụ thuộc vào phần mềm máy chủ, và phần chữ bổ sung thường là manh mối tốt nhất về nguyên nhân:

Nguyên nhân gây ra lỗi 400 Bad Request

• URL sai định dạng. Một dấu % lạc chỗ, một khoảng trắng, một ký tự lẽ ra phải được mã hóa, hoặc một đường link bị cắt cụt hay bị dán hai lần.

• Cookie bị hỏng hoặc quá lớn. Những trang web đặt nhiều cookie (đăng nhập, thử nghiệm A/B, phân tích) có thể đẩy header Cookie vượt quá giới hạn của máy chủ. Cookie bị hỏng trong quá trình cập nhật cũng có thể bị từ chối.

• Header yêu cầu quá lớn. Ngoài cookie, các token xác thực dài hoặc header do tiện ích mở rộng và proxy thêm vào cũng cộng dồn lại.

• Dữ liệu không hợp lệ gửi đến API. Thiếu trường bắt buộc, JSON sai định dạng, hoặc header Content-Type không đúng.

• HTTP được gửi đến cổng HTTPS. Thường gặp khi đứng sau load balancer và reverse proxy.

• Tệp quá lớn. Nhiều máy chủ trả về 413 Content Too Large, nhưng một số ứng dụng và framework lại trả về 400.

Cách 1: Kiểm tra URL

Hãy nhìn kỹ thanh địa chỉ. Những vấn đề cần chú ý:

• Dấu % không được theo sau bởi hai ký tự thập lục phân (%20 thì được, %2 hoặc %zz thì không).

• Khoảng trắng, { }, |, \ hoặc các ký tự bất thường khác, đặc biệt trong các link được sao chép từ email, PDF hoặc ứng dụng chat.

• Link bị dán hai lần (https://example.com/https://example.com/...) hoặc bị cắt giữa chừng.

• URL rất dài kèm tham số theo dõi. Xóa mọi thứ từ dấu ? trở đi rồi thử lại.

Nếu bạn đi theo một link từ trang web khác, hãy vào trang chủ của trang web đó và điều hướng đến trang cần xem từ đó.

Cách 2: Xóa cookie của riêng trang web đó

Cách này khắc phục hầu hết lỗi 400 trên các trang web bạn từng dùng, đặc biệt là các thông báo nhắc đến cookie hoặc header "quá lớn" (too large) hay "quá dài" (too long). Bạn không cần xóa cookie của mọi trang web, chỉ cần trang này:

• Chrome / Edge: nhấp vào biểu tượng bên trái thanh địa chỉ → Cookie và dữ liệu trang web (Cookies and site data) (hoặc Cài đặt trang web) → xóa dữ liệu của trang đó, rồi tải lại.

• Firefox: nhấp vào biểu tượng ổ khóa → Xóa cookie và dữ liệu trang web… (Clear cookies and site data…)

• Safari (Mac): Safari → Cài đặt → Quyền riêng tư → Quản lý dữ liệu trang web… (Manage Website Data…) → tìm trang web → Xóa (Remove).

• iPhone: Cài đặt → Ứng dụng → Safari → Nâng cao → Dữ liệu trang web (Website Data) → vuốt sang trái trên trang web để xóa.

Cách 3: Thử chế độ Ẩn danh, sau đó xóa bộ nhớ đệm

Mở trang trong cửa sổ Ẩn danh/Riêng tư (Ctrl + Shift + N trên Chrome và Edge, Ctrl + Shift + P trên Firefox, Cmd + Shift + N trên Safari). Cửa sổ riêng tư khởi động không có cookie và không có tiện ích mở rộng, nên nếu trang hoạt động ở đó, Cách 2 hoặc Cách 4 sẽ giải quyết dứt điểm.

Nếu chế độ Ẩn danh cũng lỗi, hãy xóa bộ nhớ đệm của trình duyệt (Ctrl + Shift + Delete → Hình ảnh và tệp được lưu trong bộ nhớ đệm), và bước cuối cùng là xóa bộ nhớ đệm DNS. DNS hiếm khi là nguyên nhân gây lỗi 400, nhưng sau khi một trang web chuyển máy chủ, địa chỉ cũ có thể đưa bạn đến một máy chủ từ chối yêu cầu của bạn.

Cách 4: Tắt tiện ích mở rộng và kiểm tra kích thước tệp

Các tiện ích mở rộng sửa đổi yêu cầu, như công cụ bảo vệ quyền riêng tư, trình chỉnh sửa header, công cụ săn mã giảm giá và một số trình chặn quảng cáo, có thể thêm hoặc thay đổi header theo cách mà máy chủ từ chối. Hãy tắt tất cả, tải lại trang, rồi bật lại từng cái một để tìm thủ phạm.

Nếu lỗi xuất hiện khi tải tệp lên, hãy thử một tệp nhỏ hơn. Nén hình ảnh hoặc chia nhỏ tệp lớn. Điều đó cho bạn biết máy chủ có đang từ chối vì kích thước hay không, ngay cả khi nó báo lỗi 400 thay vì 413.

Dành cho chủ website: Tìm nguyên nhân gây lỗi 400

Nếu người dùng báo lỗi 400 trên trang của bạn, hãy bắt đầu từ chính xác thông báo họ thấy và log của máy chủ. nginx và Apache ghi lý do ở mức info, vì vậy hãy tạm thời tăng mức chi tiết của log lỗi nếu bạn không thấy nó, còn access log cho biết URL nào trả về 400. Công cụ Kiểm Tra Header HTTP của DNS Robot hiển thị mã trạng thái, phần mềm máy chủ và mọi header Set-Cookie mà một trang gửi, giúp bạn phát hiện các cookie cứ lớn dần.

# Những yêu cầu nào nhận lỗi 400? (định dạng log combined của nginx)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Các lý do nginx đã ghi log (cần error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large"

nginx đọc header của yêu cầu vào các bộ đệm được thiết lập bởi large_client_header_buffers, mặc định là 4 bộ đệm 8 KB. Một dòng header đơn lẻ, thường là header Cookie, không vừa trong một bộ đệm sẽ gây ra lỗi 400 này. Giới hạn tương đương của Apache là LimitRequestFieldSize, mặc định 8.190 byte.

Cách khắc phục đúng là gửi ít hơn: xóa các cookie không còn cần, giữ cookie phiên nhỏ gọn, và giới hạn phạm vi cookie vào đúng đường dẫn và tên miền phụ sử dụng chúng. Nếu bạn thực sự cần header lớn hơn, ví dụ cho các token đăng nhập một lần (SSO) lớn, hãy tăng giới hạn:

# nginx (khối http hoặc server)
large_client_header_buffers 4 16k;

# Tương đương trên Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port"

nginx trả về lỗi 400 này khi có thứ gì đó gửi HTTP thuần đến một cổng mà nginx chờ TLS, thường là 443. Các nguyên nhân điển hình là load balancer hoặc proxy chuyển tiếp lưu lượng http:// đến cổng 443, một link có dạng http://example.com:443, hoặc thiết lập cũ ssl on; khiến một cổng chờ TLS trong khi lẽ ra không nên.

Hãy đảm bảo mỗi dòng listen khớp với lưu lượng đến cổng đó: listen 443 ssl; cho HTTPS và listen 80; cho HTTP thuần, kèm chuyển hướng từ 80 sang 443. Đồng thời đảm bảo proxy phía trước giao tiếp bằng HTTPS với cổng 443 (hoặc HTTP với cổng 80).

Lỗi 400 từ API

API dùng mã 400 cho các yêu cầu không vượt qua bước xác thực dữ liệu. Nếu bạn đang gọi một API, hãy đọc phần thân phản hồi, vì hầu hết API đều giải thích trường nào bị sai. Sau đó kiểm tra xem bạn có gửi JSON hợp lệ, đúng header Content-Type: application/json, và đủ mọi tham số bắt buộc hay không.

Nếu bạn đang xây dựng API, hãy trả về phần thân nêu rõ vấn đề (ví dụ {"error": "email is required"}), và cân nhắc dùng 422 Unprocessable Content cho các yêu cầu đúng cú pháp nhưng sai về ngữ nghĩa, giữ 400 cho các yêu cầu hoàn toàn không phân tích được.

Lỗi 400 khác gì 401, 403, 404, 413, 429 và 431

Hướng dẫn cho các lỗi lân cận: 403 Forbidden, 401 Unauthorized và 429 Too Many Requests. Với các chuyển hướng bị lặp vòng thay vì báo lỗi, hãy xem ERR_TOO_MANY_REDIRECTS, còn công cụ Kiểm Tra Chuyển Hướng hiển thị từng bước chuyển hướng.