Windows 스토어 앱에서 프록시가 작동하지 않나요? UWP 루프백 예외 설정 방법

먼저 확인하세요: 브라우저는 정상인데 특정 스토어 앱만 연결되지 않음

Clash 클라이언트를 켜 둔 상태에서 구독이 활성화되어 있고 노드에 연결되는지 확인한 다음, 문제가 발생한 앱을 실행하세요. 브라우저에서는 시스템 프록시로 인터넷에 접속되지만 특정 UWP 앱에 오프라인 메시지가 표시되거나 로그인이 시간 초과되고 콘텐츠가 갱신되지 않는다면 로컬 루프백 제한을 확인해 볼 수 있습니다. 처음부터 구독을 바꾸거나 DNS를 수정하거나 모든 앱에 예외를 추가하지 마세요.

이 문서는 Windows 10 및 Windows 11에서 로컬 HTTP 프록시를 사용할 때의 문제 해결 방법을 다룹니다. 클라이언트마다 메뉴 이름은 다를 수 있지만 Windows 기본 도구인 CheckNetIsolation.exe로도 동일한 작업을 할 수 있습니다. 여기서 7890은 설정 예시일 뿐 모든 클라이언트에 적용되는 고정 포트가 아닙니다. 실행하기 전에 현재 설정과 일치하는지 확인하세요.

먼저 세 가지 확인

클라이언트에서 시스템 프록시가 켜져 있는지 확인하세요. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」으로 이동해 프록시 서버 주소가 127.0.0.1:7890 같은 로컬 주소를 가리키는지 확인합니다. Windows 10에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 확인할 수 있습니다.
해당 포트가 HTTP 포트 또는 mixed-port인지 확인하세요. SOCKS5만 제공하는 포트는 Windows 수동 HTTP 프록시 포트로 바로 사용할 수 없습니다.
클라이언트의 연결 목록이나 로그를 열고 문제가 발생한 앱에서 새로고침을 실행하세요. 실행 시각, 연결 표시 여부, 적용된 규칙, 연결 실패 메시지를 기록합니다.

UWP 루프백 제한: 로컬 프록시에 연결하지 못하는 이유

로컬 루프백은 127.0.0.1 또는 IPv6 주소인 ::1에 연결하는 것처럼 같은 컴퓨터에서 실행되는 네트워크 서비스에 앱이 접속하는 것을 말합니다. Clash와 Clash Meta(mihomo) 코어는 보통 로컬에서 프록시 포트를 수신 대기합니다. 데스크톱 앱이 요청을 이 포트로 보내면 코어가 규칙에 따라 직접 연결하거나 프록시 노드를 선택합니다.

UWP 앱에서 흔히 사용하는 AppContainer 샌드박스에는 네트워크 격리 규칙이 적용됩니다. 앱이 시스템 프록시 설정을 읽더라도 제한 때문에 로컬 프록시 수신 포트에 접속하지 못할 수 있습니다. 따라서 ‘설정에서 시스템 프록시를 켜 둔 상태’와 ‘앱이 로컬 프록시에 연결할 수 있는 상태’는 별개의 조건입니다. 이 경우 앱에 오류가 표시될 수도 있고 앱 자체 로직에 따라 다른 네트워크 경로를 시도할 수도 있으므로, 반드시 프록시를 우회한다고 단정할 수는 없습니다.

일반적인 프록시 경로:
앱 → 127.0.0.1:7890 → Clash / mihomo → 규칙에 따른 트래픽 분기 → 대상 서비스

제한이 발생할 수 있는 지점:
AppContainer 앱 → 로컬 루프백 포트 접근 제한 → 요청이 프록시 코어에 도달하지 않음

루프백 예외를 추가하면 지정한 앱이 이 루프백 격리 제한을 통과할 수 있습니다. 앱에 프록시를 설정해 주거나 앱이 시스템 프록시를 사용하도록 보장하지는 않습니다. 제목의 ‘제한 해제’는 해당 앱의 루프백 제한을 해제한다는 뜻이며, 실제 작업은 예외 추가이지 예외 삭제가 아닙니다.

규칙 모드와는 다릅니다: 규칙은 요청이 코어에 도달한 뒤의 출구를 결정합니다. 요청이 코어에 도달하기 전에 발생하는 샌드박스 제한은 해결하지 못합니다.
구독과는 다릅니다: 구독은 노드, 정책 그룹 또는 규칙 설정을 제공하며 Windows의 앱 격리 상태를 변경하지 않습니다.
allow-lan과는 다릅니다:allow-lan은 LAN 기기에서 프록시에 접속할 수 있도록 하는 설정입니다. 로컬 UWP의 루프백 문제를 해결할 때는 LAN 접속을 먼저 허용할 필요가 없습니다.

