ubuntu – NginX WordPress SSL非www W3TC vhost配置文件问题

前端之家收集整理的这篇文章主要介绍了ubuntu – NginX WordPress SSL非www W3TC vhost配置文件问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个关于我的服务器块的问题,这个问题仅适用于运行https的wordpress网站,具有Nginx和W3TC浏览器缓存.

环境:

Ubuntu – 14.04LTS

Nginx – 1.4.6

PHP – 5.5.9

MysqL – Ver 14.14 Distrib 5.5.41

我的问题如下:

>“位置”部分的顺序是否重要?
> W3TC块的顺序是否重要?
>我已经看到一些“ssl”放在listen指令中而不是
使用“ssl on;”以后 – 这有关系吗?
>我处理www =>顶级服务器块中的非www,但我不是
明确地解决http://domain.com => https://domain.com
(强制SSL) – 但不知何故,它正在为我做这件事.任何想法为什么
即使我还没有告诉它,这是有效的吗?我很高兴
工作,我只是想明白为什么它的工作.
>对设置的任何其他一般建议也表示赞赏.
谢谢!

虚拟主机配置:

server {
  server_name www.domain.com;
  rewrite ^(.*) https://domain.com$1 permanent;
}

server {
  listen 443 default_server;
  server_name domain.com;

  root /usr/share/Nginx/html/domain.com;
  index index.PHP index.html index.htm;

  # BEGIN W3TC Browser Cache
  gzip on;
  gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon;
  # END W3TC Browser Cache

  ssl on;
  ssl_certificate /etc/ssl/certs/domain.com.rapidssl.crt;
  ssl_certificate_key /etc/ssl/private/domain.com.key;
  ssl_session_timeout 5m;
  ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
  ssl_prefer_server_ciphers on;

  location / {
    try_files $uri $uri/ /index.PHP?q=$uri&$args;
  }

  error_page 404 /404.html;
  error_page 500 502 503 504 /50x.html;
  location = /50x.html {
    root /usr/share/Nginx/html;
  }

  location ~ \.PHP${
    try_files $uri =404;
    fastcgi_pass unix:/var/run/PHP5-fpm.sock;
    fastcgi_index index.PHP;
    include fastcgi_params;
  }
}
请不要将多个问题合二为一.

第一步,当你不知道某些东西是如何工作的时候,就是搜索文档.在Nginx的情况下,通过official documentation directive index详尽地解释了指令.

>这取决于位置块性质.前缀位置块顺序并不重要,但正则表达式位置块顺序是,因为匹配请求URI的第一个将被选中.
>配置指令顺序无关紧要,除了少数情况,如if块. Gzip指令不属于这些指令.
>事实上,ssl on是旧的方法,而listen指令参数ssl是新的.使用ssl会强制服务器块仅接受HTTPS,而listen指令参数的使用允许在同一服务器块中处理HTTP和HTTP.
>其实你明确要求Nginx这样做.另一种获得相同结果的方法是使用return 301 https://domain.com $request_uri.重写模式^(.*)匹配所有URI并捕获它们.然后它将它们永久重写(301重定向)到https://domain.com\u0026lt; uri>.如果您感到困惑,请参阅documentation以了解重写指令的工作原理.>基于意见的问题不符合SF标准.

猜你在找的Ubuntu相关文章