Điểm:0

Đã khởi động lại máy chủ Ubuntu, trang web nginx không còn truy cập được từ trình duyệt

lá cờ pk

Tôi đã khởi động lại máy chủ Ubuntu của mình sáng nay vì tôi gặp phải lỗi có vẻ như là bộ nhớ thấp (thỉnh thoảng xảy ra, chưa đủ sự cố để thử và khắc phục nó). Nhưng bây giờ, trang web của tôi (trước đây hoạt động tốt) không thể truy cập được từ trình duyệt nữa.

Thiết lập: Tôi đang chạy một trang web NuxtJS bằng cách sử dụng pm2 để tạo nền tảng cho nó và nginx làm proxy ngược. Tôi có một hook git sau nhận để tôi có thể đẩy tới repo git từ xa của mình, sau đó xây dựng lại ứng dụng và khởi động lại phiên bản pm2.

Tôi chỉ có thể truy cập trang web của mình từ bên trong máy chủ, bên trong một cửa sổ đầu cuối. Lynx, wget và cURL đều hoạt động và thậm chí theo chuyển hướng 301 đến HTTPS. Và chúng đang hoạt động khi tôi yêu cầu chính tên miền đó, không chỉ localhost:3000 đang được ủy quyền ngược. Như trong, cuộn tròn https://my-domain.org làm. Nếu tôi cố gắng cuộn tròn/lynx/etc từ bất kỳ cửa sổ đầu cuối nào khác, thì nó chỉ đợi cho đến khi hết thời gian chờ. Tương tự với trình duyệt â đợi cho đến khi hết thời gian chờ.

Đây là những điều tôi đã thử/xem xét:

  • Tôi đang sử dụng UFW, vì vậy tôi đã kiểm tra xem tường lửa có phải là vấn đề không. Nhưng 80, 443 và 8080 đều được đặt thành CHO PHÉP.
  • Tôi đã thử xem có thể nginx không nghe bằng cách nào đó không, vì vậy tôi đã thử sudo lsof -i -P -n | grep NGHE. Đây là đầu ra của điều đó:
nginx 2896 root 6u IPv4 668673557 0t0 TCP *:443 (LẮNG NGHE)
nginx 2896 root 7u IPv4 668673558 0t0 TCP *:80 (LẮNG NGHE)
nginx 2897 www-data 6u IPv4 668673557 0t0 TCP *:443 (LẮNG NGHE)
nginx 2897 dữ liệu www 7u IPv4 668673558 0t0 TCP *:80 (LẮNG NGHE)
nginx 2898 dữ liệu www 6u IPv4 668673557 0t0 TCP *:443 (LẮNG NGHE)
nginx 2898 dữ liệu www 7u IPv4 668673558 0t0 TCP *:80 (LẮNG NGHE)
  • Tôi đã thử kiểm tra access.log của nginx. Tất cả các yêu cầu curl/wget/Lynx của tôi hiển thị như bình thường, nhưng không có yêu cầu trình duyệt nào xuất hiện. Tôi cũng đã xem error.log và nhận được điều này:
31/07/2021 11:51:52 [xuất hiện] 885#885: liên kết () với 0.0.0.0:443 không thành công (98: Địa chỉ đã được sử dụng)
31/07/2021 11:51:52 [xuất hiện] 885#885: liên kết () với 0.0.0.0:80 không thành công (98: Địa chỉ đã được sử dụng)
31/07/2021 11:51:52 [xuất hiện] 885#885: liên kết () với 0.0.0.0:443 không thành công (98: Địa chỉ đã được sử dụng)
31/07/2021 11:51:52 [xuất hiện] 885#885: liên kết () với 0.0.0.0:80 không thành công (98: Địa chỉ đã được sử dụng)
31/07/2021 11:51:52 [xuất hiện] 885#885: vẫn không thể liên kết()

Cho đến nay, tôi đã không tìm thấy bất kỳ giải pháp. Tôi chỉ bối rối, bởi vì bất cứ điều gì đã thay đổi, nó đã thay đổi do khởi động lại. Bất kỳ ý tưởng được nhiều đánh giá cao.

CHỈNH SỬA để thêm một số đầu ra:

trạng thái sudo systemctl nginx:

