Nginxを使用してSSL経由で非wwwをwwwにリダイレクトする


25

https://example.comhttps://www.example.comにリダイレクトしようとするとエラーが発生します

私がに行くときhttps://example.com、それはリダイレクトし、ページ/ 200ステータスを返していません。

これは望ましくありません。https://www.example.comにリダイレクトしてほしいです。

私がに行くときhttp://example.com、それはにリダイレクトhttps://www.example.com

誰かが私が間違っている場所を教えてもらえますか?

これは私のデフォルトおよびdefault-ssl設定ファイルです:

default.conf

server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

default-ssl.conf

upstream app_server_ssl {
    server unix:/tmp/unicorn.sock fail_timeout=0;
}

server {
    server_name example.com;
    return 301 https://www.example.com$request_uri
}
server {
    server_name www.example.com;

    listen 443;
    root /home/app/myproject/current/public;
    index index.html index.htm;

    error_log /srv/www/example.com/logs/error.log info;
    access_log /srv/www/example.com/logs/access.log combined;

    ssl on;
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_certificate /srv/www/example.com/keys/ssl.crt;
    ssl_certificate_key /srv/www/example.com/keys/www.example.com.key;
    ssl_ciphers AES128-SHA:RC4-MD5:ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:!ADH:!AECDH:!MD5:AES128-SHA;
    ssl_prefer_server_ciphers on;

    client_max_body_size 20M;


    try_files $uri/index.html $uri.html $uri @app;


    # CVE-2013-2028 http://mailman.nginx.org/pipermail/nginx-announce/2013/000112.html
    if ($http_transfer_encoding ~* chunked) {
            return 444;
        }

    location @app {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://app_server_ssl;
    }

    error_page 500 502 503 504 /500.html;

    location = /500.html {
        root /home/app/example/current/public;
    }
}

1
2つのconfファイルを作成するポイントは何ですか?
サンディップスベディ

懸念の分離、非SSL構成は非常に小さいため、SSLのみの構成から分離するのが最善と思われました。
トーマスV.

回答:


34

listenファイルにディレクティブがありませんdefault-ssl.conflisten 443;このディレクティブに追加

server {
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

デフォルトでは、このディレクティブを省略すると、nginxはポート80 リッスンする必要があると想定します。ここでは、このデフォルトの動作のドキュメントを示します。


編集:@TeroKilkanenからのコメントをありがとう。

ここで、default-ssl.confの完全な構成

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /srv/www/example.com/keys/ssl.crt;
    ssl_certificate_key /srv/www/example.com/keys/www.example.com.key;
    return 301 https://www.example.com$request_uri;
}

サイドノートnginxドキュメントの推奨事項としてssl on;ディレクティブを置き換えることができますlisten 443 ssl;


4
また、このブロックでディレクティブssl_certificatessl_certificate_keyディレクティブを設定しlisten 443 ssl;、SSL仮想ホストになるように使用する必要があります。
テロキルカネン14

currentの内容を投稿してくださいdefault-ssl.conf。おそらく、タイプミスや再注文の問題が原因です。
マセガロー14

これは恥ずかしいです:\犯人は/ etc / nginx / sites-enabledの重複したnginx設定で、/ etc / nginx / sites-enabled / default-ssl.backupはdefault-sslのリダイレクトを妨害していました。愚かなエラー。
トーマスV. 14

WWW-ドメイン用および非WWWの1のために:私は2つの本命を発行しなければならなかった
vladkras

どのようにこれはたとえばポート5007上で実現することができます。example.com:5007example.com:5007
CP3O

5

ifステートメントを投げるだけで、あなたはあなたの道にいるはずです。curl.exe -Iで結果を確認しました。https://www.example.com以外のすべてのケースは301として扱われます。SSLは、301 URLリダイレクトを取得する前にチェックされるため、注意が必要です。したがって、証明書エラーが発生します。

個人的には、ドメインからwwwを削除するのが好きですが、質問に答えるために以下のコードを書きました。

server {
listen 443 ssl;
listen [::]:443 ssl; # IPV6

server_name example.com www.example.com; # List all variations here

# If the domain is https://example.com, lets fix it!

if ($host = 'example.com') {
  return 301 https://www.example.com$request_uri;
}

# If the domain is https://www.example.com, it's OK! No changes necessary!

... # SSL .pem stuff
...
}

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

# If the domain is http://example.com or https://www.example.com, let's change it to https!

server_name example.com www.example.com;
return 310 https://www.example.com$request_uri;
}

3

私がそれを行う方法は、wwwのhttpsにリダイレクトするsslサーバーブロック内のifステートメントを使用することです

