Lỗi 502 Bad Gateway là gì? Cách khắc phục

Lỗi 502 Bad Gateway là gì?

502 Bad Gateway là mã trạng thái HTTP cho biết máy chủ đang trả lời bạn đóng vai trò gateway hoặc proxy, và nó nhận được phản hồi không hợp lệ từ máy chủ phía sau. Chuẩn HTTP (RFC 9110, mục 15.6.3) định nghĩa đúng như vậy: máy chủ, "trong khi hoạt động như một gateway hoặc proxy, đã nhận được phản hồi không hợp lệ từ một máy chủ phía trong mà nó truy cập khi cố gắng hoàn thành yêu cầu."

Hầu hết các website hiện đại có ít nhất hai lớp. Một máy chủ phía trước, như nginx, Apache, Cloudflare hoặc bộ cân bằng tải đám mây, nhận kết nối của bạn rồi chuyển yêu cầu đến một ứng dụng upstream như PHP-FPM, ứng dụng Node.js, Gunicorn của Python hoặc một container. Khi upstream đó ngừng hoạt động, bị crash, hoặc trả lời bằng thứ mà proxy không dùng được, proxy không có gì để đưa cho bạn, nên nó trả về 502.

Điểm quan trọng là bản thân gateway vẫn đang hoạt động. Nó đã nhận yêu cầu của bạn và phản hồi. Lỗi nằm ở một bước xa hơn phía sau.

Các dạng hiển thị khác nhau của lỗi 502

Mã trạng thái ở đâu cũng giống nhau, nhưng trang bạn thấy phụ thuộc vào proxy nào đã tạo ra nó:

Dù bạn thấy phiên bản nào, tên proxy ở cuối trang là một manh mối hữu ích: nó cho chủ website biết cần điều tra lớp nào.

502, 500, 503 và 504 khác nhau thế nào?

Các mã 5xx đều có nghĩa là "sự cố máy chủ", nhưng mỗi mã chỉ đến một lớp khác nhau:

Quy tắc nhanh: 502 = upstream trả lời sai (hoặc ngắt kết nối), 504 = upstream không trả lời kịp thời gian. Các hướng dẫn của chúng tôi về những mã lỗi lân cận đi sâu hơn: 500 Internal Server Error, 503 Service Unavailable và 504 Gateway Timeout.

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

• Ứng dụng upstream không chạy. PHP-FPM, Node, Gunicorn hoặc container bị crash, không khởi động được sau khi triển khai, hoặc đang khởi động lại.

• Proxy trỏ sai chỗ. proxy_pass hoặc fastcgi_pass dùng sai cổng, đường dẫn socket PHP cũ sau khi nâng cấp, hoặc localhost bên trong một container Docker.

• Ứng dụng bị crash với một số yêu cầu. Một trang khiến tiến trình bị kill do hết bộ nhớ hoặc gây ra ngoại lệ không được xử lý, và kết nối bị đóng trước khi có phản hồi.

• Tất cả worker đều bận. PHP-FPM đã chạm ngưỡng pm.max_children, nên các yêu cầu mới không có nơi nào để đi.

• Header phản hồi quá lớn. Cookie lớn hoặc header bảo mật dài làm tràn proxy_buffer_size của nginx.

• Keep-alive không khớp phía sau bộ cân bằng tải. Ứng dụng đóng các kết nối nhàn rỗi sớm hơn bộ cân bằng tải mong đợi, nên bộ cân bằng tải gửi yêu cầu vào một kết nối đang đóng.

• Tường lửa hoặc thay đổi mạng giữa proxy và máy chủ gốc. Ví dụ, CDN không còn truy cập được máy chủ gốc (origin) đã đổi địa chỉ IP hoặc quy tắc tường lửa.

Cách sửa lỗi 502 khi bạn là người truy cập

Bạn không thể sửa máy chủ của người khác, nhưng các bước sau xác nhận vấn đề thực sự nằm ở phía họ và loại bỏ những nguyên nhân cục bộ hiếm gặp:

• Đợi 30 đến 60 giây rồi tải lại (Ctrl + R, hoặc Cmd + R trên Mac). Nhiều lỗi 502 chỉ kéo dài trong lúc triển khai hoặc khởi động lại.

