Lỗi 502 Bad Gateway: nguyên nhân và cách khắc phục

Bạn đang truy cập website bình thường, bỗng trình duyệt hiện lên dòng chữ “502 Bad Gateway” trắng phớ. Không load được gì, không biết lỗi ở đâu. Nếu bạn đang quản trị website và gặp tình huống này, bài viết sẽ giúp bạn hiểu rõ lỗi 502 là gì, vì sao nó xảy ra, và quan trọng nhất: cách xử lý từng bước.

502 Bad Gateway là gì?

502 Bad Gateway là một mã trạng thái HTTP thuộc nhóm lỗi 5xx (lỗi phía server). Lỗi này xuất hiện khi một server đóng vai trò trung gian (gateway hoặc proxy) gửi yêu cầu đến server gốc nhưng nhận lại phản hồi không hợp lệ, hoặc không nhận được phản hồi gì cả.

Hiểu đơn giản hơn: khi bạn gõ URL vào trình duyệt, request đi đến web server (thường là Nginx hoặc Apache). Web server này không trực tiếp xử lý mã PHP mà chuyển tiếp request đến một backend phía sau (thường là PHP-FPM). Nếu backend đó không phản hồi hoặc phản hồi sai, web server không có gì để trả cho trình duyệt nên hiện lỗi 502.

Cơ chế này gọi là reverse proxy. Nginx đóng vai trò proxy, nhận request từ client rồi chuyển đến PHP-FPM (backend). Nếu PHP-FPM bị crash, quá tải, hoặc mất kết nối thì Nginx trả về 502.

Lỗi 502 có thể hiển thị dưới nhiều dạng khác nhau tuỳ trình duyệt, web server, và hệ thống:

• 502 Bad Gateway (phổ biến nhất)
• Error 502
• HTTP Error 502 – Bad Gateway
• 502 Proxy Error
• 502 Service Temporarily Overloaded
• 502 Bad Gateway – Cloudflare (trang lỗi có logo Cloudflare)
• 502 Bad Gateway nginx (trang trắng, chỉ có dòng text)

Dù hiển thị khác nhau, bản chất đều giống: server trung gian không nhận được phản hồi hợp lệ từ server gốc. Lỗi 502 thuộc nhóm 5xx cùng với lỗi 500 Internal Server Error, 503 Service Unavailable, và 504 Gateway Timeout, nhưng mỗi lỗi có nguyên nhân và cách xử lý riêng.

Nguyên nhân gây lỗi 502 Bad Gateway

Lỗi 502 có thể đến từ nhiều nguyên nhân khác nhau. Dưới đây là những nguyên nhân phổ biến nhất mà mình thường gặp:

PHP-FPM bị crash hoặc quá tải

Trên các server dùng Nginx + PHP-FPM (kiến trúc rất phổ biến hiện nay), PHP-FPM là tiến trình xử lý toàn bộ mã PHP. Mỗi request đến website WordPress đều cần PHP-FPM xử lý.

Nếu PHP-FPM bị crash, hết worker, hoặc restart bất thường, Nginx sẽ không nhận được phản hồi và trả về lỗi 502. Nguyên nhân thường gặp bao gồm:

• Plugin WordPress gây segmentation fault (segfault) trong PHP
• Cấu hình pm.max_children quá thấp so với lượng truy cập
• PHP hết bộ nhớ (memory_limit quá nhỏ)
• Một script PHP chạy quá lâu, chiếm hết worker

Nginx timeout khi chờ backend

Nginx có các tham số timeout như proxy_read_timeout và fastcgi_read_timeout. Mặc định thường là 60 giây. Nếu backend xử lý request quá lâu (import dữ liệu lớn, query database phức tạp, gọi API bên ngoài chậm), vượt quá giá trị timeout này, Nginx sẽ ngắt kết nối và trả lỗi 502.

Dạng lỗi này có dấu hiệu đặc trưng: trang loading khoảng 60 giây rồi mới hiện 502. Hay gặp khi bạn chạy cron job nặng, import sản phẩm WooCommerce, hoặc backup database lớn qua giao diện web.

Server bị quá tải

