Điểm:1

Trang web NginX trả về trang mặc định với HTTP (HTTPS hoạt động chính xác)

lá cờ br

Cái này để là một bản sao, nhưng tôi đã tìm kiếm trong một thời gian dài và không tìm thấy bất cứ điều gì.

Khi tôi nhập địa chỉ trang web của mình bằng cách sử dụng http, tôi nhận được Trang mặc định của NginX (https hoạt động tốt):

http://svija.love

Tệp cấu hình NginX chứa, ở cuối:

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

    server_name svija.love;
    nghe 80;
    trả lại 404; # được quản lý bởi Certbot
}

Đây là được thêm tự động bởi Certbot.

Tôi mong đợi rằng tuyên bố nếu ($host = svija.love) sẽ bắt yêu cầu http và chuyển hướng đến HTTPS.

Nhưng nó không hoạt động theo cách đó.

Đối với tôi, không phải là chuyên gia, có vẻ như bit thứ hai, bắt đầu bằng server_name svija.love, mâu thuẫn trực tiếp với phần đầu tiên:

  • khối đầu tiên chuyển hướng nếu máy chủ là svija.love
  • khối thứ hai trả về 404 nếu máy chủ là svija.love

Tên máy chủ thực tế, được cấu hình là live.svija.love, nếu điều đó tạo nên sự khác biệt.

Bất kỳ làm rõ sẽ được đánh giá rất cao.

[CẬP NHẬT] Tôi đã xóa tệp cấu hình mặc định NginX và HTTP hiện chuyển hướng đến HTTPS như mong đợi.

Tuy nhiên, nếu ai đó có thể giải thích hai khối cấu hình ở trên, tôi rất muốn hiểu rõ hơn về những gì họ đang làm.

[CẬP NHẬT] Đây không phải là một giải pháp tốt (xem bên dưới).

