1. 증상: 앱은 되는데 브라우저만 “직접 연결”처럼 보일 때
대표적인 그림은 다음과 같습니다. Clash Verge Rev나 다른 GUI에서 시스템 프록시가 켜져 있고, 일부 앱(메신저·IDE 등)은 기대한 노드를 타는데, Chrome·Edge로 연 IP 확인 사이트를 열었을 때만 국내 회선·상업용 DNS 응답이 그대로 나온다는 느낌이 드는 경우입니다. 이 때 사용자는 “프록시가 안 먹는다”고 표현하지만, 실제로는 HTTP 트래픽이 프록시를 타기 전에 DNS 해석만 브라우저 안쪽의 DoH(HTTPS로 DNS)로 새어 나가거나, Windows가 강제하는 DNS 경로가 Clash 쪽 redir·fake-ip 흐름과 맞지 않는 경우가 많습니다. 구독이나 TLS 자체는 정상인데 “웹만 이상”하다면, 구독 갱신·TLS 로그 글에서 다루는 쪽보다 DNS·보안 DNS 쪽을 먼저 의심하는 편이 빠릅니다.
또 한 가지, 확장 프로그램이 자체 DNS·광고 차단·VPN을 끼워 넣으면 동일한 증상이 납니다. 본문에서는 OS와 브라우저 기본 설정 위주로 설명하되, 문제가 난 프로필에서 시크릿 창으로 먼저 재현해 보는 습관을 권합니다.
2. 보안 DNS(DoH)가 Clash·OS와 왜 갈라지는가
보안 DNS는 질의를 HTTPS로 Cloudflare·Google Public DNS 같은 리졸버에 직접 보내는 경로입니다. Chromium 계열(Chrome, Edge)은 이를 “사용자 보호” 목적으로 켜 두는 경우가 많고, Windows 11에도 DNS over HTTPS를 어댑터 단에서 켤 수 있는 흐름이 추가되어 있습니다. 반면 Clash(mihomo)는 보통 127.0.0.1 쪽 로컬 DNS나 TUN·fake-ip를 전제로 규칙을 매칭합니다. 이 둘이 동시에 활성화되면 “도메인은 A 경로로 해석, 실제 TCP는 B 경로” 같은 불일치가 생기고, 겉으로는 시스템 프록시를 켰는데도 특정 사이트만 직접 연결에 가깝게 보입니다.
정리하면, 프록시 미적용이 아니라 DNS·TLS 연결의 출발점이 브라우저·OS·코어 셋 중 어디에 묶이느냐의 문제에 가깝습니다. 먼저 보안 DNS를 끄고 한 축으로 맞춘 뒤, 필요하면 TUN·스니퍼·규칙을 논의하는 순서가 디버깅에 유리합니다.
3. Windows에서 먼저 볼 OS 수준 DNS
설정 > 네트워크 및 인터넷에서 사용 중인 인터페이스(이더넷·Wi-Fi)의 속성을 열고, DNS 서버 지정이 자동인지 수동인지 확인합니다. 라우터가 ISP DNS를 강제하면 Clash 쪽 DNS 핸들러가 기대와 다르게 보일 수 있으니, 테스트 단계에서는 “DHCP/자동”과 “127.0.0.1 우선” 같은 구성이 섞이지 않았는지 봅니다. Windows 11 최신 빌드에서는 같은 화면이나 고급 네트워크 설정에 DNS over HTTPS 토글이 별도로 있을 수 있는데, 여기가 켜져 있으면 Clash TUN이 켜진 상태에서도 OS가 DoH로 빠지려는 흐름과 충돌하는 사례가 보고됩니다. 우선 끄거나 “암호화 기본 설정 사용”이 아닌 해제로 맞춰 보세요.
회사 PC는 MDM·보안 에이전트가 DNS를 고정하거나, 분할 터널 VPN과 Clash를 동시에 켠 상태일 수 있습니다. 그런 환경에서는 이 글의 “끄기”만으로 해결되지 않을 수 있으니, IT 정책과 다른 VPN의 공존 여부를 먼저 확인하는 편이 안전합니다.
4. Google Chrome: 보안 DNS 끄기
Chrome에서 설정 > 개인 정보 보호 및 보안 > 보안으로 이동해 고급 섹션의 보안 DNS 사용을 찾습니다. 기본값은 “현재 서비스 공급자”나 자동이지만, 한 번 Cloudflare 등으로 지정한 적이 있으면 그대로 DoH가 유지됩니다. 여기를 사용 안 함으로 바꾸면 질의가 OS의 일반 DNS 스택 쪽으로 돌아가, Clash가 53번을 가로채거나 fake-ip를 줄 때 훨씬 일관되게 맞습니다. UI 빌드에 따라 문구는 “보안 DNS” 대신 DNS 보안 등으로 보일 수 있으나, Chromium 기준 위치는 동일한 편입니다.
조직에서 정책으로 Chrome을 잠가 두었다면 chrome://policy에서 DNS 관련 항목이 강제되는지 확인할 수 있습니다. 잠긴 항목은 로컬 설정만으로는 풀리지 않으니, 이 경우엔 Edge와는 별개로 관리자와 조율이 필요합니다.
5. Microsoft Edge: 보안 DNS·프로필
Edge는 설정 > 개인정보, 검색 및 서비스 > 보안에 Microsoft Edge 보안 DNS 사용 항목이 있습니다. 사용자 지정으로 공급자를 고정해 두었거나, 자동이지만 내부적으로 DoH로 붙는 경우 Clash 시스템 프록시와 해석 경로가 어긋날 수 있습니다. 테스트 시에는 끄기에 가깝게 맞추고, 작업·개인 프로필이 나뉘어 있다면 각 프로필마다 동일하게 적용됐는지 확인하세요. Edge는 Windows과 결합이 깊어, Copilot·Microsoft 계 엔드포인트를 따로 쓰는 흐름이 있을 때도 같은 메뉴를 같이 봅니다.
InPrivate 창은 확장·캐시의 영향을 줄이는 데 유효해, 보안 DNS를 끈 뒤 InPrivate로만 재현이 사라지는지 비교해 보는 것이 좋습니다.
6. 시스템 프록시·Clash 연결 포트 다시 맞추기
Windows의 설정 > 네트워크 및 인터넷 > 프록시에서, 자동으로 설정 검색·스크립트·수동 프록시가 Clash가 켠 값과 맞는지 봅니다. 다른 앱이 PAC을 덮어쓰거나, 예전 회사용 VPN이 남은 프록시 자동 구성 URL이 있으면 Chrome만 “이상한 자동 구성”을 탈 수 있습니다. Clash Verge Rev에서 시스템 프록시 토글을 껐다 켜 mixed-port(또는 HTTP 포트)가 Windows에 제대로 기입되는지, 방화벽이 해당 포트의 루프백·로컬 연결을 막지 않는지도 같이 봅니다. 첫 설치 흐름이 필요하면 앞서 인용한 Verge Rev 가이드의 “시스템 프록시” 절을 그대로 밟는 것이 빠릅니다.
포트는 프로필마다 다를 수 있으니, GUI에 표시된 수치와 Windows 프록시 대화상자의 주소:포트가 한 글자도 어긋나지 않았는지 확인하세요. 프록시 미적용의 상당수는 “DNS만 고쳤는데 잘 된다”는 패턴이 나오므로, 2~4절과 병행하는 것이 중요합니다.
7. mihomo DNS·fake-ip·DoH가 겹칠 때
코어 DNS 섹션에서 enhanced-mode가 fake-ip이면, 로컬에 가짜 IP가 쌓이고 스니퍼·규칙이 그 IP를 본명으로 복원해야 합니다. 이 상태에서 브라우저 DoH가 먼저 “진짜” IP를 직접 가져가 버리면, 귀하가 기대한 PROXY 그룹이 아닌 DIRECT·국내로 해석되는 것처럼 느껴질 수 있습니다. 보안 DNS를 끈 뒤에도 남으면, GUI에서 DNS·스니퍼 로그를 켜고 질의가 127.0.0.1 쪽 mihomo로 들어오는지 봅니다. 프로필에 doh만 과하게 박혀 있고, 그 DoH가 해외·차단망에 막혀 있으면 “전부 느리다”로 보이기도 하니, TLS·DNS 로그 글의 단계 점검을 짧게 되짚으면 힌트가 잡힙니다.
코어가 제공하는 클라이언트 측 DoH와 Chrome 내장 DoH는 겉으론 비슷해 보여도 완전히 같은 경로가 아닙니다. 한쪽만 끄는 것이 아니라, “브라우저 DoH = 끔, Windows 어댑터 DoH = 끔, Clash는 로컬 DNS 한 축”처럼 역할을 정리해 두는 편이 덜 꼬입니다.
# PowerShell: system proxy is ignored by this tool; use for OS routing sanity only Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway } | Format-List InterfaceAlias,DNSServer
8. 짧은 검증 절차
절차는 단순합니다. (1) Windows·Chrome·Edge의 보안 DNS를 모두 끈 뒤 창을 완전히 닫고 다시 엽니다. (2) Clash에서 시스템 프록시를 한 번 끄고 켜 mixed-port를 재적용합니다. (3) 같은 노드·같은 규칙 모드에서 IP 확인·DNS 누수 사이트를 열어, IPv4/IPv6·DNS 서버가 기대한 출구에 붙는지 봅니다. (4) 여기까지 됐다면, 복잡한 도메인 규칙이나 GEOIP는 나중에 미세 조정해도 됩니다. 지역·스트리밍이 목적이면 fake-ip·지역 글과 흐름이 맞닿습니다.
한 번에 여러 항목을 바꾸지 말고, “보안 DNS만 먼저”와 “시스템 프록시만 먼저”를 나눠서 실험하면 원인이 남는 위치를 빨리 짚을 수 있습니다. 문서·커뮤니티에서 자주 쓰는 Clash·Windows 키워드 조합으로 검색해도, 결국 DoH·시스템 프록시·fake-ip 셋의 정렬이 반복됩니다.
9. 그래도 남으면: TUN을 검토하는 기준
시스템 프록시를 존중하지 않는 UWP·일부 런처·게임은 TUN 쪽이 맞는 경우가 많습니다. TUN·UWP·루프백 글의 루프백 면책과, TUN 모드 설명을 함께 읽으면 “왜 DNS만 끄면 잠깐 괜찮은데, 특정 앱만 계속 이상한지”가 분리됩니다. 반대로, 본문에서 정리한 것처럼 브라우저만 이상하다면 TUN 이전에 보안 DNS·Windows DNS·Clash DNS의 삼자 정렬을 끝내는 쪽이 대부분의 사례에서 비용이 적습니다. 이중 스택·IPv6이 켜진 PC에서는 AAAA·누수 점검을 추가로 잊지 마세요.
마지막으로, 상용 VPN과 Clash의 TUN·필터 드라이버는 동시에 켜면 충돌이 납니다. 진단용으로는 한 개만 전역 켜기를 권합니다.
이상으로, Clash·시스템 프록시는 정상인데 Chrome·Edge에서만 직접 연결·DNS 이상이 느껴질 때, Windows 10/11과 브라우저의 보안 DNS·DoH를 먼저 끄고 mihomo 측 fake-ip·로컬 DNS 흐름과 맞추는 절차를 정리했습니다. 같은 증상도 “프록시가 죽었다”로 오해되기 쉬운데, 실제로는 DNS 축이 갈라진 경우가 훨씬 많으니, 단계를 지키면 재현·해결이 쉬워집니다. 구독·TLS 쪽이 의심되면 앞서 링크한 Windows 전용 로그 글을, 전체 시스템 프록시·TUN 흐름은 Verge Rev 가이드와 이어 읽는 구성이 좋습니다.
상용 VPN에 비해 Clash·mihomo 계열은 규칙과 로그로 원인을 쪼개기 쉬워, DNS만 엇나가도 “전부가 아니고 일부만” 티가 나는 환경에서 특히 유리합니다. Windows에서 브라우저 보안 DNS를 끄는 것은 그중 가장 싸고 빠른 첫 수입니다.
→ Clash를 무료로 내려받은 뒤 최신 클라이언트로 시스템 프록시·DNS를 맞추고, 위 순서로 Chrome·Edge의 DoH를 정리해 보세요.
관련 읽기 · 같은 주제
주제 관련도가 높은 읽을거리 — 같은 카테고리의 Clash 실전 가이드.
이중 스택 네트워크에서 Clash TUN을 켜도 IPv6·DNS가 어긋날 때: 누수를 막고 mihomo 규칙을 교정하는 실측 (2026)
TUN을 켰는데도 실제 IP 노출·지역 판정 불일치가 날 때 이중 스택·AAAA·DNS 누수를 OS 제약과 mihomo DNS·fake-ip·GEOIP·Sniffer 교차 검증으로 좁히고, Windows·macOS·Verge Rev 글과 역할을 나눠 점검 순서를 정리했습니다.
자세히 보기Windows에서 npm·pnpm이 Clash를 타게: HTTP_PROXY·NO_PROXY와 레지스트리 분기 규칙 실측 (2026)
PowerShell·CMD 세션에서 mixed-port에 HTTP_PROXY·HTTPS_PROXY를 맞추고 NO_PROXY로 국내 registry 미러·localhost를 직접 연결로 빼며, Clash rules로 npmjs.org 등 해외 축만 프록시 그룹으로 보내 타임아웃·레지스트리…
자세히 보기Debian 12에 Clash Meta 설치: 바이너리·systemd 자동 기동·mixed-port 첫 설정 (2026)
bookworm·apt·경로와 방화벽(nft) 전제에 맞춰 mihomo 리눅스 바이너리, /etc/mihomo, systemd enable·now, journalctl, mixed-port·external-controller, 구독을 한 흐름으로 잡는 Debian 12 전용 절차입니다.…
자세히 보기