Windows 스토어 앱에서 프록시가 작동하지 않을 때: UWP 루프백 예외 및 CheckNetIsolation 설정

먼저 확인할 점: 격리된 앱에서만 연결에 실패하는가

브라우저는 정상적으로 접속되는데 Microsoft Store나 특정 UWP 앱에서 오프라인으로 표시된다면, 노드가 문제라고 단정할 수 없습니다. Windows 시스템 프록시가 127.0.0.1:7890을 가리키고 대상 앱이 AppContainer에서 실행된다면, 로컬 루프백 주소 연결이 차단되어 있는지 확인하세요. 이 경우 요청이 Clash 코어에 도달하기도 전에 막힐 수 있으므로 프록시 규칙을 바꾸거나 구독을 반복해서 업데이트해도 해결되지 않는 경우가 많습니다.

이 글은 Windows 10 및 Windows 11에서 로컬 HTTP 프록시 또는 혼합 포트를 사용할 때의 문제 해결 방법을 다룹니다. 7890은 아래 예시에만 사용한 포트이며 실제 포트는 클라이언트 설정을 확인하세요. 사이트 브랜드는 Clash for Mac이지만, 여기 안내된 명령은 Windows에서 실행해야 하며 macOS 터미널에서 사용할 수 없습니다.

브라우저와 대상 앱 모두 연결에 실패하는 경우: 먼저 구독이 로드되었는지, 프록시 그룹에서 사용 가능한 노드를 선택했는지, 로컬 포트가 대기 중인지 확인하세요.
브라우저는 정상이고 특정 UWP 앱만 실패하는 경우: 루프백 제한을 확인해 볼 수 있지만, 앱 자체의 서비스 장애도 배제해야 합니다.
클라이언트에 대상 요청 기록이 있는 경우: 해당 요청이 클라이언트에 도달한 것입니다. 일치한 규칙, 아웃바운드 및 연결 오류를 확인하세요.
다운로드나 로그인 중 일부만 실패하는 경우: 백그라운드 서비스, 다른 패키지 또는 별도의 네트워크 스택이 원인일 수 있습니다. 특정 앱 하나의 루프백 권한 문제로 단정하지 마세요.

AppContainer에서 로컬 프록시에 연결할 수 없는 이유

시스템 프록시를 사용하는 일반적인 요청 흐름은 다음과 같습니다. 앱이 시스템 프록시 설정을 읽고, HTTP 요청 또는 HTTPS CONNECT 요청을 로컬 프록시 포트로 보낸 뒤, 코어가 규칙에 따라 직접 연결하거나 프록시 노드를 선택합니다. 여기서 127.0.0.1은 현재 Windows 컴퓨터를 가리키는 IPv4 루프백 주소이며 원격 노드가 아닙니다.

AppContainer는 앱을 격리된 환경에서 실행합니다. 기본 네트워크 격리 정책에서는 내부 앱이 로컬 루프백 서비스에 직접 접근하지 못하는 경우가 많습니다. 프록시 프로세스가 포트를 열어 두었고 일반 데스크톱 브라우저가 연결되더라도, 격리된 앱의 요청은 프록시에 도달하기 전에 차단될 수 있습니다.

루프백 예외로 달라지는 점

CheckNetIsolation.exe의 LoopbackExempt 하위 명령으로 루프백 예외를 관리할 수 있습니다. 특정 패키지를 추가하면 해당 AppContainer에 적용된 루프백 제한을 해제할 수 있습니다. 다만 시스템 프록시를 자동으로 켜거나 구독을 가져오고 프록시 그룹을 선택해 주지는 않으며, 앱에 필요한 네트워크 기능을 추가하지도 않습니다.

설정	주요 기능	대신 확인해야 할 항목
시스템 프록시	이 설정을 따르는 앱에 프록시 주소와 포트 제공	앱이 설정을 읽는지, 포트가 대기 중인지
루프백 예외	지정한 AppContainer의 루프백 접근 제한 해제	프록시 프로토콜, 분기 규칙, 노드 상태
TUN 모드	가상 네트워크 어댑터와 라우팅을 통해 지정된 IP 트래픽 처리	라우팅, DNS, 권한 및 기타 네트워크 필터링 정책