• Kiểm tra xem trang có sập với tất cả mọi người không. Công cụ HTTP Headers của DNS Robot yêu cầu trang từ máy chủ của chúng tôi và hiển thị chính xác mã trạng thái. Nếu chúng tôi cũng nhận 502, lỗi nằm ở trang web, không phải ở bạn. Ping Test cho biết máy chủ có phản hồi hay không.

• Tải lại cứng và xóa bộ nhớ đệm. Ctrl + Shift + R (Mac: Cmd + Shift + R) bỏ qua bản sao trong bộ nhớ đệm, phòng trường hợp bạn đang thấy một trang lỗi cũ.

• Xóa bộ nhớ đệm DNS nếu trang web vừa chuyển hosting, để bạn đến được máy chủ mới. Đây là cách xóa bộ nhớ đệm DNS trên mọi hệ điều hành.

• Tắt VPN và proxy. Proxy của chính bạn có thể là "gateway" bị lỗi, đặc biệt trên mạng công ty.

• Thử trình duyệt khác hoặc điện thoại dùng dữ liệu di động. Nếu trang hoạt động ở đó, hãy xóa cookie của trang web đó.

Cách sửa lỗi 502 Bad Gateway trên máy chủ của bạn

Ở phía máy chủ, 502 là một trong những lỗi dễ sửa hơn cả, vì proxy hầu như luôn ghi lại chính xác điều gì đã sai. Hãy thực hiện lần lượt bốn bước kiểm tra sau.

1. Đọc log lỗi của proxy

Tái hiện lỗi 502, sau đó đọc những dòng cuối trong log lỗi trên máy chủ proxy:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

Các thông báo nginx sau bao quát phần lớn các lỗi 502, và mỗi thông báo chỉ ra cách khắc phục:

2. Kiểm tra ứng dụng upstream có đang chạy không

# PHP-FPM (adjust the version)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js under PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # look for containers that keep restarting
docker logs --tail 50 <container>

# Was it killed for using too much memory?
dmesg -T | grep -i "killed process"

Nếu dịch vụ đã dừng, hãy khởi động nó và tìm hiểu lý do nó dừng: một lần triển khai thất bại, lỗi cú pháp trong bản phát hành mới, hoặc OOM killer (cơ chế diệt tiến trình khi hết bộ nhớ). Trong log của PHP-FPM, server reached pm.max_children setting nghĩa là mọi worker đều bận. Chỉ tăng pm.max_children nếu máy chủ đủ RAM, nếu không hãy tìm các yêu cầu chậm đang giữ chân worker.

3. Đảm bảo proxy_pass trỏ đúng cổng hoặc socket

So sánh địa chỉ mà nginx được cấu hình để kết nối với những gì thực sự đang lắng nghe:

# What is nginx proxying to?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# What is actually listening?
sudo ss -tlnp            # TCP ports and their processes
ls -l /run/php/          # PHP-FPM socket files

Hai trường hợp không khớp kinh điển: sau khi nâng cấp PHP, socket trở thành php8.3-fpm.sock trong khi nginx vẫn trỏ đến php8.1-fpm.sock; và bên trong Docker, proxy_pass http://localhost:3000 trỏ đến chính container nginx thay vì ứng dụng, nên hãy dùng tên service trong Compose (http://app:3000). Sau mọi thay đổi, chạy sudo nginx -t và sudo systemctl reload nginx.

4. Ví dụ thực tế: dnsrobot.net đã trả về lỗi 502 như thế nào

Chuyện này xảy ra với chúng tôi vào ngày 30 tháng 9 năm 2026. Sau khi đăng một loạt bài blog mới, đúng một bài trong số đó trả về 502 Bad Gateway qua nginx 1.24, trong khi mọi trang khác vẫn hoạt động. Ứng dụng Next.js phía sau nginx trả về chính trang đó với 200 OK khi chúng tôi yêu cầu trực tiếp trên cổng 3000. Vậy là ứng dụng vẫn ổn, còn gateway mới là thứ bị lỗi.

