Windows 스토어 앱에서 프록시가 작동하지 않을 때: UWP 루프백 제한 해제 방법 3가지

먼저 확인할 사항: UWP 루프백 제한인가, 프록시 자체 문제인가

브라우저에서는 인터넷이 되는데 Microsoft Store나 특정 스토어 앱만 계속 로딩된다면 UWP 루프백 제한부터 확인해 볼 수 있습니다. Clash의 시스템 프록시는 보통 127.0.0.1:7890 같은 로컬 주소를 사용합니다. AppContainer 격리 환경에서 실행되는 앱은 기본적으로 일반 데스크톱 프로그램처럼 로컬 루프백 서비스에 접근할 수 없어 프록시 주소에 연결하지 못할 수 있습니다.

다만 스토어에서 설치했다고 해서 모두 같은 UWP 제한을 받는 것은 아닙니다. Microsoft Store는 기존 데스크톱 프로그램도 배포하며, 패키지로 제공되는 데스크톱 앱의 네트워크 동작도 다를 수 있습니다. 여기서 설명하는 루프백 예외 설정은 AppContainer 네트워크 격리의 영향을 받는 앱을 대상으로 합니다. 스토어 다운로드 실패가 모두 이 문제 때문이라고 단정하지 마세요.

먼저 기본 점검 세 가지

프록시 포트를 확인합니다. 클라이언트의 포트 설정에서 HTTP 포트 또는 혼합 포트를 확인하세요. 이 글에서는 7890을 예로 듭니다. 실제 포트가 7897이라면 아래 테스트에서도 7897로 바꿔야 합니다.
Windows 프록시 주소를 확인합니다. Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」→「편집」으로 이동해 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 클라이언트의 시스템 프록시 기능을 사용한다면 클라이언트가 해당 값을 관리하도록 하고, 양쪽에서 번갈아 덮어쓰지 않도록 합니다.
프록시 출구가 정상인지 확인합니다. 브라우저에서 대상 서비스에 접속하고 Clash의 연결 또는 로그 화면에서 요청을 확인하세요. 브라우저에서도 접속에 실패한다면 구독, 선택한 노드, 라우팅 규칙부터 점검하세요. 바로 여러 앱에 루프백 예외를 추가하지 마세요.

PowerShell에서 아래 두 명령으로 로컬 포트와 명시적 HTTP 프록시를 각각 확인할 수 있습니다. 두 번째 명령의 주소는 HTTP 포트 또는 HTTP를 지원하는 혼합 포트 테스트용이며, SOCKS만 제공하는 포트에는 사용할 수 없습니다.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 20 https://www.microsoft.com/

세 가지 방법 비교: 앱 하나라면 루프백 예외부터

앞의 두 방법은 모두 Windows의 루프백 예외 목록을 수정합니다. 그래픽 도구는 앱을 골라 설정하기 편하고, 명령줄은 패키지 이름 확인과 예외 취소에 유용합니다. 세 번째 방법은 TUN으로 네트워크 트래픽을 처리하므로 앱이 로컬 HTTP 프록시에 직접 연결할 필요가 없습니다. 이는 대체 트래픽 경로를 사용하는 방식이지, 앱에 루프백 권한을 추가하는 방법은 아닙니다.

방법	적합한 상황	적용 범위
클라이언트 내장 루프백 도구	클라이언트에 UWP 또는 Loopback 메뉴가 있고, 몇 개 앱만 설정하면 되는 경우	선택한 앱에 루프백 예외 추가
CheckNetIsolation 명령	패키지 이름을 확인하거나 현재 목록을 조회하고, 특정 예외를 정확히 취소해야 하는 경우	패키지 패밀리 이름을 기준으로 예외 목록 관리
TUN 가상 네트워크 어댑터	앱이 시스템 프록시를 따르지 않거나 더 많은 네트워크 트래픽을 처리해야 하는 경우	트래픽 처리 방식을 변경하므로 라우팅과 DNS를 추가로 점검해야 함

먼저 앞의 두 방법 중 하나를 시도하는 것이 좋습니다. 예외를 추가한 뒤에도 해결되지 않으면 앱이 시스템 프록시를 사용하는지, 대상 도메인이 직접 연결로 라우팅되는지, TUN이 필요한지 확인하세요. 문제를 좁히려면 한 번에 변수 하나만 바꾸고 변경 전후 로그를 남겨 두세요.

방법 1: 클라이언트 내장 UWP 루프백 도구 사용

일부 Windows 클라이언트에는 루프백 예외 도구가 포함되어 있습니다. 메뉴 이름은 「UWP 루프백」, 「UWP Loopback」, 「Loopback Exemption」 등으로 표시될 수 있습니다. 클라이언트와 버전에 따라 메뉴 위치가 다르므로 모든 Clash 클라이언트에 같은 메뉴가 있다고 가정하면 안 됩니다. 설정에서 해당 메뉴를 찾을 수 없다면 다음 절의 Windows 기본 명령을 사용하세요.

