Windows 스토어 앱이 프록시를 타지 않는 이유: UWP 루프백 제한 해제 방법 실측

Microsoft Store, 새 Outlook 등 UWP 앱은 기본적으로 로컬 루프백 주소 접근이 차단되어 시스템 프록시가 적용되지 않습니다. 루프백 격리 원리와 CheckNetIsolation 명령어, 클라이언트 내장 도구 두 가지 해제법을 소개합니다.

Clash 클라이언트의 시스템 프록시를 켜면 브라우저, 터미널 도구, 대부분의 데스크톱 소프트웨어는 문제없이 프록시를 통해 나가지만, Microsoft Store, 새 Outlook, 일부 마이크로소프트 자체 앱은 프록시 존재를 전혀 인식하지 못하는 것처럼 동작합니다 — 접속 오류, 업데이트 멈춤, 로그인 반복 실패가 반복됩니다. 시스템 프록시가 이미 적용되어 있고 다른 소프트웨어는 정상인 상태에서 이런 문제를 만난다면, 노드나 규칙 문제가 아니라 Windows 플랫폼 고유의 UWP 루프백 격리(Loopback Isolation) 메커니즘에 걸린 것일 가능성이 높습니다.

SEC-01

왜 일부 앱만 영향을 받지 않는가

Windows 앱 생태계에는 두 가지 큰 범주가 있습니다: exe를 더블클릭해 실행하는 전통적인 Win32 데스크톱 프로그램(대부분의 채팅 도구, 브라우저, 개발 도구가 여기 속함), 그리고 UWP(Universal Windows Platform) 프레임워크 기반으로 앱 컨테이너(App Container) 안에서 실행되는 최신 앱입니다. Microsoft Store, 시스템 내장 메일/캘린더, 새 Outlook, 일부 사전 설치된 카메라/지도 앱은 모두 UWP 또는 유사한 컨테이너화 방식으로 실행됩니다.

시스템 프록시(Clash 클라이언트가 설정하는 HTTP/HTTPS 시스템 프록시, 그리고 TUN 모드로 전역 트래픽을 가로채는 방식 포함)는 Win32 프로그램에는 거의 "예외 없이 전면 적용"됩니다: 시스템 네트워크 스택을 통과하기만 하면 프록시가 가로채서 전달합니다. 그러나 UWP 앱은 제한된 앱 컨테이너 안에서 실행되며, 보안 격리 설계상 기본적으로 컨테이너 내 프로세스의 로컬 루프백 주소(127.0.0.1 및 ::1) 접근이 차단됩니다. 그런데 Clash 클라이언트의 프록시 리스닝 포트(믹스 포트 기본값 7890, 또는 클라이언트 화면에 표시되는 포트)가 바로 이 로컬 루프백 주소에 있습니다 — 이것이 문제의 근본 원인입니다: 프록시가 적용되지 않는 게 아니라, 이 앱들이 로컬 프록시 포트에 접속하는 것을 시스템이 막고 있는 것입니다.

NOTE

루프백 격리는 마이크로소프트가 샌드박스 보안 설계 차원에서 기본으로 걸어둔 제한이며, 버그도 아니고 Clash 클라이언트의 문제도 아닙니다. 판단 기준은 간단합니다: 브라우저, 채팅 소프트웨어는 프록시가 정상 작동하는데 Microsoft Store, 새 Outlook 등 일부 앱만 이상하다면, 이 메커니즘이 작동 중이라고 거의 확신할 수 있습니다.

흔히 영향받는 상황

  • Microsoft Store에서 검색이 안 되거나, 다운로드가 0%에서 멈추거나, 앱 업데이트가 오래 회전만 함.
  • 새 Outlook(One Outlook 기술 스택 기반의 신규 클라이언트)이 프록시를 설정한 뒤에도 계정에 연결되지 않거나, 로그인 시 네트워크 오류가 표시됨.
  • 일부 Xbox 관련 앱, 시스템 내장 날씨/뉴스 앱이 프록시를 켠 뒤 콘텐츠를 전혀 새로 고침하지 못함.
  • Microsoft Store를 통해 배포되고 MSIX/AppX로 패키징된 일부 서드파티 앱도 같은 제한에 걸릴 수 있음.
SEC-02

방법 1: CheckNetIsolation 명령어로 해제