방법 1: 클라이언트에 내장된 루프백 예외 도구 사용

먼저 클라이언트의 설정이나 도구 메뉴에서 ‘UWP 루프백’, ‘루프백 예외’, ‘Loopback’ 또는 ‘UWP Loopback’ 항목을 찾아보세요. 버전에 따라 별도 도구가 열릴 수도 있고 해당 기능이 없을 수도 있습니다. 같은 이름의 버튼을 찾으려고 지원이 중단된 구버전 클라이언트를 설치하지 마세요. 메뉴가 없다면 다음 절의 Windows 명령을 사용하면 됩니다.

대상 앱을 선택하고 저장

대상 앱을 설치된 상태로 두고 작업 전에 앱을 종료하세요. 그래야 설정 후에도 이전 연결이 계속 사용되는 일을 방지할 수 있습니다.
클라이언트의 루프백 도구를 실행하세요. 사용자 계정 컨트롤 창이 나타나면 프로그램 출처를 확인한 뒤 관리자 권한을 허용합니다.
목록에서 대상 앱을 찾고 표시 이름과 패키지 정보를 확인한 다음, 로컬 프록시에 접속해야 하는 앱만 선택하세요.
도구에서 ‘저장’, ‘적용’ 또는 해당하는 확인 버튼을 누르세요. 선택만 하고 저장하지 않으면 시스템 설정이 바뀌지 않는 경우가 많습니다.
대상 앱을 다시 실행해 네트워크 작업을 수행하고 클라이언트 연결 목록을 확인하세요.

목록에서 대상 앱을 찾을 수 없다면 현재 Windows 사용자 계정에 설치되어 있는지 확인한 뒤 도구를 다시 여세요. 일부 도구는 최신 버전 앱이나 다른 계정의 패키지를 모두 표시하지 못할 수 있습니다. 이때는 이름이 비슷한 항목을 고르는 대신 실제 패키지 패밀리 이름을 조회하세요.

방법 2: CheckNetIsolation으로 지정한 패키지에 예외 추가

시작 메뉴를 마우스 오른쪽 버튼으로 클릭하고 「터미널(관리자)」를 선택하세요. Windows 10에서는 「Windows PowerShell(관리자)」로 표시될 수도 있습니다. 아래의 패키지 정보 조회 명령은 PowerShell 환경에서 실행해야 합니다. 예외 목록을 수정하려면 관리자 권한이 필요합니다. 다만 조회할 때는 현재 사용자를 확인하세요. 다른 관리자의 자격 증명으로 터미널을 실행하면 표시되는 앱 목록이 현재 로그인한 계정의 목록과 다를 수 있습니다.

1단계: 기존 예외 목록 기록

CheckNetIsolation.exe LoopbackExempt -s

-s는 현재 루프백 예외 목록을 표시합니다. 대상 패키지가 이미 있는지 확인할 수 있도록 먼저 출력을 보관하세요. 출력에는 앱 이름과 보안 식별 정보가 포함될 수 있습니다. 목록이 길다는 이유만으로 전부 지우지 마세요. 다른 소프트웨어가 기존 설정을 사용하고 있을 수 있습니다.

2단계: 대상 앱의 패키지 패밀리 이름 조회

PowerShell에서 다음 명령을 실행하면 현재 사용자 계정에 설치된 앱의 패키지 이름과 패키지 패밀리 이름을 확인할 수 있습니다. 목록이 길면 두 번째 명령으로 실제 이름을 검색하세요. 아래에서는 Microsoft Store를 예로 들지만, 스토어에서 발생하는 모든 네트워크 문제가 루프백 제한 때문이라는 뜻은 아닙니다.

Get-AppxPackage | Select-Object Name, PackageFamilyName

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

-n에는 시작 메뉴의 표시 이름이나 버전 및 아키텍처가 포함된 PackageFullName이 아니라 PackageFamilyName을 입력해야 합니다. Microsoft Store에서 흔히 사용하는 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe입니다. 실제 값은 이 PC에서 조회한 결과로 확인하세요.

3단계: 확인한 대상 패키지에만 예외 추가

