역방향 프록시를 설정하는 방법(Nginx 및 Apache용 단계별)

역방향 프록시는 웹 서버 앞에 위치하며 원본 서버에 도달하기 전에 모든 요청을 수신합니다. 이 경우 사용자나 클라이언트가 아닌 프록시를 사용하는 웹 서버라는 점을 제외하고는 정방향 프록시와 유사하게 작동합니다. 리버스 프록시는 일반적으로 웹 서버의 성능, 보안 및 안정성을 향상시키는 데 사용됩니다.

예를 들어, 서버 A의 example.com 도메인에서 호스팅되는 비 WordPress 사이트를 갖고 서버 B에서 호스팅되는 example.com/blog URL에서 WordPress에서 블로그를 실행할 수 있습니다. 기본 사이트를 호스팅하는 서버. 블로그에 대한 요청을 다른 서버(예: Kinsta와 같은 관리되는 WordPress 호스트)로 리디렉션하도록 역방향 프록시를 구성할 수 있습니다.

이 기사에서는 역방향 프록시 서버의 기본 사항, 작동 방식, 주요 이점 및 WordPress 사이트의 속도를 높이고 보안을 유지하는 데 사용하는 방법을 배웁니다.

흥분한? 시작하자!

역방향 프록시란 무엇입니까?

역방향 프록시 서버가 무엇인지 이해하려면 먼저 역할을 알고 모든 관련 용어에 익숙해져야 합니다.

일반적으로 도메인 이름을 입력하거나 링크를 클릭하여 웹을 탐색하면 브라우저/장치가 웹 사이트의 서버에 직접 연결하여 리소스 다운로드를 시작합니다.

방문하는 웹사이트에서 IP 주소를 익명으로 처리하려면 프록시 서버를 사용하여 모든 요청을 먼저 보낼 수 있습니다. 요청을 DNS 해석기로 전달한 다음 원본 서버에서 웹사이트의 리소스를 다운로드합니다.

그런 다음 해당 리소스를 장치로 전달합니다. 이를 정방향 프록시라고 합니다.

귀하의 요청이 정방향 프록시에서 시작되었다고 생각하기 때문에 귀하는 웹사이트에서 완전히 숨겨져 있습니다.

사용자 개인 정보 보호 강화와는 별도로 정방향 프록시는 주로 지리적 콘텐츠 제한을 우회하는 데 사용됩니다. 예를 들어, 해당 지역에서 차단된 비디오를 시청하려는 경우 해당 비디오를 볼 수 있는 IP 주소로 전달 프록시를 사용할 수 있습니다.

정방향 프록시는 VPN(가상 사설망)과 거의 동일한 방식으로 작동하지만 고유한 사용 사례가 있는 별개의 기술입니다(때로는 겹칠 수 있음).

역방향 프록시 서버와 정방향 프록시 서버

역방향 프록시 서버는 사용자/클라이언트가 순방향 프록시를 사용하여 동일한 결과를 얻을 수 있는 것처럼 원본 서버가 익명성을 유지하고 보안을 강화하는 전면 역할을 합니다. 사용자나 클라이언트가 원본 서버와 직접 통신하지 않도록 합니다.

정방향 프록시와 역방향 프록시의 차이는 미미하지만 다르게 작동합니다.

둘 다 기능 간에 중복이 없기 때문에 함께 작동할 수 있습니다. 일반적으로 사용자/클라이언트는 정방향 프록시를 사용하고 원본 서버는 역방향 프록시를 사용합니다.

서버 관리자는 역방향 프록시의 작동 방식을 제어할 수 있으므로 이를 사용하여 많은 유용한 기능을 활성화할 수 있습니다.

이 게시물의 뒷부분에서 모든 이점을 나열합니다.

리버스 프록시를 사용하는 이유

많은 기업, 특히 대기업은 고유한 요구 사항에 맞게 제작되고 WordPress에서 실행되지 않는 맞춤형 웹사이트를 사용합니다. 은행 및 보험 웹사이트를 예로 들 수 있습니다.

다른 경우에는 기업이 외부 소프트웨어(예: WordPress) 설치를 허용하지 않는 외부 서비스에서 사이트를 호스팅할 수 있습니다. 일반적으로 이들은 Shopify와 같은 전자 상거래 플랫폼을 사용하는 중소 소매업체입니다.

WordPress에는 강력한 CMS 기능이 있으므로 맞춤형 웹사이트를 운영하는 대기업을 비롯한 많은 기업에서 WordPress를 사용하여 블로그를 호스팅하는 것을 선호할 수 있습니다.

이 문제를 해결하는 한 가지 방법은 기본 웹 사이트의 하위 도메인에 WordPress를 설치하고 사용자가 기본 웹 사이트와 블로그 간에 쉽게 전환할 수 있도록 탐색 메뉴를 구성하는 것입니다.

