출구 IP는 목적지에서 측정해야 합니다. 프록시 목록의 주소는 클라이언트가 접속하는 리스너입니다. NAT, 라우팅, 추가 외부 중계 지점 때문에 목적지에는 다른 출발지 주소가 보일 수 있습니다.

같은 IP 확인 엔드포인트를 프록시 없이, 그리고 프록시를 거쳐 호출해 비교하세요. 간단한 공개 예제는 다음과 같습니다.

curl --noproxy '*' --connect-timeout 5 --max-time 15 https://httpbin.org/ip
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 https://httpbin.org/ip

문서용 프록시 주소를 실제 엔드포인트로 바꾸세요. HTTP 프록시 목록의 항목이라면 리스너 주소와 관측한 출구 주소를 구분해야 합니다. 첫 요청은 직접 접속이 허용되는 곳에서 프록시를 우회합니다. 둘째 요청은 우회 규칙을 지우고 프록시를 선택합니다. 확인 서비스가 두 요청을 모두 받으므로 개인 데이터, 쿠키, 토큰은 넣지 마세요.

HTTP 200만 보지 말고 반환한 주소를 확인하세요. 예상한 다른 주소라면 이 요청이 사용한 경로를 뒷받침합니다. 결과가 같다면 목록 항목이 거짓이라고 결론 내리기 전에 우회 규칙과 설정을 확인하세요.

IP 확인 서비스가 무엇을 측정하는지 확인하기

httpbin의 origin 결과는 X-Forwarded-For 가 있으면 이를 사용할 수 있습니다. 따라서 원시 소켓 연결 상대가 아니라 주소 체인이 들어갈 수 있으며, 평문 HTTP 전달 테스트에서 특히 중요합니다. 정확성이 필요하면 직접 관리하는 확인 서비스를 쓰는 편이 좋습니다. 알려진 네트워크 경계에서 실제 연결 상대를 기록하고, 전달 헤더는 자신의 인프라가 제공하고 검증할 때만 신뢰하세요.

curl이 이미 알고 있는 주소

curl --proxy http://203.0.113.10:8080 --noproxy '' --output /dev/null --write-out 'peer=%{remote_ip}\n' https://example.com/

remote_ip 는 curl의 연결 상대를 나타내며, 이 예에서는 보통 HTTP 프록시 엔드포인트입니다. curl이 어디에 접속했는지 확인하는 데 도움이 되지만 프록시의 외부 출발지 주소를 관측하지는 않습니다. 두 번째 질문에는 목적지 측 결과가 답합니다.

실제로 프록시를 사용할 앱 안에서도 확인을 반복하세요. curl 요청이 성공했다고 브라우저가 설정되지는 않습니다. 프로필, 확장 기능, 우회 규칙, 시스템 설정을 무시하는 앱은 다른 경로를 선택할 수 있습니다. 위치가 중요하다면 관측한 출구 주소를 조회하고 결과에 엔드포인트와 출구를 함께 저장하세요.

관련 글