Điểm:0

1 Gateway 2 Máy 2 Domain 3 Subdomain, Cách

lá cờ ug

Tôi có một cấu hình hoạt động trong nginx chỉ cho một trong các trang web của mình, nhưng tôi đã làm hỏng nó khi cố gắng làm cho nó hoạt động với 2 miền khác nhau, một trong số đó có 2 miền phụ, tất cả đều phục vụ các trang web hoặc ứng dụng khác nhau. Để làm cho vấn đề trở nên khó khăn hơn đối với tôi, miền đang chạy 2 ứng dụng nằm trên một máy riêng biệt và tôi đang cố gắng ủy quyền các yêu cầu cho miền đó đến đúng máy trong mạng LAN của mình. Xem bên dưới:

kiến trúc của tôi

Cấu hình NGINX của tôi là một thảm họa, nhưng như sau:

người phục vụ {
    nghe 80 default_server;
    lắng nghe [::]:80 default_server;

    gốc /home/pi/sites/main;

    # Thêm index.php vào danh sách nếu bạn đang sử dụng PHP
    chỉ mục index.html index.htm index.nginx-debian.html domain1_index.html;

    tên máy chủ _;

    địa điểm / {
        # Lần đầu tiên cố gắng phục vụ yêu cầu dưới dạng tệp, sau đó
        # làm thư mục, sau đó quay lại hiển thị lỗi 404.
        try_files $uri $uri/ =404;
    }
}

người phục vụ {

    gốc /home/pi/sites/main;

    chỉ mục index.html index.htm index.nginx-debian.html;
    server_name internal.domain1.info; # được quản lý bởi Certbot


    địa điểm / {
        # Lần đầu tiên cố gắng phục vụ yêu cầu dưới dạng tệp, sau đó
        # làm thư mục, sau đó quay lại hiển thị lỗi 404.
        try_files $uri $uri/ =404;
    }


    lắng nghe [::]:443 ssl ipv6only=on; # được quản lý bởi Certbot
    nghe 443 ssl; # được quản lý bởi Certbot
    ssl_certificate /etc/letsencrypt/live/internal.domain1.info/fullchain.pem; # được quản lý bởi Certbot
    ssl_certificate_key /etc/letsencrypt/live/internal.domain1.info/privkey.pem; # được quản lý bởi Certbot
    bao gồm /etc/letsencrypt/options-ssl-nginx.conf; # được quản lý bởi Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # được quản lý bởi Certbot



}
người phục vụ {
    if ($host = internal.domain1.info) {
        trả lại 301 https://$host$request_uri;
    } # được quản lý bởi Certbot


    nghe 80 ;
    nghe [::]:80 ;
    server_name internal.domain1.info;
    trả lại 404; # được quản lý bởi Certbot


}

người phục vụ {
  server_name shiba.com www.shiba.com thì thầm.shiba.com;
  địa điểm / {
    proxy_pass http://<machine2'sIP>:8888;
  }
}

người phục vụ {
  server_name yelling.shiba.com;
  địa điểm / {
    proxy_pass http://<machine2'sIP>:8555;
  }
}

Làm cách nào tôi có thể làm điều này để phục vụ các trang web như được chỉ định trong ảnh của tôi? Cảm ơn.

Chỉnh sửa: Cấu hình mới được đề xuất của tôi

|trang web có sẵn | liên kết tượng trưng --> | kích hoạt trang web
   conf1 | | conf1