하위 도메인은 고유한 도메인으로 작동하므로 사이트의 SEO에 영향을 줄 수 있습니다. Google은 하위 도메인과 하위 디렉토리를 동등하게 취급하지만 웹사이트가 하위 디렉토리에서 호스팅되는 경우보다 하위 도메인에서 호스팅되는 경우 검색 엔진 순위에 맞게 웹사이트를 최적화하는 데 더 많은 노력이 필요합니다.

Google은 하위 도메인과 하위 디렉토리를 동등하게 취급한다는 점을 재확인했지만 일부 SEO 전문가는 이에 동의하지 않습니다. 그리고 그것이 사이트의 SEO에 영향을 미치지 않더라도 하위 디렉토리에서 호스팅되는 사이트는 유지 관리가 더 쉽습니다.

그렇기 때문에 역 프록시를 사용하여 별도의 서버에서 호스팅되는 사이트의 블로그로 요청을 리디렉션할 수 있습니다. 예를 들어 은행은 서버에서 주요 웹사이트를 안전하게 호스팅할 수 있지만 Kinsta와 같은 관리형 WordPress 호스트에서 WordPress 기반 블로그를 별도로 호스팅할 수도 있습니다.

단일 도메인 이름으로 서로 다른 두 사이트를 통합하는 것은 역방향 프록시를 사용하는 주요 이점 중 하나입니다. 브랜드가 사이트를 조직적이고 전문적으로 유지하며 신뢰성을 유지하는 데 도움이 됩니다.

역방향 프록시 사용의 이점

위의 사용 사례 외에도 역방향 프록시는 다른 많은 이점도 제공합니다. 아래 섹션에서는 몇 가지 주요 이점에 대해 설명합니다.

로드 밸런싱

단일 원본 서버는 매일 수백만 명의 고유 방문자가 있는 웹 사이트에 대해 들어오는 모든 트래픽을 처리할 수 없습니다. 이러한 경우 여러 서버의 풀에 트래픽을 현명하게 분산할 수 있습니다. 일반적으로 모든 서버는 단일 실패 지점을 제거하기 위해 동일한 콘텐츠를 호스팅하여 웹 사이트를 보다 안정적으로 만듭니다.

역방향 프록시는 들어오는 트래픽이 원본 서버에 도달하기 전에 수신할 수 있으므로 이를 설정하는 좋은 방법입니다. 원본 서버에 과부하가 걸리거나 완전히 장애가 발생하면 사이트 기능에 영향을 주지 않고 트래픽을 다른 서버로 분산할 수 있습니다.

역방향 프록시는 들어오는 요청을 여러 서버로 보낼 수도 있으며 각 서버는 최적화된 특정 기능을 수행합니다. 그러면 역방향 프록시가 모든 서버에서 응답을 수집하여 클라이언트에 전달할 수 있습니다.

우리는 주로 로드 밸런싱을 위해 널리 사용되는 대부분의 역방향 프록시를 사용하기 때문에 로드 밸런서 라고도 합니다.

글로벌 서버 로드 밸런싱(GSLB)

GSLB는 전 세계에 전략적으로 배치된 많은 서버 간에 웹 사이트 트래픽을 분산하기 위한 고급 로드 밸런싱 방법입니다. 일반적으로 역 프록시가 클라이언트와 서버 간의 가장 빠른 이동 시간을 기반으로 서버 노드를 선택하는 애니캐스트 라우팅 기술을 통해 수행됩니다.

GSLB는 사이트의 안정성과 보안을 크게 향상시킬 뿐만 아니라 대기 시간과 로드 시간을 줄여 사용자 경험을 향상시킵니다. GSLB를 Spoon Feeding과 같은 다른 네트워크 최적화 기술과 함께 사용하여 원본 서버의 계산 리소스를 훨씬 더 확보할 수 있습니다.

서버에서 글로벌 서버 로드 밸런싱을 수동으로 설정할 수 있지만 일반적으로 Cloudflare 및 KeyCDN(Kinsta CDN도 지원)과 같은 전용 CDN에서 처리합니다. Kinsta는 Google Cloud Platform에서 제공하는 로드 밸런서를 통해 호스팅되는 모든 웹사이트를 제공합니다.

강화된 보안

역방향 프록시는 원본 서버의 IP 주소 및 기타 특성을 숨길 수 있습니다. 따라서 웹 사이트의 원본 서버는 익명성을 더 잘 유지하여 보안을 크게 높일 수 있습니다.

리버스 프록시는 메인 서버에 도달하기 전에 모든 트래픽을 수신하므로 공격자나 해커는 DDoS 공격과 같은 보안 위협으로 웹 사이트를 대상으로 하는 것이 더 어렵다는 것을 알게 될 것입니다.

엄격한 방화벽을 사용하여 일반적인 사이버 공격에 대한 보안을 강화하여 역방향 프록시를 강화할 수 있습니다. 리버스 프록시가 설치되어 있지 않으면 멀웨어를 제거하거나 게시 중단을 시작하기 어렵습니다.

