Website lỗi 500, 502, 503 hoặc 504 nghĩa là máy chủ không xử lý được yêu cầu như mong đợi. Khách có thể không xem được trang, gửi tư vấn hoặc hoàn tất đơn hàng. Mã lỗi là dấu hiệu cần điều tra, không phải kết luận nguyên nhân.
Chủ doanh nghiệp cần làm ngay: ghi mã lỗi, địa chỉ trang và thời điểm xuất hiện. Kiểm tra lỗi xảy ra toàn website hay chỉ một chức năng, rồi báo hosting hoặc người quản trị. Nếu lỗi sau thanh toán, đừng yêu cầu khách trả tiền lại trước khi kiểm tra giao dịch.
Phân biệt lỗi 500, 502, 503 và 504
| Mã | Hiểu đơn giản | Nên kiểm tra đầu tiên |
|---|---|---|
| 500 | Máy chủ gặp lỗi bất ngờ | PHP, ứng dụng, plugin và nhật ký |
| 502 | Máy chủ trung gian nhận phản hồi không hợp lệ | Hosting, máy chủ gốc, lớp trung gian |
| 503 | Hệ thống tạm không sẵn sàng | Bảo trì, quá tải, trạng thái dịch vụ |
| 504 | Máy chủ trung gian chờ phản hồi quá lâu | Cơ sở dữ liệu, API, tác vụ xử lý chậm |
Các mã trên được định nghĩa trong RFC 9110. Một mã có thể đến từ nhiều nguyên nhân, nên kỹ thuật phải đối chiếu nhật ký máy chủ và thay đổi gần nhất trước khi sửa.
Ba việc người quản lý website có thể làm ngay
- Giữ bằng chứng: chụp lỗi, ghi đường dẫn, ngày giờ và múi giờ, không để lộ thông tin khách.
- Kiểm tra phạm vi: thử trang chủ, trang liên hệ và đặt hàng nếu có. Ghi lỗi liên tục hay lúc có lúc không.
- Báo đúng người: gửi thông tin cho hosting hoặc đội kỹ thuật. Không tự khởi động lại nhiều dịch vụ cùng lúc.
Cloudflare khuyên cung cấp mã lỗi, thời điểm kèm múi giờ và URL khi cần hỗ trợ. Nếu khách gặp lỗi sau khi thanh toán, hãy đối chiếu khoản thu trước khi thử lại đơn.
Bước 1: xác định trang nào bị lỗi
Xác định lỗi chỉ xảy ra ở biểu mẫu, thanh toán hay toàn bộ trang. Cũng cần biết lỗi có ảnh hưởng mọi khách không. Một trang sản phẩm lỗi 500 cần xử lý khác với toàn website trả 503.
Bước 2: kiểm tra thay đổi gần nhất
Xem vừa cập nhật WordPress, plugin, giao diện, PHP hoặc hosting không. Ghi thời điểm thay đổi và dừng sửa thêm khi chưa rõ nguyên nhân. Nhật ký có thể giúp đối chiếu lỗi bắt đầu từ lúc nào.
Xử lý lỗi 500
Kỹ thuật nên kiểm tra lỗi PHP, plugin, giao diện, quyền truy cập và kết nối dữ liệu. Không phải lỗi 500 nào cũng do plugin. Nếu WordPress hiện thông báo lỗi nghiêm trọng, xem WordPress Critical Error / White Screen.
WordPress có Recovery Mode hỗ trợ vào trang quản trị khi một số lỗi PHP nghiêm trọng xảy ra. Chỉ người có quyền nên xử lý; tránh hiện lỗi máy chủ chi tiết cho mọi khách truy cập.
Xử lý lỗi 502
502 thường liên quan máy chủ trung gian, chẳng hạn Nginx hoặc Cloudflare, nhận phản hồi không hợp lệ từ máy chủ phía sau. Kỹ thuật kiểm tra hosting, PHP-FPM, kết nối nội bộ và nhật ký ở từng lớp. Không mặc định xóa bộ nhớ đệm sẽ hết lỗi.
Cloudflare lưu ý 502/504 có thể bắt đầu tại máy chủ gốc hoặc chính lớp trung gian. Nếu website dùng Cloudflare, cần so mã lỗi tại Cloudflare với máy chủ gốc trước khi kết luận.
Xử lý lỗi 503
503 có thể xuất hiện khi hosting quá tải, bảo trì hoặc dịch vụ tạm chưa sẵn sàng. Đội kỹ thuật kiểm tra tài nguyên và trạng thái dịch vụ. Không mặc định cứ thấy 503 là phải nâng cấp máy chủ.
Với bảo trì ngắn có kế hoạch, website có thể trả 503 kèm tiêu đề Retry-After khi phù hợp. Google Search Central khuyên không dùng 503 cho robots.txt. Lỗi kéo dài có thể ảnh hưởng việc thu thập dữ liệu.
Xử lý lỗi 504
504 nghĩa là máy chủ trung gian không nhận phản hồi kịp thời. Cần xem truy vấn cơ sở dữ liệu, PHP, mạng hoặc API nào đang chậm. API Monitoring hỗ trợ xác định kết nối kéo dài bất thường. Đừng chỉ tăng thời gian chờ mà bỏ qua nguyên nhân.
Một lần lỗi khác với nhiều khách liên tục gặp lỗi
Một lỗi đơn lẻ chưa chắc là sự cố khẩn cấp. Nhưng nếu khách không thanh toán hoặc gửi biểu mẫu được, cần ưu tiên xử lý ngay. Bài giám sát lỗi 5xx đi sâu vào tỷ lệ lỗi và cách phát hiện sớm.
Quy trình 10 bước xử lý lỗi 5xx
- Xác nhận mã lỗi, URL, thời điểm và số trang bị ảnh hưởng.
- Dừng cập nhật hoặc thay đổi mới khi chưa rõ nguyên nhân.
- Kiểm tra thay đổi plugin, PHP, hosting hoặc cấu hình gần nhất.
- Đọc nhật ký ứng dụng, PHP, máy chủ và lớp trung gian.
- Kiểm tra CPU, bộ nhớ, dung lượng và cơ sở dữ liệu.
- Kiểm tra API, kết nối và hệ thống đang phản hồi chậm.
- Chọn cách khắc phục hoặc quay lại bản đã thử nếu an toàn.
- Kiểm tra đăng nhập, biểu mẫu, giỏ hàng và email bằng dữ liệu thử.
- Theo dõi lỗi tái diễn và kiểm tra dữ liệu đã tới nơi nhận.
- Ghi nguyên nhân đã xác minh và cách ngăn lỗi tái diễn.
Khi nào nên quay lại bản trước thay vì sửa ngay?
Nếu lỗi bắt đầu ngay sau cập nhật, việc quay lại phiên bản đã thử có thể giảm gián đoạn. Tuy nhiên phải giữ đơn hàng và yêu cầu khách mới. Không khôi phục toàn bộ cơ sở dữ liệu cũ khi chưa biết phần dữ liệu nào sẽ bị ghi đè.
Khi nào cần quy trình ứng phó sự cố hoặc phục hồi hệ thống?
Nếu lỗi kéo dài, ảnh hưởng nhiều khách hoặc làm mất đơn hàng, cần kích hoạt Website Incident Response. Nếu máy chủ không còn đủ tin cậy và không thể khôi phục theo cách thông thường, đánh giá Disaster Recovery.
Những cách sửa có thể làm lỗi nặng hơn
- Khởi động lại nhiều dịch vụ, khó biết bước nào là nguyên nhân.
- Tăng thời gian chờ mà không tìm dịch vụ đang bị chậm.
- Nâng tài nguyên liên tục nhưng không xem lỗi dữ liệu hoặc mã.
- Tiếp tục cập nhật plugin khi website đang gặp sự cố.
- Xóa nhật ký trước khi giữ bằng chứng phục vụ kiểm tra.
- Đổ lỗi cho Cloudflare khi chưa kiểm tra máy chủ gốc.
- Chỉ thấy trang chủ hoạt động rồi kết luận đã hết lỗi.
Nghiệm thu sau sửa: hết mã lỗi chưa đủ
- Trang chủ và những trang tạo doanh thu mở được trên điện thoại.
- Biểu mẫu gửi thử được lưu và nhân viên nhận đúng thông báo.
- Giỏ hàng, đăng nhập và đặt hàng được kiểm tra bằng cách an toàn.
- Đã đối chiếu đơn hoặc thanh toán có thể bị kẹt, tránh thu tiền trùng.
- Nhật ký và tỷ lệ lỗi ổn định sau khi mở lại website.
Khi nào nên gọi hỗ trợ khẩn cấp?
Nếu nhiều khách không truy cập hoặc đặt hàng được, hãy báo ngay cho hosting và đội vận hành. Gửi mã lỗi, giờ, URL và thay đổi gần nhất. Nếu cần hỗ trợ ngoài, xem dịch vụ sửa lỗi website khẩn cấp.
FAQ
502 có phải luôn do Cloudflare/CDN?
Không. Cloudflare có thể hiển thị lỗi nhưng máy chủ gốc hoặc dịch vụ phía sau mới là nơi phát sinh sự cố. Cần xem nhật ký từng lớp.
503 có phải website bị quá tải?
Không nhất thiết. Máy chủ có thể đang bảo trì, quá tải hoặc dịch vụ tạm chưa sẵn sàng.
504 có nên tăng timeout?
Không nên. Tăng thời gian chờ chỉ hữu ích khi đã hiểu nguyên nhân; đôi khi còn khiến nhiều yêu cầu bị giữ lâu hơn.
Đọc tiếp trong cụm Website Incident Response
- Website Incident Response: framework tổng thể để điều phối severity, containment và recovery.
- Website bị down: triage khi người dùng mất truy cập, kể cả DNS/SSL không trả 5xx.
- WordPress lỗi sau cập nhật: xử lý change incident và rollback version.
- WordPress Critical Error / White Screen: đi sâu vào PHP fatal và Recovery Mode.
- Giám sát lỗi 5xx: phát hiện error-rate tăng trước khi incident lan rộng.
Kết luận
500, 502, 503 và 504 là bốn dấu hiệu khác nhau. Hãy xác định phạm vi lỗi, xem nhật ký và kiểm tra chức năng khách thực sự sử dụng. Một website chỉ được coi đã phục hồi khi khách có thể liên hệ và đặt hàng trở lại.
Nguồn tham khảo: RFC 9110 – HTTP Semantics.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.