Nginx

NginX 網站返回帶有 HTTP 的預設頁面（HTTPS 正常工作）

  • February 23, 2022

這必須是重複的，但是我已經搜尋了很長時間，但沒有找到任何東西。

當我使用http輸入我的網站地址時，我得到NginX 預設頁面（https 可以正常工作）：

http://svija.love

NginX 配置文件最後包含：

server {
   if ($host = svija.love) {
       return 301 https://$host$request_uri;
   } # managed by Certbot

   server_name svija.love;
   listen 80;
   return 404; # managed by Certbot
}

這是由 Certbot 自動添加的。

我希望語句**if ($host = svija.love)**會擷取 http 請求並重定向到 HTTPS。

但它不是那樣工作的。

不是專家，在我看來，從server_name svija.love開始的第二部分與第一部分直接矛盾：

  • 如果主機是 svija.love，則第一個塊重定向
  • 如果主機是 svija.love，則第二個塊返回 404

實際配置的伺服器名稱是live.svija.love，如果有區別的話。

任何澄清將不勝感激。

**$$ UPDATE $$**我刪除了 NginX 預設配置文件，HTTP 現在按預期重定向到 HTTPS。

不過，如果有人能解釋上面的兩個配置塊，我很想更好地理解他們在做什麼。

**$$ UPDATE $$**這不是一個好的解決方案（見下文）。

[更新這是nginx -T給出的配置：

# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
   worker_connections 768;
   # multi_accept on;
}

