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 từ chối kết nối, ngắt kết nối hoặc gửi câu trả lời sai, 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 phải xếp hàng trong hàng đợi của socket. Phần lớn sau đó hết thời gian chờ và thành 504; khi hàng đợi đầy, nginx ghi (11: Resource temporarily unavailable) và trả về 502.
• 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.
• Proxy không truy cập được upstream sau một thay đổi mạng. Tường lửa từ chối proxy, hoặc upstream chuyển sang IP mới, sẽ cho ra 502 (Connection refused, No route to host). Tường lửa lặng lẽ bỏ gói tin thì cho ra 504, và phía sau Cloudflare chúng hiện thành 521 hoặc 522.

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. Website Down Checker của DNS Robot mở trang từ 11 địa điểm, còn Kiểm tra HTTP Header hiển thị chính xác mã trạng thái mà máy chủ của chúng tôi nhận được. Nếu họ cũng thấy 502, lỗi nằm ở trang web, không phải ở bạn.
• Tải lại cứng bằng Ctrl + Shift + R (Mac: Cmd + Shift + R), phòng trường hợp hiếm hoi bạn đang thấy một trang lỗi nằm trong bộ nhớ đệm.
• 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 thường ghi lại điều gì đã sai (ngoại lệ là race keep-alive của bộ cân bằng tải và các lỗi 502 do chính Cloudflare tạo ra). Hãy thực hiện lần lượt ba bước kiểm tra sau; phần thứ tư là một ví dụ thực tế.

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

Tái hiện lỗi 502, sau đó đọc 50 dòng cuối trong log lỗi của proxy (lệnh nằm bên dưới bảng). Mỗi thông báo nginx sau chỉ ra một cách khắc phục riêng:

# 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

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?
sudo 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?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# 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).

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; sau khi chạy nginx -t và reload, trang trả về 200:

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;
}

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 giá trị Set-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 trong Node 26 trở về trước (server.keepAliveTimeout; Node 24.6 và 22.19 đã thêm keepAliveTimeoutBuffer 1 giây vào đó, và bản major kế tiếp nâng mặc định lên 65 giây), 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 // only needed before Node 18; harmless later

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 (hướng dẫn 502/504 của Cloudflare):

• Trang mang thương hiệu Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): chính máy chủ gốc (origin) của bạn đã trả về 502 hoặc 504 cho Cloudflare. Hãy sửa ở origin bằng các bước phía máy chủ ở trên. Nếu Cloudflare hoàn toàn không kết nối được origin, bạn sẽ thấy 521 hoặc 522, không phải 502.
• Một trang đơn giản ghi "502 Bad Gateway" với chữ "cloudflare" bên dưới: lỗi này đến từ chính Cloudflare. Tài liệu của Cloudflare nêu hai nguyên nhân: origin gửi nội dung gzip bị hỏng, hoặc nội dung gzip mà Content-Length không được cập nhật (hãy tắt nén ở origin để thử), và lưu lượng đột ngột tăng vọt tại một trung tâm dữ liệu của Cloudflare, tự hết sau một lúc.
• Trang nhắc đến nginx hoặc Apache: thường là yêu cầu đã đến máy chủ của bạn mà không qua Cloudflare, vì bản ghi DNS không được proxy (đám mây xám) hoặc bạn đang xem trực tiếp origin (trừ khi một Cache Rule bật Origin error page pass-through).
• Đã chuyển hosting? Hãy cập nhật bản ghi A của origin trong DNS của Cloudflare (IP origin sai thường hiện thành 521, 522 hoặc 523). DNS Lookup chỉ cho thấy origin với các bản ghi đám mây xám (chỉ DNS); các bản ghi được proxy trả lời bằng IP riêng của Cloudflare.

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ố.