다른 하위 도메인의 WordPress 페이지 프록시

다른 하위 도메인의 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;
    }
}

/gallery이 잘못된 구성이 프록시와 동일한 하위 도메인에 있다는 세부 사항은 누군가가 실제로 URL에 액세스하여 많은 내부 프록시 연결을 유발하는 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 요청으로 인해 몇 개의 프록시 연결이 발생할 수 있습니까?

그만큼large_client_header_buffers최대 요청 라인 길이를 제어하며 기본값은 4 8k8096 ASCII 문자입니다. 하지만http2_max_field_size더 이상 사용되지 않습니다. 간단한 테스트를 통해 curlNginx가 기본적으로 HTTP/2를 통해 최대 11157자 길이의 URL을 제공할 수 있다는 사실이 밝혀졌습니다. 제한이 무엇이든 프록시는 오류가 /gallery발생하기 전에 URL에서 1011~1394번을 허용합니다 414 Request-URI Too Large.

한도worker_connections기본값에서 증가하지 않으면 먼저 적중될 가능성이 높습니다 512. 그러면 500 Internal Server Error다음을 포함하는 오류 로그 줄이 발생합니다.

512 worker_connections are not enough while connecting to upstream

관련 정보