Nginx 역방향 프록시를 통해 Apache http 사이트를 안전한 https 사이트로 전환
Apache 웹 서버에서 실행되는 이전 WordPress 사이트를 지원해야합니다. 더 안전하게 만들기 위해이 Apache 서버는 Docker 컨테이너에 있으며 Nginx 역방향 프록시 구성을 통해 전 세계에서 액세스 할 수 있습니다. 이 사이트는 현재 http를 통해 제공되며 https로 이동하고 싶습니다.
두 가지 옵션이 있다고 생각합니다.
SSL 인증서는 Nginx 사이트 용으로 설치
proxy_pass되며 Apache 컨테이너의 일반 http 사이트에도 설치됩니다.server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/nginx/ssl/letsencrypt/live/www.example.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/letsencrypt/live/www.example.com/privkey.pem; access_log /var/log/nginx/example.com.access.log; location / { proxy_pass http://Apache2-PHP5.6:80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }Apache 서버의 관점에서 본 시나리오에서는 여전히 http를 통해 사이트를 제공하고 있습니다.
이것은 더 힘들다 : SSL 인증서는 게이트웨이 Nginx 서버와 프록시 된 Apache 사이트 모두에 설치됩니다. 그런 다음 구성 값 에서 로 변경
http해야 합니다.httpsproxy_pass
첫 번째 시나리오에서 모든 것이 잘 되었으면합니다. 그러나 아파치가 http를 통해 서비스를 제공한다고 느끼는 사실은 몇 가지 문제를 야기합니다. 재구성 / 디버그하지 않으려는 숨겨진 URL 리디렉션이 있습니다. 그리고 이러한 URL 리디렉션은 다음과 같은 작업을 수행합니다. 요청 된 URL이 http://www.example.com이면 (http 상태 301) http://www.example.com/main. 이 리디렉션은 브라우저에서 수신하므로 첫 번째 요청이 https를 통해 이루어졌지만 이제 리디렉션 된 URL은 http입니다. 또한 사이트 html에는 프로토콜 참조도 포함하는 자체 리소스 (JavaScript 및 CSS 파일)에 대한 서버 전체 경로 href가 포함되어 있습니다. 이 시점에서 해당 href가 요청이 작성된 방식에서 프로토콜을 채택하는지 또는 하드 코딩되었는지는 명확하지 않습니다. 어쨌든, 불행히도 이것은 심각한 파고 없이는 작동하지 않습니다.
그래서 나는 옵션 2를 남겼습니다. 시도해 보았고 작동합니다. Nginx와 컨테이너화 된 Apache 모두에서 동일한 SSL 인증서를 설정할 수 있습니다. 그러나 이것이 실제로 어떻게 실행되어야하는지 알고 싶습니다. Apache 서버는 이제 콘텐츠가 https를 통해 제공되고 있음을 알고 있지만 이제 모든 요청에 대해 이중 SSL-ing이 발생합니다. 옳지 않다.
답변
proxy_set_header X-Forwarded-Proto "https";첫 번째 설정 의 선언 을 사용하여 들어오는 요청이 HTTPS 요청에서 프록시되고 있음을 Apache에 알릴 수 있어야합니다.
nginx 설정에서 HTTP_X_FORWARDED_PROTO를
proxy_set_header X-Forwarded-Proto $scheme;
이 줄을 wp-config.php에 추가하여 WordPress를 인식하도록 구성하십시오.
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on';
}
이 솔루션의 변형에 대해서는 Wordpress 지원 문서 를 참조하십시오 .
일반적으로 역방향 프록시에서 모든 무거운 작업을 수행하고 가능한 한 원본으로 노출되는 백엔드 사이트를 유지하는 것을 선호합니다.
귀하의 문제는 본질적으로 (WordPress) 백엔드가 방문자가 사용하기를 원하는 것과 다른 (절대) URI를 생성하고 사용한다는 것입니다.
WordPress가 ngx_http_sub_module을 사용하여 nginx에서 생성 하는 (HTML) 콘텐츠 를 다시 작성하여 이를 해결할 수 있습니다 . 또한 다음과 유사한 방식으로 절대 URL을 다시 작성할 수 있습니다.
location / {
sub_filter 'http://example.com/' 'https://www.example.com/' ;
sub_filter 'http://www.example.com/' 'https://www.example.com/' ;
sub_filter_once off;
proxy_pass http://Apache2-PHP5.6:80;
proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}