Lỗi 502 Bad Gateway trong Nginx thường có nghĩa là Nginx không nhận được phản hồi hợp lệ từ máy chủ thượng nguồn, chẳng hạn như PHP-FPM, Node.js hoặc một ứng dụng backend khác.
Những nguyên nhân phổ biến nhất là dịch vụ ứng dụng đã dừng, cổng hoặc socket thượng nguồn được cấu hình sai, và tiến trình backend gặp sự cố hoặc đóng kết nối đột ngột.
Trước tiên, hãy kiểm tra nhật ký lỗi của Nginx. Chúng thường cho biết chính xác lý do kết nối thất bại.
Hướng dẫn này trình bày bảy bước thiết thực để chẩn đoán và khắc phục sự cố trên máy chủ Linux chạy Nginx.
Nguyên nhân nào gây ra lỗi 502 Bad Gateway trong Nginx?
Nginx thường đóng vai trò proxy ngược, chuyển tiếp yêu cầu đến các ứng dụng backend rồi trả phản hồi của chúng cho người truy cập.
Nếu dịch vụ thượng nguồn không phản hồi đúng cách, Nginx có thể trả về mã trạng thái HTTP 502.
Các nguyên nhân phổ biến bao gồm:
- Dịch vụ backend đã dừng hoặc gặp sự cố.
- Địa chỉ IP, cổng hoặc socket Unix thượng nguồn không chính xác.
- Tiến trình PHP-FPM hoặc ứng dụng gặp sự cố.
- Vấn đề về quyền truy cập socket.
- Không đủ bộ nhớ hoặc dung lượng ổ đĩa.
- Kết nối thượng nguồn không hợp lệ hoặc bị đóng quá sớm.
Các bước kiểm tra sau đây giả định rằng bạn có quyền truy cập SSH và quyền quản trị máy chủ Linux của mình.
1. Kiểm tra nhật ký lỗi của Nginx
Nhật ký lỗi của Nginx thường là cách nhanh nhất để xác định nguyên nhân gây lỗi 502.
Kết nối với máy chủ qua SSH và chạy:
sudo tail -n 50 /var/log/nginx/error.logThao tác này hiển thị 50 mục nhật ký mới nhất.
Để theo dõi khi chẩn đoán sự cố, hãy dùng:
sudo tail -f /var/log/nginx/error.logTải lại trang web bị ảnh hưởng và theo dõi các thông báo mới.
| Thông báo trong nhật ký | Nguyên nhân có thể xảy ra |
|---|---|
connect() failed (111: Connection refused) | Backend không chấp nhận kết nối |
No such file or directory | Không tìm thấy socket thượng nguồn đã cấu hình |
Permission denied | Nginx không thể truy cập socket hoặc tài nguyên |
upstream prematurely closed connection | Backend đóng kết nối đột ngột |
upstream sent invalid header | Backend trả về các header phản hồi không đúng định dạng |
Cấu hình dịch vụ lưu trữ của bạn có thể sử dụng vị trí nhật ký khác.
Đừng thay đổi cài đặt Nginx cho đến khi bạn xác định được nguyên nhân có thể xảy ra.
2. Kiểm tra xem dịch vụ backend có đang chạy không
Lỗi 502 thường xảy ra do ứng dụng chạy phía sau Nginx đã dừng.
Đối với dịch vụ ứng dụng do systemd quản lý, hãy chạy:
sudo systemctl status myappThay myapp bằng tên dịch vụ thực tế của bạn.
Đối với ứng dụng dựa trên PHP sử dụng PHP-FPM, tên dịch vụ có thể có dạng:
sudo systemctl status php8.3-fpmPhiên bản PHP đã cài đặt và tên dịch vụ có thể khác.
Nếu dịch vụ gặp sự cố, hãy kiểm tra nhật ký của dịch vụ:
sudo journalctl -u myapp -n 50Kiểm tra xem có sự cố tiến trình, thiếu thành phần phụ thuộc, lỗi cấu hình hoặc lỗi liên quan đến bộ nhớ hay không.
Chỉ khởi động lại dịch vụ sau khi xác định và xử lý nguyên nhân gốc rễ.
3. Xác minh cổng hoặc socket thượng nguồn
Nginx phải chuyển tiếp yêu cầu đến đúng địa chỉ backend.
Ví dụ, cấu hình proxy ngược có thể chứa:
location / {
proxy_pass http://127.0.0.1:3000;
}Cấu hình này yêu cầu Nginx chuyển tiếp yêu cầu đến một ứng dụng HTTP đang lắng nghe trên cổng 3000.
Kiểm tra xem có tiến trình nào đang lắng nghe trên cổng đó không:
sudo ss -ltnp | grep ':3000'Bạn cũng có thể kiểm tra trực tiếp backend HTTP:
curl -i http://127.0.0.1:3000/Nếu backend không hoạt động, hãy kiểm tra cấu hình dịch vụ của nó trước khi thay đổi Nginx.
Kiểm tra socket PHP-FPM
PHP-FPM thường sử dụng socket Unix hoặc cổng TCP.
Cấu hình Nginx có thể chứa:
fastcgi_pass unix:/run/php/php8.3-fpm.sock;Kiểm tra xem socket đã cấu hình có tồn tại không:
ls -l /run/php/Đường dẫn socket phải khớp với cài đặt listen của pool PHP-FPM, và Nginx phải có quyền kết nối.
Quan trọng: proxy_pass được dùng cho các dịch vụ thượng nguồn HTTP, còn fastcgi_pass được dùng cho các dịch vụ FastCGI như PHP-FPM. Không thể dùng chúng thay thế cho nhau.
4. Kiểm tra bộ nhớ và dung lượng ổ đĩa của máy chủ
Các ứng dụng backend có thể gặp sự cố hoặc ngừng phản hồi khi máy chủ cạn tài nguyên.
Kiểm tra bộ nhớ:
free -hKiểm tra dung lượng ổ đĩa:
df -hKiểm tra các tiến trình đang chạy:
topNếu một ứng dụng bị chấm dứt do thiếu bộ nhớ, bạn có thể tìm thấy thông báo liên quan trong nhật ký hệ thống:
sudo journalctl -k --since "1 hour ago"Tìm các sự kiện hết bộ nhớ hoặc thông báo chấm dứt tiến trình.
Nếu ổ đĩa đã hết dung lượng, hãy xác định dữ liệu nào đang chiếm dung lượng trước khi xóa tệp.
5. Kiểm tra quyền truy cập socket và nhật ký ứng dụng
Đôi khi backend vẫn đang chạy nhưng Nginx không thể giao tiếp với nó.
Đối với socket Unix, hãy kiểm tra chủ sở hữu và quyền truy cập:
ls -l /run/php/Nếu nhật ký báo lỗi quyền truy cập, hãy kiểm tra cả các thư mục trên đường dẫn đến socket.
Quyền truy cập phù hợp phụ thuộc vào người dùng chạy các tiến trình worker của Nginx và cấu hình dịch vụ backend.
Tránh cấp quyền quá rộng, chẳng hạn như chmod 777. Thay vào đó, hãy điều chỉnh cấu hình dịch vụ hoặc pool liên quan để các tiến trình được phép có thể truy cập socket.
Nếu nhật ký lỗi cho thấy dịch vụ thượng nguồn đóng kết nối quá sớm, hãy kiểm tra nhật ký ứng dụng backend để tìm các sự cố, ngoại lệ hoặc yêu cầu thất bại.
6. Kiểm tra cấu hình Nginx
Cài đặt proxy không chính xác hoặc các thay đổi cấu hình cũng có thể làm gián đoạn giao tiếp với dịch vụ thượng nguồn.
Trước khi áp dụng thay đổi, hãy xác thực cấu hình Nginx:
sudo nginx -tNếu kiểm tra thành công, hãy tải lại cấu hình Nginx:
sudo systemctl reload nginxViệc tải lại sẽ áp dụng các thay đổi cấu hình hợp lệ mà không cần khởi động lại dịch vụ.
Nếu kiểm tra không thành công, trước tiên hãy sửa lỗi cấu hình được báo.
Đừng tùy tiện tăng thời gian chờ proxy hoặc giới hạn bộ đệm. Những điều chỉnh này sẽ không khắc phục được tình trạng backend đã dừng, socket không chính xác hoặc kết nối bị từ chối.
7. Xác nhận lỗi 502 đã được khắc phục
Sau khi xử lý nguyên nhân gốc rễ, hãy kiểm tra URL bị ảnh hưởng:
curl -I https://example.comThay example.com bằng tên miền thực tế của bạn.
Một yêu cầu thành công thường trả về mã trạng thái HTTP phù hợp như 200 OK, mặc dù chuyển hướng và các phản hồi hợp lệ khác có thể trả về mã khác.
Đồng thời, hãy mở trang web trong trình duyệt và kiểm tra lại nhật ký lỗi của Nginx.
Nếu lỗi xuất hiện trở lại khi máy chủ chịu tải, hãy giám sát dịch vụ backend và mức sử dụng tài nguyên trong lúc tái hiện sự cố.
Cách ngăn ngừa lỗi 502 trong Nginx
Không phải mọi sự cố backend đều có thể ngăn ngừa, nhưng quản trị máy chủ tốt sẽ giúp giảm các lần gián đoạn dịch vụ có thể tránh được.
- Giám sát tình trạng hoạt động của Nginx và dịch vụ backend.
- Kiểm tra nhật ký ứng dụng sau mỗi lần triển khai.
- Cấu hình chính sách khôi phục dịch vụ phù hợp.
- Giám sát mức sử dụng bộ nhớ, dung lượng lưu trữ và số lượng kết nối.
- Xác thực các thay đổi cấu hình trước khi áp dụng.
- Kiểm tra trực tiếp ứng dụng trước khi định tuyến lưu lượng truy cập qua Nginx.
Nếu ứng dụng cần thêm tài nguyên, hãy đo mức sử dụng thực tế trước khi quyết định nâng cấp năng lực máy chủ.
Câu hỏi thường gặp
Điều đó có nghĩa là Nginx, khi đóng vai trò cổng kết nối hoặc proxy, đã nhận được phản hồi không hợp lệ từ máy chủ thượng nguồn. Nguyên nhân thường là dịch vụ backend đã dừng hoặc có vấn đề với kết nối thượng nguồn.
Không hẳn. Khởi động lại hoặc tải lại cấu hình Nginx sẽ không khắc phục được ứng dụng không hoạt động, cổng backend không chính xác hoặc socket PHP-FPM bị thiếu.
Lỗi 502 cho biết máy chủ thượng nguồn trả về phản hồi không hợp lệ, còn lỗi 504 có nghĩa là cổng kết nối không nhận được phản hồi từ máy chủ thượng nguồn trong thời gian chờ.
Có. Việc cạn bộ nhớ có thể khiến các tiến trình backend gặp sự cố hoặc bị chấm dứt, khiến Nginx không thể giao tiếp với chúng.
Không. Các cổng kết nối, proxy, CDN và bộ cân bằng tải khác cũng có thể trả về lỗi HTTP 502.
Kết luận
Để khắc phục lỗi 502 Bad Gateway trong Nginx, trước tiên bạn cần xác định vì sao ứng dụng thượng nguồn không phản hồi đúng cách.
Trước tiên, hãy kiểm tra nhật ký lỗi của Nginx, xác nhận dịch vụ backend đang chạy và xác minh cổng hoặc socket đã cấu hình. Sau đó, hãy kiểm tra giới hạn tài nguyên, quyền truy cập và các sự cố ứng dụng.
Trong hầu hết trường hợp, xác định chính xác sự cố thượng nguồn sẽ hiệu quả hơn việc liên tục khởi động lại Nginx hoặc thay đổi cài đặt thời gian chờ.