HAProxy와 같은 역방향 프록시는 기본 HTTP 액세스 인증을 활성화하지 않은 웹 서버에 추가할 수 있습니다. 역방향 프록시를 사용하여 다양한 유형의 요청에 대한 중앙 집중식 인증을 추가할 수도 있습니다.

강력한 캐싱

정적 및 동적 콘텐츠를 모두 캐싱하여 웹 가속을 위해 역방향 프록시를 사용할 수 있습니다. 이렇게 하면 원본 서버의 부하를 줄여 웹 사이트 속도를 높일 수 있습니다.

예를 들어 오리진 서버가 미국에 있고 유럽 사용자가 웹사이트를 방문하는 경우 유럽의 역방향 프록시 서버에서 캐시된 버전의 사이트를 제공할 수 있습니다. 역방향 프록시는 원본 서버보다 사용자에게 더 가깝기 때문에 웹 사이트를 로드하는 데 시간이 덜 걸리고 성능이 우수합니다.

Varnish 및 Nginx FastCGI는 웹 콘텐츠 캐싱에 사용되는 역방향 프록시의 대표적인 예입니다. 사이트가 Kinsta로 호스팅되는 경우 Kinsta가 모든 캐싱 작업을 처리하므로 캐싱에 대해 걱정할 필요가 없습니다.

우수한 압축

서버 응답은 많은 대역폭을 사용합니다. 클라이언트로 보내기 전에 서버 응답을 압축(예: gzip 사용)하면 필요한 대역폭의 양을 줄여 네트워크를 통한 서버 응답의 속도를 높일 수 있습니다.

역방향 프록시는 원본 서버와 클라이언트 사이에 있기 때문에 서버 응답을 압축하는 데 이상적입니다.

최적화된 SSL 암호화

각 클라이언트에 대한 SSL/TLS 요청 암호화 및 해독은 원본 서버에 많은 부담을 줄 수 있습니다. 역방향 프록시는 콘텐츠 제공과 같은 다른 중요한 작업을 위해 원본 서버의 리소스를 확보하기 위해 이 작업을 수행할 수 있습니다.

SSL/TSL 암호화 및 암호 해독 오프로드의 또 다른 이점은 원본 서버에서 지리적으로 멀리 떨어져 있는 클라이언트의 대기 시간을 줄이는 것입니다.

이 작업을 더욱 최적화하기 위해 특수 SSL/TLS 가속 하드웨어가 있는 역방향 프록시를 선택할 수도 있습니다. 이러한 역방향 프록시를 SSL/TLS 종료 프록시라고 합니다. Varnish와 같은 일부 서버는 SSL/TSL 프로토콜을 지원하지 않으므로 SSL/TSL 종료 역 프록시는 이를 통과하는 트래픽을 보호하는 데 도움이 될 수 있습니다.

더 나은 A/B 테스트

대부분의 A/B 테스트 도구에서는 외부 JavaScript 라이브러리를 사용하여 해당 기능을 로드해야 합니다. 그러나 타사 스크립트를 로드하면 페이지 로드 시간이 느려지고 사용자에게 고르지 못한 경험이 생길 수 있습니다.

대신 역방향 프록시를 사용하여 서버 수준 자체에서 두 개의 개별 흐름을 만들 수 있습니다. 예를 들어 Nginx의 split_clients 또는 sticky route 방법을 사용하여 트래픽 리디렉션을 제어할 수 있습니다.

Nginx 및 freeCodeCamp에 대한 자습서를 참조하여 역방향 프록시로 A/B 테스트를 수행하는 방법에 대해 자세히 알아볼 수 있습니다.

트래픽 모니터링 및 로깅

역방향 프록시는 이를 통과하는 모든 요청을 캡처합니다. 따라서 트래픽을 모니터링하고 기록하는 중앙 허브로 사용할 수 있습니다. 여러 웹 서버를 사용하여 웹 사이트의 모든 구성 요소를 호스팅하는 경우에도 역방향 프록시를 사용하면 사이트에서 들어오고 나가는 모든 데이터를 더 쉽게 모니터링할 수 있습니다.

가장 인기 있는 역방향 프록시

W3Techs에 따르면 웹 사이트의 거의 83% 가 모니터링하는 역방향 프록시 서비스를 사용하지 않습니다.

역방향 프록시를 사용하는 17% 웹사이트(위에 나열됨) 중 대부분이 CDN이라는 것을 알 수 있습니다. 대부분의 역방향 프록시는 기본적으로 안전 예방책으로 존재를 숨기기 때문입니다. 따라서 W3Techs와 같은 웹 사이트 모니터링 서비스에 의존하여 가장 인기 있는 역방향 프록시를 찾을 수 없습니다.

우리의 연구와 경험에 따르면 오늘날 가장 널리 사용되는 역방향 프록시는 다음과 같습니다.

엔진엑스

