이 가이드가 맞는 증상

이미 구독 URL로 프로필을 넣었고, 크롬·파이어폭스 등 일반 데스크톱 브라우저에서는 지연 테스트와 실제 접속이 잘 되는데, Microsoft Store에서 앱 설치·업데이트만 실패하거나 매우 느리고, Xbox 앱·일부 기본 제공 앱만 여전히 «집 회선 그대로»처럼 느껴질 때가 대표적입니다. 혹은 Clash가 127.0.0.1mixed 포트나 HTTP 포트로 시스템 프록시를 심어 두었는데, 특정 UWP만 프록시에 붙지 못하고 타임아웃이 나는 경우도 같은 계열입니다.

이 글은 YAML 문법 전체를 가르치기보다는, «앱 종류별로 경로가 갈린다»는 전제에서 원인 분류조치 순서에 초점을 맞춥니다. 규칙·정책 그룹을 손보는 단계는 YAML 규칙 분기 가이드와 같이 읽으면 설정 전반이 이어집니다.

왜 브라우저는 되는데 UWP만 직행·실패하는가

Clash 계열 GUI가 켜는 시스템 프록시는 운영체제에 «HTTP/HTTPS 트래픽을 이 호스트·이 포트로 보내라»는 힌트를 남깁니다. Win32 기반 브라우저는 이 힌트를 잘 따르기 때문에, 같은 자리에서 바로 우회가 됩니다. 반면 UWP(앱 패키지로 설치되는 Microsoft Store 앱 등)는 앱 컨테이너 안에서 돌아가며, 보안 모델상 자기 자신이 로컬 컴퓨터의 서비스(127.0.0.1)에 붙는 것을 기본적으로 제한합니다. 즉, 프록시가 로컬호스트에 있다는 사실 자체가 «막힐 수 있는 조건»이 됩니다.

Clash가 로컬에서 수신 대기하는 포트로 트래픽을 넘기려면, UWP 입장에서는 결국 localhost로의 아웃바운드입니다. 이 경로가 루프백 격리에 걸리면, 겉으로는 «인터넷이 안 된다»가 아니라 «Store만 안 된다»처럼 앱마다 제각각으로 보입니다. 반대로 Win32 게임 런처나 터미널 도구는 같은 제약을 받지 않는 경우가 많아, 사용자는 «Clash는 정상인데 왜 Store만 이상하지?»라는 인상을 받게 됩니다.

먼저 확인할 한 가지 Clash 쪽에서 Allow LAN(로컬 네트워크 허용)·방화벽 예외가 꺼져 있으면 Win32도 불안정해질 수 있습니다. 그러나 «브라우저만 완전히 정상인데 UWP만 127.0.0.1 프록시에 못 붙는다»는 패턴이면, 루프백 면제 쪽을 우선 의심하는 편이 빠릅니다.

시스템 프록시·루프백 면제·TUN을 표로 정리하면

세 가지는 서로를 «대체재」라기보다 겹쳐 쓰되 역할이 다른 레이어에 가깝습니다. 아래 표는 Windows 11 데스크톱에서 현장 설명용으로 자주 쓰는 요약입니다.

방식 UWP가 로컬 프록시를 쓰기 쉬운가 흔한 부작용
시스템 프록시만(127.0.0.1) 루프백 격리 때문에 기본값은 불리. 면제 없으면 Store류가 실패하기 쉬움 설정은 가볍지만 앱 종류별 편차가 큼
CheckNetIsolation 루프백 면제 로컬 프록시 경로를 열어 줌. 문제가 localhost 정책일 때 직격 면제 범위를 과하게 넓히면 공격면이 늘어나므로 최소 패키지 위주가 안전
TUN(가상 NIC) 라우팅 계층에서 잡히는 트래픽은 프록시가 로컬이 아니어도 흐름이 잡히기 쉬움 관리자·드라이버·DNS·다른 VPN과 충돌 시 «전체 단절」 위험

