Lỗi HTTP 401 Unauthorized: Nguyên nhân và cách khắc phục chi tiết

Lỗi 401 Unauthorized là gì?

Lỗi 401 Unauthorized là một mã trạng thái HTTP cho biết máy chủ yêu cầu xác thực đối với tài nguyên được yêu cầu, nhưng yêu cầu không chứa thông tin xác thực hoặc thông tin xác thực được cung cấp không hợp lệ.

Đặc tả HTTP (RFC 9110, Mục 15.5.2) đị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. Máy chủ tạo phản hồi 401 phải bao gồm header WWW-Authenticate cho biết sơ đồ xác thực nào sẽ được sử dụng.

Nói đơn giản: máy chủ đang hỏi "bạn là ai?" trước khi cho phép truy cập. Bạn không cung cấp bất kỳ thông tin nhận dạng nào, hoặc thông tin nhận dạng bạn cung cấp không đúng.

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

Lỗi 401 hiển thị khác nhau tùy thuộc vào máy chủ, trình duyệt và ứng dụng. Dưới đây là các thông báo phổ biến nhất mà bạn sẽ gặp.

• 401 Unauthorized — thông báo phản hồi HTTP tiêu chuẩn

• HTTP Error 401 – Unauthorized — phổ biến trong các ứng dụng IIS và ASP.NET

• 401 Authorization Required — trang lỗi mặc định của Nginx

• Error 401 — dạng viết tắt trên thanh địa chỉ trình duyệt

• Access Denied: Invalid credentials — trang lỗi tùy chỉnh của ứng dụng

• Authentication Required — hộp thoại đăng nhập trình duyệt cho Basic/Digest auth

• Invalid API Key — phổ biến trong phản hồi REST API

• Token Expired — JWT hoặc OAuth token cần được làm mới

Khi máy chủ gửi phản hồi 401, hầu hết các trình duyệt sẽ hiển thị hộp thoại đăng nhập yêu cầu tên người dùng và mật khẩu. Nếu máy chủ sử dụng xác thực dựa trên token (như API), bạn sẽ thấy lỗi trong phần body của phản hồi JSON.

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

Mã trạng thái 401 và 403 thường bị nhầm lẫn, ngay cả bởi những lập trình viên có kinh nghiệm. Sự khác biệt rất đơn giản: 401 nghĩa là "tôi không biết bạn là ai" trong khi 403 nghĩa là "tôi biết bạn là ai, nhưng bạn không được phép."

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

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

Hiểu tại sao lỗi 401 xảy ra phụ thuộc vào việc bạn là người dùng thông thường, lập trình viên gọi API, hay quản trị viên máy chủ. Dưới đây là các nguyên nhân thường gặp nhất.

• Sai tên người dùng hoặc mật khẩu — nguyên nhân cơ bản nhất, đặc biệt sau khi đặt lại mật khẩu

• Token xác thực hết hạn — JWT token, OAuth access token và session cookie đều có thời hạn sử dụng

• Thiếu Authorization header — yêu cầu không chứa bất kỳ 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 sơ đồ xác thực — máy chủ mong đợi Bearer token nhưng nhận được Basic auth, hoặc ngược lại

• Lệch đồng hồ (Clock skew) — xác thực JWT thất bại khi đồng hồ máy chủ và máy khách lệch nhau quá vài phút

• CORS preflight loại bỏ header — trình duyệt tự động loại bỏ Authorization header khỏi yêu cầu preflight OPTIONS

• Bộ nhớ đệm trình duyệt cũ — trình duyệt gửi session cookie hết hạn đã được cache thay vì yêu cầu cookie mới

• Cấu hình reverse proxy sai — Nginx hoặc Apache loại bỏ Authorization header trước khi chuyển tiếp đến backend

• Giới hạn tốc độ hoặc thu hồi thông tin xác thực — đăng nhập thất bại quá nhiều lần dẫn đến khóa tài khoản

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ủa bạn có thể đang gửi session cookie hết hạn hoặc token xác thực đã được cache. Việc xóa chúng sẽ buộc trình duyệt yêu cầu thông tin xác thực mới từ máy chủ.

Chrome:  Settings → Privacy → Clear browsing data → Cookies + Cached images
Firefox: Settings → Privacy → Clear Data → Cookies + Cache
Safari:  Settings → Privacy → Manage Website Data → Remove All
Edge:    Settings → Privacy → Clear browsing data → Cookies + Cache

