1. HTTP 출구 IP, WebRTC, DNS는 서로 다른 측정
많은 사용자가 IP 확인 페이지 하나만 보고 「프록시가 안 먹는다」고 결론 내리지만, 페이지마다 측정 방식이 다릅니다. 일반적인 HTTPS 요청으로 보이는 출구는 대개 Clash가 선택한 노드와 잘 맞습니다. 반면 WebRTC는 브라우저가 STUN/TURN을 통해 로컬·공인 인터페이스의 후보 주소를 직접 노출할 수 있어, 프록시 HTTP 경로와 무관하게 집 IP가 뜨기도 합니다.
DNS 유출은 또 다른 축입니다. 브라우저가 시스템 DNS나 내장 DoH로 질의를 보내면, 그 질의가 Clash의 dns: 블록을 거치지 않을 수 있습니다. 그 결과 어느 DNS가 응답했는지만으로도 거주지나 통신사 단서가 드러나는 테스트가 있습니다. 세 경로를 동시에 의심하지 말고, 어떤 칼럼이 로컬인지 먼저 구분하는 것이 중요합니다.
| 구분 | 사용자에게 보이는 증상 |
|---|---|
| HTTP/HTTPS 출구 | 검색·영상·대부분 웹이 노드 국가로 보임. IP 테스트의 「브라우저」 행이 프록시와 일치 |
| WebRTC | 같은 페이지의 「WebRTC」 또는 「로컬 네트워크」 줄에 공인 IP·사설 대역이 그대로 표시 |
| DNS | 「DNS 서버 위치」「DNS 유출」 항목이 ISP 또는 집 근처로 찍힘. DoH를 켠 브라우저와 Clash 설정이 엇갈림 |
검색·AI 사이트 분류를 다룬 글들이 도메인 규칙에 초점을 맞춘다면, 본문은 브라우저 스택과 이름 해석에 더 가깝습니다. 둘 다 결국 어느 소켓이 어떤 정책을 타는가라는 같은 질문으로 이어집니다.
2. WebRTC: 브라우저에서 먼저 막기
WebRTC는 화상·음성·일부 P2P 데모에서 쓰이며, ICE 수집 과정에서 NAT 뒤 실제 주소가 테스트 서버에 전달될 수 있습니다. Clash가 HTTP를 잘 터널링해도 UDP 후보가 직접 나가면 IP 확인 페이지는 「프록시를 켰는데도 실제 주소」처럼 보입니다.
실무에서 할 수 있는 조치
- Chromium 계열: 실험적 플래그나 확장 프로그램으로 WebRTC 후보 수집을 제한하거나, 신뢰할 수 있는 확장의 「WebRTC 누수 방지」 옵션을 검토합니다. 기업 보안 브라우저는 정책으로 막히는 경우가 많습니다.
- Firefox:
about:config에서 미디어 피어 연결 관련 설정을 조정하거나, 네트워크 설정에서 프록시 뒤에서의 동작을 제한하는 프리셋을 사용합니다. 버전마다 키 이름이 바뀌므로 최신 도움말을 확인하세요. - TUN 모드: 브라우저 UDP까지 커널 라우팅으로 끌어들이면 후보 수집 경로가 바뀔 수 있습니다. 다만 이는 TUN·방화벽·라우팅과 함께 봐야 하고, 모든 환경에서 동일하게 동작하지는 않습니다.
3. DNS: Clash와 브라우저 DoH 맞추기
DNS 유출은 종종 브라우저가 Clash를 우회해 공용 DoH를 쓰거나, 반대로 OS가 여전히 ISP DNS를 쓰는 상황에서 발생합니다. Clash 쪽에서는 dns.enable, enhanced-mode, nameserver, fallback 등이 맞물리고, 브라우저 쪽에서는 보안 DNS 스위치가 별도입니다.
정렬을 위해 확인할 것
- 클라이언트 로그에서 실제 질의가 어떤 업스트림으로 나갔는지,
fake-ip인지redir-host인지 확인합니다. - 브라우저 설정에서 DoH/보안 DNS가 켜져 있다면, Clash의 DNS 정책과 같은 출구를 쓰도록 맞추거나, 테스트 동안만 끄고 비교합니다.
- Windows에서는 어댑터 우선순위와 스마트 멀티홈이 DNS 선택을 흔들 수 있습니다. WSL2·호스트 DNS 글에서 다룬 것처럼, 「어느 스택이 질의를 잡는지」를 먼저 고정하는 편이 안전합니다.
원격 규칙으로 해외 사이트만 노드로 보내도, DNS만 국내 ISP에 남아 있으면 일부 테스트는 여전히 「국내 DNS」로 읽힙니다. 이는 연결 자체가 실패한다는 뜻이 아니라, 이름 해석 경로가 분리되어 있다는 신호로 이해하면 됩니다.
4. fake-ip·시스템 DNS와의 정렬
fake-ip 모드는 도메인에 가상 주소를 돌려 주어 규칙 매칭을 빠르게 하지만, IP 테스트 사이트가 보여 주는 숫자와 실제 출구가 헷갈릴 수 있습니다. 「내 공인 IP」를 묻는 페이지는 fake-ip 대역이 아니라 측정 서버가 본 소스 주소를 보여 주는 경우가 많습니다. 반대로 DNS 유출 테스트는 질의 경로를 보므로 fake-ip와 DNS 블록을 함께 읽는 것이 좋습니다.
점검 순서로는 (1) enhanced-mode와 fake-ip-range 확인, (2) 시스템이 Clash가 안내하는 로컬 DNS(예: 127.0.0.1 또는 클라이언트가 지정한 포트)를 쓰는지 확인, (3) 필요 시 대조 실험으로 redir-host에 잠시 바꿔 같은 테스트를 반복해 보면, 문제가 이름 해석 층에 있는지 가늠하기 쉽습니다.
5. 규칙 분류와 TUN이 의미하는 것
프록시 분류 규칙이 정교해도, WebRTC·DNS는 규칙 엔진이 보기 전에 브라우저·OS가 결정하는 경우가 있습니다. 그래서 「유튜브는 잘 되는데 IP 테스트만 이상하다」는 패턴이 자주 나옵니다. 이때 노드를 바꾸기보다 어느 프로토콜 줄이 로컬로 새는지를 로그와 테스트 페이지의 항목별 결과로 나누는 것이 빠릅니다.
TUN을 켜면 전역 캡처에 가까워져 UDP·DNS가 같은 스택을 탈 가능성이 높아지지만, 다른 VPN·보안 소프트웨어와 가상 어댑터 우선순위가 충돌하면 오히려 예외가 늘 수 있습니다. 기업망이나 캠퍼스에서는 관리자 정책으로 DoH·UDP가 막혀 측정 결과가 일관되지 않을 수도 있습니다.
6. 한 장으로 보는 점검 순서
- IP 테스트 페이지에서 HTTP 출구, WebRTC, DNS 행을 각각 읽고, 어떤 줄이 로컬인지 표시합니다.
- WebRTC 줄만 문제면 브라우저 설정·확장·TUN 순으로 좁힙니다.
- DNS 줄만 문제면 브라우저 DoH 끄기/맞추기와 Clash DNS 블록을 동시에 봅니다.
- 셋 다 엇갈리면 다른 VPN·보안 제품을 잠시 끄고 재측정합니다.
- 설정을 고칠 때마다 한 가지 변수만 바꿔 재현 가능한 메모를 남깁니다.
이 순서는 TLS 오류나 구독 실패를 다룬 다른 트러블슈팅 글과 나란히 두고 쓰면 좋습니다. 증상이 다르면 원인 층도 다릅니다.
7. 마무리
Clash를 켠 상태에서 브라우저 IP 검사가 실제 주소를 보여 준다고 해서 곧바로 노드가 잘못됐다고 보기 어렵습니다. WebRTC와 DNS는 HTTP 프록시와 다른 경로로 움직일 수 있으므로, 측정 항목을 나눠 보고 브라우저·OS·Clash 설정을 한 층씩 맞추는 것이 핵심입니다. 규칙 분류와 노드 선택은 그 다음 단계에서 다듬어도 늦지 않습니다.
문서화된 클라이언트와 최신 코어를 쓰면 DNS·TUN·시스템 프록시 옵션을 일관되게 맞추기 쉽습니다. 기본 개념은 사이트 문서에서 확인한 뒤, 이 글의 순서대로 WebRTC와 DNS만 따로 점검해 보세요.
커뮤니티에서 검증된 규칙 세트와 투명한 업데이트를 갖춘 클라이언트를 쓰면, 유사 도구 대비 DNS·모드·규칙을 한곳에서 다루기 쉽고 장애 때 원인도 좁히기 좋습니다. 일상 브라우징과 테스트 결과의 괴리를 줄이려면 층을 나눠 생각하는 습관이 가장 큰 도움이 됩니다.