NGINXで古いサイトURLを新しいサイトURLにリダイレクトする問題

私はアトラシアンスタックのベースURLを変更しようとしましたが、わずかな成功しかありませんでした。Nginxリバースプロキシを備えたUbuntuサーバー16.04LTS。内部IPと外部IPは異なるNICに割り当てられます。はい、この同じ質問がstackoverflowに投稿されていますが、私はこの1つで最大限の露出を得ようと考えました。

サンプルのNginxサーバーファイル：

server {
  listen                80;
  listen                443 ssl;
  server_name           projects.old-site.com;
  access_log            off;
  return 301 $scheme://projects.new-site.com;
}

server {
  listen                80;
  server_name           projects.new-site.com;
  access_log            off;

  client_max_body_size  100M;

  return 301 https://$host$request_uri;
}

server {
  listen                443 ssl;
  server_name           projects.new-site.com;

  client_max_body_size  100M;

  ssl_certificate       /path/to/new-site.crt;
  ssl_certificate_key   /path/to/new-site.key;

location /
...output omitted

動作：HTTPリダイレクトおよびHTTPからHTTPSへのリダイレクト。http://projects.old-site.comはhttps://projects.new-site.comに適切にリダイレクトします。http://projects.new-site.comと入力するだけで直接アクセスできます（HTTPSに正しくリダイレ​​クトされます）。

しないもの：https : //projects.old-site.comからhttps://projects.new-site.comへのリダイレクト。

さらに奇妙なことに、リダイレクトをテストするためにhttps://projects.old-site.comにアクセスしようとすると、ブラウザは.old-site.comをまだ提供されているだけでなく、そのドメインの期限切れのSSL証明書を提供されています。

私のシステムのどこにも、このサーバーでアクセス可能な期限切れの証明書はありません。Atlassian URL更新ガイドに従って、server.xmlファイルのみを変更し、アプリケーション管理画面内から（アクセス可能な場合）変更しました。すべてのDNSサーバーが正しいIPを指している。私は間違いなく何かを見逃していますが、途方に暮れています。これは、Nginxと同じバージョンのAtlassianソフトウェアがインストールされた2つの異なるUbuntu 16.04サーバーで繰り返されています。

助けてください。

構成にいくつかの問題があります。

ここでは、個々のサーバーブロックを個別に確認します。

ブロック＃1：projects.old-site.com-> projects.new-site.comリダイレクト

これはあなたが私たちに提供したものです：

server {
    listen                80;
    listen                443 ssl;
    server_name           projects.old-site.com;
    access_log            off;
    return 301 $scheme://projects.new-site.com;
}

ここでは、構成に関する多くのことを逃しています：

• ssl_certificate ディレクティブ-ドメインに提供するSSL証明書を知る必要があります。
• ssl_certificate_key ディレクティブ-「古い」プロジェクトサイトのSSL証明書に対応するSSL証明書キーファイル。

スキームに一致させるために301リダイレクトを行っていますが、サーバーブロック2で非SSLをSSLに転送する場合、なぜこれを行うのですか？HTTPSサイトにリダイレクトするだけで、明らかな理由（同じリクエストURIを渡さないため、適切に機能しません）を含め$request_uriます。

あなたの正しいここでサーバブロックは、より多くのようになります。

server {
    listen 80;
    listen 443 ssl;
    server_name projects.old-site.com;

    ssl_certificate /path/to/valid/projects.old-site.com/certificate;
    ssl_certificate_key /path/to/valid/projects.old-site.com/certificate.key;

    access_log off;
    return 301 https://projects.new-site.com$request_uri;
}

ブロック＃2：projects.new-site.comのhttp-> httpsリダイレクト

あなたは私たちにこれを与えました：

server {
    listen                80;
    server_name           projects.new-site.com;
    access_log            off;

    client_max_body_size  100M;

    return 301 https://$host$request_uri;
}

ここには多くの問題はありませんが、ここでグローバルに受け入れないようにしましょう$host（私たちはそれを必要としません、私たちはそれをどこに終わらせたいかを知っていclient_max_body_sizeます）。とにかく301リダイレクトはそれを尊重しません。

これで終わるはずです：

server {
    listen                80;
    server_name           projects.new-site.com;
    access_log            off;

    return 301 https://projects.new-site.com$request_uri;
}

ブロック＃3： https://projects.new-site.com

3つ目のブロックになります。 *サーバーブロック全体とそのすべての構成ディレクティブがなければ、ブロックの構成を適切に支援できません。

あなたは私たちにこれを与えました：

server {
    listen                443 ssl;
    server_name           projects.new-site.com;

    client_max_body_size  100M;

    ssl_certificate       /path/to/new-site.crt;
    ssl_certificate_key   /path/to/new-site.key;

    ...
}

このブロックには本当に間違って何もあなたがしかしない限り、ありません必要なclient_max_body_sizeバックエンドアプリケーションのためのディレクティブを、あなたはおそらくそれを削除する必要があります。