Windows 스토어 앱에서 프록시가 작동하지 않을 때: UWP 루프백 예외 설정과 CheckNetIsolation 사용법
UWP 앱의 로컬 루프백 주소 접근이 기본적으로 차단되는 이유와 GUI·명령줄 예외 설정 방법을 알아보고, 설정 해제 및 적용 여부 확인 방법도 살펴봅니다.
먼저 확인할 점: 루프백 제한인가, 앱의 프록시 미사용인가
브라우저에서는 Clash 클라이언트로 인터넷에 연결되는데 특정 Windows 스토어 앱만 계속 로딩된다면, 구독이 만료된 것은 아닐 수 있습니다. 클라이언트가 HTTP 또는 혼합 프록시 포트를 127.0.0.1에서 수신하고, 대상 앱이 제한된 AppContainer에서 실행된다면 앱이 이 로컬 포트에 연결하지 못할 수 있습니다. 이때 확인해 볼 설정 중 하나가 UWP 루프백 예외입니다.
다만 Microsoft Store는 앱 배포 경로일 뿐, 앱의 실행 모델을 뜻하지는 않습니다. 스토어에서 받은 기존 Win32 프로그램, 패키지형 데스크톱 앱, UWP 앱은 네트워크 제한이 서로 다를 수 있습니다. AppContainer 루프백 제한이 실제 원인인지 확인한 경우에만 예외 설정이 도움이 됩니다. 스토어에서 설치했다는 이유만으로 예외를 추가할 필요는 없습니다.
| 확인된 증상 | 우선 확인할 항목 |
|---|---|
| 브라우저와 대상 앱 모두 인터넷에 연결되지 않음 | 프록시 포트, 설정 파일 적용 여부, 노드 상태, 시스템 프록시 주소 |
| 브라우저는 정상인데 컨테이너 앱 하나만 연결 실패 | 앱의 시스템 프록시 사용 여부와 해당 앱의 루프백 예외 |
| 클라이언트에 대상 연결이 보이지만 DIRECT로 처리됨 | 규칙 순서와 프록시 그룹 선택을 확인하세요. 예외를 반복해서 추가할 문제는 아닙니다. |
| TUN을 켜도 연결되지 않음 | 트래픽 가로채기 여부, DNS와 라우팅, 앱 서버 응답을 확인하세요. 결과만으로 루프백 제한이라고 단정할 수 없습니다. |
UWP·AppContainer와 127.0.0.1의 관계
127.0.0.1은 IPv4 루프백 주소로, 연결이 로컬 네트워크의 다른 기기로 전달되지 않습니다. Clash 계열 GUI 클라이언트는 보통 로컬에서 코어를 실행한 뒤 HTTP·SOCKS·혼합 포트로 앱의 요청을 받습니다. Windows 시스템 프록시는 해당 설정을 따르는 앱에 요청을 이 로컬 포트로 보내도록 안내합니다.
AppContainer는 Windows의 앱 격리 방식입니다. 앱 ID와 권한을 기준으로 리소스 접근을 제한하며, 네트워크 접근 경계도 여기에 포함됩니다. 프록시 서비스가 같은 PC에서 실행 중이어도 제한된 컨테이너는 해당 서비스에 연결하지 못할 수 있습니다. CheckNetIsolation.exe의 LoopbackExempt 하위 명령으로 이러한 루프백 예외를 관리할 수 있습니다.
TUN 모드와의 차이
- 시스템 프록시 경로: 앱이 먼저 프록시 설정을 읽은 뒤 로컬 프록시 포트에 직접 연결합니다. 이 단계에서 루프백 제한이 발생할 수 있습니다.
- TUN 경로: 클라이언트가 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 IP 트래픽을 가로챕니다. 일반적으로 앱이 HTTP 프록시 포트에 직접 연결할 필요는 없습니다.
- 적용 범위: TUN의 실제 동작은 라우팅, DNS, 권한, 앱 동작에도 영향을 받습니다. 모든 루프백 예외를 추가하는 것과 같은 기능은 아닙니다.
문제를 확인할 때는 명확한 트래픽 처리 방식 하나만 유지하세요. 예를 들어 TUN을 끄고 시스템 프록시와 특정 앱의 루프백 연결만 테스트합니다. 프록시 모드, DNS, 규칙, 예외를 한꺼번에 바꾸면 연결이 복구되더라도 어떤 설정이 원인이었는지 알기 어렵습니다.
작업 전 확인: 프록시 포트와 테스트 기준
아래 예시는 127.0.0.1:7890을 기준으로 합니다. 7890은 모든 클라이언트에 공통으로 적용되는 포트가 아닙니다. 현재 클라이언트 설정과 실제 적용된 구성에서 포트를 확인하세요. mihomo 설정의 mixed-port는 HTTP와 SOCKS를 모두 제공합니다. socks-port만 설정된 경우 이를 Windows HTTP 시스템 프록시 포트로 입력하면 안 됩니다.
- 클라이언트 설정에서 HTTP 또는 혼합 포트를 확인하고 코어가 실행 중인지 확인합니다.
- Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」→「프록시 서버 사용」으로 이동해 주소와 포트를 확인합니다. Windows 10에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 확인할 수 있습니다.
- 클라이언트가 이 설정을 관리한다면 클라이언트의 스위치로 조정하세요. Windows 설정과 클라이언트 상태가 서로 덮어쓰는 상황을 피할 수 있습니다.
- 대상 앱 이름, 실패한 작업, 발생 시각을 기록해 두면 나중에 연결 목록이나 로그와 대조하기 쉽습니다.
먼저 PowerShell에서 예시 포트로 TCP 연결이 가능한지 확인한 다음, 프록시를 명시해 HTTPS 요청을 보낼 수 있습니다.
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/TcpTestSucceeded : True는 포트에 연결할 수 있다는 뜻일 뿐입니다. HTTP 응답을 확인하면 프록시 경로가 연결됐는지 판단하는 데 도움이 됩니다. 원격 서버에서 403 등의 응답을 반환해도 프록시 포트가 고장 났다는 뜻은 아닙니다. 여기서는 Windows PowerShell의 curl 별칭으로 인한 인수 차이를 피하기 위해 curl.exe를 사용합니다.
두 검사는 데스크톱 프로세스에서 실행되므로 UWP 앱에 루프백 권한이 부여됐다는 사실을 입증하지는 않습니다. 기준 테스트부터 실패한다면 컨테이너 권한을 조정하기 전에 수신 포트나 상위 연결 문제를 해결하세요. 이 문제를 해결하려고 「LAN 허용」을 켜거나 수신 주소를 0.0.0.0으로 바꾸지 마세요. 수신 범위를 넓히는 것과 루프백 예외를 추가하는 것은 별개의 작업입니다.
명령줄로 루프백 예외 조회·추가·삭제하기
1. 기존 목록을 기록하고 정확한 패키지 ID 찾기
시작 메뉴에서 PowerShell을 검색한 다음 「관리자 권한으로 실행」을 선택합니다. 다른 관리자 계정의 자격 증명으로 권한을 높이면 패키지 조회 결과가 다른 사용자 계정의 것이 될 수 있습니다. 먼저 대상 앱을 사용하는 사용자 세션에서 패키지 정보를 조회한 뒤, 관리자 권한 창에서 변경하세요.
CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage |
Sort-Object Name |
Select-Object Name, PackageFamilyName-s는 기존 예외 목록을 표시합니다. 추가하기 전에 출력을 저장하거나 화면을 캡처해 두면 해당 설정이 원래 있었는지 확인하기 쉽습니다. Get-AppxPackage는 기본적으로 현재 사용자의 패키지만 표시합니다. 표시 이름으로 패키지 ID를 추측하면 오류가 생길 수 있으므로 출력에서 PackageFamilyName을 확인하세요.
예를 들어 Microsoft Store 자체의 패키지 ID를 조회하려면 다음 명령을 실행합니다.
Get-AppxPackage -Name Microsoft.WindowsStore |
Select-Object Name, PackageFamilyName일반적인 결과에서 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe입니다. 버전과 아키텍처 등이 포함된 PackageFullName과는 다릅니다. 아래 -n 인수에는 패키지 패밀리 이름을 사용해야 합니다. 조회 결과가 없다면 앱이 현재 계정에 설치되어 있는지 먼저 확인하고, 표시 이름을 그대로 명령에 입력하지 마세요.
2. 대상 앱에만 예외 추가하기
아래 예시는 Microsoft Store 자체를 대상으로 하며, 스토어에서 다운로드한 다른 앱에 권한을 추가하지 않습니다. 조회 결과가 예시와 정확히 일치할 때만 그대로 실행하세요. 다른 앱에는 해당 앱에서 조회한 패키지 패밀리 이름을 사용해야 합니다.
CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s명령 실행 후 목록에 해당 ID가 표시되는지, 오류가 반환되지 않았는지 확인합니다. 액세스가 거부되면 터미널이 관리자 권한으로 실행 중인지 확인하세요. 이름이나 인수 오류가 발생하면 패키지 ID와 영문 반각 따옴표를 다시 확인합니다. 목록에 추가됐다면 대상 앱을 완전히 종료한 뒤 다시 실행하세요. 이전에 실패한 연결을 재사용하지 않도록 하기 위해서입니다.
3. 이번에 추가한 예외 취소하기
CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s-d는 지정한 앱의 예외를 삭제합니다. 이번 작업에서 새로 추가한 항목만 취소하세요. 작업 전에 이미 있던 항목이라면 테스트를 위해 삭제하면 안 됩니다. 모든 패키지에 일괄 권한을 부여하는 스크립트를 실행하거나 전체 목록을 지워 특정 항목의 예외를 취소하지 마세요. 개발 도구나 다른 앱이 기존 항목에 의존할 수 있습니다.
GUI로 설정하기: 루프백 목록에서 대상 앱 선택
Windows 「설정」에는 UWP 루프백 예외를 일괄 관리하는 일반 체크박스가 없습니다. PC에 Fiddler Classic이 설치되어 있다면 도구 모음의 WinConfig를 눌러 루프백 예외 도구를 열 수 있습니다. 일부 화면에서는 「Tools」→「Win8 Loopback Exemptions」에서 열 수도 있습니다. 메뉴에 Win8이라고 표시되지만, 관리 대상은 Windows AppContainer 루프백 설정입니다.
- 앞서 설명한 프록시 포트를 확인하고 현재 시스템 프록시 값을 기록합니다.
- Fiddler Classic을 열고 「File」→「Capture Traffic」의 체크를 해제해 캡처 프록시가 테스트 트래픽을 가로채지 않도록 합니다.
- WinConfig를 열고 안내에 따라 관리자 권한을 허용한 뒤 앱 컨테이너 목록이 로드될 때까지 기다립니다.
- 확인할 대상 앱만 선택하고 「Save Changes」를 눌러 저장합니다. 「Exempt All」로 일괄 권한을 부여하지 마세요.
- 도구와 Fiddler Classic을 종료한 다음 시스템 프록시가 Clash 클라이언트의 실제 포트를 가리키는지 다시 확인하고 대상 앱을 실행해 테스트합니다.
예외를 취소하려면 WinConfig를 다시 열고 이번에 추가한 항목의 체크를 해제한 뒤 저장하면 됩니다. GUI 도구와 명령줄은 같은 종류의 시스템 설정을 관리하므로 CheckNetIsolation.exe LoopbackExempt -s로 목록을 비교 확인할 수 있습니다. 해당 도구가 설치되지 않은 PC에서는 Windows 기본 명령을 사용하면 됩니다. 이 작업을 위해 별도의 패킷 캡처 환경을 설치할 필요는 없습니다.
적용 여부 확인: 앱 요청·규칙 일치·예외 취소 비교
예외 목록에 앱 이름이 표시되는 것은 설정이 저장됐다는 뜻일 뿐, 대상 기능이 반드시 복구된다는 의미는 아닙니다. 스토어 페이지 새로고침이나 앱 내 온라인 콘텐츠 로드처럼 같은 실패 작업을 기준으로 확인하고, 동시에 클라이언트 연결 기록도 살펴보세요.
- 테스트 조건 고정: 같은 구독, 프록시 그룹, 규칙 모드를 유지하고 캡처 도구를 종료한 뒤 테스트 시각을 기록합니다.
- 대상 앱 재시작: 필요한 경우 작업 관리자에서 해당 프로세스를 종료한 뒤 다시 엽니다. 창만 닫으면 백그라운드 프로세스가 남을 수 있습니다.
- 연결 기록 확인: 클라이언트의 「연결」 또는 「로그」 화면에서 대상 도메인, 대상 주소, 적용 규칙, 아웃바운드 정책을 확인합니다. 화면 이름은 클라이언트마다 다를 수 있습니다.
- 실제 기능 확인: 「요청이 프록시에 도달함」과 「로그인 또는 다운로드 성공」을 구분하세요. 서버의 지역 제한, 계정 상태, 인증서 오류는 별도로 해결해야 합니다.
- 필요하면 예외 취소 전후 비교: 이번에 추가한 항목만 삭제하고 같은 작업을 다시 테스트합니다. 테스트 후에는 실제 필요에 따라 설정을 복구하세요.
일부 연결은 시스템 서비스나 보조 프로세스가 시작하므로 프로세스 이름만으로 필터링할 수 없습니다. 앱이 캐시된 페이지를 먼저 표시할 수도 있어 한 번 열리는 것만으로는 근거가 부족합니다. 창에 콘텐츠가 표시되는지만 보는 것보다 시각, 대상 도메인, 적용 규칙을 함께 확인하는 편이 정확합니다.
연결이 mihomo에 도달했지만 DIRECT로 처리됐다면 일반적으로 루프백 단계는 더 이상 현재 차단 지점이 아닙니다. 규칙이 적용되는 순서, 규칙 세트의 최신 상태, 프록시 그룹에서 예상한 정책을 선택했는지 확인하세요. 규칙 모드라고 해서 모든 트래픽이 프록시를 통과하는 것은 아니며, 예외를 추가해도 달라지지 않습니다.
여전히 해결되지 않을 때 확인할 순서
예외 목록에는 표시되지만 클라이언트에 연결이 보이지 않음
먼저 예외가 비슷한 이름의 런처가 아니라 실제 네트워크 요청을 보내는 패키지에 적용됐는지 확인하세요. 앱이 Windows 시스템 프록시를 따르는지, 별도의 프록시 설정이 있는지, 앱을 재시작했는지도 확인합니다. 시스템 프록시를 사용하지 않는 앱은 루프백 예외만으로 프록시 경로가 생기지 않습니다. 기존 설정을 보존한 상태에서 TUN 가로채기를 별도로 테스트할 수 있습니다.
클라이언트에는 연결이 보이지만 앱 기능은 실패함
먼저 적용된 정책과 연결 오류를 확인한 다음 DNS 조회 실패, 상위 서버 시간 초과, TLS 오류, HTTP 오류 응답을 구분하세요. 앱 다운로드에는 여러 도메인이 사용될 수 있습니다. 홈페이지에 연결된다고 콘텐츠 배포 주소에도 같은 정책이 적용되는 것은 아닙니다. 실제 실패한 연결을 기준으로 조정하고 모든 도메인의 아웃바운드를 한꺼번에 바꾸지 마세요.
앱을 업데이트하거나 재설치한 뒤 다시 실패함
일반적인 버전 업데이트로 패키지 패밀리 이름이 바뀌는 경우는 드뭅니다. 하지만 배포 경로를 바꾸거나 미리 보기 버전을 설치하거나 Windows 계정을 옮기면 실제 패키지 ID가 달라질 수 있습니다. 패키지를 다시 조회하고 -s로 현재 환경을 확인하세요. 기업 기기가 정책으로 관리된다면 방화벽을 끄는 대신 관리자에게 제한 사항을 확인하세요.
전체 점검 순서는 다음과 같습니다. 로컬 프록시 사용 가능 → 앱이 해당 포트를 실제 사용 → 필요한 루프백 권한 허용 → 연결에 예상한 규칙 적용 → 앱 기능 정상 동작. 이 순서로 확인하면 Windows 컨테이너 제한, 클라이언트 설정, 원격 서비스 문제를 구분해 처리할 수 있습니다.