http {

   ##
   # Basic Settings
   ##

   sendfile off;
   tcp_nopush on;
   tcp_nodelay on;
   keepalive_timeout 65;
   types_hash_max_size 2048;
   # server_tokens off;

   # server_names_hash_bucket_size 64;
   # server_name_in_redirect off;

   include /etc/nginx/mime.types;
   default_type application/octet-stream;

   ##
   # SSL Settings
   ##

   ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
   ssl_prefer_server_ciphers on;

   ##
   # Logging Settings
   ##

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

   ##
   # Gzip Settings
   ##

   gzip on;

   # gzip_vary on;
   # gzip_proxied any;
   # gzip_comp_level 6;
   # gzip_buffers 16 8k;
   # gzip_http_version 1.1;
   # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

   ##
   # Virtual Host Configs
   ##

   include /etc/nginx/conf.d/*.conf;
   include /etc/nginx/sites-enabled/*;
}

# configuration file /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
load_module modules/ngx_http_image_filter_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
load_module modules/ngx_http_xslt_filter_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-mail.conf:
load_module modules/ngx_mail_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-stream.conf:
load_module modules/ngx_stream_module.so;

# configuration file /etc/nginx/mime.types:

server {

   # must match domain name or IP address
   # or else the default Nginx page will be shown
   server_name antretoise.svija.site;

   # directory of site's static elements
   location /static/ {
       root /home/antretoise;
   }

   access_log /opt/logs/access.antretoise;
   error_log /opt/logs/error.antretoise error;

   # pass all additional queries to our application
   location / {

       # parameters from /etc/nginx/uwsgi_params
       include uwsgi_params;

       # pass the traffic to the socket
       # that the uWSGI server sets up
       # SOCKETS MUST MATCH IN:
       # /etc/uwsgi/sites/antretoise.ini
       uwsgi_pass unix:/run/uwsgi/antretoise.sock;
   }

   listen 443 ssl; # managed by Certbot
   ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # managed by Certbot
   ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/privkey.pem; # managed by Certbot
   include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}


server {
   if ($host = antretoise.svija.site) {
       return 301 https://$host$request_uri;
   } # managed by Certbot


   listen 80;
   server_name antretoise.svija.site;
   return 404; # managed by Certbot


}
# configuration file /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 shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_ciphers "EC-AES128-SHA";

#———————————————————————————————————————— default

server {
   listen 80 default_server;
   listen [::]:80 default_server;

   root /var/www/html;

   # Add index.php to the list if you are using PHP
   index index.html index.htm index.nginx-debian.html;

   server_name _;

   location / {
       # First attempt to serve request as file, then
       # as directory, then fall back to displaying a 404.
       try_files $uri $uri/ =404;
   }

}

#———————————————————————————————————————— svija.love

server {

   server_name svija.love;

   # directory of site's static elements
   location /static/ {
       root /home/svijalove;
   }

   access_log /opt/logs/access.svijalove;
   error_log /opt/logs/error.svijalove error;

   # pass all additional queries to our application
   location / {

       # parameters from /etc/nginx/uwsgi_params
       include uwsgi_params;

       # pass the traffic to the socket
       # that the uWSGI server sets up
       # SOCKETS MUST MATCH IN:
       # /etc/uwsgi/sites/svijalove.ini
       uwsgi_pass unix:/run/uwsgi/svijalove.sock;
   }

   listen 443 ssl; # managed by Certbot
   ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # managed by Certbot
   ssl_certificate_key /etc/letsencrypt/live/svija.love/privkey.pem; # managed by Certbot
   include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
   if ($host = svija.love) {
       return 301 https://$host$request_uri;
   } # managed by Certbot

   server_name svija.love;
   listen 80;
   return 404; # managed by Certbot
}

# 6 other sites at end, all configured the same way
# except that in the last two lines,
# listen 80; is sometimes listed BEFORE return 404;

我在沒有真正理解的情況下解決了這個問題。

我的伺服器上有 7 個網站，其中 6 個網站正常執行（http 按預期重定向到 https。）

所有七個站點都在其 NginX 配置文件的末尾包含一個類似於以下內容的塊：

server {

# redirects traffic from http to https for each relevant domain

   if ($host = svija.love) {
       return 301 https://$host$request_uri;
   } # managed by Certbot

# ensures that any caught requests are not inadvertently redirected

   listen 80;
   server_name svija.love;
   return 404; # managed by Certbot
}

實際的伺服器主機是live.svija.love，但有問題的網站只是svija.love（沒有為 live.svija.love 配置網站）。

很明顯，該問題是由未正確評估以下行引起的：

if ($host = svija.love) {

順便說一句，伺服器 (live.svija.love) 沒有 IPv6 配置，網站 (svija.love) 有 IPv6 配置，這不應該存在。

我為伺服器添加了 IPv6 記錄，並為網站刪除了它。

這並沒有影響問題。

然後我想也許**$host變數設置為live.svija.love**（誰知道為什麼），所以我嘗試了一個我改變的測試

if ($host = svija.love) {

到

if ($host = live.svija.love) {

正如預期的那樣，NginX 預設頁面被 404 錯誤替換（參見上面的配置塊）。

所以，我放回去

if ($host = live.svija.love) {

現在一切正常。對 svija.love 的 HTTP 請求被重定向到https://svija.love，我的問題就解決了。

我假設 NginX 中有某種 DNS 記憶體機制失敗了，可能是因為我在過去的某個時候更改了伺服器的名稱。

如果請求中的標頭沒有匹配的虛擬主機Host，則 nginx 將提供預設的虛擬主機內容。

在您的情況下，您的虛擬主機將Host欄位與svija.love. 但是，您似乎正在使用live.svija.love.

由於 nginx 找不到匹配的虛擬主機，它使用它的預設主機。

刪除預設虛擬主機配置後，nginx 使用您的虛擬主機作為預設虛擬主機。這不是一個好習慣。任何人都可以為指向您網站的域設置 DNS 記錄。最終結果將http://example.com顯示http://live.svija.love.

這可能會導致Google對重複內容進行處罰。

為防止這種情況，您應該恢復預設虛擬主機，並調整您目前的配置以確保server_name.

引用自：https://serverfault.com/questions/1092523

相關問答

Nginx

DDNS 證書、多域、讓我們加密、Certbot、Nginx、Ubuntu

  • March 9, 2021
檢視問答
Nginx

無法使用 LetsEncrypt - CertBot - 設置 HTTP 到 HTTPS 重定向時

  • May 22, 2020
檢視問答
Nginx

在 Ubuntu 伺服器上使用 Nginx 配置 SSL

  • October 30, 2022
檢視問答
Ubuntu

安裝 certbot ubuntu 21.10 未滿足的依賴項

  • October 17, 2022
檢視問答
Nginx

www 證書未正確提取 - nginx 和 certbot

  • June 11, 2022
檢視問答
Https

Certbot 更新試執行失敗並出現錯誤：輸入 sub.mydomain.com: 的 webroot。跳過

  • April 21, 2022
檢視問答