Lỗi 401 Unauthorized là gì? Cách khắc phục lỗi HTTP 401

Lỗi 401 Unauthorized là gì?

Lỗi 401 Unauthorized nghĩa là máy chủ cần bạn chứng minh mình là ai, còn yêu cầu của bạn không làm vậy hoặc thông tin đi kèm đã bị từ chối. Không có mật khẩu, sai mật khẩu, token hết hạn hay thiếu API key đều dẫn đến cùng một kết quả.

Chuẩn HTTP định nghĩa nó là yêu cầu "thiếu thông tin xác thực hợp lệ cho tài nguyên đích", và máy chủ gửi 401 PHẢI kèm header WWW-Authenticate cho biết kiểu đăng nhập được chấp nhận (RFC 9110 §15.5.2).

Nói đơn giản, máy chủ đang hỏi "bạn là ai?" trước khi cho bạn vào.

Lỗi 401 hiển thị như thế nào

Trang bạn thấy phụ thuộc vào máy chủ và ứng dụng:

• 401 Unauthorized — dòng trạng thái chuẩn và cách ghi của hầu hết ứng dụng
• 401 Authorization Required — tiêu đề trang 401 dựng sẵn của nginx, bên dưới có chữ "nginx" (thường kèm số phiên bản) (mã nguồn nginx); máy chủ Apache 2.2 cũ dùng cùng chữ này
• Unauthorized · This server could not verify that you are authorized to access the document requested — trang mặc định của Apache
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS; trang chi tiết (chỉ hiện trên chính máy chủ) và nhật ký IIS cho biết lý do là 401.1, 401.2 hoặc 401.3: đăng nhập thất bại, cấu hình máy chủ hoặc quyền tệp
• Hộp thoại đăng nhập trong trình duyệt — khi máy chủ yêu cầu xác thực HTTP Basic hoặc Digest, hoặc (trên IIS và mạng nội bộ công ty) NTLM hoặc Negotiate
• This page isn't working · HTTP ERROR 401 — Chrome, khi phản hồi 401 không có trang riêng
• JSON từ một API, ví dụ {"error":{"message":"Missing Authentication header","code":401}}

Trình duyệt chỉ hiện hộp thoại đăng nhập với các kiểu đó. API dùng token ("Bearer") không bao giờ làm hiện hộp thoại: lỗi 401 của chúng trả về dạng JSON để ứng dụng tự xử lý. Các trang web có biểu mẫu đăng nhập thường đưa khách chưa đăng nhập về trang đăng nhập bằng chuyển hướng 302 thay vì trả 401.

"401 Authorization Required" trên nginx

Tiêu đề đó đến từ trang 401 dựng sẵn của nginx. Bạn gặp nó khi một location được bảo vệ bằng auth_basic và yêu cầu không kèm tên người dùng và mật khẩu, hoặc kèm sai; hủy hộp thoại đăng nhập của trình duyệt cũng hiện trang này.

Là người truy cập, hãy tải lại và nhập tên người dùng và mật khẩu mà chủ trang đã cung cấp. Chúng tách biệt với mọi tài khoản trên trang: xác thực Basic kiểm tra một tệp mật khẩu trên máy chủ.

Là chủ trang, đây là cách thiết lập bảo vệ và cách giữ một đường dẫn công khai:

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