Nginx는 리버스 프록시로도 사용할 수 있는 오픈 소스 웹 서버입니다. 웹사이트를 호스팅하는 데 사용되는 것 외에도 가장 널리 사용되는 역방향 프록시 및 로드 밸런싱 솔루션 중 하나이기도 합니다. Netcraft에 따르면 2019년 12월에 4억 7900만 개 이상의 웹 서버가 Nginx를 사용하여 웹 서버 시장 점유율의 선두 주자가 되었습니다.

Nginx는 위에서 설명한 모든 역방향 프록시 이점과 그 이상을 제공합니다. 웹 성능, 보안, 안정성 및 확장성을 향상시킵니다. 핫 리로드도 가능한 구성 파일을 사용하여 Nginx를 구성할 수 있습니다. Kinsta에서 Nginx 역방향 프록시는 사용할 수 있는 여러 프리미엄 추가 기능 중 하나입니다.

그러나 상용 제품인 Nginx Plus를 사용하여 API 기반 구성 옵션 및 대기업 웹사이트에 적합한 기타 기능에 액세스할 수도 있습니다.

Kinsta는 Nginx로 모든 웹사이트를 지원합니다. 경쟁한 모든 카테고리에서 Review Signal의 최상위 웹 호스팅 상태로 선정되었습니다. Nginx를 사용하는 다른 주요 회사로는 MaxCDN, Cloudflare 및 Netflix가 있습니다.

Nginx를 기본 역방향 프록시로 설정하는 것은 간단합니다. Nginx는 또한 요구 사항에 따라 서버의 역방향 프록시를 사용자 지정하기 위한 다양한 지시문을 제공합니다. 이 작업을 수행하는 방법은 이후 섹션에서 논의할 것입니다. Kinsta 고객인 경우 동일한 섹션에서 Kinsta로 호스팅되는 웹 사이트에 대해 역방향 프록시를 사용하는 방법도 배우게 됩니다.

광택

Varnish는 캐시 엔진이 내장된 오픈 소스 HTTP 역 프록시입니다. 주로 동적 콘텐츠를 제공하는 트래픽이 많은 웹 사이트를 위해 설계되었습니다. Varnish를 로드 밸런서, WAF(웹 앱 방화벽), 에지 인증 및 권한 부여 서버로 사용할 수도 있습니다.

Nginx 또는 Apache 웹 서버의 전면으로 주로 사용되는 모든 최신 Linux 및 FreeBSD 버전에서 작동합니다. Varnish의 강력하고 매우 유연한 VCL(Varnish Configuration Language)을 사용하면 HTTP 요청 처리, 캐싱 및 하나 이상의 웹 서버 연결과 같은 다양한 기능을 정의할 수 있습니다.

이러한 이유로 많은 CDN은 Varnish를 콘텐츠를 신속하게 제공하기 위한 주요 기반으로 사용합니다.

Varnish는 또한 한 웹 페이지의 섹션을 다른 웹 페이지에서 재사용하는 데 도움이 되는 언어인 ESI(Edge Side Include)를 지원합니다. 웹사이트가 여러 페이지에서 반복되는 콘텐츠를 많이 사용하는 경우 ESI는 자주 사용하는 섹션을 캐싱하여 사이트의 페이지 로드 시간을 단축하는 데 도움이 될 수 있습니다.

다양한 모듈(VMOD)로 Varnish를 확장할 수 있습니다. Varnish의 공식 튜토리얼로 이동하여 Varnish를 WordPress용 역 프록시로 설정하는 방법을 배우십시오.

아파치 트래픽 서버

Apache Traffic Server는 오픈 소스 캐싱 프록시 서버입니다. 빠르고 확장 가능한 기능으로 유명합니다. Yahoo!에서 개발한 상용 제품이었습니다. 오래 전이지만 오픈 소스로 만들고 유지 관리를 위해 Apache Foundation에 기부했습니다.

Comcast, Akamai, LinkedIn, Yahoo 및 Apple과 같은 여러 주요 콘텐츠 네트워크 및 CDN은 Apache Traffic Server를 사용하여 기술을 강화합니다.

HTTP 서버 데몬인 Apache HTTP Server( Apache httpd )를 사용하여 웹 서버에 역방향 프록시를 설정할 수도 있습니다. 기본 웹 서버로 작동하는 것 외에도 사용자에게 정적 및 동적 콘텐츠를 제공하는 데 도움이 됩니다. 이 기사 뒷부분에서 Apache를 역방향 프록시로 설정하는 방법을 배우게 됩니다.

HAProxy

HAProxy는 오픈 소스 역방향 프록시 및 로드 밸런서입니다. Linux 배포판 및 클라우드 플랫폼을 포함한 대부분의 기존 웹 서버 아키텍처와 통합되도록 설계되었습니다. Nginx와 유사하게 HAProxy는 이벤트 기반 I/O 모델을 사용하고 여러 작업자 프로세스에서 요청 분할을 지원합니다.

