☰

別のサブドメインから WordPress ページをプロキシする

tag-icon • tag-icon nginx wordpress subdomain
別のサブドメインから WordPress ページをプロキシする

Ubuntu サーバーに Nginx をインストールし、 に WordPress をインストールしましたblog.example.com。

WordPress で、 からアクセスできるギャラリーのページを作成しましたblog.example.com/gallery。

これで、誰かが にアクセスすると、gallery.example.comのコンテンツが表示されるはずですblog.example.com/gallery。Nginx でこれを実現するにはどうすればよいでしょうか?

以下は、nginx サーバーの設定で試した内容ですblog.example.com.config。

   location /gallery {
        proxy_pass http://gallery.example.com/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

答え1

正しい構成

プロキシの順序が逆です。これはパスからサブドメインへのプロキシです。おそらく、パスが存在するのと同じホスト名へのプロキシです。 の場合server_name gallery.example.com、現在は から へのプロキシhttp://gallery.example.com/galleryですhttp://gallery.example.com/。

http://gallery.example.comからへのプロキシにするにはhttp://blog.example.com/gallery:

server {
    server_name gallery.example.com;    
    location / {
        proxy_pass http://blog.example.com/gallery;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

現在のプロキシ構成によるサービス拒否攻撃

完全な設定ミス:

server {
    server_name gallery.example.com;    
    location /gallery {
        proxy_pass http://gallery.example.com/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

この誤った構成がプロキシ先と同じサブドメイン上にあるという詳細は興味深いものです。なぜなら、URL 部分が連続している数と同じだけ内部プロキシ接続を引き起こす URL にアクセスすることで、誰かが実際にこの種の設定をサービス拒否に悪用する可能性があるからです/gallery。

http://gallery.example.com/gallery/gallery/gallery/gallery/gallery/.../gallery
=> . . . 
=> http://gallery.example.com/gallery/gallery/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery
=> http://gallery.example.com/gallery
=> http://gallery.example.com/

このようなリクエストを多数呼び出すと、サーバーに高い負荷がかかります。これは、Nginx がネストされたプロキシ接続をすべて処理しようとしているため、攻撃が停止した後も長時間続く可能性があります。Nginx は、正当なユーザーに対して502 Bad Gateway&を表示し始める可能性もあります。500 Internal Server Error

これらすべてのリクエストをログに記録すると、問題が発生する可能性があります。[alert] 1620#1620: *2748894 write() to "/var/log/nginx/access.log" was incomplete: 3421 of 4566 while logging request

これがサーバーであればhttps://、これらすべての TLS ハンドシェイクによってさらに大きな負荷が発生します。

単一の HTTP リクエストによっていくつのプロキシ接続が発生する可能性がありますか?

のlarge_client_header_buffersリクエスト行の最大長を制御します。デフォルトは4 8k8096 ASCII文字です。http2_max_field_sizeは廃止されていますが、簡単なテストで、 Nginx はデフォルトで HTTP/2 経由で最大 11157 文字の URL を処理できることがわかります。どちらの制限であっても、プロキシはURL 内でcurl1011 回から 1394 回までを許可し、それを超えるとエラーが発生します。/gallery414 Request-URI Too Large

制限のworker_connectionsデフォルトから増やさない場合、最初にヒットする可能性が高くなります。これにより、次のようなエラー ログ行512が発生します。500 Internal Server Error

512 worker_connections are not enough while connecting to upstream

関連情報