â nginx.service - Máy chủ web hiệu suất cao và máy chủ proxy ngược
   Đã tải: đã tải (/lib/systemd/system/nginx.service; đã bật; giá trị đặt trước của nhà cung cấp: đã bật)
   Hoạt động: hoạt động (đang chạy) kể từ Thứ Bảy 2021-07-31 15:05:53 EDT; 27 phút trước
  Quá trình: 6834 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (mã=đã thoát, trạng thái
  Quy trình: 6840 ExecStart=/usr/sbin/nginx -g daemon on; master_process bật; (mã=đã thoát, trạng thái=0/THÀNH CÔNG)
  Quá trình: 6837 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process bật; (mã=đã thoát, trạng thái=0/THÀNH CÔNG)
 PID chính: 6841 (nginx)
   Nhóm C: /system.slice/nginx.service
           ââ6841 nginx: quy trình chính /usr/sbin/nginx -g daemon on; master_ process bật
           ââ6842 nginx: worker process                           
           ââ6843 nginx: worker process                           

Ngày 31 tháng 7 15:05:53 vẹt systemd[1]: Đang khởi động Máy chủ web hiệu suất cao và máy chủ proxy ngược...
Ngày 31 tháng 7 15:05:53 con vẹt systemd[1]: Bắt đầu Máy chủ web hiệu suất cao và máy chủ proxy ngược.

đầu ra của Sudo nginx -T là dài, vì vậy tôi đã làm cho nó một ý chính.

lá cờ pk
@MichaelHampton Được rồi â Tôi đã đưa ra ý chính. Liên kết ở trên, nhưng [ở đây là để tham khảo](https://gist.github.com/thely/32ae2f5d6c284277874204500ec54026).
Michael Hampton avatar
lá cờ cz
Hừm, cấu hình nginx có vẻ ổn (ngoại trừ việc bạn đã làm xáo trộn một loạt nội dung không cần thiết và cũng làm xáo trộn tên miền, điều này có thể không hữu ích). Tôi lo ngại rằng các PID từ systemd khi bắt đầu nginx không khớp với các PID bạn thấy từ `ps`. Bạn đã làm điều gì khác giữa những sự kiện này?
lá cờ pk
@MichaelHampton Điều duy nhất tôi đã xóa là ssl_ciphers (vì lý do bảo mật tiềm năng, mặc dù tôi chưa quen với điều này). Hiện tại, main-site.org là trang duy nhất tôi có và chạy trên pm2, vì đó là trang duy nhất trong số bốn trang mà tôi quan tâm, nhưng tôi để phần còn lại ở đó cho đầy đủ. Tôi đã kiểm tra `ps -e` và thấy rằng nginx đang sử dụng 6841, 6842 và 6843, giống như trong trạng thái systemctl.
Michael Hampton avatar
lá cờ cz
Hở? Mật mã ssl của bạn là thông tin công khai; mọi kết nối https đến trang web của bạn đều được gửi cho họ. Dù sao, rõ ràng có điều gì đó không đồng bộ; Tôi chỉ cần khởi động lại nginx một lần nữa.
lá cờ pk
Vâng, xấu của tôi, sau đó. Tôi chỉ xóa chúng khỏi ý chính mà tôi đã tạo, không phải từ các tệp .conf thực tế.
lá cờ pk
Tôi đã thử khởi động lại nginx nhiều lần và bây giờ tôi quyết định thử khởi động lại máy chủ một lần nữa để xem điều đó có khắc phục được không. Vẫn tình trạng như vậy. :/
Michael Hampton avatar
lá cờ cz
Kiểm tra lại nhật ký lỗi nginx để xem có gì khác xuất hiện không.
djdomi avatar
lá cờ za
Còn về killall -9 nginx và khởi động lại ứng dụng từ systemctl thì sao? để thử nghiệm
lá cờ pk
Đó là `ufw` â xem bên dưới. Tôi không biết tại sao lại là `ufw`, nhưng tôi đoán là như vậy.
lá cờ tg
Bạn đã thử tắt `ufw` và xem điều gì đang xảy ra chưa? Bạn có thể truy cập trang web của mình khi tắt tường lửa không?
lá cờ pk
@MasEDI đó thực sự chính xác là những gì tôi đã làm! iptables-persistent đã chặn tất cả các cổng khi khởi động lại và vô hiệu hóa ufw là điều cuối cùng đã đưa tôi đến câu trả lời đúng. Tôi đã để lại một liên kết đến câu trả lời SO cụ thể hơn trong câu trả lời của mình.
Điểm:0
lá cờ pk

Điều này thật ngu ngốc đến nỗi tôi không biết tại sao nó lại là một vấn đề, vì vậy mọi suy nghĩ về điều này đều được đánh giá cao. Của tôi uww cài đặt đã/như sau:

Trạng thái: Đang hoạt động

Đến hành động từ
-- ------ ----
22 CHO PHÉP mọi nơi                  
80/tcp CHO PHÉP mọi nơi                  
443/tcp CHO PHÉP mọi nơi                  
80 CHO PHÉP Mọi nơi                  
8080 CHO PHÉP mọi nơi                  
22 (v6) CHO PHÉP Ở mọi nơi (v6)             
80/tcp (v6) CHO PHÉP mọi nơi (v6)             
443/tcp (v6) CHO PHÉP mọi nơi (v6)             
80 (v6) CHO PHÉP Mọi nơi (v6)             
8080 (v6) CHO PHÉP mọi nơi (v6) 

Một số thứ 80 dư thừa trong đó, nhưng tôi đang thêm những thứ bổ sung để xem nó có giúp được gì không.

Ai đó đã khuyên tôi nên thử tắt ufw, chỉ để đảm bảo rằng đó không phải là vấn đề. Rõ ràng, nó đã được. Tôi đã tắt nó, trang web bắt đầu hoạt động ngay lập tức và khi tôi bật lại nó, mong rằng nó sẽ bị hỏng trở lại, thì nó ... vẫn hoạt động. Vì vậy, một cái gì đó về ufw cần được kích hoạt lại khi tôi khởi động lại máy chủ.

CHỈNH SỬA: Điều này có thể là do iptables-persistent, được cài đặt tự động trên hầu hết các máy chủ, tôi đoán vậy? Hình như là vấn đề tương tự như câu trả lời SO này.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.