증상: 브라우저만 유난히 로컬 IP·로컬 대역이 보일 때

Clash를 켠 뒤 일반 웹사이트는 기대한 출구를 보이는데, 「내 IP」·WebRTC 전용 검사 페이지에서만 LAN 대역(예: 192.168.x.x)이나 ISP 공인 IPv4가 그대로 노출되는 패턴이 흔합니다. 동일 PC에서 터미널로 curl한 결과와 브라우저 탭의 결과가 다르면, HTTP 프록시만 타는 트래픽과 UDP 기반 WebRTC가 갈라진 상태로 이해하는 편이 빠릅니다. 반대로 모든 앱에서 동일하게 집 주소가 보인다면 IPv6 이중 스택·DNS 쪽을 우선 점검하는 것이 순서에 맞습니다.

원인을 한 가지로 몰지 말고, (1) 브라우저 쪽 WebRTC 유출, (2) Clash 외 DNS·IPv6 경로, (3) 정책 그룹·MATCH 위치 같은 분류 이슈를 나눠 보세요. 세 번째는 규칙 분류 모범 사례에서 다룬 위→아래 순서와 도메인 규칙만으로는 잡히지 않는 IP 목적지 트래픽을 함께 떠올리면 정리가 쉬워집니다.

ℹ 이 글의 초점: 브라우저에서 WebRTC를 제한하거나 끄고, 공개 유출 테스트로 다시 확인한 다음 Clash 연결 기록으로 브라우저 프록시·TUN 전환을 대조하는 절차입니다. DNS·Fake-IP 세부 스키마는 Meta DNS 가이드와 병행하면 혼선이 줄어듭니다.

WebRTC가 프록시 밖으로 새는 이유(STUN·ICE)

WebRTC는 음성·화상 외에도 데이터 채널에 쓰이며, ICE가 후보 주소를 모읍니다. 브라우저가 STUN 응답으로 받은 서버 리플렉티브 주소가 곧 사용자의 공인 출구와 맞닿을 수 있고, 호스트 후보는 사설 대역을 그대로 적을 수 있습니다. 일반적인 HTTP 프록시는 TLS 웹만 붙잡고, 이 UDP·멀티홈 협상까지 항상 동일하게 끌고 가지는 않습니다. 그래서 「시스템이나 TUN으로 막았는데도」 특정 스크립트가 올라온 탭에서만 숫자가 튀는 현상이 나옵니다.

완화 전략은 두 갈래입니다. 브라우저 안에서 WebRTC가 로컬/공인 후보를 덜 노출하게 조정하거나, OS TUN으로 UDP까지 같은 인터페이스에 올려 후보 수집 자체를 기대 경로에 맞추는 것입니다. 후자는 TUN 심화에서 충돌·스택 선택과 함께 읽는 것이 좋습니다.

TUN·시스템 프록시·브라우저 전용 차이

시스템 프록시만 켠 상태에서 브라우저가 시스템 설정을 따르면 HTTP(S)는 Clash 쪽으로 가지만, WebRTC UDP가 OS 라우팅상 우회하면 여전히 「홈 공인 IP」가 테스트 페이지에 찍힐 수 있습니다. TUN은 인터페이스 레벨에서 트래픽을 더 넓게 가져오므로, 동일 프로필에서 WebRTC 숫자가 줄어드는지 비교 실험을 해볼 가치가 있습니다. 다만 다른 VPN·기업 에이전트와 겹치면 라우팅 표가 꼬이므로, 종료 시 복구까지는 프록시·TUN 잔류 정리 글의 순서를 먼저 익혀 두면 안전합니다.

「브라우저만 프록시」로 쓰는 확장·프로필이라면, 확장이 붙잡는 범위 밖으로 나가는 WebRTC가 남을 수 있습니다. 어떤 클라이언트가 시스템/TUN/확장 중 무엇을 따르는지에 따라 증상이 달라지므로, 진단 화면이 편한 GUI를 고르는 것도 도움이 됩니다. Clash 클라이언트 선택 글의 체크리스트를 참고하세요.

Chrome·Edge에서 WebRTC 최소 제한

크로미엄 계열은 버전마다 실험 플래그 이름이 바뀔 수 있어, 검색으로 webrtc·泄露 관련 플래그를 찾아 보거나, 정책 템플릿을 쓰는 조직 PC라면 관리자 정책으로 막는 편이 일관됩니다. 개인 사용자는 (1) 신뢰할 수 있는 확장으로 후보 노출을 줄이거나, (2) 시크릿 창에서만 테스트해 캐시·앱 영향을 분리하는 식으로 변수를 줄입니다. 플래그는 chrome://flags / edge://flags에서 조심스럽게 바꾸고, 바꾼 직후 webrtc 검사 사이트에서 한 번 더 확인하세요.

브라우저 주소창 플래그는 기기·채널별로 다릅니다. 기록해 둔 플래그 값은 브라우저 업데이트 후 다시 확인하세요.

