NginX 网站使用 HTTP 返回默认页面(HTTPS 正常运行)

NginX 网站使用 HTTP 返回默认页面(HTTPS 正常运行)

是重复的,但我已经搜索了很长时间,并没有发现任何东西。

当我使用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 自动添加

我希望声明如果 ($host = svija.love)将捕获 http 请求并重定向到 HTTPS。

但事实并非如此。

我不是专家,但我认为第二部分,以服务器名称 svija.love,与第一部分直接矛盾:

  • 如果主机是 svija.love,则第一个块会重定向
  • 如果主机是 svija.love,则第二个块返回 404

实际配置的服务器名称是live.svija.love,如果这有区别的话。

如能提供任何澄清,我们将不胜感激。

[更新]我删除了 NginX 默认配置文件,HTTP 现在按预期重定向到 HTTPS。

不过,如果有人可以解释上述两个配置块,我会很高兴更好地理解它们的作用。

[更新]这不是一个好的解决方案(见下文)。

[更新这是给出的配置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;

答案1

Host如果请求中的标头没有匹配的虚拟主机,则 nginx 将提供默认虚拟主机内容。

就您而言,您的虚拟主机Host与匹配svija.love。但是,您似乎正在使用 进行测试live.svija.love

由于 nginx 找不到匹配的虚拟主机,因此它使用默认虚拟主机。

删除默认虚拟主机配置后,nginx 将使用您的虚拟主机作为默认虚拟主机。这不是一个好的做法。任何人都可以为指向您网站的域设置 DNS 记录。最终结果是将http://example.com显示 的内容http://live.svija.love

这可能会导致 Google 因重复内容而受到惩罚。

为了防止这种情况,您应该恢复默认虚拟主机,并调整当前配置以获得正确的配置server_name

答案2

我虽然没有真正理解这个问题,但却解决了它。

我的服务器上有 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 记录,并为网站删除了它。
这对问题没有影响。

然后我想也许$主机变量设置为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 缓存机制出现故障,可能是因为我过去某个时间点更改了服务器的名称。

相关内容