HTTP 요청의 경우 HAProxy는 로드가 많은 경우에도 예외적으로 잘 수행됩니다. Airbnb, Reddit, Instagram, Stack Overflow, Tumblr, GitHub 및 Imgur와 같이 인터넷에서 트래픽이 가장 많은 웹 사이트 중 일부는 HAProxy를 사용하여 웹 사이트를 효율적으로 제공합니다.

HAProxy를 구현하는 방법을 논의하는 것은 이 기사의 범위를 벗어나지만 작동 방식을 이해하기 위해 해당 문서를 참조할 수 있습니다.

참고: Traefik 및 Envoy는 HAProxy에 대한 두 가지 다른 오픈 소스 대안입니다. 둘 다 고성능 역방향 프록시이자 많은 고급 기능을 갖춘 로드 밸런서입니다.

다른 인기 있는 역방향 프록시로는 AWS Elastic Load Balancer, GLBC, DigitalOcean Load Balancer 및 Google Cloud Load Balancer가 있습니다. 현재 사용 중인 상위 역방향 프록시 및 로드 밸런서의 전체 목록은 Stackshare.io에서 확인할 수 있습니다.

역방향 프록시: WordPress 사이트 사용 사례

Kinsta에서 호스팅되는 사이트를 포함하여 WordPress 사이트에 역방향 프록시를 사용하는 경우는 주로 세 가지가 있습니다.

이 예에서는 Nginx만 사용합니다. Nginx는 오늘날 WordPress 사이트에 가장 많이 사용되는 역방향 프록시이기 때문입니다. 그러나 동일한 기본 원칙이 다른 역방향 프록시에도 적용됩니다.

역방향 프록시는 설치, 구성 및 지원이 어려운 경우가 많습니다. 이러한 이유로 Kinsta는 설정에 도움이 필요한 각 역방향 프록시에 대해 월 $50의 추가 기능 구독을 제공합니다. 자세한 내용은 Kinsta의 지원 팀에 문의할 수 있습니다.

1. 동일한 서버에서 호스팅되는 메인 및 프록시 사이트

기본 사이트와 프록시 사이트가 모두 동일한 서버에서 호스팅되는 경우 기본 사이트는 WordPress 설치에서 실행할 수 있지만 별도의 WordPress 설치는 프록시 사이트에 전원을 공급합니다.

사이트와 공유 웹 서버에 모두 액세스할 수 있으므로 기본 사이트에 대한 역방향 프록시 규칙을 설정한 다음 역방향 프록시에서 로드하도록 프록시 사이트를 구성할 수 있습니다.

Kinsta에서 이 두 사이트를 모두 호스팅하는 경우 Kinsta의 지원 팀에 연락하여 역방향 프록시를 설정하도록 요청할 수 있습니다. 따라야 할 절차는 다음과 같습니다.

• 기본 사이트와 프록시 사이트가 모두 Kinsta에서 호스팅되는지 확인합니다. 그렇지 않은 경우 수동으로 또는 마이그레이션 요청을 제출하여 두 사이트를 Kinsta 환경으로 마이그레이션할 수 있습니다.
• 지원 티켓을 열고 Kinsta의 지원 팀에 도메인 구성에 대한 명확한 설명을 제공합니다. 역방향 프록시를 설정하는 데 영업일 기준 약 1일이 소요됩니다.
• Kinsta는 기본 사이트에서 관련 역방향 프록시 규칙을 설정하고 역방향 프록시를 통해 로드되도록 프록시된 사이트를 구성합니다.