Firefox about:config로 끄기

Firefox는 about:config에서 media.peerconnection.enabled를 false로 두면 WebRTC 자체를 끌 수 있어, 「가장 확실한 최소 검증」에 쓰기 좋습니다. 대신 화상 회의·일부 협업 도구가 동작하지 않을 수 있으니, 확인 목적의 프로필을 따로 두거나 테스트 후 원래 값으로 되돌리세요. 관련 키워드로 media.peerconnection.ice. 접두사 항목을 함께 살펴보면 후보 수집을 덜 공격적으로 만드는 노브가 있습니다(버전별로 존재 여부가 다름).

Firefox — illustrative preference key 
# about:config
media.peerconnection.enabled = false

Safari·모바일에서의 현실적 한계

Safari와 iOS/Android WebView는 사용자가 데스크톱만큼 세밀하게 WebRTC를 끄기 어렵습니다. iOS는 프로필·시스템 VPN/TUN 조합과 앱별 정책에 더 민감합니다. 모바일에서 반복적으로 주소가 새면, 데스크톱에서 먼저 동일 계정·동일 규칙으로 재현되는지 나누고, 셀룰러와 Wi-Fi를 바꿔 보아 어느 인터페이스 후보가 찍히는지 비교하는 편이 낫습니다.

DNS·IPv6 유출과 헷갈리지 않기

DNS 요청이 구독 밖 리졸버로 새면 「속도는 나오는데 지(region)만 이상하다」 식으로 읽히고, IPv6 이중 스택에서는 측정 페이지 한쪽만 통신사 IPv6를 보여 줄 수 있습니다. 이 패턴은 IPv6·DNS 유출 가이드에서 다룬 커널 ipv6·DNS·dns-hijack 정렬과 맞물립니다. WebRTC 문제인지 분리하려면 동일 시점에 DNS/IPv6 검사와 WebRTC 전용 검사를 번갈아 실행해, 어떤 탭에서만 달라지는지 표로 적어 보세요.

Clash로 분류·연결 로그 검증하기

브라우저 설정을 바꾼 뒤에는 Clash 쪽에서도 분류 검증을 해 두면 이후에 같은 의문이 들 때 빠르게 답을 찾을 수 있습니다. (1) 고정한 노드·정책 그룹으로 IP 확인 사이트에 접속했을 때 로그에 찍히는 정책 이름이 기대와 같은지, (2) WebRTC 테스트를 켠 탭에서 UDP가 어떤 인터페이스로 찍히는지, (3) MATCH 이전에 특정 IP 대역이 DIRECT로 빠지지 않는지를 규칙 순서와 함께 확인합니다. TLS 단계에서만 실패하는지는 연결 로그·TLS 글과 연결해 읽을 수 있습니다.

공개 유출 테스트 절차

신뢰할 수 있는 공개 페이지에서 WebRTC 전용 항목을 연 뒤, (가) 브라우저 변경 전, (나) WebRTC 관련 설정 변경 직후, (다) Clash TUN 전환 직후를 같은 순서로 기록합니다. 시크릿 창, 확장 끄기, 하드웨어 가속 끄기까지 단계를 한 겹씩 줄이면 어느 변수에서 숫자가 안정되는지 보입니다. 외부 링크는 신뢰도를 스스로 판단해 주세요.

⚠ 준수: 소재지 법령·고용주·학교·통신사 약관과 각 서비스 이용약관을 지키세요. 이 글은 허용된 네트워크에서 브라우저·클라이언트 설정을 점검하는 방법을 기술적으로 설명하며, 무단 침해·약관 위반을 조장하지 않습니다.

일부 환경에서는 VPN·프록시 사용 자체가 정책 위반이거나 계약 위반이 될 수 있습니다. 네트워크를 바꾸기 전에 권한 있는 담당자에게 확인하는 것이 안전합니다.

맺음말

Clash와 브라우저 프록시를 켠 상태에서도 측정 탭에 실제 IP가 보이는 현상은, WebRTC가 HTTP 경로와 분리된 채 UDP 후보를 드러내는 전형적인 패턴입니다. 브라우저에서 후보 노출을 줄이거나 WebRTC를 끄고, 필요하면 TUN으로 경로를 넓힌 뒤 같은 검사 페이지에서 숫자를 다시 맞추면, 「프록시가 고장 난 것」이 아니라 어느 계층의 트래픽이었는지 분명해집니다.

Meta DNS·규칙·로그를 한 프로필에 남겨 두면 같은 증상이 재발했을 때 비교가 쉽습니다. 상용 VPN 한 앱에만 맡기기보다 Clash 쪽이 분류 검증에 유리한 경우가 많으니, 유출 테스트와 연결 기록을 한 세트로 저장해 두세요.

→ Clash를 무료로 다운로드해 프로필과 로그를 정리한 뒤, WebRTC 검사와 노드 출구를 같은 절차로 다시 확인해 보세요.