Windows 시스템에는 앱 컨테이너의 네트워크 격리 규칙을 관리하는 명령줄 도구 CheckNetIsolation.exe가 내장되어 있으며, 루프백 접근 허용 목록도 여기서 관리됩니다. 이 방법은 클라이언트 기능에 의존하지 않고 원리가 명확하며 효과가 지속적이라, 가장 기본적이고 범용적인 해결 방식입니다.

  1. 관리자 권한으로 명령 프롬프트 열기

    시작 메뉴에서 "명령 프롬프트" 또는 "cmd"를 검색하고, 마우스 오른쪽 클릭으로 "관리자 권한으로 실행"을 선택합니다. 루프백 격리 규칙 수정에는 관리자 권한이 필요하며, 일반 권한 창에서 실행하면 바로 실패합니다.

  2. 현재 허용된 앱 목록 확인(선택)

    먼저 다음 명령을 실행해 현재 시스템에서 이미 허용된 앱이 무엇인지 확인해서, 중복 추가를 피합니다:

    CheckNetIsolation LoopbackExempt -s
  3. 대상 앱에 루프백 허용 추가

    Microsoft Store를 예로 들면, 앱의 패키지 패밀리 이름(Package Family Name)은 Microsoft.WindowsStore_8wekyb3d8bbwe이며, 다음을 실행합니다:

    CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

    명령 실행 후 오류가 없으면 성공한 것입니다. 새 Outlook이나 다른 UWP 앱을 허용하려면, 먼저 Get-AppxPackage로 해당 패키지 전체 이름을 확인한 뒤 -n= 뒤의 값을 교체하면 됩니다.

  4. 다른 앱의 패키지 전체 이름 찾기

    PowerShell을 열고(마찬가지로 관리자 권한 권장), 다음 명령으로 설치된 UWP 앱과 그 패키지 전체 이름을 나열합니다:

    Get-AppxPackage | Select Name, PackageFamilyName

    결과에서 대상 앱의 PackageFamilyName 필드를 찾아 그대로 복사해서 이전 단계의 명령에 넣으면 됩니다.

  5. 앱을 재시작해서 확인

    대상 앱을 완전히 종료(최소화가 아니라)한 뒤 다시 열어서 프록시가 적용되는지 확인합니다. 루프백 허용 수정은 보통 즉시 적용되며 시스템 재부팅은 필요하지 않습니다.

이후 특정 앱의 허용을 취소하려면, 명령의 -a(add)를 -d(delete)로 바꾸면 됩니다:

CheckNetIsolation LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
SEC-03

방법 2: 클라이언트 내장 원클릭 해제 도구

패키지 이름을 직접 찾고 명령어를 입력하는 것은 명령줄에 익숙하지 않은 사용자에게는 문턱이 높기 때문에, 많은 Clash 클라이언트의 Windows 버전에는 그래픽 인터페이스의 루프백 허용 도구가 내장되어 있습니다. 본질적으로 CheckNetIsolation을 감싼 것이지만, 패키지 전체 이름을 찾는 단계를 생략할 수 있습니다.

  • 클라이언트의 "시스템 설정" 또는 "네트워크 설정" 영역에서 "UWP 루프백 허용", "LoopbackExempt", "네트워크 격리 예외" 같은 이름의 항목을 찾습니다.
  • 열면 보통 시스템에 설치된 UWP/MSIX 앱이 자동으로 나열되며, 대상 앱(Microsoft Store, 새 Outlook 등)을 체크하고 적용을 누르면, 내부적으로 패키지 전체 이름을 자동으로 조합해 시스템 명령을 호출합니다.
  • 일부 클라이언트는 "자주 쓰는 앱 원클릭 허용" 버튼을 제공해, Store, Xbox, 메일 등 빈도 높게 제한받는 앱을 미리 설정해 두어 하나씩 확인하고 싶지 않은 사용자에게 적합합니다.
WARN

그래픽 도구도 관리자 권한이 있어야 효과가 있으므로, 클릭 후 별다른 반응이 없거나 적용이 안 될 경우 클라이언트 자체가 관리자 권한으로 실행 중인지 먼저 확인하세요. 일부 클라이언트 버전은 관리자 권한이 없을 때 오류 알림 없이 조용히 실패하는데, 이는 "기능이 작동하지 않는다"로 오판하기 쉬운 부분입니다.

내장 도구가 명령줄보다 신뢰성이 떨어지는 경우

그래픽 래핑은 편리하지만 두 가지 한계가 있습니다: 하나는 앱 목록이 클라이언트 자체의 감지 로직에 의존하기 때문에, 새로 설치한 앱이나 비표준 패키징 방식을 사용하는 앱이 목록에 나타나지 않을 수 있다는 점; 다른 하나는 클라이언트 버전마다 이 기능의 유지보수 정도가 달라, 일부 버전은 이 항목이 최신 시스템 앱 이름에 오랫동안 대응하지 못했을 수 있다는 점입니다. 목록에서 대상 앱을 찾을 수 없거나, 허용을 클릭해도 여전히 효과가 없는 경우, 명령줄 방식으로 돌아가 직접 패키지 이름을 찾아 추가하는 것이 더 확실한 최종 수단입니다.