Sau khi xóa, hãy đóng hoàn toàn trình duyệt (không chỉ tab), mở lại và truy cập trang. Bạn sẽ thấy hộp thoại đă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 đảm bảo bạn đang truy cập đúng URL. Một số máy chủ trả về 401 cho các đường dẫn yêu cầu xác thực, ngay cả khi đường dẫn đó sai. Bạn có thể đang cố truy cập vùng bị hạn chế mà bạn không nên truy cập.

Kiểm tra xem có phiên bản công khai của trang tại URL khác không. Ví dụ, example.com/admin/ có thể trả về 401 trong khi example.com/ có thể truy cập công khai.

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 có định dạng sai. Header WWW-Authenticate trong phản hồi của máy chủ cho bạn biết chính xác sơ đồ nào được mong đợi.

Kiểm tra rằng header của bạn khớp với định dạng yêu cầu. Các sơ đồ phổ biến nhất là Bearer (cho token) và Basic (cho tên người dùng:mật khẩu được 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... ← WRONG
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Luôn kiểm tra header WWW-Authenticate trong phản hồi 401. Nó cho bạn biết chính xác máy chủ mong đợi điều gì. Sử dụng công cụ HTTP Headers của DNS Robot để kiểm tra toàn bộ phản hồi.

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

API key có thể ngừng hoạt động âm thầm vì nhiều lý do: key đã được xoay vòng, tài khoản liên kết bị hạ cấp, key đạt giới hạn tốc độ, hoặc key được cấp phạm vi cho các endpoint khác với những gì bạn đang gọi.

Xác minh key của bạn vẫn còn hoạt động trong bảng điều khiển của nhà cung cấp. Nhiều API (Google, AWS, Stripe) cho phép bạn kiểm tra key trực tiếp từ bảng điều khiển.

# Test if your API key is valid
curl -I -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = key is valid
# 401 = key is invalid or expired
# 403 = key is valid but lacks permission for this endpoint

# Check common API key issues:
# 1. Trailing whitespace in .env file:  API_KEY="abc123 " ← trailing space
# 2. Wrong environment:                 using test key on production
# 3. Missing prefix:                    some APIs need "sk_live_" prefix

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

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

Cách khắc phục phụ thuộc vào luồng xác thực của bạn. OAuth 2.0 sử dụng refresh token để lấy access token mới mà không cần xác thực lại. Các hệ thống dựa trên JWT thường yêu cầu đăng nhập lại.

# Decode a JWT token to check its expiry (works on macOS and Linux)
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d'.' -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Look for "exp" field — it's a Unix timestamp
# Compare with current time: date +%s

# OAuth 2.0 refresh token flow
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 trình duyệt gửi yêu cầu cross-origin với Authorization header, nó sẽ gửi yêu cầu preflight OPTIONS trước. Trình duyệt tự động loại bỏ Authorization header khỏi yêu cầu preflight này. Nếu máy chủ yêu cầu xác thực đối với yêu cầu OPTIONS, nó trả về 401 trước khi yêu cầu thực sự được gửi.

Cách khắc phục: cấu hình máy chủ cho phép yêu cầu OPTIONS không cần xác thực trên các endpoint hỗ trợ CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin *;
        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;
    }

    # 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ủ

Kiểm tra rằng xác thực chỉ được bật trên các route cần thiết. Lỗi phổ biến là bảo vệ toàn bộ thư mục hoặc trang web khi chỉ các đường dẫn cụ thể mới cần đăng nhập.

Trên Nginx, kiểm tra các chỉ thị auth_basic. Trên Apache, kiểm tra các chỉ thị AuthType và Require. Trên Node.js/Express, kiểm tra thứ tự middleware — middleware xác thực đặt trước route handler sẽ chặn tất cả mọi thứ.

# 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 máy chủ Apache, tệp .htaccess có thể bật xác thực Basic hoặc Digest cho các thư mục cụ thể. Nếu tệp .htaccess có chỉ thị AuthType tồn tại trong thư mục công khai, mọi khách truy cập sẽ nhận được hộp thoại đăng nhập 401.

Kiểm tra tệp .htaccess trong thư mục bị ảnh hưởng và tất cả thư mục cha — Apache áp dụng quy tắc từ mọi tệp .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. Sửa lỗi reverse proxy loại bỏ header