‘LAN 연결 허용’을 켜도 보통 이 문제는 해결되지 않습니다. 이 옵션은 주로 프록시가 연결을 수신하는 범위를 변경합니다. 포트의 LAN 접근을 허용하는 것과 AppContainer에 루프백 권한을 부여하는 것은 다르며, 포트가 노출되는 범위만 넓어질 수 있습니다.

설정 전에 프록시 주소와 대기 포트 확인

클라이언트 설정에서 ‘혼합 포트’ 또는 HTTP 프록시 포트를 찾으세요. 실제 포트 번호를 기록하고, SOCKS 전용 포트를 HTTP 프록시 포트로 착각하지 않도록 합니다.
Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘프록시 서버 사용’의 ‘설정’을 엽니다. Windows 10에서는 같은 이름의 ‘프록시’ 페이지에서 수동 프록시를 확인할 수 있습니다.
주소와 포트를 확인합니다. 예를 들어 주소는 127.0.0.1, 포트는 7890입니다. 클라이언트에서 ‘시스템 프록시’가 켜져 있는지도 확인하세요.
다른 프록시 프로그램은 잠시 종료해 두세요. 여러 클라이언트가 시스템 프록시 설정을 번갈아 덮어쓰는 상황을 피할 수 있습니다. 처음 원인을 찾을 때는 트래픽 진입점을 하나만 사용하세요.

PowerShell에서 아래 명령을 실행해 로컬 TCP 포트와 프록시를 지정한 요청을 각각 확인할 수 있습니다.

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/

TcpTestSucceeded : True는 TCP 연결에 성공했다는 뜻일 뿐, 프록시 프로토콜이나 TLS, 원격 노드까지 정상이라는 의미는 아닙니다. 두 번째 명령은 HTTP 프록시를 명시해 최대 20초 동안 요청합니다. 실제 포트가 다르면 함께 수정하세요. Windows PowerShell에서 같은 이름의 별칭으로 인한 매개변수 차이를 피하려고 curl.exe를 사용합니다.

이 명령은 일반 데스크톱 프로세스에서 실행되므로 UWP 앱의 루프백 접근 권한을 확인할 수는 없습니다. 먼저 프록시 진입점이 작동하는지 확인해 포트 오입력을 격리 문제로 오인하지 않도록 하는 데 목적이 있습니다.

방법 1: 클라이언트에 포함된 루프백 도구 사용

일부 Windows 클라이언트에는 UWP 루프백 보조 도구가 포함되어 있습니다. 예전 Clash for Windows에서는 보통 General → UWP Loopback → Launch Helper에서 실행했습니다. 이는 특정 클라이언트의 메뉴 경로이며 모든 Clash 또는 mihomo GUI 클라이언트에 공통으로 제공되는 기능은 아닙니다. 이 도구를 사용하려고 구형 클라이언트로 바꿀 필요도 없습니다.

먼저 클라이언트의 로컬 프록시 포트가 작동하는지 확인한 다음 루프백 보조 도구를 엽니다.
Windows 사용자 계정 컨트롤 창이 표시되면 프로그램 출처를 확인한 후 허용하세요. 루프백 예외를 변경하려면 보통 관리자 권한이 필요합니다.
목록에서 확인하려는 앱을 찾습니다. 앱 이름과 패키지 정보를 확인하고, 로컬 프록시를 실제로 사용해야 하는 항목만 선택하세요.
도구에 표시된 저장 또는 적용 버튼을 누릅니다. 일부 도구에는 Save Changes라고 표시되니 현재 화면의 안내를 따르세요.
대상 앱을 완전히 종료한 뒤 다시 실행하고, 이전에 실패했던 작업을 다시 시도하세요. 창만 닫아서는 백그라운드 프로세스가 종료되지 않을 수 있습니다.

목록에 대상 앱이 없다면 먼저 현재 사용자 계정에 앱이 설치되어 있는지 확인하세요. 이름이 비슷하다는 이유만으로 다른 패키지를 선택하지 말고, 모든 앱에 일괄적으로 권한을 부여하는 것도 피하세요. 보조 도구가 없다면 다음 절의 시스템 명령을 사용하면 됩니다. 추가한 예외는 같은 방식으로 조회하고 되돌릴 수 있습니다.

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

