# HTTP Status Code Cho Tester: Bảng Tra 2xx–5xx

> Khi mới test API, bạn sẽ thấy mỗi response trả về một con số ba chữ số — và việc đọc đúng con số đó quyết định bạn báo bug cho ai. 🙂 Bài này tôi gom toàn bộ http status code mà tester hay gặp thành bảng tra nhanh 2xx–5xx, kèm ý nghĩa và "tester nên test gì" cho từng nhóm. Bạn lưu lại làm cheat sheet là dùng được ngay khi ngồi với Postman.

- **URL canonical**: https://itlearn.edu.vn/blog/http-status-code
- **Published**: 2026-07-02T11:00:00+07:00
- **Modified**: 2026-07-02T12:08:34+07:00
- **Author**: Anh Tuấn
- **Category**: API Testing (https://itlearn.edu.vn/blog/cat/api-testing)
- **Reading time**: 12 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## HTTP status code là gì?

**HTTP status code (mã trạng thái HTTP) là con số ba chữ số mà server trả về trong mỗi HTTP response để cho client biết request vừa rồi được xử lý ra sao.** Chữ số đầu tiên chia thành 5 nhóm: 1xx thông tin, 2xx thành công, 3xx chuyển hướng, 4xx lỗi do client gửi sai, 5xx lỗi do server.

Với tester, đọc đúng http status code chính là bước đầu để biết bug nằm ở đâu. Một mã http 4xx nói "request của bạn có vấn đề"; một mã 5xx nói "server tôi đang hỏng". Hai câu chuyện hoàn toàn khác nhau, dẫn tới hai cách báo bug khác nhau. Nếu bạn còn mơ hồ về API và request–response, hãy đọc trước [API RESTful là gì](/blog/api-restful-la-gi) để nắm nền tảng, rồi quay lại bảng tra bên dưới.

## 5 nhóm status code (1xx–5xx) — bảng tổng quan

Mọi http status code đều bắt đầu bằng một chữ số xác định nhóm. Trước khi đi vào từng mã, hãy nhớ logic của chữ số đầu — nắm được nhóm thì bạn đoán được "ai có lỗi" mà chưa cần thuộc lòng từng số:

Nhóm

Tên

Ý nghĩa ngắn gọn

Ai chịu trách nhiệm

1xx

Informational

Server đã nhận request, đang xử lý tiếp

(hiếm gặp khi test thủ công)

2xx

Success

Request thành công

Mọi thứ ổn

3xx

Redirection

Cần thao tác thêm (thường là chuyển hướng)

Client đi theo hướng mới

4xx

Client Error

Request sai (sai cú pháp, thiếu quyền, sai địa chỉ)

**Client / phía gửi request**

5xx

Server Error

Server gặp sự cố khi xử lý

**Server / phía backend**

Nhóm 3xx như **301 (Moved Permanently)** và **302 (Found)** chủ yếu liên quan chuyển hướng URL; tester web cần để mắt khi kiểm tra redirect, nhưng trong test API REST thuần thì 2xx, 4xx và 5xx mới là ba nhóm bạn gặp hằng ngày. Vì vậy phần dưới tôi đào sâu ba nhóm này.

## 2xx Thành công (200/201/204)

Nhóm 2xx báo request đã thành công, nhưng "thành công" có nhiều sắc thái:

Mã

Tên

Khi nào trả về

Tester nên test gì

200

OK

GET/PUT thành công, có dữ liệu trả về

Kiểm tra cả **body**, không chỉ mã: đúng field, đúng giá trị, đúng kiểu

201

Created

POST tạo mới thành công

Tài nguyên đã thực sự được tạo? GET lại để xác nhận; kiểm tra header `Location`

204

No Content

Thành công nhưng không có body (thường là DELETE)

Body rỗng đúng kỳ vọng; gọi GET lại để chắc dữ liệu đã bị xóa

Cái bẫy lớn nhất ở nhóm này: **200 không có nghĩa là "đúng".** Trong hệ thống đặt phòng họp nội bộ tôi hay lấy làm ví dụ, API có thể trả 200 OK nhưng body lại báo `"error": "Phòng đã được đặt"`. Status nói thành công, nội dung lại là lỗi nghiệp vụ. Nếu test case của bạn chỉ assert `status == 200` mà quên đọc body, bug lọt lưới ngon ơ. Đây là lỗi tôi sửa cho học viên nhiều nhất.

## 4xx Lỗi client (400/401/403/404/422)

Nhóm 4xx nói: "request của bạn có vấn đề". Đây là nhóm tester chạm nhiều nhất khi viết negative test:

Mã

Tên

Khi nào trả về

Tester nên test gì

400

Bad Request

Request sai cú pháp / JSON hỏng / thiếu trường bắt buộc

Gửi body sai định dạng, thiếu field; xem API có chặn đúng không

401

Unauthorized

**Chưa xác thực** — thiếu hoặc sai token

Gọi API không kèm token, token hết hạn, token sai

403

Forbidden

**Đã xác thực nhưng không đủ quyền**

Đăng nhập tài khoản thường rồi gọi API admin

404

Not Found

Không tìm thấy tài nguyên ở địa chỉ đó

Gọi ID không tồn tại, sai endpoint

422

Unprocessable Entity

Cú pháp đúng nhưng **vi phạm quy tắc nghiệp vụ**

Ngày kết thúc < ngày bắt đầu, email sai định dạng

Hai cặp dễ nhầm nhất:

- **401 vs 403.** 401 là "tôi không biết bạn là ai" (chưa đăng nhập / token sai). 403 là "tôi biết bạn là ai rồi, nhưng bạn không được phép làm việc này". Mẹo nhớ: 401 thiếu danh tính, 403 thiếu quyền.

- **400 vs 422.** 400 là sai cú pháp (JSON gãy, thiếu field). 422 là cú pháp đúng nhưng dữ liệu phạm luật nghiệp vụ — ví dụ đặt phòng với giờ kết thúc trước giờ bắt đầu. Nhiều API gộp cả hai vào 400; khi viết test, bạn cứ kiểm tra API trả mã nào và mã đó có nhất quán không.

## 5xx Lỗi server (500/502/503)

Nhóm 5xx nói: "request của bạn có thể đúng, nhưng server tôi đang trục trặc". Đây là tín hiệu bug phía backend, cần báo cho dev:

Mã

Tên

Khi nào trả về

Tester nên test gì

500

Internal Server Error

Lỗi chung chung trong code server

Xem có input nào khiến server "vỡ" thành 500 thay vì trả 4xx rõ ràng

502

Bad Gateway

Server trung gian nhận response lỗi từ server upstream

Thường gặp khi backend/microservice phía sau chết

503

Service Unavailable

Server tạm quá tải hoặc đang bảo trì

Kiểm tra hành vi khi tải cao; có retry / thông báo rõ không

Một nguyên tắc tôi luôn nhắc: **lỗi do người dùng nhập sai phải trả 4xx, không phải 5xx.** Nếu bạn gửi một body thiếu trường bắt buộc mà API trả về 500, đó chính là một bug đáng báo — server lẽ ra phải bắt lỗi đầu vào và trả 400 gọn gàng, chứ không nên "vỡ" thành lỗi 500 chung chung. Khi gặp 5xx, hãy ghi lại đầy đủ request đã gửi để dev tái hiện; cách ghi bug chuẩn xem thêm ở [vòng đời của bug](/blog/bug-life-cycle-bug-report).

## Status code tester hay nhầm/test sai

Sau nhiều khóa, tôi thấy lỗi đọc http status code lặp lại theo vài kiểu rất quen:

- **Chỉ assert status, quên kiểm tra body.** 200 OK nhưng dữ liệu sai vẫn là bug. Test API tốt phải kiểm tra cả mã lẫn nội dung response.

- **Nhầm 401 với 403.** Báo "lỗi phân quyền" trong khi thực ra là chưa đăng nhập, khiến dev điều tra sai hướng.

- **Coi 5xx và 4xx như nhau.** Hai nhóm này chỉ về hai người khác nhau: 4xx là phía gửi request, 5xx là phía server. Phân biệt đúng giúp bug đi đúng địa chỉ.

- **Bỏ qua negative test.** Chỉ test "đường hạnh phúc" (200/201) mà không thử các ca lỗi 400/401/403/404 — trong khi đây mới là chỗ API hay vỡ.

- **Mặc định 404 luôn là bug.** 404 đôi khi là hành vi đúng (gọi tài nguyên không tồn tại thì phải trả 404). Hãy đối chiếu với kỳ vọng, đừng vội kết luận.

Muốn luyện phản xạ đọc status code, bạn nên thực hành gửi request thật với [Postman test API](/blog/postman-test-api) — gửi cả ca hợp lệ lẫn ca lỗi rồi quan sát mã trả về.

## Bảng tra nhanh cho tester

Đây là cheat sheet http status code để bạn dán cạnh màn hình. Mỗi dòng là một http response code hay gặp kèm "nên làm gì khi thấy nó":

Mã

Nhóm

Nghĩa nhanh

Phản xạ của tester

200

2xx

OK

Đọc body, đừng tin mỗi mã

201

2xx

Đã tạo mới

GET lại xác nhận, check `Location`

204

2xx

Thành công, không body

Đảm bảo body rỗng đúng kỳ vọng

301 / 302

3xx

Chuyển hướng

Kiểm tra URL đích đúng không

400

4xx

Request sai cú pháp

Đúng kỳ vọng cho input hỏng?

401

4xx

Chưa xác thực

Token thiếu/sai/hết hạn

403

4xx

Không đủ quyền

Test phân quyền theo vai trò

404

4xx

Không tìm thấy

Đối chiếu kỳ vọng, chưa chắc là bug

422

4xx

Sai luật nghiệp vụ

Test validation đầu vào

500

5xx

Lỗi server chung

Báo bug, đính kèm request

502 / 503

5xx

Gateway lỗi / quá tải

Test hành vi khi backend trục trặc

Bảng này là phần lõi tôi cho học viên thực hành trong [khóa API Testing](/api.html): nhìn mã là biết phải kiểm tra gì tiếp theo. Để hiểu mã trạng thái nằm ở đâu trong bức tranh kiểm thử dịch vụ, đọc thêm [API testing là gì](/blog/api-testing-la-gi).

## Câu hỏi thường gặp

### Status code 200 nghĩa là gì?

200 OK nghĩa là request đã được server xử lý thành công và thường kèm dữ liệu trả về trong body. Nhưng với tester, 200 không đồng nghĩa "đúng": API có thể trả 200 mà body lại chứa lỗi nghiệp vụ. Vì vậy luôn kiểm tra cả mã lẫn nội dung response.

### 401 và 403 khác nhau thế nào?

401 Unauthorized nghĩa là chưa xác thực — thiếu hoặc sai token, server không biết bạn là ai. 403 Forbidden nghĩa là đã xác thực nhưng không đủ quyền cho thao tác này. Mẹo nhớ: 401 thiếu danh tính, 403 thiếu quyền. Phân biệt đúng giúp dev điều tra bug đúng hướng.

### 4xx và 5xx khác gì?

4xx là nhóm lỗi do phía client: request sai cú pháp, thiếu quyền hoặc sai địa chỉ — lỗi nằm ở phía gửi request. 5xx là nhóm lỗi do server gặp sự cố khi xử lý, dù request có thể hợp lệ. Nói gọn: 4xx là "bạn sai", 5xx là "tôi (server) hỏng".

### 404 là lỗi gì?

404 Not Found nghĩa là server không tìm thấy tài nguyên ở địa chỉ được yêu cầu — do sai endpoint hoặc ID không tồn tại. Với tester, 404 không phải lúc nào cũng là bug: gọi một tài nguyên không tồn tại thì trả 404 lại là hành vi đúng. Hãy luôn đối chiếu với kỳ vọng test case.

### Status code nào tester hay kiểm tra?

Hay gặp nhất là 200, 201 (thành công), 400, 401, 403, 404, 422 (lỗi client) và 500 (lỗi server). Tester cần phủ cả "đường hạnh phúc" (2xx) lẫn các ca lỗi (4xx/5xx) bằng negative test, đồng thời luôn kiểm tra body chứ không chỉ dừng ở con số http status code. Muốn thành thạo đọc và kiểm thử status code trên dự án thật với Postman, bạn có thể tham khảo [khóa API Testing](/api.html) của IT LEARN. Nếu mới bắt đầu, hãy chắc nền tảng với [API RESTful là gì](/blog/api-restful-la-gi) trước đã.