ssl_certificate /srv/www/example.com/keys/ssl.crt;
ssl_certificate_key /srv/www/example.com/keys/www.example.com.key;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES128-SHA:RC4-MD5:ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:!ADH:!AECDH:!MD5:AES128-SHA;
ssl_prefer_server_ciphers on;
client_max_body_size 20M;

upstream app_server_ssl {
    server unix:/tmp/unicorn.sock fail_timeout=0;
}

server {
    server_name example.com;
    return 301 https://www.example.com$request_uri
}

server {
    listen 443 default_server ssl;
    server_name www.example.com;

    # redirect https://example.com to https://www.example.com
    # mainly for SEO purposes etc
    #we will use a variable to do that
    set $redirect_var 0;

    if ($host = 'example.com') {
      set $redirect_var 1;
    }
    if ($host = 'www.example.com') {
      set $redirect_var 1;
    }

    if ($redirect_var = 1) {
      return 301 https://www.example.com$request_uri;
    } 

    try_files $uri/index.html $uri.html $uri @app;

    # CVE-2013-2028 http://mailman.nginx.org/pipermail/nginx-announce/2013/000112.html
    if ($http_transfer_encoding ~* chunked) {
            return 444;
        }

    location @app {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://app_server_ssl;
    }

    error_page 500 502 503 504 /500.html;

    location = /500.html {
        root /home/app/example/current/public;
    }
}

もちろん、nginx構成ファイルでifステートメントを使用したいときはいつでも。読む必要があります:https : //www.nginx.com/resources/wiki/start/topics/depth/ifisevil/


条件if ($host = 'www.example.com')は必要ありません。
-Karl.S

2

その2018年と私は、誰かが簡単な解決策を探している場合に備えて、これに新たなショットを与えることを考えました。

比較的新参者としての私の考えは、物事をできるだけシンプルにすることです。基本的に、http://example.comhttps://example.comの両方をhttps:// www .example.com にリダイレクトします。そして、http://example.comのリダイレクトにのみ成功すること

これは、2つのサーバーブロックのみを必要とする非常に簡単な操作です(これを1つの構成ファイルで簡単に説明します)。

# 1. Server block to redirect all non-www and/or non-https to https://www
server {
    # listen to the standard http port 80
    listen 80; 

    # Now, since you want to route https://example.com to http://www.example.com....
    # you need to get this block to listen on https port 443 as well
    # alternative to defining 'ssl on' is to put it with listen 443
    listen 443 ssl; 

    # define server_name
    server_name example.com *.example.com; 

    # DO NOT (!) forget your ssl certificate and key
    ssl_certificate PATH_TO_YOUR_CRT_FILE;
    ssl_certificate_key PATH_TO_YOUR_KEY_FILE; 

    # permanent redirect
    return 301 https://www.example.com$request_uri;  
    # hard coded example.com for legibility 
}
# end of server block 1. nearly there....

# 2. Server block for the www (primary) domain
# note that this is the block that will ultimately deliver content
server {
    # define your server name
    server_name www.example.com; 

    # this block only cares about https port 443
    listen 443 ssl;

    # DO NOT (!) forget your ssl certificate and key
    ssl_certificate PATH_TO_YOUR_CRT_FILE;
    ssl_certificate_key PATH_TO_YOUR_KEY_FILE; 

    # define your logging .. access , error , and the usual 

    # and of course define your config that actually points to your service
    # i.e. location / { include proxy_params; proxy_pass PATH_TO_SOME_SOCKET; }
}
# End of block 2.
# voilà! 

今両方http://example.comhttps://example.comにリダイレクトする必要がありhttps://www.example.com。基本的に、このセットアップはすべての非wwwおよび/または非httpsをhttps:// wwwにリダイレクトします


-1

すべてのリクエストを https://www.example

SSLポート(通常は443)とデフォルトのHTTPポート80にリダイレクトおよびプライマリドメイン用のサーバーブロックを作成します。

# non-www to ssl www redirect
server {
  listen 80; 
  listen 443 ssl;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
  # ... ssl certs
}

# ssl setup for www (primary) domain
server {
  listen 80;
  listen 443 ssl;
  server_name www.example.com;
  if ($scheme = http) {
    return 301 https://www.example.com$request_uri;
  }
  # ... the rest of your config + ssl certs
}

保存して従う sudo nginx -s reload

これはリダイレクトします

http://example      301 -> https://www.example
https://example     301 -> https://www.example
http://www.example  301 -> https://www.example
https://www.example 200

;if句の2番目のサーバーブロックにaがありません。それはreturn 301 https://www.example.com$request_uri;
Lukas Oppermann

1
しかし、それでもうまくいくでしょうか?それがために聞くことができるhttp443
ルーカスオッパーマン

あなたは正しいです、私はそれを追加しました。私はそれを追加しました。
lfender644516
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.