Khi lượng truy cập tăng đột biến (ví dụ: bài viết được chia sẻ viral, hoặc bị bot quét hàng loạt) mà server không đủ RAM, CPU, hoặc số PHP worker, các request sẽ bị xếp hàng rồi bị “bỏ rơi”. Kết quả là server trả lỗi 502 cho những request không được xử lý kịp.

Trường hợp này thường có dấu hiệu: website chậm dần trước, rồi mới bắt đầu lỗi 502 hoàn toàn. Kiểm tra bằng lệnh top hoặc htop trên server sẽ thấy CPU hoặc RAM gần 100%.

Lỗi từ CDN (Cloudflare, Fastly, v.v.)

Nếu bạn đang dùng Cloudflare hoặc CDN khác, lỗi 502 có thể đến từ CDN chứ không phải server gốc. CDN đóng vai trò proxy, nếu nó không kết nối được đến server gốc (do firewall chặn IP Cloudflare, SSL mode sai, hoặc server gốc đang down) thì sẽ hiện trang lỗi 502 riêng của CDN.

Cách nhận biết: nếu trang lỗi có logo Cloudflare ở footer, kèm thông tin như “Cloudflare Ray ID”, thì lỗi 502 xuất phát từ kết nối giữa Cloudflare và server gốc. Ngược lại, nếu chỉ thấy dòng “502 Bad Gateway nginx” trên nền trắng thì lỗi từ server.

Vấn đề DNS

DNS trỏ sai IP, bản ghi DNS chưa cập nhật sau khi chuyển hosting (DNS propagation chưa xong), hoặc DNS cache trên máy bạn đã cũ. Những trường hợp này đều có thể gây 502 do request bị gửi đến server không đúng hoặc server cũ đã không còn hoạt động.

DNS propagation có thể mất từ vài phút đến 48 tiếng tuỳ thuộc vào giá trị TTL của bản ghi DNS. Nếu bạn vừa chuyển hosting, đợi đủ thời gian propagation trước khi lo lắng.

Plugin hoặc theme gây xung đột

Một plugin WordPress có code lỗi có thể gây crash PHP, dẫn đến lỗi 502. Trường hợp này hay xảy ra ngay sau khi bạn cài plugin mới, cập nhật plugin/theme lên phiên bản mới, hoặc cập nhật WordPress core. Hai plugin xung đột với nhau cũng có thể gây ra tình trạng tương tự.

Cách 1: Reload trang và xóa cache trình duyệt

Trước khi làm gì phức tạp, hãy thử những bước đơn giản nhất. Nhiều trường hợp lỗi 502 chỉ là tạm thời và tự hết sau vài giây.

Bước 1: Reload trang

Nhấn F5 hoặc Ctrl + F5 (Windows) / Cmd + Shift + R (Mac) để tải lại trang bỏ qua cache. Đợi khoảng 30 giây rồi thử lại lần nữa. Server có thể đang restart dịch vụ hoặc xử lý xong đợt request trước đó.

Bước 2: Thử trình duyệt khác hoặc thiết bị khác

Mở website trên trình duyệt khác (Chrome, Firefox, Safari, Edge) hoặc dùng điện thoại với mạng 4G/5G (khác mạng WiFi đang dùng). Mục đích là loại trừ vấn đề do mạng hoặc trình duyệt của bạn.

• Nếu thiết bị khác truy cập bình thường → vấn đề ở máy/trình duyệt/mạng của bạn
• Nếu thiết bị khác cũng lỗi → vấn đề ở server, tiếp tục các bước bên dưới

Bước 3: Xóa cache và cookies trình duyệt

Đôi khi trình duyệt cache lại trang lỗi và tiếp tục hiển thị lỗi dù server đã phục hồi. Trên Chrome: vào Settings → Privacy and Security → Clear browsing data. Chọn All time, tích vào Cached images and files và Cookies and other site data, rồi nhấn Clear data.

Nếu bạn không muốn xoá toàn bộ cookies (sẽ phải đăng nhập lại các website), bạn có thể chỉ xoá cookies của website đang bị lỗi: vào Settings → Privacy → Cookies → See all cookies, tìm tên domain rồi xóa.

Bước 4: Flush DNS trên máy tính

DNS cache trên máy tính có thể giữ lại bản ghi cũ, đặc biệt nếu website vừa chuyển hosting hoặc thay đổi IP. Flush DNS để buộc máy tính truy vấn lại DNS server:

# Windows (mở Command Prompt với quyền Administrator)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (Ubuntu/Debian)
sudo systemd-resolve --flush-caches

Sau khi flush DNS, đóng trình duyệt hoàn toàn rồi mở lại và truy cập website.

Cách 2: Kiểm tra CDN và Cloudflare

Nếu website đang dùng Cloudflare hoặc CDN khác, đây là bước cần kiểm tra sớm. CDN đứng giữa người dùng và server gốc, đóng vai trò reverse proxy. Lỗi 502 hoàn toàn có thể đến từ CDN chứ không phải server của bạn.

Cách phân biệt lỗi từ Cloudflare hay từ server gốc:

• Trang lỗi có logo và footer “Cloudflare”, kèm Cloudflare Ray ID → lỗi nằm ở kết nối giữa Cloudflare và server gốc. Server gốc có thể đang down hoặc Cloudflare không kết nối được.
• Trang lỗi trắng, chỉ có dòng “502 Bad Gateway nginx” → lỗi trực tiếp từ Nginx trên server gốc, không liên quan CDN.

Kiểm tra trạng thái Cloudflare:

Truy cập cloudflarestatus.com để xem Cloudflare có đang gặp sự cố toàn cầu hoặc tại khu vực của bạn không. Nếu có, bạn chỉ cần chờ Cloudflare khắc phục.

Tạm tắt Cloudflare proxy để xác nhận:

Đăng nhập Cloudflare Dashboard, vào domain của bạn, mục DNS → Records. Tạm chuyển proxy status của bản ghi A chính từ Proxied (biểu tượng đám mây cam) sang DNS only (đám mây xám). Đợi 2-5 phút rồi truy cập lại website.

• Nếu website hoạt động bình thường sau khi tắt proxy → lỗi liên quan đến Cloudflare. Kiểm tra lại cấu hình SSL/TLS mode: nên dùng Full hoặc Full (Strict) nếu server có SSL certificate. Dùng mode Flexible khi server đã có SSL thường gây loop hoặc lỗi 502.
• Nếu vẫn lỗi → vấn đề ở server gốc, tiếp tục các bước bên dưới.

Kiểm tra firewall server:

Một nguyên nhân khá phổ biến: firewall trên server chặn IP của Cloudflare. Cloudflare có dải IP riêng, nếu bạn dùng iptables, UFW, hoặc CSF trên server, hãy đảm bảo whitelist các dải IP của Cloudflare. Danh sách IP: cloudflare.com/ips.

Cách 3: Kiểm tra PHP-FPM và cấu hình timeout

Nếu bạn dùng VPS hoặc server riêng và có quyền SSH, đây là bước quan trọng nhất để tìm ra nguyên nhân gốc rễ. Phần lớn lỗi 502 trên server dùng Nginx + PHP-FPM đều liên quan đến PHP-FPM.

Kiểm tra PHP-FPM có đang chạy không:

# Kiểm tra trạng thái PHP-FPM (thay 8.2 bằng version PHP đang dùng)
sudo systemctl status php8.2-fpm
# Nếu thấy "Active: inactive (dead)" hoặc "failed", restart lại
sudo systemctl restart php8.2-fpm
# Kiểm tra lại
sudo systemctl status php8.2-fpm

Nếu không biết PHP version, chạy php -v hoặc ls /etc/php/ để xem.

Đọc log PHP-FPM để tìm nguyên nhân:

# Xem 50 dòng log gần nhất
sudo tail -50 /var/log/php8.2-fpm.log
# Tìm lỗi segfault, child exited, hoặc emergency restart
sudo grep -i "segfault\|exited\|emergency\|max_children" /var/log/php8.2-fpm.log | tail -20

Mỗi dòng log sẽ cho bạn manh mối:

• WARNING: [pool www] server reached pm.max_children setting (5) → PHP-FPM hết worker. Cần tăng pm.max_children.
• child xxxx exited on signal 11 (SIGSEGV) → PHP bị segfault, thường do plugin/extension gây crash.
• WARNING: [pool www] child xxxx exited with code 255 → Script PHP bị lỗi nghiêm trọng.

Tăng pm.max_children nếu hết worker:

# Mở file cấu hình pool PHP-FPM
sudo nano /etc/php/8.2/fpm/pool.d/www.conf
# Tìm và điều chỉnh các giá trị (tuỳ RAM server):
pm = dynamic
pm.max_children = 20        # Server 2GB RAM: ~15-20, 4GB: ~30-40
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500       # Tự restart worker sau 500 requests, tránh memory leak
# Sau khi sửa, restart PHP-FPM
sudo systemctl restart php8.2-fpm

Quy tắc tính nhanh pm.max_children: lấy RAM khả dụng (bỏ qua phần dùng cho MySQL, OS) chia cho bộ nhớ trung bình mỗi PHP process (thường 30-50MB với WordPress). Ví dụ server 2GB RAM, dành 1GB cho PHP-FPM, mỗi process 50MB → max_children khoảng 20.

Kiểm tra và điều chỉnh timeout Nginx:

Nếu lỗi 502 xuất hiện sau khoảng 60 giây loading, khả năng cao là timeout. Kiểm tra cấu hình Nginx:

# Tìm các giá trị timeout hiện tại
grep -r "timeout" /etc/nginx/nginx.conf /etc/nginx/conf.d/ /etc/nginx/sites-enabled/
# Các giá trị nên điều chỉnh (thêm vào block server hoặc http):
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;
fastcgi_read_timeout 300;
# Kiểm tra syntax rồi reload
sudo nginx -t && sudo systemctl reload nginx

Kiểm tra log Nginx:

# Xem error log Nginx
sudo tail -50 /var/log/nginx/error.log
# Tìm lỗi liên quan upstream (PHP-FPM)
sudo grep "upstream" /var/log/nginx/error.log | tail -20

Dòng log kiểu upstream prematurely closed connection while reading response header xác nhận PHP-FPM bị ngắt kết nối giữa chừng, Nginx không nhận được phản hồi nên trả 502.

Nếu bạn dùng shared hosting và không có quyền SSH, hãy liên hệ nhà cung cấp hosting để họ kiểm tra. Khi liên hệ, cung cấp: thời điểm xảy ra lỗi, URL bị lỗi, và các bước bạn đã thử.

💡 Nếu server thường xuyên hết tài nguyên dù đã tối ưu, bạn nên cân nhắc nâng cấp lên gói hosting mạnh hơn với nhiều CPU, RAM, và PHP worker hơn để website chạy ổn định khi lượng truy cập tăng.

Cách 4: Kiểm tra plugin, theme và error log

Nếu lỗi 502 xảy ra ngay sau khi bạn cài hoặc cập nhật plugin/theme, rất có thể đó là nguyên nhân. Plugin có code lỗi, không tương thích với phiên bản PHP hoặc WordPress hiện tại, hoặc xung đột với plugin khác đều có thể gây crash PHP dẫn đến 502.

Trường hợp 1: Vẫn truy cập được WordPress Admin

Vào Plugins → Installed Plugins, tích chọn tất cả plugin, chọn Deactivate từ Bulk Actions rồi nhấn Apply. Kiểm tra website:

• Nếu hết lỗi 502 → kích hoạt lại từng plugin một, mỗi lần bật 1 plugin rồi kiểm tra website. Plugin nào bật lên mà lỗi quay lại thì đó là thủ phạm.
• Nếu vẫn lỗi sau khi tắt hết plugin → thử đổi về theme mặc định (Twenty Twenty-Five) để loại trừ theme.

Trường hợp 2: Không vào được WordPress Admin

Khi lỗi 502 khiến bạn không truy cập được cả wp-admin, phải thao tác qua FTP hoặc File Manager trong hosting panel (cPanel, DirectAdmin, v.v.). Nếu có SSH thì càng nhanh:

# Đổi tên thư mục plugins để vô hiệu hoá toàn bộ
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled
# Kiểm tra website. Nếu hết lỗi → đổi tên lại
mv plugins_disabled plugins
# Vô hiệu từng plugin để tìm thủ phạm
cd plugins
mv plugin-nghi-ngo plugin-nghi-ngo.bak
# Kiểm tra website sau mỗi lần đổi tên

Tương tự, bạn có thể đổi tên thư mục theme đang dùng trong wp-content/themes/. WordPress sẽ tự chuyển về theme mặc định nếu theme hiện tại không tồn tại.

