프록시 포트 하나가 HTTP와 SOCKS를 모두 받아들이는 방법

혼합 프록시 리스너가 하나의 TCP 포트에서 HTTP와 SOCKS를 모두 받아들일 수 있는 것은 서버가 초기 프로토콜 바이트를 검사하기 때문입니다. 포트 번호가 그 판별을 수행하는 것은 아닙니다.

HTTP 프록시 요청은 GET이나 CONNECT 같은 HTTP 메서드로 시작합니다. SOCKS 인사는 바이너리 프로토콜 필드로 시작합니다. 이러한 입력을 위해 설계된 소프트웨어는 연결을 적절한 핸들러로 전달할 수 있습니다.

이것은 명시적인 구현 기능입니다. 일반적인 Squid HTTP 리스너는 포트를 1080으로 바꾼다고 혼합 리스너가 되지 않습니다. SOCKS 전용 리스너도 브라우저 설정에서 HTTP를 배우지 않습니다.

TLS는 또 다른 경계를 추가합니다. 암호화된 프록시 연결은 눈에 보이는 HTTP 메서드가 아니라 TLS로 시작합니다. 같은 엔드포인트에서 이를 지원하려면 추가적인 의도적 처리가 필요합니다. 평문 HTTP와 SOCKS를 인식하는 것이 그 능력을 입증하지는 않습니다.

엔드포인트에 문서화된 클라이언트 프로토콜을 사용하세요. 둘 다 작동한다면 그것은 해당 서버의 혼합 리스너에 대한 증거이며, 모든 클라이언트에서 프로토콜을 지정하지 않을 이유는 아닙니다.

Glider의 혼합 리스너는 구체적인 예를 제공합니다. 1바이트를 소비하지 않고 살펴보고, 0x05를 SOCKS5 핸들러로 보내며, 그렇지 않으면 HTTP 파서를 호출합니다. 그 파서는 여전히 들어오는 요청을 검증합니다. 전달 선택이 임의의 입력을 유효한 HTTP로 만들지는 않습니다.

TCP 리스너를 공유한다고 해서 SOCKS5 UDP 연관이 제공되지는 않습니다. Glider는 UDP 리스너를 별도로 시작합니다. TCP 프로토콜 선택과 이후의 데이터그램 중계는 별개의 능력입니다.