SEC-04

TUN 모드에서도 루프백 격리 처리가 필요한가

여기서는 시스템 프록시 모드와 TUN 모드의 차이를 구분해야 합니다. 시스템 프록시 모드는 HTTP/HTTPS 프록시 주소를 시스템 네트워크 설정에 기록하고, 앱이 이 설정을 능동적으로 읽어서 로컬 루프백 포트로 연결을 시도해야 하는데, 바로 이 연결 동작이 루프백 격리에 막히는 부분이므로 시스템 프록시 모드에서는 UWP 앱이 영향받을 가능성이 더 높습니다.

TUN 모드는 시스템 레벨에서 가상 네트워크 어댑터를 만들어 네트워크 계층에서 모든 아웃바운드 트래픽(UWP 앱 컨테이너 내부에서 나가는 트래픽 포함)을 직접 가로채며, 앱이 능동적으로 로컬 프록시 포트에 연결할 필요가 없어 이론상 루프백 격리 제한을 우회할 수 있습니다. UWP 앱의 프록시 미적용 문제를 자주 겪고 클라이언트가 TUN 모드를 지원한다면, TUN 모드로 전환해 문제가 사라지는지 먼저 테스트해 보는 것을 권장합니다. 다만 TUN 모드는 추가로 가상 네트워크 어댑터 드라이버 권한이 필요해 시스템 프록시보다 설정 문턱이 약간 높으므로, 먼저 클라이언트 문서에서 TUN 모드 활성화 단계를 확인한 뒤 순차적으로 점검하는 것을 권장합니다.

루프백 주소(Loopback Address)

네트워크 기초

기기 자신을 가리키는 주소로, IPv4에서는 127.0.0.1(전체 127.0.0.0/8 대역이 루프백에 속함), IPv6에서는 ::1입니다. 로컬에서 실행되는 프록시 서비스는 보통 루프백 주소에서 리스닝하며, 로컬 프로세스만 접근할 수 있고 외부 네트워크에는 노출되지 않습니다.

SEC-05

점검 순서 정리

"일부 앱만 프록시를 타지 않고 대부분은 정상"인 상황을 만나면, 아래 순서로 점검하는 것을 권장하며, 무관한 방향에 시간을 낭비하지 않도록 합니다:

  1. 영향받는 앱의 종류 확인

    먼저 문제가 발생한 앱이 Microsoft Store에서 왔는지 또는 UWP/MSIX 패키징 방식인지 확인합니다. 일반 exe 데스크톱 프로그램은 기본적으로 루프백 격리의 영향을 받지 않으므로 이 방향으로 점검할 필요가 없습니다.

  2. 명령줄로 허용 상태 확인

    CheckNetIsolation LoopbackExempt -s를 실행해 현재 허용 목록을 확인하고, 대상 앱이 이미 포함되어 있는지 확인해서 중복 작업이나 원인 오판을 피합니다.

  3. 허용 추가 후 앱을 완전히 재시작

    루프백 허용 규칙을 수정한 뒤에는 대상 앱을 완전히 종료하고 다시 열어야 적용됩니다. 백그라운드로 전환한 뒤 다시 앞으로 가져오는 것만으로는 재로딩되지 않습니다.

  4. 여전히 효과가 없으면 TUN 모드로 전환해 확인

    허용을 추가하고 앱도 완전히 재시작했는데 문제가 계속된다면, TUN 모드로 전환해 테스트하면 루프백 격리의 잔여 문제인지 다른 네트워크 설정 문제인지 더 구분할 수 있습니다.

루프백 격리 메커니즘 자체는 Windows 시스템 차원의 보안 설계이며, Clash 클라이언트가 사용하는 커널이나 구독 규칙과는 직접적인 관련이 없습니다 — 노드를 바꾸거나 구독을 다시 불러와도, 해당 앱의 루프백 제한을 해제하지 않으면 문제는 다시 나타납니다. 이 점을 이해하면, "스토어 앱/새 Outlook만 프록시를 타지 않는다"는 문의를 만났을 때 바로 UWP 루프백 격리라는 방향으로 짚을 수 있어, 규칙 설정에서 반복적으로 헤맬 필요가 없습니다.

클라이언트 다운로드