Windows에서 UWP 앱이 Clash를 타지 않을 때: Loopback 면제와 시스템 프록시 점검 (2026)

증상을 먼저 나누기: “안 탄다”의 두 가지 얼굴

커뮤니티 질문을 보면 비슷한 문장이 반복됩니다. “Clash Windows에서 시스템 프록시를 켰는데 스토어만 예전처럼 느리다”, “Xbox 앱은 아예 연결이 이상하다”처럼요. 여기서 중요한 것은 한 가지 레이블로 몰아넣지 말고, ① WinINET 기반으로 시스템 프록시를 따르는 경로가 있는지, ② 로컬 MITM·로컬 PAC·로컬 HTTP 프록시(127.0.0.1)를 UWP가 허용하는지를 분리해 보는 것입니다. 전자는 시스템 프록시·프로필 모드 문제에 가깝고, 후자는 Loopback 면제 이슈에 가깝습니다. 둘 다 아니면 TUN으로 캡처 범위를 넓혀야 하는 케이스가 나옵니다.

Clash 클라이언트(예: Verge 계열)는 보통 로컬 포트에서 HTTP/SOCKS를 열고, “시스템 프록시” 토글로 Windows 설정의 프록시 서버를 그 포트로 맞춥니다. 그런데 UWP는 데스크톱 앱과 달리 네트워크 격리 규칙이 있어, 같은 설정을 읽더라도 localhost로의 아웃바운드가 기본적으로 막히거나, 스토어 자체 정책으로 직접 연결을 고집하는 흐름이 섞일 수 있습니다. 그래서 “브라우저만 되고 스토어만 안 된다”는 패턴이 설명 가능해집니다.

1기준선: Clash 설치·시스템 프록시가 맞는지

UWP 이야기에 들어가기 전에, 데스크톱 Edge나 Chrome이 동일한 프로필에서 기대한 노드를 타는지 확인하세요. 여기서부터 어긋나면 원인은 UWP가 아니라 구독·규칙·DNS·모드(Rule vs Global) 쪽일 가능성이 큽니다. 초기 설치·구독 동기화·시스템 프록시 토글이 익숙하지 않다면 Windows용 Clash Verge Rev 설치 가이드를 먼저 밟고 오는 편이 실수가 적습니다. 같은 문서 흐름에서 시스템 프록시가 실제로 켜졌는지, 포트 충돌이 없는지도 함께 짚을 수 있습니다.

Windows 설정 > 네트워크 및 인터넷 > 프록시에서 수동 프록시가 127.0.0.1과 Clash가 안내하는 포트로 맞는지 눈으로 확인하세요. 일부 보안·최적화 유틸이 프록시를 덮어쓰면 “Clash는 켰는데 OS는 다른 값”이 됩니다. 또한 회사 단말은 그룹 정책으로 프록시가 고정되어 UWP만 예외 처리되는 경우도 있어, 개인 프로필 PC와 증상을 비교하면 원인 분리가 빨라집니다.

2Loopback 제한이란 무엇인가

Windows의 UWP 앱은 기본적으로 자기 자신을 제외한 로컬 머신으로의 소켓 연결을 제한하는 정책을 가질 수 있습니다. 프록시 클라이언트가 127.0.0.1:7890 같은 주소로 트래픽을 넘기려 할 때, 이 제한이 걸려 있으면 “프록시가 있는 것처럼 보이지만 실제로는 붙지 않는다”는 현상이 납니다. 이를 흔히 Loopback exemption(루프백 면제)으로 풉니다. 반면 순수하게 원격 서버로만 직접 TCP를 여는 앱은 이 제한과 무관하게 “시스템 프록시를 무시하고 직접” 나갈 수 있어, 이때는 면제가 아니라 TUN 같은 상위 캡처가 필요합니다.

3Loopback 면제: CheckNetIsolation로 앱 단위 허용

관리자 권한이 있는 PowerShell이나 CMD에서 CheckNetIsolation 유틸리티를 사용하면, 특정 UWP 패키지에 대해 루프백을 허용할 수 있습니다. 먼저 대상 앱의 패밀리 네임(패키지 식별 문자열)을 알아야 합니다. Windows 설정의 앱 목록이나 Get-AppxPackage로 스토어·Xbox 관련 패키지 전체 이름을 확인한 뒤, 아래 형식의 명령을 참고하세요. 빌드·앱 버전에 따라 정확한 문자열은 달라지므로, 본인 PC에서 조회한 값으로 바꿔야 합니다.

# Example only — replace with your package family name from Get-AppxPackage
CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

-a는 추가를 의미합니다. 이미 목록에 있는지 확인하려면 LoopbackExempt -c 계열로 현재 면제 목록을 덤프해 보는 방법도 문서화되어 있습니다. 여러 UWP를 동시에 쓴다면 스토어·Xbox·게임 패스 등 증상이 나는 앱마다 면제를 넣어야 할 수 있습니다. 이 작업은 OS 업데이트 후에도 유지되는 경우가 많지만, 앱이 완전히 재설치되면 패키지 ID가 바뀌는지 한 번씩 다시 확인하는 것이 안전합니다.

개발자용 Loopback 도구

