Lỗi 500, 502, 503 và 504 đều thuộc nhóm HTTP 5xx nhưng không có cùng nguyên nhân. Xử lý incident đúng cần phân biệt application error, gateway/upstream, service unavailable và timeout thay vì dùng một checklist chung cho mọi mã.
Tóm tắt: 500 thường chỉ ra lỗi nội bộ của server/application; 502 liên quan gateway nhận phản hồi không hợp lệ từ upstream; 503 thường là service tạm không thể phục vụ; 504 là gateway timeout chờ upstream. Hãy kiểm tra phạm vi, recent change, log, resource và dependency trước khi rollback hoặc restart.
Ý nghĩa của từng mã 5xx
| Mã | Ý nghĩa chính theo HTTP semantics | Hướng triage đầu tiên |
|---|---|---|
| 500 | Server gặp điều kiện bất ngờ và không thể hoàn tất request | Application/PHP/log/recent change |
| 502 | Gateway/proxy nhận response không hợp lệ từ upstream | Proxy, origin, upstream connectivity |
| 503 | Service hiện không thể xử lý request, thường tạm thời | Overload, maintenance, resource, service health |
| 504 | Gateway không nhận response kịp thời từ upstream | Timeout, database/API/upstream latency |
Các semantics này được định nghĩa trong RFC 9110; tuy nhiên mã lỗi chỉ là tín hiệu, không tự chứng minh root cause.
Bước 1: xác định phạm vi lỗi
Kiểm tra lỗi xảy ra trên toàn site hay một endpoint, tất cả người dùng hay một khu vực, liên tục hay theo spike. Nếu chỉ một route 500, cách xử lý khác hoàn toàn với toàn hệ thống trả 503.
Bước 2: đối chiếu recent change
Deploy, update plugin/theme, thay PHP, thay cache/CDN, chỉnh database hoặc cấu hình proxy gần thời điểm lỗi là tín hiệu quan trọng. Freeze change và ghi lại timeline trước khi thử sửa.
Xử lý lỗi 500
Ưu tiên kiểm tra application log/PHP fatal, plugin/theme, config, permission, database connection và recent deploy. Với WordPress, nếu xuất hiện Critical Error sau update, xem WordPress Critical Error / White Screen.
Xử lý lỗi 502
502 thường xuất hiện ở reverse proxy/CDN/load balancer khi upstream trả phản hồi không hợp lệ hoặc kết nối lỗi. Kiểm tra origin health, web server/PHP-FPM, upstream port, TLS nội bộ và proxy log. Không nên mặc định xóa cache sẽ giải quyết.
Xử lý lỗi 503
503 có thể liên quan overload, maintenance, autoscaling chậm, service bị dừng hoặc application tự từ chối request. Kiểm tra CPU/memory/disk, service health, queue, maintenance flag và traffic spike.
Xử lý lỗi 504
504 thường yêu cầu tìm dependency đang chậm: database query, API ngoài, PHP worker, upstream service hoặc network. API Monitoring và latency metric giúp xác định upstream nào đang kéo dài response.
Error-rate quan trọng hơn một lỗi đơn lẻ
Một 500 đơn lẻ không nhất thiết là P1. Cần nhìn tỷ lệ lỗi, request volume và endpoint. Bài giám sát lỗi 5xx tập trung vào detection/error-rate; bài này tập trung vào incident response sau khi lỗi đã xảy ra.
Runbook xử lý 5xx
- xác nhận mã và phạm vi;
- freeze change;
- kiểm tra recent deploy/config;
- đọc application/web server/proxy log;
- kiểm tra resource và database;
- kiểm tra upstream API/dependency;
- rollback thay đổi gần nhất nếu có bằng chứng;
- smoke test endpoint critical;
- monitor error rate sau recovery;
- ghi root cause và preventive action.
Khi nào rollback tốt hơn “sửa nóng”?
Nếu lỗi xuất hiện ngay sau một release và rollback path đã được test, rollback thường giảm MTTR hơn việc debug trực tiếp trên production. Nhưng cần bảo toàn dữ liệu mới và biết rollback có ảnh hưởng schema/database hay không.
Khi nào cần Incident Response hoặc DR?
Nếu 5xx diện rộng, kéo dài, ảnh hưởng checkout/lead hoặc không có workaround, hãy xử lý theo Website Incident Response. Nếu production không còn đáng tin cậy hoặc recovery thông thường không đạt ngưỡng, chuyển sang Disaster Recovery.
Những sai lầm thường gặp
- restart nhiều service cùng lúc làm mất dấu nguyên nhân;
- tăng timeout mà không tìm upstream chậm;
- tăng resource vô hạn thay vì tìm leak/query lỗi;
- update WordPress/plugin giữa incident;
- xóa log/cache trước khi thu thập bằng chứng;
- không phân biệt 502 proxy với 500 application;
- không smoke test sau recovery.
Khi nào nên gọi hỗ trợ khẩn cấp?
Nếu error rate cao, site thương mại đang mất giao dịch, bạn không có quyền server/log hoặc recent change không rõ, xem dịch vụ sửa lỗi website khẩn cấp để triage và phục hồi có kiểm soát.
FAQ
502 có phải luôn do Cloudflare/CDN?
Không. CDN có thể là nơi hiển thị 502 nhưng nguyên nhân có thể nằm ở origin hoặc upstream phía sau.
503 có phải website bị quá tải?
Có thể, nhưng cũng có thể do maintenance, service health hoặc application chủ động từ chối request.
504 có nên tăng timeout?
Không nên coi đó là giải pháp mặc định. Tăng timeout có thể che dependency chậm và làm worker 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/504 là bốn tín hiệu khác nhau của server-side failure. Triage theo mã, phạm vi, recent change, log, resource và dependency sẽ giúp recovery nhanh hơn và tránh những “fix” chỉ che triệu chứng.
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ả.
