站点在Firefox中解析为www,而在Chrome中则不解析

时间:2020-06-26 作者:Gee_k

我猜这是由我的nginx配置引起的,但是我不太清楚如何进行故障排除以解决问题。

我正在使用带有LEMP堆栈的Ubuntu 20.04来托管wordpress安装。除了这个怪癖之外,一切都很好。这个怪癖是,如果我在Chrome中键入网站的URL,网站将解析为\'https://example.com“网站上的一切都很好。

然而,在Firefox中,如果我键入网站的URL,它将解析为\'https://www.example.com,这将是好的,除了网站上的某些图标现在将不会加载,不会显示,并由一个方形框代替。

下面是我正在使用的nginx配置:

server {
listen       80;

server_name  www.{{ domain_name }}{{ tld }} {{ domain_name }}{{ tld }};
return 301 https://$server_name$request_uri;



}

server {
listen 443 ssl;
server_name  www.{{ domain_name }}{{ tld }};
ssl_certificate /etc/letsencrypt/certs/fullchain_{{ domain_name }};
ssl_certificate_key /etc/letsencrypt/keys/{{ domain_name }}.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM;
#    ssl_ecdh_curve secp521r1;
root   /home/{{ domain_name }}/public_html;
index index.php index.html index.htm;

location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
}
#    return 301 https://www.$server_name$request_uri;

location ~ \\.php$ {
        # Basic
        try_files $uri =404;
        fastcgi_index index.php;

        # Create a no cache flag
        set $no_cache "";

        # Don\'t ever cache POSTs
        if ($request_method = POST) {
          set $no_cache 1;
        }

        # Admin stuff should not be cached
        if ($request_uri ~* "/(wp-admin/|wp-login.php)") {
          set $no_cache 1;
        }

        # WooCommerce stuff should not be cached
        if ($request_uri ~* "/store.*|/cart.*|/my-account.*|/checkout.*|/addons.*") {
          set $no_cache 1;
        }

        # If we are the admin, make sure nothing
        # gets cached, so no weird stuff will happen
        if ($http_cookie ~* "wordpress_logged_in_") {
          set $no_cache 1;
        }

        # Cache and cache bypass handling
        fastcgi_no_cache $no_cache;
        fastcgi_cache_bypass $no_cache;
        fastcgi_cache microcache;
        fastcgi_cache_key $scheme$request_method$server_name$request_uri$args;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_valid 404 10m;
        fastcgi_cache_use_stale updating;


        # General FastCGI handling
        fastcgi_pass unix:/var/run/php/{{ domain_name }}.sock;
        fastcgi_pass_header Set-Cookie;
        fastcgi_pass_header Cookie;
        fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
        fastcgi_split_path_info ^(.+\\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        fastcgi_intercept_errors on;
        include fastcgi_params;
}

location ~* \\.(js|css|png|jpg|jpeg|gif|ico|woff|ttf|svg|otf)$ {
        expires 30d;
        add_header Pragma public;
        add_header Cache-Control "public";
        access_log off;
}

}

2 个回复
SO网友:mozboz

每次我看到您描述的内容都是由于浏览器缓存了重定向。

我看不出在这种情况下,不同的浏览器有什么不同的行为。您可能想尝试一种以前从未使用过的浏览器/机器来访问此网站,因为这将明确地告诉您发生了什么。

您还可以在这里用域和wget/curl之类的工具进行回复,这样就可以很容易地看到发生了什么重定向。

SO网友:Ivan Shatsky

您在问题中显示的内容看起来像一些nginx模板,而不是真正的nginx配置。不管怎样,假设您的域是example.com.

server {
    listen       80;
    server_name  www.example.com example.com;
    return       301 https://$server_name$request_uri;
}
此块将重定向普通HTTP请求(http://example.com/..., http://www.example.com/...) 到https://www.example.com/..., 这个$server_name 内部nginx变量的值为中给定的第一个字符串server_name 指令参数,www.example.com 在这种情况下。此外,如果它是在端口80上侦听的唯一定义的服务器块,它将处理此端口上的任何传入请求并将其重定向到https://www.example.com/... 无论有什么价值Host 此请求的HTTP标头(如果存在)。

server {
    listen       443 ssl;
    server_name  www.example.com;
    ...
}
此块将处理传入的请求www.example.com 端口443上的域,即。https://www.example.com/... 请求,但与前一个块一样,如果它是侦听端口443的唯一已定义的服务器块,则它将处理任何传入的SSL请求,无论值是什么,都具有Host 请求的HTTP标头。如果您为这两个项目颁发了证书example.comwww.example.com 域,它将处理任何https://example.com/... 没有任何错误的请求,如Certificate mismatch 或类似的。

总而言之,看起来你进入了http://example.com 在Firefox中(并获得301https://www.example.com 重定向)和https://example.com 在Chrome中(并获得了无任何重定向的响应内容)。无论如何,这并不能解释您在Firefox中出错的原因,但描述了使用此配置的nginx行为。进来http://example.com 在Chrome地址栏中,您将被重定向到https://www.example.com. 进来https://example.com 在Firefox地址栏中,您将收到没有任何重定向的网站内容。在incognito窗口中执行此操作,以避免可能的缓存重定向或内容。

相关推荐

Nginx.conf出现在文件夹上的所有WordPress安装中

我在自己的云服务器上运行了几个WordPress站点。所有这些站点都在相同的Apache安装上运行。最近,我发现在我所有的WordPress webroot文件夹中,一个名为nginx.conf 已出现。我应该担心(安全漏洞)吗?我不认为WordPress创造了nginx.conf 更新或安装时webroot上的文件。但我在谷歌上找不到任何关于这方面的信息。