1. TUN인데도 UWP만 다른 이유
Windows의 UWP(범용 Windows 플랫폼) 앱과 Microsoft Store에서 내려받은 일부 패키지는 일반 데스크톱 프로그램과 네트워크 격리 모델이 다릅니다. AppContainer 샌드박스 안에서 동작하는 앱은 보안상 로컬 호스트로의 연결에 기본적으로 제한이 걸려 있고, 이를 「루프백 격리」라고 부릅니다. 브라우저나 Win32 앱은 잘 되는데 특정 스토어 앱만 이상하다면, 먼저 「트래픽이 TUN을 안 탄다」가 아니라 앱이 127.0.0.1·로컬 서비스와의 통신에서 막혀 있다는 쪽을 의심할 가치가 있습니다.
또 한 가지는 Clash 쪽 규칙입니다. TUN이 전역으로 트래픽을 끌어가더라도, 설정에 따라 특정 프로세스 이름은 DIRECT로 빠지거나 반대로 특정 그룹만 타도록 고정할 수 있습니다. TUN 모드 개념과 별개로, rules 배열의 위쪽에 걸린 조건이 먼저 적용되므로 「TUN 켰으니 전부 동일하게 나갈 것」이라고 단정하면 안 됩니다.
정리
UWP 이슈는 (가) 루프백·로컬 통신 제한, (나) Clash 규칙상 해당 앱/프로세스가 다른 정책으로 분기되는 경우, (다) 클라이언트가 MIXED/시스템 프록시와 TUN을 동시에 쓰며 혼선이 나는 경우로 나누어 보면 원인 좁히기가 쉬워집니다.
2. 루프백 격리와 로컬 프록시
과거 많은 사용자가 「시스템 프록시 = 127.0.0.1:7890」 형태로 쓰던 방식에서는, UWP가 로컬 프록시 프로세스에 붙지 못해 아예 인터넷이 안 되거나 스토어 로그인만 실패하는 패턴이 흔했습니다. Clash TUN을 켜면 트래픽이 가상 어댑터 쪽으로 흐르기 때문에 증상이 달라질 수 있지만, 앱 내부에서 여전히 localhost로 헬스 체크·인증·캐시 서버를 두르는 경우에는 루프백 이슈가 남을 수 있습니다.
즉, 「TUN을 썼으니 루프백은 무조건 해결」이 아니라, 해당 앱이 로컬 소켓에 의존하는지를 먼저 가늠해야 합니다. 의심이 가면 Windows의 루프백 면제 도구나 CheckNetIsolation로 해당 패키지에 대한 예외를 주는 것이 정석적인 Windows 쪽 조치입니다.
3. Loopback 면제(Exempt) 확인하기
관리자 권한 명령 프롬프트나 PowerShell에서 네트워크 격리 설정을 다룰 수 있습니다. 대표적으로는 Microsoft가 문서화한 CheckNetIsolation 유틸리티를 사용해, 특정 앱 패키지 패밀리 이름에 대해 루프백을 허용하는 방식입니다. 커뮤니티에서 널리 쓰이는 GUI 도구(예: 루프백을 일괄 허용하는 유틸리티)를 써도 되지만, 어떤 앱에 예외가 들어갔는지 목록을 확인하는 습관이 중요합니다.
실무에서는 다음 순서를 권합니다. 먼저 문제가 되는 앱의 패키지 ID를 확인하고, 루프백 면제 목록에 포함되어 있는지 봅니다. 없다면 면제를 추가한 뒤 앱을 완전히 종료했다가 다시 실행해 봅니다. 여전히 동일하면 Clash 쪽 규칙·DNS·스택(System / gVisor 등)을 다음 절의 PROCESS-NAME과 함께 점검합니다.
명령 예시 (개념용)
아래는 형식을 보여 주기 위한 예시이며, 실제 패키지 SID·이름은 환경마다 다릅니다. 관리자 권한에서 실행하세요.
# Existing loopback exemptions list (conceptual) CheckNetIsolation LoopbackExempt -s # Add exemption for a specific package (replace with your package SID) CheckNetIsolation LoopbackExempt -a -n=YourPackageFamilyName
스토어 앱마다 표시 이름과 패키지 패밀리 이름이 다르게 보이므로, 작업 관리자·설정 앱·PowerShell의 Get-AppxPackage 등으로 정확한 식별자를 맞추는 것이 실수를 줄이는 지름길입니다. 이 단계는 Clash 설정 파일만으로는 해결되지 않는 OS 수준 예외에 해당합니다.
4. PROCESS-NAME 규칙으로 앱 단위 분기
Clash Meta(mihomo) 계열에서는 Windows에서 실행 파일 이름을 기준으로 트래픽을 나누는 PROCESS-NAME 규칙을 지원합니다. 예를 들어 특정 게임 런처나 UWP가 아닌 Win32 앱만 별도 노드로 보내고 싶을 때 유용합니다. 다만 UWP는 백그라운드에 여러 프로세스가 붙을 수 있어, 이름이 사용자가 예상한 것과 다를 수 있습니다. 작업 관리자에서 실제로 네트워크를 쓰는 프로세스 이름(.exe)을 확인한 뒤 규칙에 넣는 것이 안전합니다.
규칙은 위에서 아래로 매칭되므로, PROCESS-NAME을 넣을 때는 DOMAIN·GEOIP 규칙과의 순서를 함께 설계해야 합니다. 의도치 않게 특정 앱만 직접 연결로 나가거나, 반대로 프록시 그룹에 갇혀 루프가 나는 경우가 있어, 라우팅 규칙 전반을 한 번 훑는 것을 권장합니다.
설정 예시 (형식 참고)
rules: # Route traffic from a specific executable to a policy group - PROCESS-NAME,example.exe,🔰 Proxy - PROCESS-NAME,AnotherApp.exe,DIRECT # ... other rules (DOMAIN, GEOIP, MATCH, etc.)
PROCESS-NAME은 만능이 아닙니다. 시스템 구성 요소·서비스 호스트와 이름이 겹치거나, 앱 업데이트로 실행 파일명이 바뀌면 규칙이 빗나갈 수 있습니다. 그럴 때는 로그에서 실제 연결을 남기는 프로세스를 다시 확인하고, 필요하면 DOMAIN-SUFFIX 등과 병행하는 편이 안정적입니다.
5. 자주 있는 오해와 체크 포인트
「TUN만 켜면 UWP도 자동으로 같은 노드를 쓴다」
TUN은 트래픽을 가로채는 경로에 가깝고, Clash 규칙·DNS·스니핑 설정에 따라 최종 아웃바운드는 달라질 수 있습니다. 규칙에서 특정 대상이 DIRECT로 빠지고 있지 않은지 로그로 확인하세요.
「시스템 프록시만 켜져 있으면 TUN과 동일하다」
UWP·스토어·터미널·WSL 등은 시스템 프록시를 무시하는 경우가 있습니다. 전역에 가깝게 쓰려면 TUN과 서비스 권한(클라이언트에 따라 다름)을 함께 고려하는 편이 좋습니다. 자세한 원리는 TUN 모드 가이드를 참고하세요.
「Loopback 면제는 보안상 무조건 나쁘다」
면제는 해당 앱이 로컬 서버와 통신할 수 있게 풀어 주는 것이므로, 필요한 앱에만 최소한으로 적용하고 목록을 주기적으로 점검하는 것이 좋습니다. 불필요한 일괄 허용은 피하세요.
6. 한 번에 점검하는 체크리스트
아래 항목을 순서대로 체크하면 원인을 상당 부분 좁힐 수 있습니다. 한 단계에서 해결되면 이후 단계는 생략해도 됩니다.
Windows에서 스토어·UWP 계열 앱은 데스크톱 브라우저와 같은 방식으로만 보면 놓치기 쉬운 변수가 많습니다. OS의 루프백 정책과 Clash 쪽 규칙 설계를 나란히 두고 보면, TUN을 켠 뒤에도 남는 「유독 한 앱만 이상한」 현상을 훨씬 빠르게 정리할 수 있습니다. 같은 하드웨어에서도 클라이언트 UI와 코어 설정에 따라 체감이 달라지므로, 한 번 검증된 구성을 유지하는 것이 장기적으로 가장 안정적입니다. 최신 Clash 계열 클라이언트는 TUN·규칙 편집·로그 확인이 한 화면에서 이어지는 경우가 많아, 반복 튜닝에도 시간을 덜 쓸 수 있습니다. 다른 범용 VPN보다 규칙·프로세스 단위 제어가 유연한 편이라, 복잡한 분할 요구가 있는 사용자에게 특히 잘 맞습니다.
→ Clash를 무료로 내려받고, 자신의 Windows 환경에 맞춰 TUN과 규칙을 차근차근 맞춰 보세요. 설치·구독 반영이 수월한 클라이언트를 쓰면 위와 같은 트러블슈팅도 훨씬 부담이 적습니다.