Microsoft는 과거에 로컬 웹 서버와 UWP를 함께 디버깅할 수 있도록 별도 도구를 제공한 바 있습니다. GUI로 면제 목록을 관리하는 방식은 검색어로 “Loopback exemption tool” 등과 함께 찾을 수 있으나, 출처가 명확한 도구만 사용하고, 회사 보안 정책이 있다면 사전 승인을 받으세요. 원칙적으로는 공식 문서에 가까운 CheckNetIsolation이 재현성과 설명에 유리합니다.

4시스템 프록시만으로 부족한지 판별하기

일부 UWP와 시스템 구성요소는 WinHTTP 스택을 따로 쓰거나, 프록시 설정을 캐시합니다. netsh winhttp show proxy로 WinHTTP 쪽이 Clash가 기대하는 값과 다른지 볼 수 있습니다. 시스템 프록시 동기화 옵션을 클라이언트가 제공한다면 켜 두는 것이 일관성에 도움이 됩니다. 그래도 특정 앱만 빠져나간다면, 앞서 말한 직접 연결 가능성을 열어 두고 Clash Verge Rev TUN 모드 가이드에서 설명하는 것처럼 TUN으로 OS 아래에서 트래픽을 코어로 보내는 경로를 검토합니다.

TUN은 드라이버·권한 이슈가 따라올 수 있으므로, “Loopback 면제 후에도 동일 앱이 시스템 프록시를 무시한다”는 식으로 단계적 가설을 세우는 것이 좋습니다. 브라우저·Win32는 정상인데 동일 앱만 이상하면 UWP 특성을, 모든 앱이 이상하면 코어·DNS·노드 쪽을 우선 의심합니다.

5Microsoft Store·Xbox에서 자주 보이는 패턴

스토어 자체는 CDN·인증 엔드포인트가 여러 도메인으로 흩어져 있어, 규칙 세트가 지나치게 보수적이면 일부 요청만 직행하는 것처럼 보일 수 있습니다. Clash에서 RULE 모드와 GEOIP·국내 직접 연결 규칙이 앞에 있으면, 의도치 않게 특정 호스트가 DIRECT로 떨어지기도 합니다. 로그 패널에서 해당 시각의 도메인·정책 결과를 확인해 “프록시를 안 탄 게 아니라 규칙상 직접이다”인지 가릅니다. Xbox 앱은 게임·채팅·콘텐츠 스트림이 서로 다른 호스트를 쓰므로, 한 노드만 느린지 전체가 안 되는지도 증상을 잘게 쪼개야 합니다.

또한 Microsoft 계정 동기화·Windows 업데이트 채널은 조직 정책과 연동되는 경우가 있어, “VPN만 켜면 된다”는 인상과 달리 로컬 정책·DNS가 우선할 수 있습니다. 이때 Meta 코어 DNS 유출 방지 가이드와 함께, FakeIP·업스트림 DNS가 스토어 도메인과 충돌하지 않는지 점검하면 원인 분리에 도움이 됩니다.

한 페이지 체크리스트 (2026)

1. 브라우저·Win32에서 동일 프로필로 목적지에 도달하는가.
2. Windows 프록시 설정이 127.0.0.1:포트와 일치하는가.
3. Loopback 면제가 증상 앱 패키지에 대해 등록되었는가.
4. WinHTTP 프록시와 클라이언트의 시스템 동기화가 일치하는가.
5. 규칙 로그에서 해당 트래픽이 의도한 정책 그룹으로 갔는가.
6. 위가 모두이면 TUN으로 캡처 범위를 넓혀 재현 실험.

문서·설정 허브와 함께 보기

용어(tun, dns-hijack, 정책 그룹)를 한곳에서 정리해 두면 이후 장애 대응이 빨라집니다. Clash 문서·설정 허브의 링크를 북마크해 두고, 본 글의 순서와 병행하면 “UWP만 이상한지”와 “전체 스택이 이상한지”를 반복해서 가르기 쉽습니다. 오픈소스 저장소는 라이선스·이슈 확인용으로 두고, 클라이언트 설치 패키지는 사이트의 안내에 맞추는 편이 혼선이 적습니다.

마치며

Clash Windows 환경에서 UWP만 예외적으로 동작할 때는, 한 번에 “버그”로 단정하기보다 Loopback과 시스템 프록시·규칙·TUN을 순서대로 배제하는 편이 낫습니다. 같은 증상이라도 패키지 면제 한 줄로 끝나는 경우가 있는 반면, 앱이 프록시 자체를 우회하면 코어 쪽 캡처를 바꿔야 합니다. Meta 계열 클라이언트는 로그와 모드 전환이 잘 드러나 있어, 이런 대조 실험에 적합합니다.

다른 도구 여러 개를 겹치기보다 한 클라이언트에 프로필을 정리하고, 브라우저·UWP·터미널을 같은 검증 루틴으로 두면 재발 시에도 대응 시간이 줄어듭니다. 설치와 기본 튜닝을 아직 끝내지 않았다면 위에서 안내한 설치 글과 TUN 글을 순서대로 맞춰 보세요.

→ Clash를 무료로 내려받고 Windows에서 일관된 프록시 경험을 이어 가 보세요