1. PackageFamilyName 확인

대상 앱을 설치한 Windows 사용자 세션에서 PowerShell을 열고, 먼저 Microsoft Store를 예로 들어 패키지 패밀리 이름을 확인합니다.

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

Microsoft Store의 일반적인 패키지 패밀리 이름은 Microsoft.WindowsStore_8wekyb3d8bbwe입니다. 그래도 작업 전에는 해당 PC에서 조회한 결과를 기준으로 삼으세요. 명령에는 PackageFamilyName이 필요합니다. 버전이나 아키텍처 정보가 포함된 PackageFullName을 잘못 사용하거나 스토어 페이지의 제품 ID를 입력하지 마세요.

대상 패키지의 내부 이름을 모른다면 먼저 현재 사용자의 패키지 목록을 확인하세요.

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

결과가 나오지 않으면 로그인한 사용자와 앱이 설치된 계정이 같은지 먼저 확인하세요. 다른 관리자 계정으로 권한을 높이면 패키지를 조회하는 사용자 컨텍스트도 달라질 수 있습니다. 특히 여러 사람이 함께 사용하는 PC에서는 -AllUsers를 기본 해결책으로 사용하지 마세요.

2. 현재 상태를 기록하고 예외 추가

시작 버튼을 마우스 오른쪽 버튼으로 클릭하고 ‘터미널(관리자)’ 또는 ‘Windows PowerShell(관리자)’를 선택합니다. 먼저 현재 목록을 조회한 다음, 확인한 패키지에 예외를 추가하세요.

CheckNetIsolation.exe LoopbackExempt -s

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

CheckNetIsolation.exe LoopbackExempt -s

-s: 현재 루프백 예외 목록을 표시합니다.
-a: 예외 항목을 추가합니다.
-n: 패키지 패밀리 이름을 지정합니다. 다른 앱을 확인할 때는 조회 결과에 나온 실제 이름을 사용하세요.

추가하기 전에 목록을 저장하거나 복사해 두면 원래 등록되어 있던 항목을 확인하기 쉽습니다. 목록에는 이름과 SID가 함께 표시될 수 있으므로, 명령이 성공 메시지를 출력했는지만 보지 말고 대상 패키지에 해당하는 항목을 확인하세요. ‘액세스가 거부되었습니다’라는 메시지가 나오면 패키지 이름을 계속 바꾸어 시도하지 말고 터미널을 관리자 권한으로 실행했는지 먼저 확인하세요.

3. 앱을 다시 시작하고 요청 재현

대상 앱을 종료하고, 필요한 경우 작업 관리자에서 프로세스까지 끝낸 뒤 다시 실행하세요. 프록시 그룹과 네트워크, 테스트 작업은 그대로 유지합니다. 예를 들어 스토어 홈을 새로고침해 보세요. 그래야 예외 추가 전후의 차이를 비교할 수 있습니다. 보통 PC 전체를 재부팅할 필요는 없습니다. 네트워크 초기화나 DNS 변경을 함께 하면 실제로 효과가 있었던 단계를 파악하기 어렵습니다.

추가한 후에도 실패하는 경우: 요청 흐름에 따라 점검

클라이언트에 새 연결이 표시되지 않음

먼저 실제 네트워크 요청을 보내는 패키지에 예외를 추가했는지 확인한 다음, 시스템 프록시 주소와 포트, 우회 목록을 확인하세요. 일부 앱은 시스템 프록시를 사용하지 않으며 다운로드 작업을 백그라운드 서비스에서 처리하기도 합니다. 화면에 표시되는 앱에만 예외를 추가해도 백그라운드 서비스의 네트워크 동작은 바뀌지 않을 수 있습니다.

netsh winhttp set proxy를 모든 스토어 앱에 통하는 해결책으로 사용하지 마세요. WinHTTP 프록시와 현재 사용자 계정의 시스템 프록시는 서로 다른 설정입니다. 이를 변경하면 시스템 서비스에는 영향을 주면서 대상 앱에는 아무런 변화가 없을 수 있습니다.

클라이언트에 연결은 표시되지만 아웃바운드가 예상과 다름

