보안 및 개인정보 보호 · Clash 기술 블로그

Clash에서 실제 IP가 유출될 수 있나요? DNS, WebRTC 및 IPv6 유출 확인 방법

검사 페이지에 로컬 주소나 다른 지역이 표시된다고 해서 반드시 유출은 아닙니다. 아웃바운드 IP, DNS, WebRTC 및 IPv6를 각각 기록하고 실제로 Clash를 우회하는 항목만 수정하세요.

  • DNS 유출
  • WebRTC
  • IPv6
  • 개인정보 보호
이 글의 목차

'유출이 있는가'에 먼저 답하려면 녹색 알림 하나가 아니라 공용 외부 경로를 확인하세요

Clash는 모든 앱, DNS, WebRTC와 IPv6가 같은 외부 경로를 사용한다고 자동으로 보장하지 않습니다. 유출 여부를 판단하려면 프록시를 켜기 전후의 공용 IPv4, IPv6, DNS 서버와 WebRTC 후보를 각각 기록해야 합니다.

192.168.x.x 같은 사설 주소가 보인다고 실제 공용 IP가 노출되었다는 뜻은 아닙니다. 프록시를 켠 뒤에도 로컬 인터넷 제공업체의 공용 주소가 나타나는 경우를 처리해야 합니다.

혼동하지 마세요

검사 항목확인하는 내용비정상으로 판단할 상황
공용 IPv4웹사이트에서 보는 외부 경로프록시를 켠 뒤에도 명확한 로컬 인터넷 제공업체 외부 경로가 표시됨
공용 IPv6IPv6가 같은 인수 방식을 사용하는지 확인IPv4는 노드를 사용하지만 IPv6는 계속 로컬에서 직접 나감
DNS 서버조회 처리 주체 확인구성과 다르며 도메인이 예상 규칙을 우회하게 함
WebRTC 후보 주소브라우저가 실시간 통신용으로 찾은 주소예상과 다른 실제 공용 외부 경로가 나타남. 192.168/10.x 자체는 공용 주소 유출이 아님

직접 연결, 시스템 프록시와 TUN에서 각각 한 번 테스트

검사 페이지 자체는 결론이 아니며 전후 두 결과를 비교해야 의미가 있습니다. 같은 브라우저, 네트워크와 검사 페이지를 사용하고 Clash의 인수 방식만 바꾼 뒤 네 항목의 결과를 나란히 저장하세요.

비교 가능한 테스트

  1. 프록시를 완전히 종료하고 직접 연결 기록

    IPv4, IPv6, DNS와 WebRTC 네 항목을 저장하고 녹색 결과 하나만 캡처하지 않습니다.

  2. 시스템 프록시 켜기

    새 시크릿 창에서 다시 검사해 브라우저 요청의 외부 경로가 바뀌는지 확인합니다.

  3. 필요할 때 TUN 켜기

    같은 네트워크와 노드에서 계속 테스트하며 IPv6와 시스템 프록시를 읽지 않는 앱을 관찰합니다.

  4. 매번 연결 페이지 확인

    검사 도메인이 나타나고 규칙과 외부 경로가 일치해야 결과가 현재 Clash 구성과 관련됩니다.

Chrome의 DNS 결과만 다르면 보안 DNS 확인

Chrome은 '설정 → 개인정보 보호 및 보안 → 보안'에서 보안 DNS를 별도로 켤 수 있습니다. Firefox의 DNS over HTTPS는 개인정보 보호 설정에 있습니다. 브라우저에서 독립 DoH를 켜면 조회가 시스템 DNS를 거치지 않을 수 있고 Clash 시스템 프록시가 이 조회 요청까지 반드시 인수하는 것도 아닙니다.

브라우저 DoH를 잠시 끄고 브라우저를 완전히 종료한 뒤 다시 여세요. DNS 결과가 Clash의 예상 진입점으로 돌아오면 원인이 확인된 것입니다. 이후 브라우저에서 계속 처리하거나 Mihomo에 통합할 수 있습니다. 중요한 점은 세 곳에서 동시에 덮어쓰지 않는 것입니다.

WebRTC에 192.168.x.x가 표시되면 사설 주소인지 먼저 확인

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。

일치하지 않는 항목만 수정하고 네 항목의 지역을 모두 맞추려 하지 마세요

DNS 서버와 외부 노드의 지역이 다르다고 반드시 비정상인 것은 아니며 WebRTC에 사설 주소가 나타나도 유출을 의미하지 않습니다. 특정 항목에서 나타나면 안 되는 공용 외부 경로가 계속 노출되는지 확인한 뒤 해당 항목만 처리하세요.

공용 IPv4가 계속 로컬 외부 경로임

브라우저 요청이 프록시에 들어오지 않으므로 시스템 프록시, 확장 기능 또는 규칙 일치를 확인합니다.

IPv4는 노드이고 IPv6는 로컬 외부 경로임

TUN의 IPv6 경로를 확인하세요. IPv6가 필요하지 않다면 운영체제 방식으로 끄고 비교할 수 있습니다.

DNS만 예상과 다름

브라우저 DoH, 시스템 DNS와 Mihomo DNS 중 무엇이 실제로 처리하는지 확인합니다.

로컬 네트워크 사설 주소만 표시됨

실제 공용 후보가 더 있는지 먼저 확인하고 사설 주소를 바로 유출로 판단하지 마세요.

참고 자료