SOCKS5와 SOCKS5h: DNS 조회는 어디서 일어날까

curl에서 목적지 이름을 프록시가 확인하게 하려면 socks5h:// 를 선택합니다. curl이 로컬에서 이름을 확인한 뒤 주소를 프록시에 전달하게 하려면 socks5:// 를 선택합니다. 둘 다 SOCKS5를 사용하며, 끝의 h 는 클라이언트 URL 표기 규칙입니다.

로컬 리스너 대신 자신의 SOCKS5 엔드포인트를 넣고 두 모드를 비교하세요.

curl --noproxy '' --proxy socks5://127.0.0.1:1080 --connect-timeout 5 --max-time 15 --verbose https://example.com/
curl --noproxy '' --proxy socks5h://127.0.0.1:1080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

달라지는 것은 이름 확인 모드뿐입니다. --noproxy '' 는 이 호출들의 프록시 우회 규칙을 지우고, 시간 제한은 비교에 걸리는 시간을 한정합니다. 같은 역할을 하는 전용 옵션은 --socks5 와 --socks5-hostname 입니다. 목적지에는 호스트 이름을 사용하세요. IP 주소를 직접 쓰면 목적지 이름 조회가 필요 없어 이 차이를 확인할 수 없습니다.

한쪽에서만 확인할 수 있는 이름도 있다

프록시가 개발 네트워크 안에서 실행되고 그 네트워크의 DNS가 내부 서비스 이름을 알고 있다고 가정해 보세요. 노트북에서는 socks5 모드로 그 이름을 확인하지 못하더라도 socks5h 를 쓰면 프록시가 확인할 수 있습니다. 반대로 노트북의 hosts 파일에만 정의된 이름이라면 원격 조회가 실패할 수 있습니다.

공용 DNS도 네트워크에 따라 다른 주소를 반환할 수 있습니다. 결과가 다르다면 곧바로 프록시를 바꾸기보다 선택된 주소와 해당 주소에 도달할 수 있는지를 비교해야 합니다.

• 프록시 호스트 이름을 확인할 수 없음:어느 모드도 시작할 수 없습니다. 클라이언트는 proxy.example 를 여전히 직접 확인합니다. socks5h://proxy.example:1080 도 예외가 아닙니다.
• 목적지의 로컬 이름 조회 실패:클라이언트의 리졸버를 확인하거나 프록시에 호스트 이름을 전달하는 모드와 비교하세요.
• SOCKS 서버가 목적지를 거부함:응답과 정책을 확인하세요. 로컬 조회가 성공해도 원격에서 도달할 수 있다는 뜻은 아닙니다.
• 터널은 작동하지만 인증서 검증 실패:목적지 TLS를 조사하세요. DNS 모드를 바꾸는 것은 신뢰 문제를 전반적으로 해결하는 방법이 아닙니다.

직접 관리하는 프록시라면 통제된 테스트 이름과 서버 측 로그를 통해 어떤 주소 유형이 프록시에 전달됐는지 확인할 수 있습니다. 출구 IP를 보여 주는 웹페이지로는 알 수 없습니다. 그 페이지는 외부로 나가는 연결을 보여 줄 뿐, DNS 조회가 어디서 일어났는지는 알려 주지 않습니다.

개인정보 보호 효과에는 범위가 있다

프록시 측 조회는 이 요청의 목적지 이름을 로컬에서 조회하지 않게 합니다. SOCKS를 암호화하거나, 프록시가 암호화된 DNS를 쓴다는 것을 증명하거나, 다른 애플리케이션과 브라우저 프리페치 트래픽까지 프록시로 보내 주지는 않습니다. SOCKS를 지원하는 Requests도 같은 로컬 조회와 프록시 측 조회 구분을 사용합니다. 다른 클라이언트는 curl의 URL 표기 대신 설정 항목을 제공할 수 있습니다. SOCKS5 프록시 목록에서 엔드포인트를 복사하기 전에 애플리케이션이 지원하는 프로토콜을 선택하세요.