Windows 스토어 앱이 Clash 프록시를 우회한다? UWP 루프백 제한 해제 절차
마이크로소프트 스토어 앱은 기본적으로 루프백 제한에 막혀 프록시를 우회합니다. UWP 네트워크 격리 원리를 설명하고, 시스템 도구와 클라이언트 내장 기능으로 제한을 해제하는 전체 절차와 검증법을 소개합니다.
브라우저는 프록시가 되는데 스토어 앱은 왜 안 될까
많은 사용자가 이 문제를 처음 겪을 때는 대체로 같은 상황입니다. 데스크톱 브라우저나 일반 exe 프로그램은 프록시가 아무 문제 없이 작동하고 지연 속도 측정도 정상이며 규칙도 잘 매칭되는데, 마이크로소프트 스토어에서 설치한 앱—채팅 앱이든 리더 앱이든 일부 게임 클라이언트든—만은 하나같이 네트워크 오류를 표시하며 마치 프록시가 전혀 적용되지 않은 것처럼 동작합니다. 이리저리 확인해봐도 시스템 프록시 설정은 문제가 없고 Clash 클라이언트도 정상 작동 중인데, 원인은 결국 해당 앱 자체의 실행 방식에 있습니다.
마이크로소프트 스토어의 앱 대부분은 UWP(Universal Windows Platform) 구조로, 전통적인 Win32 데스크톱 프로그램과는 완전히 다른 실행 메커니즘을 갖습니다. UWP 앱은 AppContainer라는 샌드박스 환경에서 실행되며 전통 프로그램보다 훨씬 낮은 권한을 갖습니다. 네트워크 접근은 Win32 프로그램이 기기 전체의 네트워크 권한을 기본으로 갖는 것과 달리, 시스템이 사전에 선언한 "기능"(Capability)에 의해서만 허용됩니다. 이 샌드박스 설계는 보안을 강화하려는 목적이지만, 부작용으로 앱이 본기기의 루프백 주소(127.0.0.1 또는 localhost)에 접속하는 것을 기본적으로 막아버립니다.
이 점이 바로 Clash의 동작 방식을 직접 막습니다. Clash 클라이언트는 로컬에서 하나의 수신 포트(흔히 7890번 시스템 프록시 포트)를 열고, 시스템 레벨의 프록시 설정은 본질적으로 각 프로그램이 네트워크 요청을 127.0.0.1:7890이라는 루프백 주소로 전달하도록 하는 것입니다. Win32 프로그램은 태생적으로 루프백 주소에 접근할 수 있어서 브라우저나 채팅 프로그램은 문제없이 전달됩니다. UWP 앱은 샌드박스 격리 때문에 루프백 주소로 가는 경로가 시스템에 의해 직접 막혀 있어 요청 자체가 나가지 못하고, 결국 네트워크 오류를 표시하거나 원본 직접 연결로 넘어갑니다—직접 연결 자체가 차단되어 있다면 "완전히 접속 안 됨"으로 나타나고, 직접 연결은 되지만 대상 서비스가 지역 제한이 있다면 "오류 표시는 없지만 콘텐츠가 로드되지 않음"으로 나타납니다.
시스템 기본 도구 CheckNetIsolation으로 제한 해제하기
마이크로소프트는 이 문제에 공식 해법을 남겨두었습니다. 명령줄 도구 CheckNetIsolation은 Windows 10/11에 기본 포함되어 있어 별도 설치가 필요 없습니다. 이 도구로 특정 UWP 앱에 "루프백 예외"(LoopbackExempt)를 부여할 수 있으며, 이는 시스템 샌드박스에게 해당 앱이 로컬 루프백 주소 접근을 허용받았음을 알려주는 것과 같습니다.
- Win 키를 눌러 "명령 프롬프트"를 검색하고 마우스 우클릭으로 "관리자 권한으로 실행"을 선택합니다. 관리자 권한이 아니면 명령이 조용히 실패합니다.
- 다음 명령을 입력해 현재 설치된 모든 UWP 앱과 패키지명을 나열하고, 문제가 되는 앱의
PackageFamilyName을 찾습니다:CheckNetIsolation LoopbackExempt -s - 패키지명을 확인한 후 예외 명령을 실행합니다.
패키지명은 앞서 확인한 전체 문자열로 바꿉니다:CheckNetIsolation LoopbackExempt -a -n="패키지명" - 명령 실행 후 오류가 없으면 성공한 것이며, 시스템을 재부팅할 필요는 없지만 해당 UWP 앱을 완전히 종료한 뒤 다시 열어 새 네트워크 권한이 적용되도록 하는 것을 권장합니다.
구체적인 패키지명을 찾기 어렵다면, 명령 한 줄로 설치된 모든 UWP 앱에 일괄로 루프백 예외를 부여할 수도 있습니다. 원인을 빠르게 확인하고 싶은 진단 단계에 적합합니다:
CheckNetIsolation LoopbackExempt -a -p=*문제가 해결된 것을 확인한 뒤에는 다음 명령으로 범위를 다시 특정 앱으로 좁혀, 모든 스토어 앱에 장기간 이 예외를 열어두지 않도록 하는 것을 권장합니다:
CheckNetIsolation LoopbackExempt -c
CheckNetIsolation LoopbackExempt -a -n="대상 앱 패키지명"| 명령 | 기능 |
|---|---|
-s | 현재 모든 루프백 예외 기록과 설치된 패키지명을 나열 |
-a -n="패키지명" | 지정한 앱에 루프백 예외 추가 |
-d -n="패키지명" | 지정한 앱의 루프백 예외 제거 |
-c | 추가된 모든 예외 기록 초기화 |
클라이언트 내장 기능: TUN 모드로 시스템 프록시 계층 우회하기
명령줄 방식은 개별 앱에 정확하게 효과적이지만, 여러 스토어 앱이 동시에 영향을 받는 경우 하나씩 수동으로 예외를 부여하는 것은 번거롭습니다. 더 간편한 방법은 Clash 클라이언트를 TUN 모드(일부 클라이언트에서는 "가상 네트워크 어댑터 모드" 또는 "강화 모드"로 표시됨)로 전환하는 것입니다.
TUN 모드의 원리는 시스템 프록시 설정과 완전히 다릅니다. 시스템 프록시는 각 프로그램이 요청을 로컬 루프백 포트로 전달하도록 하며, 각 앱이 시스템 프록시 설정에 "협조할" 의지가 있는지에 의존합니다. TUN 모드는 시스템에 가상 네트워크 어댑터를 생성해 클라이언트가 네트워크 계층에서 모든 아웃바운드 트래픽을 가로채고 넘겨받습니다. 요청을 보내는 프로그램이 Win32든 UWP든 표준 TCP/IP 스택을 사용하기만 하면 모두 이 가상 어댑터에 의해 가로채져 전달되므로, 더 이상 루프백 주소 경로에 의존하지 않고 자연스럽게 UWP 샌드박스의 루프백 접근 제한을 우회합니다.
활성화 방법은 클라이언트 화면에 따라 약간 다르지만 대략적인 절차는 동일합니다:
- 클라이언트 설정 화면을 열고 "네트워크 모드" 또는 "연결 방식" 옵션을 찾습니다.
- 모드를 "시스템 프록시"에서 "TUN" 또는 "가상 네트워크 어댑터"로 전환합니다.
- 처음 활성화할 때는 보통 추가 권한이 필요합니다. 가상 네트워크 어댑터 드라이버를 한 번 설치하고 클라이언트를 관리자 권한으로 실행하도록 허용해야 하며, 시스템에서 드라이버 설치 확인 창이 한 번 뜹니다.
- 전환에 성공한 뒤에는 시스템 프록시 설정을 기본값으로 유지해도 되며 별도로 다시 설정할 필요가 없습니다. 스토어 앱과 일반 데스크톱 프로그램은 같은 전달 경로를 사용하게 됩니다.
두 방법 중 무엇을 선택할지, 흔한 오류는 어떻게 확인할지
스토어 앱 한두 개만 이상하고 나머지는 모두 정상이라면 CheckNetIsolation으로 정확하게 예외를 부여하는 것이 우선입니다. 변경 범위가 작고 다른 네트워크 설정에 영향을 주지 않습니다. 여러 스토어 앱이 전반적으로 영향을 받거나 원래부터 더 안정적인 전달 방식을 장기간 쓰려는 계획이라면, 바로 TUN 모드로 전환해 한 번에 해결하는 것이 더 편리하며 이후 새로 설치하는 스토어 앱도 개별 처리할 필요가 없습니다.
처리 과정에서도 여전히 통하지 않는다면 다음 순서로 확인합니다:
- 명령 프롬프트가 관리자 권한으로 실행되었는지 확인합니다. 관리자 권한이 아닌 상태에서
CheckNetIsolation명령은 성공 메시지를 반환하지만 실제로는 적용되지 않는데, 이는 가장 자주 놓치는 부분입니다. -s옵션으로 예외 목록을 다시 확인해, 대상 패키지명이 실제로 목록에 있는지 확인합니다. 오타로 존재하지 않는 패키지에 예외를 부여한 것은 아닌지 확인합니다.- Clash 클라이언트의 수신 포트와 시스템 프록시 설정의 포트가 일치하는지 확인합니다. 루프백 제한을 해제해도 접근 경로만 열린 것일 뿐, 포트 설정이 잘못되어 있으면 여전히 연결되지 않습니다.
- TUN 모드로 전환한 뒤에도 변화가 없다면, 클라이언트에 가상 네트워크 어댑터 드라이버 설치 실패 알림이 있는지 확인하고, 클라이언트나 시스템을 재시작한 뒤 다시 시도합니다.
- 일부 스토어 앱(특히 일부 리더, 다운로드 앱)은 자체적인 네트워크 설정 항목을 갖고 있으므로, 앱 내부에서 "직접 연결만 사용" 같은 옵션을 별도로 꺼야 합니다.
프록시가 실제로 적용되는지 검증하기
제한을 해제한 뒤에는 단순히 앱에서 콘텐츠가 열리는지만 보지 말아야 합니다. 그렇게 하면 "되는 것처럼 보이지만 실제로는 직접 연결"이라는 잘못된 판단을 내리기 쉽습니다. 다음 세 가지 방법을 교차 검증하는 것이 더 신뢰할 수 있습니다:
- IP 소속 지역 비교: 브라우저에서 IP 조회 페이지를 열어 직접 연결 시 표시되는 지역을 기록한 뒤, 스토어 앱 내에서 네트워크 요청을 한 번 발생시켜(예: 지역 제한이 있는 페이지 새로고침) 프록시 노드가 위치한 지역과 일치하는 동작 차이가 나타나는지 비교합니다.
- 클라이언트 연결 로그: Clash 클라이언트의 로그나 연결 패널을 열고 스토어 앱을 조작하는 동시에 해당 연결 기록이 새로 생기는지 관찰합니다. 구체적인 도메인과 사용된 프록시 노드까지 확인할 수 있어 가장 직접적인 증거가 됩니다.
- 노드 전환 후 재테스트: 프록시 노드를 다른 지역으로 전환한 뒤 같은 작업을 반복합니다. 스토어 앱 안의 콘텐츠 표시가 이에 따라 바뀐다면 트래픽이 실제로 프록시를 경유한 것이고, 직접 연결로 캐시가 적중된 것이 아니라는 뜻입니다.
세 가지 방법 중 클라이언트 연결 로그가 가장 확실합니다. 스토어 앱 자체의 화면 반응에 의존하지 않고 트래픽 전달 계층에서 요청이 실제로 넘겨받아졌는지 직접 확인할 수 있기 때문입니다. 로그에 해당 앱의 연결 기록이 전혀 나타나지 않는다면, 루프백 제한 해제나 TUN 모드 설정이 실제로 적용되지 않은 것이므로 앞선 확인 순서를 다시 처음부터 따라가야 합니다.