502 Bad Gateway — Ý nghĩa và cách khắc phục

"Bad Gateway" thực chất nghĩa là gì

Phần lớn website không do một chương trình duy nhất phục vụ. Máy chủ phía trước — thường là Nginx, Apache hoặc một CDN như Cloudflare — nhận yêu cầu của bạn rồi chuyển cho thứ nằm phía sau: PHP-FPM, một tiến trình Node, một ứng dụng Python, hay một web server khác. Trong sắp đặt đó, máy chủ phía trước đóng vai gateway.

502 là cách máy chủ phía trước nói một cách trung thực rằng nó đã làm xong việc của mình còn thứ phía sau thì không. Hoặc không trả lời gì, hoặc trả lời với định dạng nó không đọc được, hoặc bị ngắt kết nối giữa chừng. Bản thân máy chủ phía trước vẫn khỏe — chính vì thế bạn nhận được một trang lỗi được định dạng đàng hoàng chứ không phải timeout.

502 khác 500 và 504 ra sao

Ba mã này hay bị gộp chung thành "lỗi máy chủ", khiến người ta tìm sai chỗ. Thực tế chúng chỉ về những thành phần khác nhau.

Nguyên nhân thường gặp, phổ biến nhất trước

• Tiến trình backend đã crash hoặc chưa từng được khởi động. PHP-FPM, Node hay service ứng dụng không chạy nên máy chủ phía trước không có ai để nói chuyện. Đây là nguyên nhân phổ biến nhất, bỏ xa các nguyên nhân khác.
• Máy chủ hết bộ nhớ và kernel đã giết backend. Tìm dòng OOM-killer trong log hệ thống — tiến trình biến mất mà không để lại lỗi nào của riêng nó, và đó chính là thứ tạo ra 502.
• Backend quá tải và từ chối kết nối mới. Toàn bộ worker PHP-FPM đang bận nên yêu cầu mới bị từ chối thẳng thay vì xếp hàng.
• Cấu hình proxy trỏ sai đích. Sau một lần triển khai hoặc đổi cấu hình, máy chủ phía trước trỏ nhầm cổng hoặc socket. Nếu 502 xuất hiện ngay sau một thay đổi, hãy bắt đầu từ đây.
• Một quy tắc tường lửa giữa hai thành phần. Hay gặp ở kiến trúc nhiều máy chủ khi front end và ứng dụng nằm trên các máy khác nhau.
• Backend trả về dữ liệu sai định dạng. Một fatal error PHP in ra trước header, hoặc một tiến trình ghi vào stdout khi không nên, tạo ra phản hồi mà gateway không phân tích được.
• Vấn đề ở CDN hoặc reverse proxy. Nếu bạn dùng Cloudflare, 502 có thể đến từ chính Cloudflare chứ không phải origin — trang lỗi thường ghi rõ bên nào.

Kiểm tra theo thứ tự này

Trình tự sau được sắp xếp để loại trừ nguyên nhân khả dĩ nhất với ít công nhất, đồng thời tránh sai lầm kinh điển là khởi động lại lung tung cho đến khi có gì đó thay đổi.

• Kiểm tra backend có đang chạy không. Trên máy chủ Linux: "systemctl status php-fpm" hoặc lệnh tương đương cho stack của bạn. Nếu nó chết, đó là câu trả lời và câu hỏi tiếp theo là tại sao.
• Đọc error log của máy chủ phía trước trước khi khởi động lại bất cứ thứ gì. Nginx ghi lý do thật vào /var/log/nginx/error.log — các thông báo "connect() failed", "no live upstreams" và "recv() failed" mỗi cái chỉ về một hướng khác nhau. Khởi động lại trước sẽ xóa mất bằng chứng này.
• Kiểm tra bộ nhớ trống và tìm OOM killer trong log hệ thống. Nếu backend liên tục chết khi tải tăng mà không ghi lỗi của riêng nó, kernel đang giết nó và máy quá nhỏ so với lưu lượng.
• Xác nhận đích proxy khớp với nơi backend thực sự lắng nghe — cổng hoặc đường dẫn socket trong cấu hình máy chủ phía trước so với trong cấu hình backend. Sai một chữ số là đủ.
• Khởi động lại backend, rồi tới máy chủ phía trước, theo đúng thứ tự đó. Chỉ làm sau khi đã thu thập bằng chứng.
• Nếu lỗi lúc có lúc không thay vì liên tục, hãy đối chiếu với biểu đồ lưu lượng. 502 xuất hiện lúc cao điểm và biến mất lúc vắng là vấn đề công suất, không phải lỗi cấu hình, và không cách chỉnh cấu hình nào chữa được.

Làm được gì trên shared hosting

Trên shared hosting bạn không kiểm tra được PHP-FPM hay đọc được log hệ thống, nên phần lớn các bước trên đóng lại. Điều đó không có nghĩa bạn bất lực, nhưng cách tiếp cận đúng là khác.

Hãy bắt đầu bằng việc xác định lỗi chỉ ảnh hưởng website của bạn hay mọi website trên máy chủ đó — nếu nhà cung cấp có trang trạng thái, xem ở đó trước. Sau đó nghĩ xem phía bạn có gì thay đổi: cập nhật plugin, đổi theme, hay một script đột nhiên ngốn bộ nhớ nhiều hơn hẳn. Hoàn tác thay đổi đó thường nhanh hơn là chẩn đoán nó.

Nếu 502 cứ quay lại ở mức lưu lượng bình thường, câu trả lời trung thực thường là tài khoản đã vượt quá khả năng của shared hosting. Trên máy chủ dùng chung, tài nguyên của bạn chia sẻ với mọi người khác, và một đợt tăng lưu lượng của hàng xóm có thể hạ gục website bạn mà bạn chẳng làm gì sai. Chuyển sang VPS với CPU và RAM riêng loại bỏ hẳn nhóm vấn đề này, đồng thời cho bạn log cần thiết để tự chẩn đoán lần sau.