Clash를 실행하고 시스템 프록시가 켜져 있는지 확인한 뒤 현재 수신 포트를 기록합니다.
클라이언트 설정에서 UWP 또는 Loopback 관련 메뉴를 찾아 도구를 엽니다. Windows에서 관리자 권한을 요청하면 프로그램 출처를 확인한 뒤 허용하세요.
앱 목록에서 Microsoft Store 등 대상 앱을 찾습니다. 이름과 패키지 식별자가 함께 표시된다면 비슷한 아이콘만 보고 판단하지 말고 패키지 식별자도 확인하세요.
로컬 프록시를 사용할 앱만 선택한 뒤 도구의 저장 또는 적용 버튼을 누릅니다. 버튼 이름은 도구마다 다를 수 있습니다.
대상 앱을 완전히 종료한 뒤 다시 실행합니다. 백그라운드 프로세스가 남아 있다면 작업 관리자에서 해당 앱의 작업을 끝낸 다음 테스트하세요.

목록에서 대상 앱을 찾을 수 없다면

앱이 다른 계정이 아니라 현재 Windows 사용자 계정에 설치되어 있는지 먼저 확인하세요. 목록을 새로 고쳐도 보이지 않는다면 PowerShell로 패키지 이름을 조회합니다. 기존 Win32 앱은 이 도구로 관리할 수 없는 대상일 수 있으므로, 이름이 비슷한 패키지를 선택한다고 해결되지는 않습니다.

방법 2: CheckNetIsolation으로 예외를 정확히 추가하고 취소

Windows 10과 Windows 11에는 별도의 루프백 도구를 설치하지 않아도 사용할 수 있는 CheckNetIsolation.exe가 포함되어 있습니다. 「시작」 메뉴에서 PowerShell을 검색하고 마우스 오른쪽 버튼을 눌러 「관리자 권한으로 실행」을 선택하세요. 아래 조회는 현재 로그인한 사용자에게 설치된 Microsoft Store를 예로 들며, 모든 사용자 계정의 패키지를 먼저 검색할 필요는 없습니다.

1단계: PackageFamilyName 조회

Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

Microsoft Store에서 흔히 사용하는 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe입니다. 실제로는 해당 PC에서 조회한 결과를 기준으로 하세요. 필요한 값은 PackageFamilyName이며, 버전과 프로세서 아키텍처가 포함된 PackageFullName이 아닙니다.

다른 앱을 찾으려면 현재 사용자 계정의 패키지 목록을 먼저 확인한 다음 이름으로 필터링할 수 있습니다. 아래 명령은 이름순으로 정렬해 대상 앱을 쉽게 찾도록 합니다.

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

2단계: 기존 목록 확인 및 대상 패키지 추가

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

-s는 기존 예외를 표시하고, -a는 항목을 추가하며, -n은 패키지 패밀리 이름을 지정합니다. 마지막으로 목록을 다시 조회해 대상 패키지가 추가됐는지 확인하세요. 명령이 정상 실행됐다는 것은 권한 설정이 완료됐다는 뜻일 뿐입니다. 앱을 다시 시작한 뒤 실제 요청도 확인해야 합니다.

3단계: 변수를 사용해 다른 앱 처리하기

아래 예시도 Microsoft Store를 사용합니다. 먼저 조회 결과를 변수에 저장한 다음 명령에 전달합니다. 다른 앱을 처리할 때는 앞 단계의 목록에서 정확한 Name을 확인한 뒤 조회 조건을 바꾸세요. 앱의 표시 이름을 패키지 이름으로 바로 사용하면 안 됩니다.

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
} else {
    Write-Output "현재 사용자 계정에서 Microsoft Store 패키지를 찾을 수 없습니다."
}

취소할 때는 이번에 추가한 항목만 삭제

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s

-d는 지정한 예외를 삭제합니다. 한 번의 문제 해결을 위해 목록 전체를 지우면 다른 앱 설정에 영향을 줄 수 있습니다. 액세스 거부 오류가 발생하면 터미널이 관리자 권한으로 실행 중인지 확인하세요. 패키지를 찾을 수 없다면 현재 사용자 계정의 설치 상태와 패키지 패밀리 이름을 다시 조회하고, 식별자를 추측하지 마세요.

방법 3: 시스템 프록시를 따르지 않는 앱은 TUN으로 처리

앱이 Windows 시스템 프록시를 사용하지 않는다면 루프백 예외를 추가해도 요청이 자동으로 Clash에 전달되지는 않습니다. 이 경우 mihomo 기반 클라이언트처럼 TUN을 지원하는 클라이언트를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 IP 트래픽을 처리하므로 앱이 127.0.0.1:7890에 직접 연결할 필요가 없습니다.