TUN을 켰다고 해서 루프백 이슈가 100% 사라지는 것은 아닙니다. 여전히 앱이 «로컬 API 서버」에만 붙는 패턴이면 면제가 필요할 수 있고, 반대로 루프백만 풀고도 규칙상 DIRECT로 새는 경우는 GEOIP·DOMAIN 규칙을 봐야 합니다. TUN·시스템 프록시 비교 글에서 Windows 쪽 권한·Wintun·DNS 이슈를 먼저 정리한 뒤 이 글의 UWP 단계로 내려오면 흐름이 자연스럽습니다.

1단계: Package Family Name 찾기

CheckNetIsolation은 Windows에 내장된 유틸리티로, 특정 UWP 패키지에 대해 네트워크 루프백 면제(loopback exemption)를 등록하거나 목록을 확인할 때 씁니다. 면제를 걸 때 필요한 식별자는 보통 Package Family Name(PFN)입니다. 관리자 권한이 필요한 명령이 많으니, PowerShell이나 터미널을 관리자로 실행한 상태에서 진행하세요.

예를 들어 이름에 «store»가 들어가는 패키지의 PFN을 보고 싶다면 다음과 같이 좁힐 수 있습니다.

# List Microsoft Store-related packages and PFN
Get-AppxPackage *store* | Select-Object Name, PackageFamilyName

Xbox 앱이 문제라면 키워드를 바꿔 같은 방식으로 조회합니다. PFN은 문자열 한 줄이며, 이후 면제 명령의 -n= 인자로 그대로 넘깁니다.

2단계: 단일 패키지에 면제 등록

가장 보수적인 방법은 문제를 일으키는 앱만 골라 면제하는 것입니다. 관리자 명령 프롬프트나 PowerShell에서 아래 형식을 씁니다(YOUR-PFN을 실제 PFN으로 바꿉니다).

CheckNetIsolation LoopbackExempt -a -n=YOUR-PFN

-a는 add를 뜻합니다. 이미 등록된 항목을 보고 싶다면 다음을 실행합니다.

CheckNetIsolation LoopbackExempt -s
보안 관점 루프백 면제는 «UWP가 로컬에서 돌아가는 다른 서비스와 대화할 수 있게 한다»는 뜻이기도 합니다. 개발 편의를 위해 모든 패키지에 면제를 걸 수도 있지만, 일반 사용자 PC에서는 필요한 PFN만 남기고 주기적으로 -s로 목록을 점검하는 편이 좋습니다.

3단계: 여러 후보를 빠르게 시험할 때

Store 연동 모듈처럼 PFN이 여러 개로 쪼개진 경우, 원인 앱을 하나로 특정하기 어려울 수 있습니다. 이때는 임시로 면제 범위를 넓혀 재현이 사라지는지 본 뒤, 다시 좁히는 방식이 현장에서 자주 쓰입니다. 반복해서 전체 면제 스크립트를 돌리기보다는, 증상이 재현되는 최소 집합을 찾아 고정하는 것이 유지 보수에 유리합니다.

일부 Clash GUI는 «UWP 루프백» 메뉴에서 자주 쓰는 PFN을 한 번에 등록해 주기도 합니다. 이 경우에도 내부적으로는 CheckNetIsolation과 같은 계열의 OS 기능을 다루는 것으로 이해하면 혼란이 줄어듭니다.

TUN을 켜 UWP 트래픽을 규칙으로 다시 묶기

루프백 면제는 «로컬 프록시로 들어오는 길»을 열어 주는 조치입니다. 반면 TUN 모드는 가상 NIC와 라우팅을 통해 «앱이 프록시 주소를 정확히 알지 못해도» Clash 쪽으로 흐름이 지나가게 만드는 쪽에 가깝습니다. 그래서 시스템 프록시만으로는 빠지던 Microsoft 서비스 트래픽이, TUN을 켠 뒤에는 rulesproxy-groups를 타는 패턴이 흔합니다.

Windows 11에서는 관리자 권한, Wintun 계열 드라이버, 다른 VPN 제품과의 어댑터 우선순위가 발목을 잡기 쉽습니다. TUN을 켠 직후 «PC 전체가 안 된다»면 UWP 이전에 먼저 TUN 스택·DNS를 의심해야 하며, 이에 대한 순서별 배제는 앞서 링크한 TUN 트러블슈팅 글의 Windows 절을 그대로 밟는 것이 빠릅니다.