아래 PowerShell 코드는 먼저 Microsoft Store 패키지를 조회하고, 찾지 못하면 중단해 빈 값으로 작업이 계속되지 않도록 합니다. 다른 앱을 점검하는 경우 앞 단계의 목록에서 확인한 실제 Name에 맞게 조회 이름을 바꾸세요. 예시를 모든 앱에 적용되는 해결 명령으로 사용하지 마세요.

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $pkg) {
    throw "현재 사용자 계정에서 Microsoft.WindowsStore를 찾을 수 없습니다. 앱 이름과 로그인 계정을 확인하세요."
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-a는 추가를 뜻합니다. 명령이 성공했는지 확인한 다음 -s로 목록에 대상 항목이 나타나는지 확인하세요. 이 PC에서 패키지 패밀리 이름을 이미 확인했다면 아래 명령을 바로 실행할 수도 있습니다. 이 명령에도 관리자 권한이 필요합니다.

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

4단계: 앱을 종료한 뒤 다시 테스트

작업 중인 내용을 저장하고 대상 앱을 종료하세요. 필요하다면 작업 관리자에서 남아 있는 프로세스를 끝낸 다음 앱을 다시 열어 콘텐츠를 새로고침합니다. 일반적으로 PC 전체를 다시 시작할 필요는 없습니다. 이때도 클라이언트를 켜 두고 시스템 프록시를 활성화해야 하며, 앞에서 연결을 확인한 노드를 사용하세요.

‘액세스가 거부되었습니다’라는 메시지가 나오면 관리자 터미널을 사용 중인지 확인하세요. 잘못된 매개변수 오류가 발생하면 하이픈, 패키지 패밀리 이름, 복사 과정에서 명령이 줄바꿈되어 잘리지 않았는지 확인합니다. 조직에서 관리하는 기기는 정책에 의해 제한될 수 있으므로 보안 기능을 반복해서 끄기보다 관리자에게 확인하세요.

검증 방법: 포트 연결, 앱 요청, 트래픽 출구

명령이 성공적으로 실행됐다는 것은 예외 설정이 적용됐다는 뜻일 뿐, 앱이 프록시를 사용한다는 증거는 아닙니다. 검증을 세 단계로 나누고 한 번에 한 가지 조건만 바꾸면 실제로 영향을 준 설정을 찾기 쉽습니다.

검증 단계	확인 방법	확인할 수 있는 내용
프록시 포트	로컬 TCP 포트 7890 테스트	접속 가능한 서비스가 해당 포트에서 수신 대기하는지
앱 요청	대상 앱을 새로고침하고 연결 목록 확인	요청이 Clash 또는 mihomo에 도달했는지
규칙에 따른 출구	도메인, 규칙 및 정책 체인 확인	요청이 최종적으로 직접 연결되는지 프록시를 사용하는지

PowerShell에서 다음 명령을 실행하세요. 현재 설정에 7897을 사용한다면 포트도 7897로 바꾸세요. 출력의 TcpTestSucceeded : True는 TCP 연결이 성공했다는 뜻일 뿐, 해당 포트에서 수신 대기하는 프로그램이 Clash라는 의미는 아닙니다. UWP의 루프백 권한이 정상인지도 확인해 주지 않습니다.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

Windows 기본 도구인 curl.exe에서 HTTP 프록시를 명시해 일반 데스크톱 프로세스가 해당 포트로 HTTPS 요청을 보내는지 테스트할 수도 있습니다. curl.exe라는 전체 이름을 사용하면 일부 PowerShell 버전에서 같은 이름을 사용하는 별칭을 피할 수 있습니다.

curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://www.microsoft.com/

HTTP 응답을 받았다는 것은 해당 명령이 서버나 중간 장치의 응답을 받았다는 뜻입니다. 전체 결과는 로그와 함께 확인해야 하며, 대상 UWP 앱을 직접 테스트한 것은 아닙니다. 마지막으로 앱에서 로그인이나 새로고침을 실행하고 같은 시각에 새 연결이 발생하는지 확인하세요. 백그라운드 트래픽이 많다면 다른 앱을 잠시 종료해 방해 요인을 줄일 수 있습니다.

예외를 추가했는데도 실패한다면: 증상별 추가 점검

연결 목록에 대상 요청이 전혀 표시되지 않음

먼저 대상 앱이 실제로 AppContainer 루프백 제한을 받는지, 현재 설치된 패키지에 예외가 적용됐는지 확인하세요. 다음으로 앱이 시스템 프록시를 사용하는지 살펴봅니다. 일부 프로그램은 자체 네트워크 스택을 사용하고, 일부 요청은 시스템 서비스나 다른 프로세스에서 발생합니다. 앱 화면에 표시되는 패키지에 예외를 추가해도 다른 프로세스의 네트워크 동작까지 바뀌지는 않습니다.

Windows 설정의 수동 프록시, PAC 자동 구성, WinHTTP 프록시는 서로 다른 설정입니다. netsh winhttp import proxy source=ie를 만능 해결책으로 사용하지 마세요. 별도의 프록시 설정을 변경하는 명령이라 대상 앱에는 영향을 주지 않을 수 있습니다.
Microsoft Store의 화면 로딩, 계정 로그인, 앱 다운로드는 서로 다른 구성 요소를 사용할 수 있습니다. 화면이 정상으로 돌아왔다고 해서 다운로드 서비스도 같은 경로를 사용한다고 볼 수 없으므로 각각 테스트하세요.
스토어 캐시를 지우거나 앱을 다시 설치하는 것은 다른 종류의 문제를 해결하는 방법입니다. 루프백 예외를 확인하는 작업을 대신할 수 없으며, 오류 근거도 없이 먼저 시도할 필요는 없습니다.

요청은 표시되지만 규칙 결과가 DIRECT

요청이 이미 코어에 도달했으므로 이제 예외를 더 추가할 것이 아니라 규칙과 정책 그룹을 확인해야 합니다. 연결의 도메인, 대상 IP, 적용된 규칙, 실제 출구를 살펴보세요. 설정에 따라 해당 서비스가 DIRECT로 지정된 경우 루프백 예외를 추가해도 프록시로 강제 전환되지는 않습니다.

비교를 위해 잠시 전역 모드로 전환할 수 있지만, 전역 모드에서도 사용 가능한 프록시 정책을 선택해야 합니다. 테스트가 끝나면 기존 규칙 모드로 되돌리세요. 전역 모드에서 된다는 이유만으로 전체 규칙을 계속 대체하지 말고, 해당 도메인과 규칙 우선순위를 먼저 확인하세요.

요청이 프록시를 사용하지만 로그인은 여전히 실패함

로그에서 DNS 오류, 연결 시간 초과, TLS 오류를 확인하고 계정 지역, 시스템 시간, 서비스 상태도 점검하세요. 웹 페이지를 열 수 있는 노드라고 해서 대상 서비스가 해당 출구를 허용한다는 뜻은 아닙니다. 인증서 문제가 발생해도 인증서 검증을 끄는 방식으로 오류를 숨기지 마세요. 먼저 시스템 시간, 인증서 체인, 별도의 HTTPS 검사 프로그램이 있는지 확인하세요.

TUN 모드를 켜야 하나요?

TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱을 점검할 때 유용할 수 있습니다. 하지만 ‘루프백 예외 추가’와 같은 기능은 아닙니다. 실제 동작은 클라이언트, mihomo 설정, 라우팅, DNS, Windows 네트워크 격리 정책에 따라 달라지므로 TUN을 켜도 모든 UWP 요청이 작동한다고 보장할 수 없습니다.

TUN을 테스트하려면 먼저 현재 설정을 저장하고 클라이언트 안내에 따라 서비스를 설치하거나 활성화한 뒤, 한 번에 설정 하나만 변경하세요. 활성화 전후의 연결과 라우팅 상태를 기록합니다. Fake-IP, 규칙, 시스템 프록시, 방화벽을 동시에 변경하면 어떤 조치가 결과를 바꿨는지 파악하기 어렵습니다. 관련 설정은 고급 설정에서 확인할 수 있습니다.

예외 해제 및 관리

앱이 더 이상 로컬 프록시에 접속할 필요가 없다면 해당 예외를 삭제할 수 있습니다. 아래에서는 앞에서 확인한 Microsoft Store 패키지 패밀리 이름을 예로 듭니다. -d는 지정한 항목을 삭제한다는 뜻이며 앱을 제거하거나 Clash 설정을 삭제하지는 않습니다.

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

예외 하나를 취소하기 위해 전체 예외 목록을 지우지 마세요. 앱을 업데이트해도 일반적으로 패키지 패밀리 ID는 유지됩니다. 다시 설치하거나 배포 경로를 바꾸거나 다른 계정을 사용한다면 실제 이름을 다시 조회하세요. 이전 이름을 무조건 반복해서 추가할 필요는 없습니다. 시스템 프록시 포트가 바뀌면 Windows 프록시 주소도 함께 확인해야 합니다. 루프백 예외가 포트를 자동으로 변경해 주지는 않습니다.

브라우저에서도 연결되지 않음: 먼저 클라이언트, 수신 포트, 구독 및 노드 연결을 확인하세요.
격리된 앱만 실패하고 연결 기록이 없음: 앱 종류, 패키지 패밀리 이름, 루프백 예외를 확인하세요.
연결 기록이 있음: 규칙, DNS, 프록시 출구 및 대상 서비스를 확인하세요. 모든 문제를 UWP 탓으로 돌리지 마세요.

문제 해결 순서는 다음과 같이 정할 수 있습니다. 로컬 프록시가 작동하는지 확인하고, 대상 앱을 식별한 다음 필요한 경우에만 예외를 추가합니다. 앱을 다시 시작한 뒤 연결과 출구를 확인하세요. 이렇게 하면 실제로 로컬 루프백 제한 때문에 발생한 문제를 해결하는 동시에 규칙에 따른 트래픽 분기, 시스템 서비스 프록시, 계정 문제를 혼동하지 않을 수 있습니다.