Vấn đềBạn kiểm tra log lỗi của Nginx tại /var/log/nginx/error.log và thấy một dòng lặp lại như thế này:
connect() failed (111: Connection refused) while connecting to upstream, client: 1.2.3.4, server: example.com, upstream: "http://127.0.0.1:3000/"
Nói một cách đơn giản, Nginx đang gõ cửa nhưng không có ai ở nhà. Đây không giống như lỗi 504 Gateway Timeout khi backend chỉ đơn giản là phản hồi chậm. Lỗi 111 là sự từ chối ngay lập tức. Có thể là không có gì đang lắng nghe trên cổng đó, hoặc hệ điều hành đang chủ động đóng cửa.
Các nguyên nhân phổ biến- Dịch vụ bị treo: Tiến trình Node.js, PM2 hoặc Gunicorn của bạn đã dừng đột ngột hoặc chưa từng khởi chạy.- Nhầm lẫn cổng: Ứng dụng đang chạy trên cổng 8080, nhưng Nginx lại tìm nó ở cổng 3000.- Bẫy Localhost: Nginx cố gắng kết nối qua localhost (IPv6 ::1), nhưng ứng dụng của bạn chỉ lắng nghe trên 127.0.0.1 (IPv4).- Rào cản bảo mật: SELinux hoặc tường lửa đang chặn giao tiếp nội bộ giữa Nginx và ứng dụng của bạn.## Hướng dẫn khắc phục từng bước### 1. Backend thực sự đang hoạt động chứ?Trước khi chạm vào bất kỳ tệp cấu hình nào, hãy xem tiến trình ứng dụng của bạn có đang hoạt động hay không. Nếu nó bị treo, Nginx sẽ không có gì để giao tiếp.
# Kiểm tra trạng thái systemd cho ứng dụng
sudo systemctl status my-backend-app
# Sử dụng PM2?
pm2 status
# Cách truyền thống
ps aux | grep node
Nếu trạng thái hiển thị inactive hoặc failed, hãy khởi động lại nó. Kiểm tra log ứng dụng ngay lập tức để xem lỗi cú pháp hoặc thiếu biến môi trường có phải là nguyên nhân gây treo hay không.
2. Xác minh cổng đang lắng ngheĐôi khi một dịch vụ đang "hoạt động" nhưng thực tế lại không được gán vào cổng mà bạn mong đợi. Sử dụng lệnh ss để xem chính xác điều gì đang xảy ra trên ngăn xếp mạng của bạn.
sudo ss -tlpn | grep :3000
Bạn sẽ muốn thấy một dòng như thế này:
LISTEN 0 128 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1234,fd=19))
Không có kết quả? Ứng dụng của bạn không lắng nghe trên cổng 3000. Hãy tìm cài đặt PORT=3000 trong tệp .env hoặc được mã hóa cứng trong thiết lập máy chủ của bạn.
3. Kiểm tra cấu hình NginxMở cấu hình trang web của bạn, thường nằm trong /etc/nginx/sites-available/. Hãy xem kỹ dòng proxy_pass.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
}
Tránh sử dụng "localhost". Trên các hệ thống Linux hiện đại, localhost thường phân giải thành địa chỉ IPv6 ::1. Nếu backend của bạn chỉ gắn với IPv4 (127.0.0.1), Nginx sẽ không thể kết nối. Sử dụng địa chỉ IP rõ ràng 127.0.0.1 là lựa chọn an toàn hơn để tránh sự mơ hồ về DNS này.
Kiểm tra và áp dụng các thay đổi của bạn:
sudo nginx -t
sudo systemctl reload nginx
4. Chế ngự SELinux (RHEL/CentOS/AlmaLinux)Trên các hệ thống dựa trên Red Hat, SELinux thường là bức tường vô hình. Theo mặc định, nó ngăn Nginx thực hiện các kết nối mạng ra bên ngoài.
Kiểm tra cài đặt hiện tại:
getsebool httpd_can_network_connect
Nếu nó trả về off, đó chính là vấn đề của bạn. Hãy bật nó vĩnh viễn bằng lệnh này:
sudo setsebool -P httpd_can_network_connect 1
Xác minh cuối cùngĐảm bảo Nginx và backend của bạn đang nói cùng một ngôn ngữ. Chạy một bài kiểm tra nhanh từ dòng lệnh của máy chủ.
# Máy chủ có thể giao tiếp với backend không?
curl -I http://127.0.0.1:3000
# Nginx có thể tiếp cận backend không?
curl -I http://localhost
Nếu lệnh đầu tiên trả về 200 OK nhưng lệnh thứ hai thất bại, logic proxy_pass của Nginx vẫn còn sai. Nếu cả hai đều hoạt động, bạn đã giải quyết được vấn đề.