だから私はnginxサーバーをセットアップし、wordpressとSSLをインストールしています。
サイトはhttpとhttpsの両方で完全に機能していますが、nginxのサーバーブロックを介してhttpをhttpsにリダイレクトしようとすると、httpとhttpsの両方で無限のリダイレクトループが発生します。
これが私のサーバーブロックです
server {
listen 80;
return 301 $server_name$request_uri;
listen 443 ssl spdy;
root /var/www/wordpress;
index index.php index.html index.htm;
server_name www.example.com;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
spdy_headers_comp 6;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /etc/ssl/certs/www.example.com.certchain.crt;
ssl_certificate_key /etc/ssl/private/www.example.com.key;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header Alternate-Protocol 443:npn-spdy/2;
proxy_set_header X-Forwarded-Proto https;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
location / {
proxy_set_header X-Forwarded-Proto $scheme;
# try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?q=$uri&$args;
if ($http_referer ~* (buttons-for-website.com)) { return 444; }
if ($http_referer ~* (semalt.com)) { return 444; }
}
location ~ \.(hh|php)$ {
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Ssl on;
fastcgi_keep_conn on;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache microcache;
fastcgi_cache_valid 200 60m;
}
location ~ \.php$ {
location @fallback {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache microcache; fastcgi_cache_valid 200 60m;
}
# Cache Static Files For As Long As Possible
location ~*
\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|Zip|tgz|gz|rar|bz2|$
{
access_log off;
log_not_found off;
expires max;
}
# Security Settings For Better Privacy Deny Hidden Files
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
# Return 403 Forbidden For readme.(txt|html) or license.(txt|html)
if ($request_uri ~* "^.+(readme|license)\.(txt|html)$") {
return 403;
}
# Disallow PHP In Upload Folder
location /wp-content/uploads/ {
location ~ \.php$ {
deny all;
}
}
}
誰かの助けを本当に感謝します。私は3行目の「return301」をコメントアウトし、グーグルは同じページのhttpバージョンとhttpsバージョンの両方にインデックスを付け、ほとんどのページのインデックスを解除し、いくつかのキーワードのランキングを落としました。
よろしくお願いします!
Nginxがリクエストを処理するとき、それは first リクエストを処理するサーバーブロックを識別します。これは、server_nameおよびlistenディレクティブと一致することを意味します。
あなたの場合、あなたが持っている単一のサーバーブロックには以下が含まれています:
_server {
listen 80;
return 301 $server_name$request_uri;
listen 443 ssl spdy;
root /var/www/wordpress;
index index.php index.html index.htm;
server_name www.example.com;
...
_
これは、ポート80と443の両方でリッスンします。returnディレクティブはこの時点では処理されないため、2つの間にreturnディレクティブがあるという事実は重要ではありません。
サーバーブロックが一致すると、Nginxは他のディレクティブの処理に進みます。書き換えディレクティブ(returnなど)の場合、 リストされている順序 で処理されます。ロケーションディレクティブの場合、一致の特異性に基づいて処理されます(正確なルールは ここ にリストされています)。
リダイレクトを実装するには、書き換えディレクティブを別のサーバーブロックに分離する必要があります。
_server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl spdy;
server_name www.example.com;
root /var/www/wordpress;
index index.php index.html index.htm;
...
}
_
ページの同じ(HTTP)バージョンではなく、HTTPSバージョンを返すことを指定する必要があることに注意してください。場合によっては、サーバー名をハードコーディングすることが望ましい場合があります(たとえば、wwwトラフィックとwww以外のトラフィックを同じHTTPSページにリダイレクトする場合)。
編集:あなたのコメントに対処するには:
_https://www.example.com
_からコンテンツを配信し、次のリダイレクトが必要です。
http://(www.)?example.com
は_https://www.example.com
_にリダイレクトしますhttps://example.com
_は_https://www.example.com
_にリダイレクトしますこれを行うには、3つのサーバーブロックが必要です。
_server { #Redirect non-https to https - match both www and non-www
listen 80;
server_name www.example.com example.com;
return 301 https://www.example.com$request_uri;
}
server { #Redirect https, non-www to https, www
listen 443 ssl spdy;
server_name example.com;
ssl_certificate /etc/ssl/certs/www.example.com.certchain.crt;
ssl_certificate_key /etc/ssl/private/www.example.com.key;
return 301 https://www.example.com$request_uri;
}
server { #Main server block
listen 443 ssl spdy;
server_name www.example.com;
root /var/www/wordpress;
index index.php index.html index.htm;
ssl_certificate /etc/ssl/certs/www.example.com.certchain.crt;
ssl_certificate_key /etc/ssl/private/www.example.com.key;
...
}
_
言及すべきいくつかの重要なポイント:
SSL証明書には、サブジェクトの代替名としてwww.example.comとexample.comの両方が記載されている必要があります。 example.comからリダイレクトしている場合でも、リダイレクトの前にSSL接続が確立されます。 example.comの有効な証明書がないと、ユーザーは無効な証明書の警告を受け取り、リダイレクトは発生しません。 (これは、証明書を https://example.com ブロックに含める必要があることも意味します)
リダイレクトには複数のSSLサーバーブロックが必要なため、SSL構成の一部をサーバーブロックの外(httpブロック内)に移動することをお勧めします。これらには、_ssl_session_timeout
_、_ssl_session_cache
_、_ssl_protocols
_、_ssl_ciphers
_、_ssl_prefer_server_ciphers
_、_ssl_stapling
_、_ssl_stapling_verify
_、_ssl_trusted_certificate
_が含まれます。 、_ssl_dhparam
_、およびHSTSヘッダー。 (余談ですが、 MozillaのサーバーサイドTLS ページを確認することを強くお勧めします)