location /admin/ {
    auth_basic           "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

Vẫn 401 dù mật khẩu đúng? Hãy kiểm tra người dùng có trong tệp không (htpasswd -c ghi đè tệp và xóa các người dùng trước đó) và ứng dụng phía sau nginx có cần cả header Authorization không: đăng nhập Basic của nginx và token Bearer của ứng dụng dùng chung một header, nên ứng dụng nhận thông tin của nginx rồi từ chối.

Sự khác biệt giữa 401 và 403 là gì?

Hai mã 401 và 403 thường bị nhầm lẫn. Tóm lại: 401 nghĩa là "tôi không biết bạn là ai", còn 403 nghĩa là "tôi không cho bạn vào", dù danh tính có phải vấn đề hay không.

Quy tắc thực tế: nếu nhập đúng tên người dùng và mật khẩu (hoặc API key) sẽ giải quyết được, máy chủ nên trả 401. Nếu người dùng đã xác thực nhưng không có quyền truy cập tài nguyên đó, máy chủ nên trả 403 Forbidden.

Nguyên nhân phổ biến gây ra lỗi 401

Các nguyên nhân, từ phía người truy cập đến phía máy chủ:

• Sai tên người dùng hoặc mật khẩu — nguyên nhân cơ bản nhất, nhất là sau khi đặt lại mật khẩu
• Token xác thực hết hạn — token JWT, access token OAuth và cookie phiên đều có thời hạn
• Thiếu Authorization header — yêu cầu không kèm thông tin xác thực nào
• API key không hợp lệ — key đã bị thu hồi, xoay vòng hoặc sao chép sai
• Sai kiểu xác thực — máy chủ mong token Bearer nhưng nhận Basic, hoặc ngược lại
• Lệch đồng hồ (clock skew) — máy chủ kiểm tra JWT và máy chủ đã cấp nó (hoặc máy của bạn, nếu máy bạn ký JWT) lệch giờ nhau; nhiều thư viện không cho phép bất kỳ độ lệch nào
• Yêu cầu CORS preflight — bước kiểm tra OPTIONS của trình duyệt không bao giờ kèm thông tin đăng nhập, nên máy chủ đòi chúng sẽ trả 401 và yêu cầu thật không bao giờ được gửi
• Phiên đã cũ — trình duyệt gửi cookie phiên mà máy chủ đã kết thúc
• Có thứ gì đó giữa đường làm mất header — Apache giấu Authorization khỏi PHP-FPM và script CGI nếu không được cấu hình, CloudFront mặc định bỏ nó khỏi yêu cầu GET và HEAD, và xác thực Basic của nginx đặt trước ứng dụng sẽ chiếm lấy nó
• Thông tin đăng nhập bị khóa hoặc thu hồi — nhập sai quá nhiều lần có thể khóa tài khoản (một số API khi đó trả 429 Too Many Requests)

Cách khắc phục lỗi 401 cho người dùng

Nếu bạn gặp lỗi 401 khi cố truy cập một trang web, vấn đề hầu như luôn liên quan đến thông tin đăng nhập. Hãy làm theo các bước sau theo thứ tự.

1. Kiểm tra thông tin đăng nhập

Nguyên nhân phổ biến nhất của lỗi 401 là thông tin đăng nhập sai. Nếu trang web hiển thị hộp thoại đăng nhập hoặc biểu mẫu, hãy kiểm tra lại tên người dùng và mật khẩu.

Những lỗi thường gặp: phím Caps Lock đang bật, bạn đang dùng mật khẩu cũ (đặc biệt sau khi vừa đặt lại), hoặc bạn đang đăng nhập nhầm tài khoản. Nếu bạn dùng trình quản lý mật khẩu, hãy để nó tự động điền thông tin để tránh lỗi đánh máy.

2. Xóa bộ nhớ đệm và cookie trình duyệt

Trình duyệt có thể đang gửi cookie phiên đã hết hạn. Xóa cookie của trang sẽ buộc nó yêu cầu đăng nhập lại.

Trong Chrome tiếng Việt, mở "Xoá dữ liệu duyệt web" bằng Ctrl+Shift+Delete (Cmd+Shift+Delete trên Mac), chọn phạm vi thời gian "Từ trước đến nay" thay cho "Một giờ qua", chọn "Cookie và các dữ liệu trang web khác" cùng "Tệp và hình ảnh lưu vào bộ nhớ đệm", rồi chọn "Xoá dữ liệu". Thao tác này sẽ đăng xuất bạn khỏi mọi trang web. Để chỉ xóa một trang: Tuỳ chọn khác → Cài đặt → Quyền riêng tư và bảo mật → Cookie của bên thứ ba → "Xem tất cả dữ liệu và quyền của trang web", tìm tên trang rồi chọn biểu tượng Xoá. Các bước cho trình duyệt khác (tên tiếng Anh):

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

Sau khi xóa, hãy đóng hoàn toàn trình duyệt (không chỉ thẻ), mở lại và vào trang một lần nữa. Bạn sẽ thấy yêu cầu đăng nhập mới.

3. Thử chế độ ẩn danh hoặc riêng tư

Mở URL trong cửa sổ ẩn danh (Chrome) hoặc riêng tư (Firefox/Safari). Điều này bỏ qua tất cả cookie đã cache, tiện ích mở rộng và thông tin xác thực đã lưu.

Nếu trang hoạt động ở chế độ ẩn danh nhưng không hoạt động trong trình duyệt thông thường, vấn đề là do cookie đã cache hoặc tiện ích mở rộng trình duyệt đang can thiệp vào quá trình xác thực. Hãy tắt từng tiện ích mở rộng để tìm ra nguyên nhân.

4. Xác minh URL

Hãy chắc chắn bạn đang vào đúng URL. Một số máy chủ trả 401 cho những đường dẫn yêu cầu xác thực, dù chính đường dẫn đó sai. Có thể bạn đang cố vào một khu vực hạn chế không dành cho mình.

Kiểm tra xem trang có phiên bản công khai ở URL khác không. Ví dụ, example.com/admin/ có thể trả 401 trong khi example.com/ truy cập công khai được.

Không chắc trang có hoạt động không? Hãy thử Kiểm tra web sập: công cụ mở trang từ 11 nơi, nên bạn phân biệt được lỗi đăng nhập với sự cố sập trang.

Cách khắc phục lỗi 401 cho lập trình viên

Đối với lập trình viên làm việc với API, lỗi 401 thường liên quan đến Authorization header, định dạng token hoặc vòng đời thông tin xác thực. Dưới đây là các cách khắc phục phổ biến nhất.

5. Xác minh Authorization header

Lỗi phổ biến nhất của lập trình viên là Authorization header sai định dạng. Khi máy chủ gửi header WWW-Authenticate, nó cho biết kiểu mà máy chủ mong đợi; nhiều API JSON (như của GitHub và OpenRouter) bỏ qua header này và giải thích vấn đề trong nội dung phản hồi.

Hãy kiểm tra header của bạn đúng định dạng yêu cầu. Các kiểu phổ biến nhất là Bearer (cho token) và Basic (tên người dùng:mật khẩu mã hóa Base64).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Sau đó đọc header WWW-Authenticate trong phản hồi 401: nó cho biết kiểu mà máy chủ mong đợi. Kiểm tra HTTP Header của DNS Robot hiển thị toàn bộ phản hồi.

6. Kiểm tra tính hợp lệ của API key

API key ngừng hoạt động khi key bị xoay vòng hoặc thu hồi, tài khoản bị đình chỉ hoặc hạ gói, hoặc dùng key thử nghiệm cho môi trường production. (Vượt giới hạn tốc độ trả 429, còn key không có quyền với một endpoint thường nhận 403.)

Hãy kiểm tra trong trang quản trị của nhà cung cấp rằng key còn hoạt động, rồi thử trực tiếp:

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

7. Xử lý hết hạn và làm mới token

Token JWT và access token OAuth có thời hạn giới hạn, thường từ 15 phút đến 24 giờ. Khi hết hạn, mọi lời gọi API đều trả 401 cho đến khi bạn lấy token mới.

Nếu bạn có refresh token (OAuth 2.0 và hầu hết cấu hình JWT), hãy đổi nó lấy access token mới; nếu không, hãy đăng nhập lại.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. Khắc phục vấn đề CORS preflight

Khi một trang web gọi API ở tên miền khác kèm Authorization header, trình duyệt trước tiên gửi yêu cầu preflight OPTIONS, và preflight không bao giờ kèm thông tin đăng nhập. Nếu máy chủ đòi xác thực trên OPTIONS, nó trả 401, preflight thất bại và trình duyệt báo lỗi CORS: yêu cầu thật không bao giờ được gửi.

Cách khắc phục: cho phép yêu cầu OPTIONS đi qua mà không cần xác thực trên các endpoint bật CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Cách khắc phục lỗi 401 cho quản trị viên

Nếu khách truy cập hoặc người dùng báo cáo lỗi 401, vấn đề nằm ở cấu hình xác thực của máy chủ. Hãy kiểm tra các mục sau theo thứ tự.

9. Kiểm tra cấu hình xác thực máy chủ

Hãy kiểm tra xác thực chỉ được bật trên những route cần đến nó. Lỗi thường gặp là bảo vệ cả thư mục hoặc cả trang trong khi chỉ một số đường dẫn cần đăng nhập.

Trên nginx, kiểm tra các chỉ thị auth_basic; trên Apache, AuthType và Require. Trên Node.js/Express, kiểm tra thứ tự middleware: app.use(auth) đăng ký trước các route công khai sẽ bảo vệ luôn chúng, nên hãy đăng ký route công khai trước hoặc chỉ gắn xác thực vào router được bảo vệ.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. Kiểm tra quy tắc xác thực .htaccess

Trên Apache, tệp .htaccess có thể bật xác thực Basic hoặc Digest cho một thư mục. Nếu thư mục công khai có .htaccess với các chỉ thị AuthType và Require, mọi khách truy cập đều nhận 401 kèm hộp thoại đăng nhập.

Hãy tìm các tệp .htaccess trong thư mục bị ảnh hưởng và mọi thư mục cha: Apache áp dụng quy tắc từ mọi .htaccess trên đường dẫn.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Đảm bảo Authorization header đến được ứng dụng

Máy khách gửi thông tin đúng nhưng ứng dụng không bao giờ thấy chúng. Nơi header bị mất:

nginx mặc định chuyển Authorization đến backend nên bạn không cần thêm dòng nào; nhưng nếu cùng location dùng auth_basic, đăng nhập của nginx sẽ chiếm lấy header (xem phần nginx ở trên). Apache giấu Authorization khỏi PHP-FPM và script CGI trừ khi bạn bật CGIPassAuth (Apache 2.4.13+), nguyên nhân kinh điển gây 401 cho các API WordPress và Laravel đặt sau Apache.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

Gỡ lỗi 401 bằng HTTP headers

Cách nhanh nhất để chẩn đoán 401 là đọc phản hồi: header WWW-Authenticate, khi máy chủ gửi, cho biết kiểu đăng nhập nó muốn, và các API JSON thường giải thích lỗi trong nội dung phản hồi.

Hãy dùng Kiểm tra HTTP Header của DNS Robot (nếu lỗi 401 chỉ xuất hiện sau một lần chuyển hướng, Kiểm tra Redirect cho biết bước nào trả về nó) hoặc curl trong terminal:

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

Nếu WWW-Authenticate ghi Bearer, bạn cần token; nếu ghi Basic, cần tên người dùng và mật khẩu. error="invalid_token" nghĩa là token đã hết hạn, bị thu hồi, sai định dạng hoặc không hợp lệ vì lý do khác. Không có header nào? Hãy đọc nội dung phản hồi: nhiều API ghi lý do ở đó.

Lỗi 401 có ảnh hưởng đến SEO không?

Lỗi 401 trên một trang công khai sẽ đưa trang đó ra khỏi Google. Google xử lý mọi mã 4xx trừ 429 như nhau: trình thu thập báo rằng nội dung không tồn tại, và URL đã lập chỉ mục sẽ bị gỡ (tài liệu của Google về thu thập dữ liệu).

Lỗi 401 trên các trang đáng ra phải yêu cầu đăng nhập (trang quản trị, dashboard, API) là bình thường: Google không phạt trang web vì điều đó. Chỉ cần đừng dùng 401 hay 403 để làm chậm Googlebot; theo Google, chúng không ảnh hưởng đến tốc độ thu thập dữ liệu.

Vấn đề là lỗi 401 trên những trang lẽ ra phải công khai, thường do xác thực áp dụng cho cả trang web, hoặc do quy tắc CDN hay proxy đòi thông tin đăng nhập trên các đường dẫn công khai.

Cách phòng tránh lỗi 401

Phòng ngừa giúp bạn đỡ phải gỡ lỗi về sau. Hãy áp dụng các thực hành sau để giảm lỗi 401 trong ứng dụng và trang web.

• Triển khai tự động làm mới token — dùng refresh token để lặng lẽ lấy access token mới trước khi hết hạn
• Đặt đúng phạm vi xác thực — chỉ bảo vệ những route thật sự cần, giữ các trang công khai ở trạng thái mở
• Dùng thông báo lỗi rõ ràng — trả về nội dung JSON hữu ích kèm 401, không chỉ mỗi mã trạng thái
• Giám sát lỗi xác thực — thiết lập cảnh báo khi số phản hồi 401 tăng đột biến, vì đó có thể là dấu hiệu sự cố thông tin đăng nhập hoặc tấn công
• Đồng bộ đồng hồ máy chủ — dùng NTP để giữ mọi máy chủ lệch UTC không quá vài giây, tránh JWT bị từ chối do lệch đồng hồ
• Kiểm thử bằng Kiểm tra HTTP Header — thường xuyên xác nhận trang công khai trả 200 và trang được bảo vệ trả 401 như mong đợi
• Tài liệu hóa kiểu xác thực — nêu rõ định dạng Authorization header mong đợi trong tài liệu API của bạn
• Xử lý CORS preflight — luôn cho phép yêu cầu OPTIONS không cần xác thực trên các endpoint API