503 Service Unavailable — Nguyên nhân và cách khắc phục

503 khác 500, 502 và 504 ra sao

Cả bốn đều là lỗi 5xx nên trông giống nhau với khách, nhưng nguyên nhân nằm ở những chỗ hoàn toàn khác nhau.

Nguyên nhân thường gặp, phổ biến nhất trước

• Chế độ bảo trì bị kẹt. Trên WordPress, một lần cập nhật thất bại để lại file .maintenance ở thư mục gốc và website báo 503 mãi cho tới khi bạn xóa file đó.
• Cạn worker của PHP-FPM. Mọi tiến trình đều bận, hàng đợi đầy, và process manager bắt đầu từ chối yêu cầu mới thay vì xếp hàng vô hạn.
• Hết RAM. Kernel giết tiến trình để giải phóng bộ nhớ, dịch vụ nửa sống nửa chết, và proxy phía trước trả về 503.
• Plugin hoặc theme lỗi làm sập PHP hàng loạt. Thường đi kèm 500 xen kẽ, và luôn bắt đầu ngay sau một lần cập nhật.
• Giới hạn tốc độ hoặc quy tắc chống DDoS. Cloudflare, ModSecurity và các module rate-limit đều dùng 503 khi chặn lưu lượng vượt ngưỡng.
• Tăng đột biến lượt truy cập vượt sức máy chủ. Một bài viết lan truyền hoặc một đợt bot quét mạnh đều tạo ra cùng một triệu chứng.
• Dịch vụ backend chưa khởi động xong. Sau khi reboot, Nginx lên trước ứng dụng vài giây và mọi yêu cầu trong khoảng đó nhận 503.

Kiểm tra theo thứ tự này

• Nếu là WordPress, kiểm tra file .maintenance ở thư mục gốc trước tiên. Nó xuất hiện khi cập nhật bị gián đoạn, và xóa nó là cách sửa mất đúng năm giây.
• Xác nhận dịch vụ backend đang chạy. Chạy "systemctl status php8.2-fpm" hoặc lệnh tương ứng với stack của bạn; nếu nó đã chết, khởi động lại rồi mới đọc log để hiểu vì sao.
• Kiểm tra RAM bằng "free -m" và tìm dấu vết OOM killer bằng "dmesg | grep -i oom". Nếu kernel đã giết tiến trình, mọi thứ khác chỉ là hệ quả.
• Xem log của PHP-FPM tìm dòng cảnh báo về pm.max_children. Nếu có, bạn đang cạn worker và cần xử lý phần chậm giữ chúng lại, chứ không đơn thuần tăng số worker.
• Đọc error log của Nginx hoặc Apache trong lúc tải lại trang. 503 do rate-limit trông rất khác 503 do backend chết, và log nói rõ điều đó.
• Nếu website đứng sau Cloudflare, kiểm tra xem trang lỗi đến từ Cloudflare hay từ máy chủ. Trang của Cloudflare có ray ID; nếu vậy quy tắc nằm trong bảng điều khiển của họ.
• Nếu chỉ mới xảy ra sau một bản cập nhật, tắt plugin gần nhất qua FTP bằng cách đổi tên thư mục của nó. Đây là kiểm tra nhanh nhất khi bạn không vào được trang admin.

Cách dùng 503 đúng khi bảo trì

Khi bạn chủ động tắt website để cập nhật, 503 chính là mã đúng — miễn là bạn gửi kèm thông tin cần thiết.

Luôn kèm header Retry-After với số giây hoặc một mốc thời gian cụ thể. Nó cho công cụ tìm kiếm biết đây là tình trạng tạm thời và nên quay lại lúc nào, thay vì để chúng tự đoán.

Đừng bao giờ dùng 200 cho trang bảo trì. Trang thông báo "chúng tôi sẽ trở lại" trả về mã thành công là lời mời Google đưa nội dung đó vào chỉ mục thay cho nội dung thật của bạn — và việc phục hồi tốn thời gian hơn nhiều so với chính đợt bảo trì.

Đừng dùng 302 chuyển hướng sang trang bảo trì. Cách này làm mất URL gốc trong mắt trình thu thập và tạo ra một trang mới không mong muốn trong chỉ mục.

Giữ thời gian bảo trì ngắn. Google chấp nhận 503 trong vài giờ tới vài ngày mà không có hậu quả gì; kéo dài hàng tuần thì các URL sẽ bắt đầu rời chỉ mục.

Khi 503 cứ quay lại

503 lẻ tẻ vào giờ cao điểm là một thông điệp về sức chứa, không phải một lỗi cần vá. Máy chủ đang nói rằng nhu cầu vượt quá khả năng phục vụ đồng thời của nó.

Việc đầu tiên nên làm là bật cache trang. Website nội dung phục vụ HTML tĩnh sẽ giảm số yêu cầu chạm tới PHP xuống một phần nhỏ, và rất nhiều trường hợp 503 định kỳ biến mất hoàn toàn chỉ với bước này.

Tiếp theo là tìm truy vấn chậm. Worker bị giữ lại lâu chính là lý do khiến chúng cạn kiệt; sửa một truy vấn thiếu index thường giải phóng nhiều sức chứa hơn cả việc tăng gấp đôi số worker.

Chỉ sau khi đã cache và đã tối ưu, việc thiếu tài nguyên mới là kết luận hợp lý. Lúc đó dấu hiệu sẽ rất rõ: CPU cao liên tục, RAM cạn và swap hoạt động không ngừng ngay cả khi lưu lượng bình thường.