실무에서는 (1) 시스템 프록시로 일상 트래픽을 유지하고, (2) Store·Xbox만 문제일 때 루프백 면제를 추가한 다음, (3) 그래도 지역·DNS 이슈가 남으면 TUN을 켜 규칙으로 재정렬하는 세 단계가 잘 맞습니다. 한 번에 모든 옵션을 켜면 원인 추적이 어려워지므로, 가능하면 한 겹씩 추가하세요.

여전히 직행한다면: 규칙·DNS·Microsoft 트래픽

localhost 문제를 풀었는데도 특정 Microsoft 도메인만 직행하거나 반대로 끊긴다면, 이제는 Clash 규칙DNS 영역입니다. 예를 들어 GEOIP,CN이나 국내 DIRECT 묶음이 지나치게 앞에 있으면, 의도와 다르게 Microsoft CDN 구간이 직행으로 빠질 수 있습니다. 반대로 fake-ip·DNS hijack 조합이 맞지 않으면 «이름은 되는데 연결만 실패»처럼 보이기도 합니다.

이때는 앱 종류보다 도메인 로그를 잠깐 켜고, 문제가 되는 호스트가 어떤 정책 그룹으로 떨어지는지 확인하는 것이 정석입니다. 규칙 예시와 정책 그룹 설계는 YAML 규칙 가이드의 순서·스니펫을 참고하면, Microsoft 스토어·업데이트 전용으로 소규모 rules 블록을 추가하기도 수월합니다.

  • 모드: 글로벌로 올려 테스트해 «규칙 문제인지 경로 문제인지」를 먼저 나눕니다.
  • DNS: 시스템 DNS, 브라우저 DoH, Clash DNS가 겹치면 루프와 타임아웃이 납니다. 테스트 때는 한쪽만 단순화해 보세요.
  • IPv6: IPv6가 직행으로 새면 «절반만 우회»처럼 느껴질 수 있어, 환경에 따라 잠시 끄고 비교합니다.

실측 체크리스트(순서 고정용)

  1. 브라우저·Win32 앱은 정상인지, UWP만 이상한지 먼저 표시해 둡니다.
  2. Clash가 쓰는 로컬 포트·시스템 프록시 대상이 127.0.0.1인지 확인합니다.
  3. 문제 UWP의 Package Family Name을 조회하고, CheckNetIsolation LoopbackExempt로 면제를 추가합니다.
  4. 면제 후에도 동일하면 TUN을 켜고, 관리자·드라이버·다른 VPN을 순서대로 배제합니다.
  5. 그다음에도 남으면 규칙·DNS·IPv6를 YAML 관점에서 좁힙니다.

마무리

Windows 11에서 Clash를 쓸 때 «브라우저만 된다»는 느낌은, 대개 시스템 프록시가 따라가는 앱과 UWP 앱 컨테이너가 따라가는 방식이 다르기 때문에 생깁니다. localhost 루프백 격리CheckNetIsolation으로 풀어 주면 Store·Xbox 류가 로컬 프록시에 안정적으로 붙는 경우가 많고, 그 위에 TUN을 얹으면 라우팅 계층에서 한 번 더 흐름을 정리할 수 있습니다. 둘 다 강력하지만, 문제가 생겼을 때는 한 번에 하나씩만 바꾸는 것이 복구 시간을 줄입니다.

같은 증상이라도 클라이언트 포크마다 메뉴 이름이 조금씩 다릅니다. 반복해서 여러 빌드를 옮겨 다니기보다, 한 플랫폼에서 검증된 조합을 고정해 두면 데스크톱 운영이 한결 편해집니다. ClashNote 다운로드 페이지에서는 Windows용 클라이언트를 한곳에서 비교하며 설치 경로를 정리할 수 있습니다.

Clash 무료로 다운로드하고, UWP 루프백 면제와 TUN·시스템 프록시를 단계적으로 맞춰 Windows 11 환경을 정돈해 보세요.

다른 플랫폼이나 구독 갱신·DNS 이슈는 기술 칼럼의 주제별 글과 이어서 읽으면 전체 그림이 잡힙니다.