trang web #https
người phục vụ {
    gốc /home/pi/sites/main;

    chỉ mục index.html index.htm index.nginx-debian.html;
    
    địa điểm / {
        # Lần đầu tiên cố gắng phục vụ yêu cầu dưới dạng tệp, sau đó
        # làm thư mục, sau đó quay lại hiển thị lỗi 404.
        try_files $uri $uri/ =404;
    }

    lắng nghe [::]:443 ssl ipv6only=on; # được quản lý bởi Certbot
    nghe 443 ssl; # được quản lý bởi Certbot
    ssl_certificate /etc/letsencrypt/live/internal.domain1.info/fullchain.pem; # được quản lý bởi Certbot
    ssl_certificate_key /etc/letsencrypt/live/internal.domain1.info/privkey.pem; # được quản lý bởi Certbot
    bao gồm /etc/letsencrypt/options-ssl-nginx.conf; # được quản lý bởi Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # được quản lý bởi Certbot
}
chuyển hướng trang web #http
người phục vụ {
    if ($host = internal.domain1.info) {
        trả lại 301 https://$host$request_uri;
    } # được quản lý bởi Certbot

    nghe 80 ;
    nghe [::]:80 ;
    server_name internal.domain1.info;
    trả lại 404; # được quản lý bởi Certbot
}
|trang web có sẵn | liên kết tượng trưng --> | kích hoạt trang web
   conf2 | | conf2
người phục vụ {
    nghe 80 ;
    nghe [::]:80 ;
    server_name thì thầm.shiba.info;

    trả lại 301 http://xxx.xxx.x.xx:8555;
}
|trang web có sẵn | liên kết tượng trưng --> | kích hoạt trang web
   conf3 | | conf3
người phục vụ {
    nghe 80 ;
    nghe [::]:80 ;
    server_name yelling.shiba.info;

    trả về 301 http://xxx.xxx.x.xx:8888;
}
drookie avatar
lá cờ za
Bạn đang sử dụng bộ nhận dạng mặc định `server{}` cùng với `server {}` không có `listen`. Đó có lẽ là lý do tại sao không có gì hoạt động bình thường. Và vâng, một phần nguyên nhân là do cấu hình của bạn lộn xộn. Có vẻ như bạn ghét UNIX và nginx nói riêng. Mọi thứ trông thật tạm bợ và tiêu điều.
WhisperingShiba avatar
lá cờ ug
@droookie Đó là bản demoish, đây là cấu hình đầu tiên của tôi trong dự án đầu tiên của tôi. Tôi muốn hack cấu hình hiện có của mình, nhưng rõ ràng tôi không biết đủ. Bạn có gợi ý rằng tôi nên tạo các cấu hình riêng biệt trong các trang có sẵn và liên kết tượng trưng đến các trang được bật hay tôi nên có một cấu hình với 3 máy chủ cho toàn bộ kiến ​​trúc của mình hoặc 1 cấu hình, 1 máy chủ và 3 vị trí? Tôi đang gặp khó khăn khi tìm kiếm phương pháp ưa thích để thiết lập một hệ thống như thế này.
Nikita Kipriyanov avatar
lá cờ za
Mỗi máy chủ (vitualhost) nên được đưa vào tệp cấu hình của riêng nó. Không bao giờ phục vụ các trang đích với máy chủ mặc định; nó chỉ nên được sử dụng như một trình giữ chỗ để phát hiện cấu hình sai. Sẽ không quan trọng nếu bạn đặt các tệp vào các trang có sẵn và sau đó liên kết tượng trưng với chúng, nhưng đây là phương pháp được ưa thích hơn vì nó làm cho việc xóa cấu hình ngẫu nhiên ít có thể xảy ra hơn.
WhisperingShiba avatar
lá cờ ug
@NikitaKipriyanov Tôi đã chỉnh sửa câu hỏi của mình bằng các cấu hình được đề xuất. Trực giác của tôi là điều này sẽ không hoạt động vì tôi đang nghe trên cổng 80 3 lần và do đó nginx thậm chí sẽ không khởi động. Ngoài ra, tôi không chắc liệu việc xác nhận tên máy chủ có chuyển hướng yêu cầu yelling.shiba.info tới xxx.xxx.x.xx:8555 hay không. Tôi có cần thực hiện if ($host == yelling.shiba.info> { return 301 http://xxx.xxx.x.xx:PORT } như tôi trình bày trong ví dụ của mình không? Cảm ơn.

Đă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.