커널과 권한 확인. 클라이언트의 커널 정보에서 현재 사용하는 커널이 TUN을 지원하는지 확인하세요. 서비스 모드 설치를 요청하는 클라이언트라면 화면의 안내에 따라 설치하고 서비스가 실행 중인지 확인합니다. 구현에 따라 관리자 권한으로 실행해야 할 수도 있습니다.
테스트 조건을 하나로 설정. 먼저 시스템 프록시 상태를 기록한 다음 시스템 프록시를 잠시 끄고 TUN만 켜서 테스트하세요. 어느 경로가 작동했는지 구분하기 쉽습니다.
라우팅과 DNS 처리 활성화. 클라이언트 TUN 설정에서 자동 라우팅과 DNS 관련 옵션을 확인하세요. mihomo 설정에서 흔히 쓰이는 필드는 tun.enable, auto-route, dns-hijack이지만, 설정 일부만 복사한다고 모든 클라이언트에 적용되는 것은 아닙니다.
대상 앱을 다시 시작하고 연결 확인. 클라이언트 연결 목록에 요청이 표시되는지 확인한 뒤 적용된 규칙, 정책 그룹, 실제 출구를 살펴보세요.

TUN으로 트래픽을 처리한다고 해서 모든 트래픽이 프록시 노드를 거치는 것은 아닙니다. Clash가 Rule 모드라면 요청은 여전히 규칙에 따라 처리되며 DIRECT로 연결되거나 프록시 정책 그룹을 사용할 수 있습니다. 스토어 관련 도메인이 직접 연결로 설정되어 있고 현재 네트워크에서 직접 연결할 수 없다면 로딩에 실패할 수 있습니다.

예외를 추가해도 해결되지 않을 때: 로그로 문제 유형 구분

1. 대상 요청이 전혀 보이지 않음

먼저 앱을 완전히 종료한 뒤 다시 실행하고, Windows 시스템 프록시가 클라이언트의 실제 포트를 가리키는지 확인하세요. 루프백 목록이 올바르고 브라우저의 명시적 프록시 테스트도 성공했는데 해당 앱의 요청 기록이 계속 없다면, 앱이 시스템 프록시를 사용하지 않거나 다른 구성 요소가 요청을 보낼 수 있습니다. 같은 패키지를 반복해서 추가하는 대신 TUN으로 비교 테스트해 보세요.

2. 요청은 보이지만 규칙이 DIRECT로 적용됨

요청이 커널에 도달했다는 뜻이므로 라우팅 규칙을 확인하세요. 연결 상세 정보에서 대상 도메인, 규칙 유형, 출구를 살펴봅니다. Microsoft Store의 로그인, 페이지 콘텐츠, 다운로드는 서로 다른 도메인이나 시스템 구성 요소를 사용할 수 있습니다. 한 접속 경로를 해결해도 전체 다운로드 과정이 해결되는 것은 아닙니다. 페이지가 열린다는 이유만으로 백그라운드 다운로드도 같은 경로를 사용한다고 판단하지 마세요.

3. 프록시에 연결한 뒤 시간 초과 또는 DNS 오류 발생

선택한 노드가 같은 대상에 접속할 수 있는지 확인하고, 로그에 도메인 조회 실패가 있는지 살펴보세요. TUN을 사용한다면 DNS 요청이 의도한 설정에 따라 처리되는지도 확인해야 합니다. 기업 네트워크의 내부 도메인, 다른 VPN의 DNS, 클라이언트 DNS 설정이 충돌할 수 있으므로 하나씩 테스트하세요. DNS 서버, 노드, 라우팅을 한꺼번에 바꾸지 마세요.

4. 페이지는 열리지만 다운로드가 멈춤

다운로드에는 시스템 서비스나 다른 프로세스가 관여할 수 있습니다. 특정 앱에 루프백 예외를 추가해도 PC의 모든 서비스가 사용자 프록시를 사용하는 것은 아닙니다. WinHTTP 전역 프록시를 변경하는 명령을 바로 실행하거나, 네트워크 문제를 대신 해결하려고 스토어 캐시를 반복해서 초기화하지 마세요. 다운로드 중 새 연결이 생기는지, 어떤 프로세스가 연결을 만드는지 먼저 확인한 뒤 TUN 사용이나 규칙 수정이 필요한지 판단하세요.

결과 확인 및 원상 복구: 재현 가능한 설정 유지

앱 기능 확인: 실행, 로그인, 콘텐츠 로딩, 다운로드를 각각 테스트하세요. 버튼 하나가 작동한다고 모든 기능이 해결된 것은 아닙니다.
프록시 경로 확인: 연결 기록에서 적용된 규칙과 출구를 확인하세요. 테스트가 끝나면 임시 설정을 평소 사용하는 Rule 모드로 되돌립니다.
변경 사항 기록: 앱 패키지 패밀리 이름, 실제 포트, 추가한 예외를 기록해 두면 나중에 설정을 옮기거나 취소하기 쉽습니다.
원상 복구가 필요할 때: 그래픽 도구에서 해당 앱의 선택을 해제하거나 LoopbackExempt -d로 지정한 패키지를 삭제하세요. TUN을 테스트했다면 TUN과 시스템 프록시도 원래 상태로 되돌립니다.

가장 간단한 점검 순서는 로컬 프록시가 정상인지 확인한 다음, 제한을 받는 앱에 루프백 예외를 추가하고, 앱이 시스템 프록시를 사용하지 않을 때 TUN을 검토하는 것입니다. 이렇게 하면 포트, 권한, 라우팅, 분기 규칙 문제를 나눠 살펴볼 수 있고, 변경 후 어느 단계가 효과가 있었는지도 정확히 확인할 수 있습니다.