Bật WordPress Debug Log:

Để WordPress ghi chi tiết lỗi PHP ra file log, mở wp-config.php (nằm ở thư mục gốc WordPress) và thêm hoặc sửa các dòng sau trước dòng /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // Ghi log vào wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Không hiện lỗi trên giao diện

Sau đó truy cập website (sẽ vẫn lỗi 502 nếu chưa fix), rồi kiểm tra file wp-content/debug.log:

# Xem 50 dòng cuối cùng trong debug log
tail -50 wp-content/debug.log
# Lọc lỗi nghiêm trọng
grep "Fatal error" wp-content/debug.log | tail -10
# Ví dụ output:
# [24-Mar-2026 01:30:15 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted
# [24-Mar-2026 01:30:15 UTC] PHP Fatal error: Call to undefined function xyz() in /wp-content/plugins/abc/main.php

Dòng log sẽ chỉ rõ file và dòng code gây lỗi, giúp bạn xác định chính xác plugin hoặc theme nào cần xử lý.

Sau khi xác định và xử lý xong, nhớ tắt WP_DEBUG bằng cách đổi true thành false. Để debug log chạy trên production lâu dài sẽ ghi file liên tục, vừa tốn disk vừa có thể lộ thông tin nhạy cảm.

Lỗi 502 Bad Gateway ảnh hưởng SEO như thế nào?

Lỗi 502 nếu chỉ xảy ra trong vài phút rồi tự hết thì hầu như không ảnh hưởng gì đến SEO. Googlebot khi crawl mà gặp lỗi tạm thời sẽ lấy trang từ cache và quay lại crawl sau.

Tuy nhiên, nếu website bị lỗi 502 liên tục trong nhiều giờ (từ 6 tiếng trở lên), Google có thể coi đây là vấn đề cấp website và bắt đầu giảm thứ hạng. Ngoài SEO, lỗi 502 kéo dài còn ảnh hưởng trực tiếp đến người dùng: họ sẽ rời đi ngay lập tức, bounce rate tăng, và mất lòng tin.

Khác với lỗi 503 (Service Unavailable) thường dùng khi bảo trì có chủ đích (Google hiểu và sẽ quay lại), lỗi 502 thể hiện server đang gặp vấn đề thật sự. Google Search Console sẽ ghi nhận lỗi 502 dưới mục Crawl stats → Responses. Nếu thấy nhiều lỗi 502 ở đó, bạn cần xử lý sớm.

Để giảm thiểu ảnh hưởng SEO khi server gặp sự cố, một số biện pháp phòng ngừa nên làm:

• Cài đặt monitoring (UptimeRobot, Hetrix, v.v.) để nhận cảnh báo ngay khi website down
• Dùng page caching (LiteSpeed Cache, WP Super Cache) để giảm tải cho PHP-FPM
• Cấu hình Nginx trả trang cache tĩnh khi backend bị lỗi (proxy_cache_use_stale)
• Giữ cho plugin, theme, và WordPress core luôn cập nhật phiên bản mới nhất

Câu hỏi thường gặp

Tổng kết

Lỗi 502 Bad Gateway tuy nhìn “đáng sợ” nhưng phần lớn các trường hợp đều có thể xử lý được nếu bạn kiểm tra đúng thứ tự. Quy trình khắc phục tóm gọn:

1. Reload trang + xóa cache trình duyệt + flush DNS
2. Kiểm tra CDN/Cloudflare (tạm tắt proxy, kiểm tra SSL mode)
3. SSH vào server, kiểm tra PHP-FPM status và log, điều chỉnh max_children và timeout Nginx
4. Tắt plugin/theme để tìm xung đột, bật WP_DEBUG_LOG để đọc error log
5. Nếu server thiếu tài nguyên, cân nhắc nâng cấp hosting để đảm bảo website chạy ổn định

Nếu bạn đã thử hết các cách trên mà vẫn bị lỗi, hãy liên hệ nhà cung cấp hosting. Khi liên hệ, cung cấp càng nhiều thông tin càng tốt: thời điểm bắt đầu lỗi, URL cụ thể bị ảnh hưởng, nội dung error log, và các bước bạn đã thử. Càng chi tiết thì bộ phận kỹ thuật xử lý càng nhanh.