Apache 프록시는 포트 3128에서 수신합니다. 클라이언트는 정상적으로 도달하지만 포트 8443의 HTTPS 서비스는 실패합니다. 프록시의 수신 포트를 바꾸는 것으로는 그 특정 차이가 해결될 가능성이 낮습니다.

클라이언트는 먼저 프록시 리스너에 연결합니다. 그다음 CONNECT 요청 이 별도의 대상 호스트와 포트를 지정합니다. Apache는 첫 번째 연결을 받아들이고 두 번째 작업을 거부할 수 있습니다.

AllowCONNECT를 대상 정책으로 읽기

Apache 2.4에서는 mod_proxy_connect 가 들어오는 CONNECT 요청을 처리합니다. 이 모듈의 AllowCONNECT 지시문이 해당 요청에 사용할 수 있는 대상 포트를 제어합니다. 문서화된 기본값은 443과 563입니다.

AllowCONNECT 443 8443

이 예제는 그 두 대상 포트를 선택합니다. 기본 선택을 대체하며, 기본 포트를 모두 조용히 유지하면서 8443을 추가하는 것은 아닙니다. 해당 서버 또는 가상 호스트 구성에서 지시문을 사용하십시오.

유지하십시오 프록시의 클라이언트 권한 부여 규칙 을 그대로 둡니다. 허용된 대상 포트는 어떤 클라이언트가 서비스를 사용할 수 있는지 알려주지 않으며, 필요할 때 대상 호스트 제한을 대신하지도 않습니다.

리버스 프록시 예제는 다른 질문에 답한다

Apache와 HTTPS 검색 결과는 흔히 고정 백엔드로 전달하는 공개 웹사이트를 보여 줍니다. 그 구성은 브라우저가 포워드 프록시에 선택한 웹사이트로 CONNECT 터널을 열어 달라고 요청하는 방식이 아닙니다. 그 라우팅 지시문을 복사하면 원래의 프록시 문제가 그대로 남을 수 있습니다.

실패를 진단할 때는 클라이언트가 도달한 리스너, 요청된 CONNECT authority, 프록시의 응답을 기록하십시오. CONNECT가 성공하고 그 뒤 TLS가 실패한다면 대상 포트 권한은 이미 제 역할을 마쳤습니다. AllowCONNECT를 반복해서 넓히는 대신 TLS 실패 로 넘어가십시오.

관련 글