다음은 Kinsta에서 역방향 프록시를 통해 하위 디렉토리 사이트를 로드하는 데 사용하는 표준 Nginx 역방향 프록시 지시문입니다.

 location ^~ /subfolder/ { proxy_pass http://subfolder.domain.com; 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; }

위의 코드에서 /subfolder/ 자리 표시자를 실제 하위 디렉토리 이름(예: /blog/ , /shop/ )으로 바꿔야 합니다. 또한 http://subfolder.domain.com 하위 도메인은 역 프록시가 프록시 사이트를 가리키는 데 사용되는 URL과 일치해야 합니다.

location 지시문에는 캐럿 및 물결표 기호( ^~ )가 포함되어 있어 Nginx에 정의된 문자열을 찾으면 더 이상 일치 항목 검색을 중지하고 여기에 나열된 지시문을 사용해야 함을 알립니다. 문서에서 Nginx의 역방향 프록시 지시문에 대해 자세히 알아보세요.
다음으로 역방향 프록시를 통해 로드하도록 프록시 사이트를 구성해야 합니다. 다음은 Kinsta가 프록시 사이트를 구성하는 데 따르는 표준 단계입니다.

• 프록시 사이트가 로드되는 경로에 하위 디렉터리를 만듭니다. 프록시된 웹 사이트의 모든 파일은 이 하위 디렉토리로 이동됩니다.
• 웹 서버의 구성 파일을 업데이트하여 새 하위 디렉토리를 프록시 사이트의 루트 디렉토리로 정의합니다. 또한 수신되는 각 요청에 대한 요청 URI에서 하위 디렉토리를 제거하는 재작성 규칙을 추가해야 합니다.
• 라이브 사이트 URL(예: example.com/blog )과 일치하도록 프록시 사이트의 데이터베이스에 있는 모든 URL을 업데이트합니다.
• $_SERVER['HTTP_HOST'] 정의로 프록시된 사이트의 wp-config.php 파일을 편집하여 기본 사이트의 URL을 가리키도록 합니다.
• SSL 인증서를 사용하는 경우 리디렉션 루프를 방지하기 위해 wp-config.php 파일에 엄격한 규칙을 정의해야 합니다.

참고: 프록시 사이트는 프록시 사이트가 로드되는 동일한 하위 디렉토리를 복제하는 URL을 만들 수 없습니다. 예를 들어, example.com/blog/blog 의 프록시 사이트는 example.com/blog 에서 페이지나 디렉토리를 생성할 수 없습니다.

2. 귀하의 서버에서 호스팅되는 프록시 사이트만

프록시 사이트와 해당 웹 서버에만 액세스할 수 있는 경우 기본 사이트의 서버 관리자에게 연락하여 역방향 프록시 규칙을 설정하도록 요청해야 합니다.

이렇게 하려면 두 개의 서로 다른 서버에서 규칙을 구성해야 하는 경우를 제외하고 위에서 설명한 것과 동일한 단계를 따라야 합니다.

Kinsta로 프록시 사이트를 호스팅하려면 역방향 프록시를 가리킬 도메인을 사이트에 추가하십시오. 일반적으로 하위 도메인은 이 목적(예: blog.example.com )에 적합하여 하위 디렉토리 링크(예: example.com/blog )를 통해 프록시 사이트를 로드합니다.

Kinsta에서 프록시 사이트를 설정한 후 Kinsta 지원 팀에 문의하여 역방향 프록시를 통해 로드하도록 프록시 사이트를 구성할 수 있습니다. 이때, 저희 지원팀은 방문수를 정확하게 계산하는 방식으로 설정 프로세스를 완료하기 위해 귀하의 서버의 실제 IP를 요구할 것입니다. 특정 공급자(예: AWS CloudFront)의 동적 IP 제한으로 인해 고정 IP를 제공할 수 없는 경우 계획은 대신 유사한 대역폭 기반 계획으로 변환됩니다.

마지막으로 서버에 역방향 프록시를 설정하는 것은 서버 관리자만 처리할 수 있으므로 Kinsta 지원 범위를 벗어납니다.

3. 귀하의 서버에서 호스팅되는 메인 사이트만

기본 사이트와 해당 웹 서버에만 액세스할 수 있는 경우 역방향 프록시를 설정하고 외부 호스트에서 프록시된 사이트를 로드하도록 해당 규칙을 구성해야 합니다. 역방향 프록시를 통해 로드하도록 프록시 사이트를 설치 및 구성하는 것은 보조 서버의 관리자의 책임입니다.

Kinsta에서 메인 사이트를 호스팅하면 Kinsta의 지원 팀에 액세스할 수 있습니다. 이 문서의 앞부분에 나열된 표준 역방향 프록시 규칙을 추가하기 위해 지원 티켓을 올릴 수 있습니다. 필요한 경우 해당 규칙에 추가 사용자 정의를 추가할 수도 있습니다.

이 시나리오에서는 역 프록시를 통해 제대로 로드하도록 프록시 사이트를 구성하는 데 전적으로 책임이 있습니다.

Nginx를 역방향 프록시로 설정하는 방법

Kinsta가 웹사이트를 호스팅하지 않고 서버를 관리하는 경우 역방향 프록시를 직접 설정하고 프록시된 사이트를 가리키도록 구성해야 합니다.

웹 서버의 운영 체제에 따라 Nginx를 다르게 설치할 수 있습니다. Linux 배포판의 경우 Linux 배포판 버전에 따라 다양한 Nginx 패키지를 사용할 수 있습니다.

아래 예에서는 example.com 도메인 이름에 기본 사이트를 설치했고, 프록시된 WordPress 사이트는 blog.domain.com 하위 도메인에 설치했습니다. 둘 다 Ubuntu 18.04에서 실행되는 웹 서버의 Apache에 의해 구동됩니다. Nginx를 주 서버에 역방향 프록시로 설치하고 구성합니다.

시작하려면 SSH를 통해 서버의 터미널에 액세스하십시오. 그런 다음 apt-get 명령을 사용하여 배포의 패키지 목록을 업데이트하고 웹 서버에 Nginx를 설치합니다.

 sudo apt update sudo apt install nginx

다음으로 Apache에서 호스팅되는 도메인에 대한 요청을 프록시하도록 Nginx를 구성해야 합니다. 그렇게 하려면 새 가상 호스트 파일을 만드십시오. 여기서는 nano 편집기를 사용하여 코드를 추가하지만 원하는 코드 편집기를 사용할 수 있습니다.

 sudo nano /etc/nginx/sites-available/example.com.conf

그런 다음 다음 server {...} 및 location 블록을 추가하여 Apache에 요청을 전달하도록 Nginx 지시문을 설정합니다.

 server { listen 80; server_name example.com www.example.com; index index.php; root /var/www/example.com/public # fallback for index.php location / { try_files $uri $uri/ /index.php?$query_string; }location /blog { proxy_pass http://blog.domain.com;proxy_http_version 1.1; proxy_cache_bypass $http_upgrade; # Proxy headers proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; 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; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; # Proxy timeouts proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; }

위의 코드에서 Apache 서버에서 제공할 하위 디렉토리 example.com/blog 링크를 정의하고 있습니다. proxy_pass 지시문에서 프록시 웹사이트의 공개 IP 주소(또는 URL)를 사용하는지 확인하십시오. 제 경우에는 내 프록시 웹사이트가 blog.domain.com 하위 도메인에서 호스팅됩니다.

참고: 변경하기 전에 프록시 웹 사이트가 설치되어 있고 제공할 준비가 되었는지 확인하십시오.

Nginx의 자세한 지시문 색인에서 사용된 모든 역방향 프록시 지시문에 대해 자세히 알아볼 수 있습니다.

가상 호스트 파일을 저장합니다. 그런 다음 /etc/nginx/sites-available 및 /etc/nginx/sites-enabled 디렉터리 모두에 example.com.conf 라는 파일에 대한 심볼릭 링크를 만들어 새 가상 호스트를 활성화합니다.

 sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf

그런 다음 구성 오류가 있는지 Nginx를 테스트합니다.

 sudo nginx -t

오류가 없으면 Nginx를 다시 로드하여 변경 사항을 적용합니다.

 sudo systemctl reload nginx

이제 역방향 프록시로 작동하도록 Nginx를 성공적으로 설정했습니다. 이를 확인하기 위해 phpinfo() 함수를 사용하여 프록시 사이트를 방문할 때 로드된 PHP 변수를 확인할 수 있습니다.

SERVER_SOFTWARE 및 DOCUMENT_ROOT PHP 변수 아래에서 Apache가 백엔드에서 이 도메인을 제공하는 것을 볼 수 있습니다. 그러나 HTTP_X_REAL_IP 및 HTTP_X_FORWARDED_FOR PHP 변수는 Nginx가 요청을 전달하기 위한 역 프록시로 사용되었음을 확인합니다.

fastcgi_cache 및 ngx_cache_purge 모듈을 사용하여 Nginx를 통해 WordPress 사이트 제공 속도를 높일 수 있습니다. 첫 번째 모듈이 사이트를 캐시하는 동안 두 번째 모듈은 특정 이벤트(예: WordPress 게시물/페이지 게시 또는 편집)를 기반으로 캐시를 자동으로 제거합니다.

Nginx Cache Controller WordPress 플러그인을 사용하여 WordPress 관리 대시보드에서 직접 Nginx의 프록시 서버 캐시를 제어할 수 있습니다. WordPress Multisite 설치를 사용하는 경우 Nginx Helper 플러그인을 사용하여 동일한 작업을 수행할 수 있습니다.

Nginx 및 WordPress를 사용하는 방법에 대한 자세한 개요는 Nginx의 기본 문서 및 Nginx WordPress 설정 가이드를 확인하세요.

Apache를 역방향 프록시로 설정하는 방법

시작하기 전에 example.com 과 blog.domain.com 에서 두 개의 웹사이트가 실행 중인지 확인하세요. 첫 번째 웹사이트는 WordPress 사이트일 수도 있고 아닐 수도 있지만 두 번째 웹사이트는 기본적으로 example.com/blog 하위 디렉토리 링크에서 루트 도메인의 블로그를 로드하는 데 사용되므로 WordPress 사이트여야 합니다.

SSH를 통해 서버의 터미널을 열고 Apache의 프록시 모듈을 활성화하여 Apache 구성을 시작합니다.

 sudo a2enmod proxy proxy_http ssl

위의 명령을 실행하면 Apache를 다시 시작하여 새로 정의된 지시문을 다시 로드할 가능성이 높습니다.

다음으로 주 서버의 가상 호스트 파일을 편집하여 역방향 프록시를 만듭니다. 추가해야 하는 코드는 다음과 같습니다.

 <VirtualHost *> DocumentRoot /var/www/app/public SSLProxyEngine On ProxyRequests off ProxyPass /blog http://blog.domain.com ProxyPassReverse /blog http://blog.domain.com </VirtualHost>

ProxyPass 지시문은 지정된 경로에 대해 역방향 프록시를 생성하는 반면 ProxyPassReverse 지시문은 이 역방향 프록시를 통해 전송된 HTTP 응답 헤더를 가로채서 Apache 서버와 일치하도록 다시 작성합니다.

파일을 저장한 후 편집 중지를 묻는 줄 바로 앞에 다음 코드를 추가하여 wp-config.php 파일을 편집해야 합니다.

 # ProxyPass Settings # overrides the variables below to ensure that any # request to /blog/* subdirectory is taken care of properly $_SERVER['REQUEST_URI'] = '/blog' . $_SERVER['REQUEST_URI']; $_SERVER['SCRIPT_NAME'] = '/blog' . $_SERVER['SCRIPT_NAME']; $_SERVER['PHP_SELF'] = '/blog' . $_SERVER['PHP_SELF'];

마지막으로 /blog 하위 디렉토리 링크에 대한 구성 값을 추가하려면 WordPress 사이트의 데이터베이스를 업데이트해야 합니다. 다음 SQL 쿼리를 실행하여 이를 수행할 수 있습니다.

 UPDATE wp_options SET option_value = 'https://www.example.com/blog' WHERE option_name IN( 'siteurl', 'home' );

이제 https://www.example.com/blog URL을 방문하여 http://blog.domain.com 에서 호스팅되는 WordPress 사이트를 URL 변경 없이 하위 도메인 로드할 수 있어야 합니다. 평소처럼 WordPress를 계속 사용하여 사이트를 탐색, 작성, 편집 및 관리할 수 있습니다.

역방향 프록시의 한계

• 역방향 프록시는 통과하는 모든 트래픽을 읽고 변경할 수 있으므로 상당한 보안 위험이 있습니다. 역방향 프록시를 통해 HTTPS 트래픽을 전달하는 경우 전달되는 데이터를 해독하고 다시 암호화해야 합니다. 이는 SSL/TLS 인증서의 개인 키를 소유해야 함을 의미합니다. 따라서 악의적인 당사자가 역방향 프록시를 손상시킬 수 있는 경우 암호를 기록하고 웹사이트에 맬웨어를 삽입할 수 있습니다.
• 귀하 또는 귀하의 사용자가 주 서버에 직접 액세스할 수 없는 경우 역방향 프록시를 사용하면 단일 실패 지점이 발생할 수 있습니다. 예를 들어 역 프록시를 전면으로 사용하여 여러 도메인에 서비스를 제공하는 경우 서비스 중단으로 인해 모든 도메인이 동시에 오프라인 상태가 될 수 있습니다.
• 타사 역방향 프록시(예: Cloudflare)를 사용하는 경우 사이트의 민감한 정보를 타사에 넘겨주는 것입니다. 그들이 신뢰할 수 있지만 그것이 무엇을 초래할지 예측할 수 없습니다.
• 역 프록시를 통해 로드되는 웹 사이트에서 백업을 복원하거나 스테이징 사이트를 라이브로 푸시하면 프록시 사이트가 제대로 로드되지 않을 수 있습니다.

CDN과 역방향 프록시 중에서 선택

CDN은 대부분의 구성 및 유지 관리를 타사에서 처리하는 고급 형태의 역방향 프록시입니다. 그들은 당신의 끝에서 약간의 노력으로 WordPress 사이트에 놀라운 성능 이점을 제공할 수 있습니다.

CDN은 콘텐츠를 캐싱하여 사용자에게 신속하게 제공할 뿐만 아니라 원본 서버의 부하를 줄이고 대역폭 비용을 낮추며 추가 보안 계층을 제공하고 사이트의 SEO를 높이고 웹사이트를 더 잘 확장하는 데 도움이 됩니다.

CDN이 제공하는 대부분의 이점은 역방향 프록시가 제공하는 이점과 동일합니다. 그렇다면 역방향 프록시를 통해 CDN을 선택해야 합니까, 아니면 그 반대로 선택해야 합니까?

하나만으로 해결해야 할 이유가 없습니다. 역방향 프록시가 이미 설치되어 있는 경우에도 CDN을 사용하면 속도와 성능이 향상됩니다. 두 캐시 모두 잘 계층화되어 있으며 고유한 요청 처리 요구 사항(예: 동적 콘텐츠, 전자 상거래)이 있는 경우 CDN 또는 역방향 프록시에서 전달된 일부 사용자 정의 헤더를 사용하여 쉽게 구성할 수 있습니다.

요약

워드프레스는 매우 유연합니다. 블로그, 전자 상거래 사이트 또는 학습 관리 시스템으로 사용할 수 있습니다. 대부분의 경우 고유한 요구 사항에 맞게 WordPress를 사용자 지정할 수 있습니다.

그러나 때로는 별도의 도메인이나 보조 서버를 사용하여 추가 사이트를 호스팅해야 할 수도 있습니다. 앞서 논의한 바와 같이 대기업 사이트에 다른 기술 스택을 사용하거나 기존의 비 WordPress 사이트에 대해 WordPress 블로그를 시작하기 때문일 수 있습니다.

역방향 프록시는 이 두 경우 모두에 도움이 되며 기본 웹사이트를 포기하고 다시 시작하지 않고도 WordPress를 최대한 활용할 수 있습니다.