Trang vừa báo lỗi, khách bấm F5 vài lần vẫn thấy một màn hình trắng ghi “502 Bad Gateway”, còn bạn chưa biết nên nhìn vào đâu trước. 502 Bad Gateway là gì: đây là lỗi xảy ra khi server đóng vai trò gateway hoặc proxy (ví dụ Nginx, Cloudflare) nhận được phản hồi KHÔNG hợp lệ từ server phía sau nó (PHP-FPM, backend ứng dụng, hoặc một server gốc khác). Phần dưới là cây chẩn đoán theo từng tầng hạ tầng, kèm lệnh đọc log cụ thể, để bạn không phải đoán mò.
502 Bad Gateway là gì và khác 500, 503 ở đâu
Ba mã lỗi này đều thuộc nhóm 5xx (lỗi phía server), nhưng vai trò gây lỗi khác nhau. Phân biệt đúng giúp bạn nhìn đúng chỗ ngay từ đầu, thay vì restart lung tung mọi dịch vụ.
| Mã lỗi | Ai đang báo lỗi | Ý nghĩa | Liên quan |
|---|---|---|---|
| 500 Internal Server Error | Server gốc (backend) tự báo lỗi khi xử lý request | Code, plugin hoặc cấu hình trên chính server gốc gặp sự cố | Lỗi 500 là gì |
| 502 Bad Gateway | Server trung gian (gateway/proxy) nhận phản hồi hỏng từ backend | Backend không trả lời đúng cách, timeout, hoặc sập giữa chừng | Bài này |
| 503 Service Unavailable | Server báo đang tạm ngừng tiếp nhận request | Quá tải tạm thời hoặc đang bảo trì có chủ đích | Lỗi 503 là gì |
Điểm chung: tất cả 5xx đều khiến Google tạm thời đối xử khác với URL đó khi thu thập dữ liệu — chi tiết ở phần sau.
Cây chẩn đoán lỗi 502 theo từng tầng hạ tầng
Thay vì kiểm tra ngẫu nhiên, đi theo thứ tự từ ngoài vào trong — mỗi tầng loại trừ được một nhóm nguyên nhân.
- Tầng CDN/proxy biên (Cloudflare hoặc tương tự): nếu bật proxy (biểu tượng mây màu), CDN có thể tự trả 502 khi server gốc không phản hồi đúng hạn hoặc chứng chỉ SSL giữa CDN và server gốc có vấn đề.
- Tầng Nginx (web server/reverse proxy): Nginx đóng vai trò gateway tới PHP-FPM hoặc backend. 502 ở tầng này thường do upstream (PHP-FPM) không phản hồi, bị treo, hoặc socket/port cấu hình sai trong block
proxy_pass/fastcgi_pass. - Tầng PHP-FPM hoặc backend ứng dụng: hết worker xử lý (pool cạn), vượt
max_execution_time, hoặc tiến trình PHP-FPM bị crash do thiếu RAM. - Tầng database/kết nối ngoài: backend đang chờ database trả kết quả một truy vấn nặng, kéo dài tới mức Nginx coi là timeout và trả 502 thay cho người dùng.
Lệnh đọc log để xác định tầng đang lỗi
Không cần đoán — log sẽ chỉ thẳng tầng nào đang có vấn đề, miễn là bạn biết nhìn vào đâu.
tail -f /var/log/nginx/error.log: tìm dòngupstream timed outhoặcconnection refused— nghĩa là Nginx không nhận được phản hồi từ PHP-FPM/backend.systemctl status php-fpm(hoặc tên service tương ứng theo bản phân phối): kiểm tra service còn chạy hay đã crash, xem thời điểm restart gần nhất.tail -f /var/log/php-fpm/error.log(hoặc đường dẫn cấu hình trongwww.conf): tìm lỗi hết worker, vượt thời gian xử lý, hoặc lỗi PHP fatal làm tiến trình chết.free -hvàtop: kiểm tra RAM/CPU còn trống hay đã cạn — nguyên nhân phổ biến khiến PHP-FPM bị kill ngầm bởi hệ điều hành.
502 do Cloudflare: nguyên nhân riêng cần kiểm thêm
Nếu site đang chạy qua Cloudflare (hoặc CDN tương tự) và chỉ 502 khi bật proxy, kiểm thêm các điểm sau trước khi đổ lỗi cho server gốc:
- Chế độ SSL giữa Cloudflare và server gốc (Full, Full Strict) không khớp với chứng chỉ thực tế trên server — gây bắt tay SSL thất bại.
- Server gốc chặn nhầm dải IP của Cloudflare qua firewall, khiến request từ CDN không đến được server.
- Server gốc phản hồi quá chậm, vượt ngưỡng chờ phía CDN, dù chính server đó không báo lỗi gì trong log nội bộ.
502 trên WordPress: thêm vài điểm cần kiểm riêng
Với site chạy WordPress, ngoài cây chẩn đoán chung ở trên, có vài nguyên nhân đặc thù nên loại trừ trước khi đụng tới cấu hình server:
- Plugin xung đột hoặc lỗi thời: tắt tạm toàn bộ plugin (qua quản trị file, không qua giao diện nếu site đang không vào được), rồi bật lại từng nhóm để xác định plugin gây treo tiến trình PHP.
- Giới hạn bộ nhớ PHP quá thấp (
memory_limittrongphp.inihoặcwp-config.php): một theme hoặc plugin nặng có thể khiến tiến trình PHP vượt giới hạn, bị kill, và Nginx trả 502 vì không nhận được phản hồi. - Lỗi vòng lặp trong hook (action/filter gọi lẫn nhau không dừng): hiếm gặp hơn nhưng khi xảy ra sẽ làm một request treo mãi tới khi backend tự timeout.
Cách nhanh để khoanh vùng: thử truy cập trực tiếp một file tĩnh (ví dụ ảnh) trên cùng server. Nếu file tĩnh load được nhưng trang WordPress vẫn 502, nhiều khả năng vấn đề nằm ở tầng PHP/WordPress, không phải ở Nginx hay mạng.
Khi nào chỉ cần restart, khi nào phải sửa cấu hình
Restart service (PHP-FPM, Nginx) thường giải quyết được sự cố tạm thời — ví dụ pool worker bị kẹt một lần do traffic tăng đột biến. Nhưng nếu 502 lặp lại đều đặn theo một khung giờ hoặc một hành động cụ thể (ví dụ mỗi lần chạy một tác vụ nền nặng), restart chỉ xử lý triệu chứng, không xử lý nguyên nhân. Trường hợp này cần sửa cấu hình (tăng worker, tăng memory_limit, tối ưu truy vấn) thay vì restart lặp lại mỗi lần gặp lỗi.
Lỗi 502 ảnh hưởng việc Google thu thập dữ liệu thế nào
Theo tài liệu Google Search Central về lỗi mạng và server, lỗi 5xx (gồm 502) khiến Googlebot giảm tốc độ crawl trang đó, mức giảm tỉ lệ theo số URL đang gặp lỗi trên site. Khi server trở lại trả mã 2xx ổn định, Google tăng dần crawl rate trở lại bình thường — không phải ngay lập tức. Tài liệu không công bố một mốc thời gian cụ thể nào để coi site là “đã sập”, nên việc sửa nhanh quan trọng hơn việc đoán thời hạn.
Cách phòng tránh 502 lặp lại
Vài việc làm giảm rõ tần suất gặp lại lỗi này, thay vì chỉ xử lý mỗi khi nó xảy ra:
- Tăng số worker PHP-FPM phù hợp với RAM thực tế của server, tránh để pool cạn khi traffic tăng đột ngột.
- Giám sát tài nguyên (RAM, CPU) định kỳ để phát hiện tiến trình ăn tài nguyên bất thường trước khi nó làm sập backend.
- Tối ưu truy vấn database nặng, tránh để một truy vấn chậm kéo theo timeout ở tầng gateway.
- Kiểm tra chế độ SSL và whitelist IP đúng cách khi dùng CDN, tránh 502 chỉ xảy ra riêng ở tầng CDN.
Lỗi 502 cứ lặp lại mà chưa rõ tầng nào đang có vấn đề?
VIDCO rà theo đúng cây chẩn đoán: CDN, Nginx, PHP-FPM, database — để tìm ra tầng gây lỗi thật, không đoán mò hay restart ngẫu nhiên từng dịch vụ.
Nguồn tham khảo
Thông tin trong bài được đối chiếu với các nguồn chính thức dưới đây tại thời điểm biên soạn; văn bản và chính sách có thể thay đổi.
Câu hỏi thường gặp
502 Bad Gateway khác 500 Internal Server Error ở điểm nào?
500 là lỗi do chính server gốc (backend) tự báo khi xử lý request gặp sự cố trong code/cấu hình. 502 là lỗi do server trung gian (gateway/proxy như Nginx, Cloudflare) nhận phản hồi không hợp lệ từ server gốc phía sau — tức ít nhất hai lớp server đang liên quan.
Tải lại trang (F5) có hết lỗi 502 không?
Có thể hết nếu nguyên nhân là tạm thời (ví dụ backend vừa quá tải một thời điểm ngắn). Nhưng nếu nguyên nhân là cấu hình sai hoặc service đã crash, tải lại không giải quyết được — cần vào log theo cây chẩn đoán ở trên.
Lỗi 502 kéo dài bao lâu thì ảnh hưởng SEO nghiêm trọng?
Google không công bố một mốc thời gian cụ thể. Theo tài liệu Google Search Central, Google giảm tốc độ crawl tỉ lệ theo số URL lỗi và tăng dần trở lại sau khi site ổn định — nên mục tiêu là sửa nhanh nhất có thể, không chờ tới một ngưỡng nào đó.
502 chỉ xảy ra khi bật Cloudflare, tắt đi thì hết — vậy lỗi ở đâu?
Thường là vấn đề ở chế độ SSL giữa Cloudflare và server gốc, hoặc server gốc chặn nhầm IP của Cloudflare qua firewall. Server gốc có thể hoàn toàn bình thường khi truy cập trực tiếp, nhưng vẫn lỗi khi đi qua CDN.
Có cần thuê người xử lý 502 không, hay tự làm được?
Nếu bạn có quyền truy cập server và biết đọc log, có thể tự chẩn đoán theo các bước trên. Nếu không rành hạ tầng hoặc lỗi lặp lại nhiều lần không rõ nguyên nhân gốc, nên để người có kinh nghiệm quản trị server rà theo đúng tầng.
Đọc thêm
- Lỗi 500 Internal Server Error là gì
- Lỗi 503 Service Unavailable là gì
- Server/hosting ảnh hưởng SEO thế nào
- Dịch vụ SEO Audit
- Dịch vụ chăm sóc website
Nguồn đối chiếu: developers.google.com/search/docs/crawling-indexing/http-network-errors (Google Search Central, mục lỗi 5xx) — kiểm ngày 08/10/2026. Google không công bố một mốc thời gian cố định để coi site là “sập”, bài này mô tả đúng cơ chế giảm/tăng tốc độ crawl mà Google đã công bố, không bịa số liệu.