브라우저는 Squid를 통해 HTTP 페이지를 불러옵니다. 같은 대상이 proxychains에서는 실패합니다. 이것이 두 프로그램 중 하나가 잘못된 프록시 IP를 골랐다는 뜻은 아닙니다.

일반적인 HTTP 인식 클라이언트는 웹 요청을 HTTP 프록시 형식으로 포워드 프록시에 보낼 수 있습니다. 반면 일반 소켓 래퍼는 애플리케이션이 열려던 연결을 위해 바이트 터널이 필요합니다. 체인에 있는 HTTP 프록시에 대해서 proxychains는 CONNECT를 사용합니다.

즉 포트 80의 평문 웹사이트가 포트 80에 대한 CONNECT 요청을 만들 수 있습니다. CONNECT를 승인된 TLS 포트 목록으로만 허용하는 Squid 정책은 포트 80으로 가는 일반 HTTP 요청이 허용되더라도 그 터널을 거부할 수 있습니다.

호스트 이름만이 아니라 요청을 비교하라

proxychains-ng 문서는 자체 HTTP CONNECT 지원을 설명합니다. Squid의 접근 규칙은 메서드와 대상 포트를 구분할 수 있습니다. 같은 웹사이트로 가는 서로 다른 요청 경로입니다.

변경하기 전에 거부 사유와 의도된 정책을 읽으십시오. CONNECT 접근을 모든 포트로 확장하는 것은 큰 변경입니다. 래퍼 불일치에 대한 기본 대응이 되어서는 안 됩니다.

애플리케이션에 네이티브 HTTP 프록시 지원이 있으면 그것을 사용해 평문 HTTP에 불필요한 일반 터널을 피할 수 있습니다. 정말로 원시 TCP 터널이 필요하다면 그것을 제공하는 승인된 프록시 프로토콜과 포트 정책을 선택하십시오.

성공한 브라우저 요청은 프록시의 도달 가능성과 하나의 지원되는 요청 모드에 대한 유용한 증거입니다. 그러나 모든 터널링 방식, 대상 포트, 애플리케이션 프로토콜이 그 프록시를 통해 허용된다는 것을 증명하지는 않습니다.

관련 글