이 글의 목차
검사 페이지에 집 안의 사설 주소가 보이거나 노드 이름과 다른 지역이 표시되면 유출을 의심하기 쉽습니다. 그 결과가 웹사이트에 보이는 외부 주소인지, 이름 확인 서버인지, 브라우저가 찾은 통신 주소인지 구분한 뒤 직접 연결 결과와 비교하세요. 프록시 우회가 확인된 요청만 수정하고 회의와 일반 인터넷 연결도 정상인지 점검해야 합니다.
공인 IPv4, IPv6, DNS와 WebRTC는 각각 무엇을 보여 줄까요?
같은 브라우저와 네트워크에서 IPv4, IPv6, DNS, WebRTC 결과를 각각 기록하고 이용 중인 통신사의 공인 주소를 표시하세요. WebRTC는 브라우저 음성 및 영상 통신에 쓰이며, 여기서 발견한 주소가 웹사이트에 보이는 출구 주소와 같지는 않습니다. Clash도 이 요청들을 자동으로 같은 출구로 보내지는 않습니다.
혼동하지 마세요
| 검사 항목 | 확인하는 내용 | 확인이 필요한 결과 | 검사 페이지 |
|---|---|---|---|
| 공용 IPv4 | 웹사이트에서 보는 외부 경로 | 프록시를 사용해야 하는 요청에 여전히 현재 통신사의 공인 주소가 표시됨 | BrowserLeaks IPv4 / IPv6 |
| 공용 IPv6 | IPv6도 같은 방식으로 트래픽이 처리되는지 확인 | IPv4는 노드를 사용하지만 IPv6는 계속 로컬에서 직접 나감 | BrowserLeaks IPv4 / IPv6 |
| DNS 서버 | 조회 처리 주체 확인 | 구성과 다르며 도메인이 예상 규칙을 우회하게 함 | BrowserLeaks DNS |
| WebRTC 후보 주소 | 브라우저가 실시간 통신용으로 찾은 주소 | 예상과 다른 실제 공용 외부 경로가 나타남. 192.168/10.x 자체는 공용 주소 유출이 아님 | BrowserLeaks WebRTC |
표의 IPv4 / IPv6 또는 WebRTC 링크를 여세요. Your Remote IP에서 IPv4 Address와 IPv6 Address를, Your WebRTC IP에서 Local IP Address와 Public IP Address를 읽으세요. 공인 주소는 직접 연결했을 때의 기록과 비교하고 사설 주소는 표의 설명에 따라 판단하세요.
DNS 링크를 연 뒤 Run DNS Leak Test를 눌러 Your DNS Servers 목록을 기록하고 설정 및 직접 연결 결과와 비교하세요. JavaScript Disabled가 표시되거나 결과가 비어 있거나 테스트가 끝나지 않았다면 누출이 없다고 판단할 수 없습니다.
직접 연결, 시스템 프록시와 TUN에서 각각 한 번 테스트
검사 페이지 자체는 결론이 아니며 전후 두 결과를 비교해야 의미가 있습니다. 같은 브라우저, 네트워크와 검사 페이지를 사용하고 Clash가 트래픽을 처리하는 방식만 바꾼 뒤 네 항목의 결과를 나란히 저장하세요.
비교 가능한 테스트
프록시를 완전히 종료하고 직접 연결 기록
IPv4, IPv6, DNS와 WebRTC 네 항목을 저장하고 녹색 결과 하나만 캡처하지 않습니다.
시스템 프록시 켜기
새 시크릿 창에서 다시 검사해 브라우저 요청의 외부 경로가 바뀌는지 확인합니다.
필요할 때 TUN 켜기
같은 네트워크와 노드에서 계속 테스트하며 IPv6와 시스템 프록시를 읽지 않는 앱을 관찰합니다.
매번 연결 페이지 확인
검사 도메인이 나타나고 규칙과 외부 경로가 일치해야 결과가 현재 Clash 구성과 관련됩니다.
Chrome의 DNS 결과만 다르면 보안 DNS 확인
Chrome은 '설정 → 개인정보 보호 및 보안 → 보안'에서 보안 DNS를 별도로 켤 수 있습니다. Firefox의 DNS over HTTPS는 개인정보 보호 설정에 있습니다. 브라우저에서 독립 DoH를 켜면 조회가 시스템 DNS를 거치지 않을 수 있고 Clash 시스템 프록시가 이 조회 요청까지 반드시 처리하는 것도 아닙니다.
브라우저 DoH를 잠시 끄고 완전히 종료한 뒤 다시 여세요. DNS 결과가 Clash에서 예상한 서버로 돌아오면 브라우저의 이름 해석 설정이 이번 결과에 영향을 준 것입니다. 이후 브라우저가 계속 처리하게 하거나 Mihomo에 맡길 수 있으며 브라우저·시스템·코어의 해석 설정을 동시에 바꾸지 마세요.
WebRTC의 사설 주소 표시와 공인 주소 노출은 어떻게 다를까요?
WebRTC는 음성, 영상과 P2P 통신을 위해 후보 주소를 수집합니다. 최신 브라우저는 로컬 주소를 mDNS 이름으로 숨기거나 사설 대역을 표시할 수 있습니다. 이 정보는 로컬 네트워크 환경을 보여 주지만 인터넷에서 컴퓨터로 직접 라우팅할 수 있는 주소는 아닙니다.
프록시를 사용해야 하는 요청이 상대방에게 통신사의 공인 IPv4 또는 IPv6를 계속 노출한다면 조치가 필요합니다. WebRTC를 완전히 끄면 웹 회의와 화면 공유가 작동하지 않습니다. 브라우저의 주소 제한 옵션을 우선 사용하고 Zoom, Meet, Slack Huddle에서 기능을 다시 확인하세요.
IPv4는 노드를 거치고 IPv6는 직접 나간다면 트래픽 처리 설정 확인하기
시스템 프록시는 대개 앱이 명시적으로 프록시에 넘긴 요청만 처리하며 모든 IPv6 연결을 처리한다고 보장하지 않습니다. TUN의 IPv6 처리도 클라이언트 버전, 경로와 구성에 따라 달라집니다. 업무에 IPv6가 필요한지 먼저 확인하세요. 처리할 수 없다면 규칙 끝에 REJECT를 무작정 추가하는 것보다 IPv6를 잠시 끄고 비교하는 편이 원인을 더 잘 보여 줍니다.
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
# 若明确需要 IPv6，应改为让当前 TUN 与规则完整接管，
# 而不是长期依赖 ipv6: false。공인 IP, DNS, 사설 주소는 각각 어떻게 판단하고 처리하나요?
공용 IPv4가 계속 로컬 외부 경로임
브라우저 요청이 예상한 프록시 노드를 거치지 않았습니다. 시스템 프록시, 확장 기능과 적용 규칙을 확인하세요.
IPv4는 노드이고 IPv6는 로컬 외부 경로임
TUN의 IPv6 경로를 확인하세요. IPv6가 필요하지 않다면 운영체제 방식으로 끄고 비교할 수 있습니다.
DNS만 예상과 다름
브라우저 DoH, 시스템 DNS와 Mihomo DNS 중 무엇이 실제로 처리하는지 확인합니다.
로컬 네트워크 사설 주소만 표시됨
실제 공용 후보가 더 있는지 먼저 확인하고 사설 주소를 바로 유출로 판단하지 마세요.