프록시는 HTTP 트래픽을 처리해도 WebRTC는 STUN/ICE를 통해 UDP로 후보 주소를 교환할 수 있습니다. 이 글에서는 로컬·사설 주소가 언제 노출되는지와 네트워크 출구와 브라우저 환경을 일관되게 맞추는 방법을 설명합니다.
프록시를 설정했고 IP 조회 페이지에서도 예상한 지역과 통신사가 표시됩니다. 네트워크 신원이 깔끔하게 정리된 것처럼 보입니다. 그런데 누수 검사 페이지를 열면 WebRTC 항목이 빨간색으로 표시되고 실제 인터넷 회선의 주소가 나타날 수 있습니다.
그렇다고 바로 프록시를 바꿀 필요는 없습니다. 대부분의 경우 문제는 프록시 품질이 아니라 프록시가 관여하지 못하는 트래픽에 있습니다.
프록시는 HTTP를 처리하지만 WebRTC는 다른 경로를 사용한다
프록시는 네트워크 계층에서 동작합니다. 브라우저 확장 프로그램이든 시스템 수준 터널이든 HTTP/HTTPS 요청을 처리하고 해당 트래픽을 프록시 출구로 보냅니다.
WebRTC는 다릅니다. 브라우저에 내장된 실시간 통신 기능으로, 음성·영상 통화와 P2P 전송에 적절한 경로를 찾기 위해 외부 서버에 STUN 질의를 능동적으로 보낼 수 있습니다. 쉽게 말해 “당신 쪽에서는 내 주소가 무엇으로 보이나요?”라고 묻고, 그 결과를 ICE 후보로 정리해 웹페이지에 전달합니다. 이 질의는 UDP를 사용하므로 HTTP 터널과는 서로 독립된 경로입니다.
그 결과 웹 요청은 프록시 출구로 나가는데 브라우저는 동시에 로컬 주소를 알릴 수 있는 불일치가 생깁니다. 프록시를 설정하면 네트워크 신원 전체가 자동으로 깔끔해진다고 생각하는 것이 이 문제의 가장 흔한 출발점입니다.
노출되는 것은 공인 IP만이 아니다
ICE 후보에는 보통 두 종류의 주소가 들어갑니다. 하나는 실제 인터넷 사업자 회선의 출구인 공인 주소이고, 다른 하나는 192.168로 시작하는 사설 주소 같은 로컬 주소입니다. 경우에 따라 가상 네트워크 어댑터 주소도 포함될 수 있습니다.
사설 네트워크 주소 하나만으로는 큰 의미가 없습니다. 거의 모든 컴퓨터에 있기 때문입니다. 하지만 충분히 안정적일 수 있어 여러 계정에서 후보 주소가 반복해서 겹치면 플랫폼이 해당 계정들을 같은 기기와 연결하는 추가 신호로 사용할 수 있습니다. 공인 주소는 더 직접적입니다. 실제 통신사와 대략적인 지리적 위치를 가리킵니다. 얼마나 세밀하게 식별할 수 있는지는 상대방 구현에 달렸지만 방향은 분명합니다. 주소가 실제에 가까울수록 연결하기가 쉬워집니다.
실제로 웹사이트가 읽을 수 있는 경우는 언제인가
모든 사이트가 이런 정보를 읽는 것은 아닙니다. 주소 교환을 하려면 페이지가 RTCPeerConnection 객체를 직접 생성해야 하며, 일반적인 콘텐츠 페이지에는 보통 필요하지 않습니다.
주로 실시간 통신이 필요한 사이트에서 사용됩니다. 예를 들어 화상 회의, 온라인 고객 지원, 일부 라이브 스트리밍 페이지가 여기에 해당합니다. 광고나 부정 행위 방지가 중요한 사이트, 그리고 위험 관리 체계가 잘 갖춰진 플랫폼도 사용할 수 있습니다. 이런 읽기 동작은 화면에 보이지 않는 곳에서 이루어지며, 수집 후 어떻게 활용되는지 별도 알림을 받는 경우도 드뭅니다.
사이트 자체와 무관한 상황도 있습니다. 프록시가 재연결되거나 노드를 바꾸는 짧은 사이에 브라우저의 STUN 요청이 로컬 네트워크로 나갈 수 있습니다. 시간은 매우 짧지만 한 번 기록되기에는 충분합니다.
흔한 세 가지 실패 상황
브라우저 확장 프로그램 형태의 프록시는 일반적으로 HTTP/HTTPS 요청만 처리합니다. UDP는 범위 밖이며, 화면에서 “전역” 옵션을 선택해도 이 점은 바뀌지 않습니다.
시스템 수준의 전역 프록시는 기기 전체 트래픽을 덮으므로 더 완전해 보입니다. 하지만 후보 주소 수집이 로컬 네트워크 인터페이스에 직접 바인딩되어 시스템 라우팅 테이블을 우회할 수 있고, 이 단계에서 터널에 빈틈이 생길 수 있습니다.
세 번째는 기술만의 문제가 아니라 위험 관리 기준이 변한 데서 생깁니다. 위험 관리 시스템은 WebRTC 주소를 계정 연관성 판단에 쓰는 여러 신호 중 하나로 점점 더 많이 활용하고 있습니다. 과거에는 측정하지 않았거나 무시했던 데이터가 이제는 판단에 포함될 수 있습니다.
핵심은 스위치 하나를 끄는 것이 아니라 출구를 일관되게 맞추는 것
몇 가지 일반적인 방법이 있습니다. 업무상 실시간 통신이 전혀 필요하지 않다면 WebRTC를 비활성화하는 것이 가장 간단합니다. 대신 영상 통화나 온라인 고객 지원 같은 기능도 사용할 수 없게 됩니다.
기능을 유지해야 한다면 WebRTC 계층에서 반환되는 주소를 프록시 출구와 일치시키는 방식이 흔합니다. 더 안정적으로 하려면 STUN 요청도 프록시 채널로 전달해 인터페이스가 로컬 주소를 노출하지 않도록 할 수 있습니다. P2P나 영상 통화가 필요하다면 HTTP 계층만이 아니라 UDP 트래픽 전체가 프록시를 거쳐야 합니다.
자주 하는 실수는 WebRTC만 끄면 환경 전체가 깨끗해진다고 생각하는 것입니다. 중요한 것은 네트워크 출구, DNS 해석, IP 소유와 ASN, 시간대와 언어, 기기 특성이 서로 일관되는 것입니다. 어느 하나라도 맞지 않으면 이상 신호가 남을 수 있으며, WebRTC는 그중에서도 특히 놓치기 쉬운 항목일 뿐입니다.
확인 방법은 간단합니다. 노드를 바꾼 뒤 한 번, 실제 사용에 들어가기 전 한 번 누수 검사를 열어 WebRTC 항목이 프록시 출구, 로컬 주소, 실제 공인 주소 중 무엇을 반환하는지 확인하면 됩니다. 일반적인 IP 조회만으로는 이 항목을 확인할 수 없습니다.
브라우저 엔진 수준의 환경 분리 솔루션은 환경마다 WebRTC 주소 정책을 따로 설정하고 해당 환경의 네트워크 출구와 연결할 수 있습니다. PurpleMark가 제공하는 것도 이런 유형의 기능입니다. 여러 환경이 하나의 출구를 공유하거나 각 환경의 주소 정책이 서로 일관되지 않으면 분리의 의미는 크게 줄어듭니다.
위 내용은 기술 원리에 대한 설명입니다. 관련 도구는 플랫폼 규칙과 현지 법률을 준수하는 범위에서 사용하십시오.