Nếu ứng dụng của bạn nằm sau Nginx, Apache hoặc load balancer, proxy có thể loại bỏ Authorization header trước khi chuyển tiếp yêu cầu đến backend. Đây là một trong những nguyên nhân 401 khó chịu nhất vì client gửi đúng thông tin xác thực nhưng máy chủ không bao giờ nhận được.

Kiểm tra cấu hình proxy để đảm bảo nó chuyển tiếp Authorization header.

# Nginx reverse proxy — pass Authorization header to backend
location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Authorization $http_authorization;  # ← Critical!
    proxy_pass_header Authorization;                      # ← Also add this
}

# Apache reverse proxy
<Location /api/>
    ProxyPass http://localhost:3000/api/
    ProxyPassReverse http://localhost:3000/api/
    RequestHeader set Authorization "expr=%{HTTP:Authorization}"  # Pass auth header
</Location>

Gỡ lỗi 401 bằng HTTP Headers

Cách nhanh nhất để chẩn đoán lỗi 401 là kiểm tra các header phản hồi. Header WWW-Authenticate trong phản hồi của máy chủ cho bạn biết chính xác phương thức xác thực nào được yêu cầu.

Sử dụng công cụ HTTP Headers của DNS Robot hoặc curl từ terminal để xem toàn bộ phản hồi.

# Check the WWW-Authenticate header in the 401 response
curl -I https://api.example.com/protected-endpoint

# Typical 401 response headers:
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"
# Content-Type: application/json

# The WWW-Authenticate header tells you:
# - The auth scheme (Bearer, Basic, Digest)
# - The realm (which area is protected)
# - The error reason (invalid_token, expired, etc.)

Hãy chú ý kỹ đến header WWW-Authenticate. Nếu nó ghi Bearer, bạn cần một token. Nếu ghi Basic, bạn cần tên người dùng và mật khẩu. Nếu bao gồm error=invalid_token, token của bạn tồn tại nhưng có định dạng sai hoặc đã hết hạn. Chỉ riêng header này thường cho bạn biết chính xác vấn đề nằm ở đâu.

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

Lỗi 401 trên các trang công khai sẽ ảnh hưởng xấu đến SEO. Khi Googlebot gặp 401, nó không thể thu thập dữ liệu trang và cuối cùng sẽ loại trang khỏi chỉ mục.

Tuy nhiên, lỗi 401 trên các trang cần xác thực (trang quản trị, bảng điều khiển người dùng, API endpoint) là hoàn toàn bình thường. Google mong đợi các trang này được bảo vệ và sẽ không phạt trang web của bạn vì điều đó.

Vấn đề phát sinh khi lỗi 401 xuất hiện trên các trang lẽ ra phải truy cập công khai được. Điều này thường xảy ra khi middleware xác thực bị cấu hình sai hoặc khi CDN/reverse proxy yêu cầu thông tin xác thực một cách sai trên các route công khai.

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

Phòng bệnh hơn chữa bệnh. Hãy thực hiện các biện pháp sau để giảm thiểu lỗi 401 trong ứng dụng và trang web của bạn.

• Triển khai tự động làm mới token — sử dụng refresh token để tự động lấy access token mới trước khi hết hạn

• Đặt phạm vi xác thực phù hợp — chỉ bảo vệ các route thực sự cần xác thực, giữ các trang công khai mở

• Sử dụng thông báo lỗi rõ ràng — trả về nội dung lỗi JSON hữu ích cùng với 401, không chỉ mã trạng thái

• Giám sát các lần xác thực thất bại — thiết lập cảnh báo cho các đợt tăng đột biến phản hồi 401, có thể cho thấy vấn đề thông tin xác thực hoặc tấn công

• Đồng bộ hóa đồng hồ máy chủ — sử dụng NTP để giữ tất cả máy chủ trong phạm vi vài giây so với UTC, ngăn chặn lỗi JWT do lệch đồng hồ

• Kiểm tra bằng [công cụ HTTP Headers](/http-headers) — thường xuyên xác minh rằng các trang công khai trả về 200 và các trang được bảo vệ trả về 401 như mong đợi

• Tài liệu hóa sơ đồ xác thực — ghi rõ định dạng Authorization header mong đợi trong tài liệu API

• 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 API endpoint