Log lỗi của nginx có câu trả lời trong một dòng: upstream sent too big header while reading response header from upstream. Header phản hồi của trang đó lên tới 4.087 byte, chủ yếu là một header Content-Security-Policy dài cộng với các header Link để preload. nginx đọc phần đầu của phản hồi, bao gồm toàn bộ header, vào một bộ đệm được đặt bởi proxy_buffer_size, mặc định bằng một trang bộ nhớ: 4 KB trên máy chủ của chúng tôi. Như vậy chỉ còn 9 byte trống, và toàn bộ khối header, tính cả dòng trạng thái, đã làm tràn bộ đệm.

Cách khắc phục là ba dòng trong khối location chuyển tiếp yêu cầu đến ứng dụng:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # room for large headers (was the 4k default)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

Sau khi chạy nginx -t và reload, trang trả về 200. Bài học: nếu chỉ một số trang trả về 502 trong khi phần còn lại của trang web vẫn hoạt động, hãy tìm giới hạn về kích thước, như header lớn hoặc cookie lớn trên các trang đó, trước khi nghi ngờ ứng dụng.

Node.js phía sau bộ cân bằng tải: lỗi 502 ngẫu nhiên

Nếu bạn chạy Node.js phía sau AWS Application Load Balancer hoặc một bộ cân bằng tải tương tự và thỉnh thoảng thấy lỗi 502 mà log ứng dụng không có lỗi nào, hãy kiểm tra thời gian chờ keep-alive. Máy chủ HTTP của Node mặc định đóng các kết nối keep-alive nhàn rỗi sau 5 giây (server.keepAliveTimeout, trong Node.js 26 trở về trước), trong khi AWS ALB giữ kết nối nhàn rỗi mở trong 60 giây. Đôi khi bộ cân bằng tải tái sử dụng một kết nối đúng lúc Node đóng nó, và yêu cầu đó trả về lỗi 502.

Cách khắc phục là đặt thời gian chờ của ứng dụng dài hơn của bộ cân bằng tải:

const server = app.listen(3000)
// Must be longer than the load balancer's idle timeout (ALB default: 60s)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // keep slightly above keepAliveTimeout

Lỗi 502 Bad Gateway trên Cloudflare

Khi dùng Cloudflare, trước tiên hãy xem ai đã tạo ra trang lỗi:

• Trang mang thương hiệu Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): Cloudflare đang hoạt động nhưng không nhận được phản hồi hợp lệ từ máy chủ gốc (origin) của bạn. Kiểm tra máy chủ gốc có đang chạy, có lắng nghe trên cổng 443/80 và không chặn các dải IP của Cloudflare trong tường lửa. Kiểm tra trực tiếp máy chủ gốc bằng Port Checker.

• Trang 502 đơn giản, không có thương hiệu: nếu trang không nhắc đến cloudflare (ví dụ ghi tên nginx hoặc Apache), chính máy chủ gốc của bạn đã tạo ra lỗi 502. Hãy dùng các bước phía máy chủ ở trên. Một trang trống chỉ có chữ "cloudflare" ở cuối là do chính Cloudflare tạo ra, ví dụ trong lúc định tuyến lại lưu lượng ngắn hạn hoặc khi máy chủ gốc gửi nội dung gzip bị hỏng.

• IP máy chủ gốc đã thay đổi? Nếu bạn đã chuyển hosting, hãy cập nhật bản ghi A trong DNS của Cloudflare. DNS Lookup cho biết thế giới hiện đang thấy gì.

Lỗi 502 có ảnh hưởng đến SEO không?

Sự cố ngắn thì không. Tài liệu của Google cho biết lỗi máy chủ 5xx khiến trình thu thập dữ liệu của Google tạm thời giảm tốc độ thu thập. Các trang đã được lập chỉ mục ban đầu vẫn nằm trong chỉ mục, nhưng nếu lỗi kéo dài, Google cuối cùng sẽ loại bỏ các URL đó.

Vì vậy, lỗi 502 kéo dài vài phút trong lúc triển khai là vô hại. Lỗi 502 trên các trang quan trọng kéo dài nhiều ngày, hoặc xuất hiện chập chờn trong nhiều tuần, có thể làm giảm việc thu thập dữ liệu và khiến bạn mất thứ hạng. Hãy theo dõi các URL quan trọng, và kiểm tra báo cáo Số liệu thống kê về hoạt động thu thập dữ liệu (Crawl stats) trong Search Console sau mỗi sự cố.