연결 화면에서 대상 도메인, 일치한 규칙, 실제 아웃바운드를 확인하세요. 루프백 예외는 규칙 우선순위를 바꾸지 않으므로 요청이 DIRECT에 일치하면 계속 직접 연결됩니다. 요청이 클라이언트에 도달한 것을 확인한 뒤에만 규칙 모드와 전역 모드를 잠시 비교해 보는 것이 진단에 도움이 됩니다. 테스트가 끝나면 기존 아웃바운드 모드로 되돌리세요.

TUN을 켠 후 증상이 달라짐

TUN 모드는 시스템 프록시를 사용하지 않는 앱의 일부 트래픽을 처리할 수 있지만, Windows 네트워크 격리를 해제하지는 않습니다. 앱이 여전히 로컬 프록시에 연결하도록 설정되어 있다면 루프백 제한이 원인일 수 있습니다. ‘시스템 프록시 켜기, TUN 끄기’와 ‘클라이언트 안내에 따라 설정한 TUN 경로’를 각각 테스트하고 차이를 기록하세요. 두 옵션을 동시에 켠 뒤 문제를 해결했다고 단정하지 마세요.

복구 방법: 이번에 추가한 항목만 제거

더 이상 로컬 프록시 접근이 필요하지 않다면 같은 보조 도구에서 대상 앱의 선택을 해제하고 저장하거나, 관리자 터미널에서 삭제 명령을 실행할 수 있습니다. 아래 예시는 계속 Microsoft Store를 기준으로 설명합니다.

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

CheckNetIsolation.exe LoopbackExempt -s

-d는 지정한 항목을 삭제합니다. 실행 후 대상 앱을 다시 시작하고 목록과 실제 동작을 확인하세요. 이번에 새로 추가한 항목만 취소하고, 개발 도구나 다른 앱이 원래 설정한 예외는 삭제하지 마세요. 앱 하나를 복구하려고 목록 전체를 비우는 것도 피하세요.

루프백 예외와 시스템 프록시 설정은 별개입니다. 클라이언트의 시스템 프록시를 꺼도 예외가 자동으로 제거되지 않으며, 예외를 삭제해도 Windows 프록시 설정은 복구되지 않습니다. 클라이언트 사용을 중단할 계획이라면 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’도 확인하세요. Windows가 더 이상 대기하지 않는 로컬 포트를 계속 가리키지 않도록 해야 합니다.

자주 묻는 질문

루프백 예외를 추가하면 앱이 반드시 프록시를 사용하나요?

그렇지는 않습니다. 예외는 해당 AppContainer의 루프백 접근 제한만 해제합니다. 앱이 로컬 프록시 주소를 사용해야 하고, 클라이언트가 올바른 포트에서 대기해야 하며, 사용 가능한 설정도 있어야 합니다. 직접 연결할지 프록시를 사용할지는 아웃바운드 모드와 일치한 규칙에 따라 결정됩니다.

구독이나 노드를 바꾸면 예외를 다시 추가해야 하나요?

보통은 필요하지 않습니다. 예외는 패키지 ID에 연결되며 노드, 구독 URL 또는 로컬 포트에 연결되지 않습니다. 앱을 업데이트해도 패키지 패밀리 이름이 그대로라면 대체로 다시 추가할 필요가 없습니다. 삭제 후 재설치한 뒤 동작이 달라졌다면 패키지 ID와 예외 목록을 다시 확인하세요.

localhost와 127.0.0.1은 다른가요?

localhost는 IPv4 또는 IPv6 루프백 주소로 해석될 수 있습니다. 프록시는 127.0.0.1에서만 대기하는데 연결이 ::1을 사용하려 하면 실패할 수 있습니다. 문제를 확인할 때는 먼저 명확한 IPv4 주소로 대기 상태를 확인하세요. 다만 이 방법으로 AppContainer 격리를 우회할 수는 없습니다.

모든 앱에 한꺼번에 예외를 추가해도 되나요?

권장하지 않습니다. 앱마다 하나씩 추가하면 효과를 확인하기 쉽고 되돌리기도 편합니다. 추가 전 목록을 보관하고 대상 패키지 패밀리 이름을 기록한 뒤 필요한 항목만 변경하는 것이 일괄 설정보다 일상적인 문제 해결에 적합합니다.