[CẬP NHẬT Đây là cấu hình được cung cấp bởi nginx -T:

# tập tin cấu hình /etc/nginx/nginx.conf:
dữ liệu www của người dùng;
worker_processes tự động;
pid /run/nginx.pid;
bao gồm /etc/nginx/modules-enabled/*.conf;

sự kiện {
    công_nhân kết_nối 768 ;
    # đa_chấp vào ;
}

http {

    ##
    # Cài đặt cơ bản
    ##

    gửi tệp tắt;
    bật tcp_nopus;
    bật tcp_nodelay;
    keepalive_timeout 65;
    loại_hash_max_size 2048;
    # server_token tắt;

    # server_name_hash_bucket_size 64;
    # máy chủ_tên_trong_chuyển hướng tắt;

    bao gồm /etc/nginx/mime.types;
    ứng dụng default_type/octet-stream;

    ##
    # Cài đặt SSL
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Bỏ SSLv3, tham khảo: POODLE
    bật ssl_prefer_server_ciphers;

    ##
    # Cài đặt ghi nhật ký
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Cài đặt Gzip
    ##

    bật gzip;

    # gzip_vary bật;
    # gzip_proxied bất kỳ;
    # gzip_comp_cấp 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # văn bản gzip_types/văn bản thuần túy/ứng dụng css/ứng dụng json/văn bản javascript/ứng dụng xml/ứng dụng xml/xml+văn bản rss/javascript;

    ##
    # Cấu hình máy chủ ảo
    ##

    bao gồm /etc/nginx/conf.d/*.conf;
    bao gồm /etc/nginx/sites-enabled/*;
}

# tệp cấu hình /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
mô-đun load_module/ngx_http_image_filter_module.so;

# tệp cấu hình /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
mô-đun load_module/ngx_http_xslt_filter_module.so;

# tệp cấu hình /etc/nginx/modules-enabled/50-mod-mail.conf:
mô-đun load_module/ngx_mail_module.so;

# tệp cấu hình /etc/nginx/modules-enabled/50-mod-stream.conf:
mô-đun load_module/ngx_stream_module.so;

# tập tin cấu hình /etc/nginx/mime.types:

người phục vụ {

    # phải khớp với tên miền hoặc địa chỉ IP
    # nếu không thì trang Nginx mặc định sẽ được hiển thị
    server_name antretoise.svija.site;

    # thư mục chứa các phần tử tĩnh của trang web
    vị trí /tĩnh/ {
        gốc/nhà/antretoise;
    }

    access_log /opt/logs/access.antretoise;
    error_log /opt/logs/error.antretoise lỗi;

    # chuyển tất cả các truy vấn bổ sung cho ứng dụng của chúng tôi
    địa điểm / {

        # tham số từ /etc/nginx/uwsgi_params
        bao gồm uwsgi_params;

        # truyền lưu lượng đến ổ cắm
        # mà máy chủ uWSGI thiết lập
        # Ổ CẮM PHẢI GẮN TRONG:
        # /etc/uwsgi/sites/antretoise.ini
        uwsgi_pass unix:/run/uwsgi/antretoise.sock;
    }

    nghe 443 ssl; # được quản lý bởi Certbot
    ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # được quản lý bởi Certbot
    ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/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 = antretoise.svija.site) {
        trả lại 301 https://$host$request_uri;
    } # được quản lý bởi Certbot


    nghe 80;
    server_name antretoise.svija.site;
    trả lại 404; # được quản lý bởi Certbot


}
# tập tin cấu hình /etc/nginx/uwsgi_params:

uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;

uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REQUEST_SCHEME $scheme;
uwsgi_param HTTPS $https if_not_empty;

uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;

ssl_session_cache được chia sẻ:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
tắt ssl_session_tickets;

ssl_protocols TLSv1.2 TLSv1.3;
tắt ssl_prefer_server_ciphers;

ssl_ciphers "EC-AES128-SHA";

#âââââââââââââââââ ââââââââââââââââ âââââââ mặc định

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

    gốc/var/www/html;

    # 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;

    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;
    }

}

#âââââââââââââââââ ââââââââââââââââ âââââââ svija.love

người phục vụ {

    server_name svija.love;

    # thư mục chứa các phần tử tĩnh của trang web
    vị trí /tĩnh/ {
        gốc/nhà/svijalove;
    }

    access_log /opt/logs/access.svijalove;
    error_log /opt/logs/error.svijalove lỗi;

    # chuyển tất cả các truy vấn bổ sung cho ứng dụng của chúng tôi
    địa điểm / {

        # tham số từ /etc/nginx/uwsgi_params
        bao gồm uwsgi_params;

        # truyền lưu lượng đến ổ cắm
        # mà máy chủ uWSGI thiết lập
        # Ổ CẮM PHẢI GẮN TRONG:
        # /etc/uwsgi/sites/svijalove.ini
        uwsgi_pass unix:/run/uwsgi/svijalove.sock;
    }

    nghe 443 ssl; # được quản lý bởi Certbot
    ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # được quản lý bởi Certbot
    ssl_certificate_key /etc/letsencrypt/live/svija.love/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ụ {
    nếu ($host = svija.love) {
        trả lại 301 https://$host$request_uri;
    } # được quản lý bởi Certbot

    server_name svija.love;
    nghe 80;
    trả lại 404; # được quản lý bởi Certbot
}

# 6 trang web khác ở cuối, tất cả đều được định cấu hình theo cùng một cách
# ngoại trừ trong hai dòng cuối cùng,
#nghe80; đôi khi được liệt kê TRƯỚC return 404;
lá cờ in
FYI: Khi tôi truy vấn `http://svija.love`, tôi nhận được chuyển hướng đến `https://svija.love/`, kết quả là 500. Sau đó, wget thử lại yêu cầu thứ hai và nhận được 200. Tôi không nhận được 404. Đối với 500, bạn cần kiểm tra nhật ký máy chủ của mình.
lá cờ br
Bạn đã thực hiện truy vấn như thế nào? Tôi nhận ra rằng mình đã nói sai vấn đề — tôi nhận được không phải lỗi 404 (trong trình duyệt của mình) mà là trang mặc định của NginX (tôi đã sửa câu hỏi). Tôi không thấy lỗi 500, nhưng tôi sẽ kiểm tra nhật ký.
lá cờ in
Chỉ cần một `wget -S http://svija.love` đơn giản
lá cờ br
Tôi đã xóa cấu hình mặc định của NginX và bây giờ nó chuyển hướng chính xác. Tôi cho rằng đó là do nó đang diễn giải cấu hình mặc định trước khi đến cấu hình svija.love.
lá cờ us
Vui lòng thêm cấu hình nginx đầy đủ được cung cấp bởi lệnh `nginx -T`.
lá cờ us
Dự đoán duy nhất của tôi là khối `if` trước` server_name` bằng cách nào đó làm xáo trộn nginx. Thông thường, tôi bắt đầu khối `server` với `listen`, `server_name` ở trên cùng để dễ đọc và sau đó là các lệnh khác.
lá cờ us
Một tùy chọn khác để gỡ lỗi này là kích hoạt nhật ký gỡ lỗi nginx bằng cách sử dụng `error_log /opt/logs/error.antretoise debug;` Tùy thuộc vào bản phân phối, có thể cần khởi động nginx bằng một lệnh khác. Với nhật ký gỡ lỗi, người ta có thể thấy nginx xử lý yêu cầu nội bộ chính xác như thế nào.
lá cờ br
Tôi đã dành vài giờ để xem nhật ký và thử nhiều sửa đổi khác nhau của tệp cấu hình nhưng không thành công. Cuối cùng, nó bắt đầu hoạt động với cấu hình ban đầu (xem câu trả lời tôi đã đăng) — có thể là một số vấn đề về bộ nhớ đệm DNS. Cảm ơn những gợi ý của bạn, chúng đã cho tôi can đảm để tiếp tục cố gắng và những ý tưởng để thử.
Điểm:2
lá cờ us

Nếu không có máy chủ ảo phù hợp cho Chủ nhà tiêu đề trong yêu cầu, thì nginx sẽ phục vụ nội dung máy chủ ảo mặc định.

Trong trường hợp của bạn, máy chủ ảo của bạn phù hợp với Chủ nhà lĩnh vực với svija.love. Tuy nhiên, có vẻ như bạn đang thử nghiệm với live.svija.love.

Vì nginx không thể tìm thấy máy chủ ảo phù hợp nên nó sử dụng máy chủ mặc định của nó.

Sau khi bạn xóa cấu hình máy chủ ảo mặc định, nginx sẽ sử dụng máy chủ ảo của bạn làm máy chủ ảo mặc định. Đó không phải là một thực hành tốt. Bất kỳ ai cũng có thể thiết lập bản ghi DNS cho tên miền trỏ đến trang web của bạn. kết quả cuối cùng sẽ là http://example.com sẽ hiển thị nội dung của http://live.svija.love.

Điều đó có thể dẫn đến các hình phạt của Google đối với nội dung trùng lặp.

Để ngăn chặn điều này, bạn nên khôi phục máy chủ ảo mặc định và điều chỉnh cấu hình hiện tại của mình cho chính xác. tên máy chủ.

lá cờ br
Tôi không thử nghiệm với live.svija.love â đó là tên của máy chủ (/etc/hosts), nhưng tôi chưa bao giờ thử truy cập máy chủ tại địa chỉ đó. Tôi sẽ đặt lại cài đặt mặc định như bạn đề xuất và xem liệu tôi có thể làm cho nó hoạt động dựa trên câu trả lời của bạn hay không.
lá cờ br
Bây giờ khi tôi truy cập svija.love, tôi lại nhận được trang mặc định của NginX. Điều tôi không hiểu là tại sao svija.love không khớp với "if ($host = svija.love) {" trong cấu hình.
lá cờ br
Tôi đã thêm cấu hình nginx đầy đủ vào câu hỏi.
Điểm:0
lá cờ br

Tôi đã giải quyết vấn đề mà không thực sự hiểu nó.

Có bảy trang web trên máy chủ của tôi và sáu trang web hoạt động chính xác (http chuyển hướng đến https như mong đợi.)

Tất cả bảy trang web đều chứa một khối ở cuối tệp cấu hình NginX của chúng giống như sau:

người phục vụ {

# chuyển hướng lưu lượng truy cập từ http sang https cho từng miền có liên quan

    nếu ($host = svija.love) {
        trả lại 301 https://$host$request_uri;
    } # được quản lý bởi Certbot

# đảm bảo rằng mọi yêu cầu đã bắt được không bị chuyển hướng vô tình

    nghe 80;
    server_name svija.love;
    trả lại 404; # được quản lý bởi Certbot
}

Máy chủ lưu trữ thực tế là live.svija.love, nhưng trang web có vấn đề chỉ đơn giản là svija.love (không có trang web nào được định cấu hình cho live.svija.love).

Rõ ràng là sự cố xảy ra do dòng sau không được đánh giá chính xác:

nếu ($host = svija.love) {

Ngoài ra, không có cấu hình IPv6 cho máy chủ (live.svija.love) và có cấu hình IPv6 cho trang web (svija.love), cấu hình này lẽ ra không tồn tại.

Tôi đã thêm bản ghi IPv6 cho máy chủ và xóa nó cho trang web.
Điều này không ảnh hưởng đến vấn đề.

Sau đó, tôi nghĩ rằng có lẽ máy chủ $ biến đã được đặt thành live.svija.love (ai biết tại sao), vì vậy tôi đã thử kiểm tra nơi tôi đã thay đổi

nếu ($host = svija.love) {

đến

nếu ($host = live.svija.love) {

Đúng như dự đoán, trang mặc định NginX đã được thay thế bằng lỗi 404 (xem khối cấu hình ở trên).

Vì vậy, tôi đặt lại

nếu ($host = live.svija.love) {

và mọi thứ bây giờ hoạt động chính xác. Yêu cầu HTTP đến svija.love được chuyển hướng đến https://svija.love và vấn đề của tôi đã được giải quyết.

Tôi cho rằng có một số loại cơ chế lưu trữ DNS trong NginX đã bị lỗi, có thể là do tôi đã thay đổi tên của máy chủ vào một thời điểm nào đó trong quá khứ.

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