☰

Проксирование страницы WordPress с другого поддомена

tag-icon • tag-icon nginx wordpress subdomain
Проксирование страницы WordPress с другого поддомена

У меня на сервере Ubuntu установлен Nginx, а на 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-адресу, который вызовет столько внутренних прокси-подключений, сколько /galleryчастей URL-адреса следуют друг за другом.

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-запросом?

Thelarge_client_header_buffersконтролирует максимальную длину строки запроса, по умолчанию 4 8k8096 символов ASCII. Хотяhttp2_max_field_sizeустарел, быстрый тест curlпоказывает, что по умолчанию Nginx может обслуживать URL длиной до 11157 символов по HTTP/2. Какой бы ни был предел, ваш прокси-сервер разрешит от 1011 до 1394 повторений /galleryв URL, прежде чем выдаст 414 Request-URI Too Largeошибку.

Пределworker_connectionsскорее всего, ударит первым, если не увеличится от значения по умолчанию 512. Это приведет к появлению 500 Internal Server Errorи строк журнала ошибок, содержащих:

512 worker_connections are not enough while connecting to upstream

Связанный контент