Windows 스토어 앱에서 프록시가 연결되지 않을 때: CheckNetIsolation으로 UWP 루프백 제한 해제

1. 브라우저는 연결되지만 스토어 앱은 실패한다면: 루프백 제한 여부 확인

Windows 10 또는 Windows 11에서 Clash Meta 클라이언트의 시스템 프록시를 켰고 브라우저로는 사이트에 접속되지만, 특정 앱에서 네트워크를 사용할 수 없다고 표시될 수 있습니다. 앱 컨테이너(AppContainer)의 네트워크 격리가 원인일 수 있습니다. 격리된 앱은 일반 데스크톱 프로그램과 달리 기본적으로 로컬 루프백 주소의 서비스에 직접 연결할 수 없습니다.

프록시 주소로 흔히 사용하는 값은 127.0.0.1:7890입니다. 127.0.0.1은 현재 PC를 가리키고, 7890은 예시 포트일 뿐 모든 클라이언트에서 고정으로 사용하는 값은 아닙니다. 앱이 시스템 프록시 설정을 읽더라도 로컬 수신 포트에 연결하지 못하면 mihomo 코어에 도달하기 전에 요청이 실패할 수 있습니다.

먼저 세 가지를 확인하세요

일반 브라우저에서는 접속되는지: 같은 주소로 접속해 노드, 구독, 기본 네트워크가 정상인지 확인합니다.
프록시 수신 포트가 올바른지: 클라이언트 설정이나 현재 적용된 구성에서 HTTP 포트와 혼합 포트를 확인합니다. 외부 제어 포트를 프록시 포트로 착각하지 마세요.
앱 요청이 코어에 들어오는지: 클라이언트의 연결 목록이나 로그를 열고 앱에서 요청을 다시 보냅니다. 기록이 전혀 없다면 트래픽을 가로채는 경로를 확인해야 한다는 뜻일 뿐, 이것만으로 루프백 제한이 원인이라고 단정할 수는 없습니다.

루프백 예외는 앱이 로컬 서비스에 접근할 권한만 해결합니다. 만료된 구독이나 사용할 수 없는 노드, 원격 서버 장애를 고쳐 주지 않으며, 시스템 프록시를 무시하던 프로그램이 갑자기 HTTP 프록시를 사용하게 만들지도 않습니다.

2. 시스템 프록시와 mihomo 수신 포트 확인

Windows에서 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」으로 이동합니다. Windows 11에서는 보통 「프록시 서버 사용」 옆의 「편집」을 눌러야 합니다. 주소와 포트가 현재 사용 중인 클라이언트 설정과 일치하는지 확인하세요. 로컬 mihomo를 사용하는 경우 주소는 127.0.0.1, 포트는 7890인 구성이 흔합니다.

Clash Meta 설정의 mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 아래는 수신 관련 설정 예시입니다. 기존 설정에 합쳐 사용하고 구독 파일 전체를 대체하지 마세요.

config.yaml · 로컬 수신 설정 예시

mixed-port: 7890
allow-lan: false
mode: rule

클라이언트의 덮어쓰기 기능이 최종 설정을 생성할 수 있습니다. 로드되지 않는 YAML 파일만 수정하지 말고 실제 적용된 값을 확인하세요. UWP 앱이 로컬 프록시에 접근하도록 허용하려고 LAN 접근을 켤 필요는 없습니다. 문제 해결을 위해 수신 주소를 모든 네트워크 인터페이스로 바꾸는 것도 피하세요.

PowerShell로 로컬 포트 확인

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

첫 번째 명령은 TCP 수신 상태를 확인하고, 두 번째 명령은 일반 데스크톱 프로세스가 프록시를 명시적으로 사용하도록 합니다. 포트는 실제 값으로 바꿔 입력하세요. HTTP 응답을 받으면 이번 프록시 경로가 응답했다는 뜻이지만, 격리된 앱에 루프백 접근 권한이 있다는 뜻은 아닙니다. 연결이 거부되면 코어가 실행 중인지, 포트 충돌은 없는지 먼저 확인하세요. 시간 초과가 발생하면 노드, 규칙, 대상 사이트를 이어서 점검합니다.

netsh winhttp show proxy 결과만으로 Windows 설정 페이지의 상태를 판단하지 마세요. WinHTTP 프록시와 사용자 수준 시스템 프록시는 서로 다른 설정이며, 앱마다 사용하는 네트워크 인터페이스도 다를 수 있습니다.

3. CheckNetIsolation으로 특정 앱에 루프백 예외 추가

CheckNetIsolation.exe는 Windows에서 제공하는 네트워크 격리 진단 도구입니다. 루프백 예외를 추가하거나 삭제하려면 Windows 터미널 또는 PowerShell을 관리자 권한으로 실행하세요. 실제로 필요한 앱에만 적용하는 것이 좋습니다. 먼저 현재 목록을 저장한 다음 패키지 하나만 추가하세요.

첫 번째 단계: 기존 예외와 앱 패키지 이름 확인

CheckNetIsolation.exe LoopbackExempt -s

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

두 번째 명령은 기본적으로 현재 사용자의 앱 패키지를 나열합니다. 대상 앱을 찾은 뒤 표시 이름, 설치 경로, 버전이 포함된 PackageFullName이 아니라 PackageFamilyName을 사용하세요. 앱이 많다면 알고 있는 이름 일부로 필터링할 수 있습니다. 아래 예시는 Microsoft Store 패키지를 대상으로 하며, 모든 네트워크 문제에서 스토어 자체에 예외를 추가해야 한다는 뜻은 아닙니다.

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

관리자 터미널에서 다른 계정을 사용하면 패키지 목록이 평소 사용하는 계정의 목록과 다를 수 있습니다. 이 경우 대상 사용자 세션으로 돌아가 패키지 정보를 확인하세요. 패키지를 찾지 못했다고 설치된 모든 앱에 권한을 주지는 마세요.

두 번째 단계: 패키지 하나에 예외 추가

아래 PowerShell 명령은 현재 사용자에게 설치된 Microsoft Store 패키지를 조회한 다음, 실제 패키지 패밀리 이름을 시스템 도구에 전달합니다. 다른 앱을 대상으로 하려면 먼저 앞의 목록에서 정확한 Name을 확인하고 조회 조건을 수정하세요.

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -eq $app) {
  throw "현재 사용자에서 Microsoft.WindowsStore 패키지를 찾지 못했습니다. 사용자 계정과 패키지 이름을 확인하세요."
}

CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

출력에 대상 패키지가 있는지 확인한 다음 앱을 완전히 종료하고 다시 실행하세요. 창만 닫아도 백그라운드 프로세스가 남아 있을 수 있습니다. 작업 관리자에서 대상 앱이 종료되었는지 확인하되, 시스템 핵심 프로세스는 종료하지 마세요. 요청을 다시 보내면서 Clash Meta 연결 목록을 확인합니다.

세 번째 단계: 적용 여부 확인 및 취소 방법 확보

앱이 다시 연결되고 mihomo 로그에 해당 연결이 표시되면 이 경로로 트래픽이 통과한 것입니다. 여전히 실패하더라도 같은 예외를 반복해서 추가하지 마세요. 앱이 시스템 프록시를 읽는지, 별도의 백그라운드 구성 요소가 있는지, 프록시 규칙에서 대상 도메인이 예상한 정책 그룹에 할당되었는지 확인합니다.

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -ne $app) {
  CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

CheckNetIsolation.exe LoopbackExempt -s

위 명령은 해당 패키지의 예외를 삭제합니다. 루프백 권한을 주면 앱이 로컬 서비스를 이용할 수 있으며, 권한 범위는 Clash 포트에만 한정되지 않습니다. 테스트 결과가 없거나 더 이상 사용하지 않는다면 해당 항목을 취소하세요. 모든 목록을 지우는 방식으로 개별 항목을 취소하지 마세요. 다른 도구의 기존 설정에 영향을 줄 수 있습니다.

4. 그래픽 도구로 설정하기: AppContainer 루프백 예외 도구

PC에 Fiddler Classic이 설치되어 있다면 WinConfig 메뉴를 통해 AppContainer Loopback Exemption Utility를 열 수 있습니다. 여기서 안내하는 도구는 Fiddler Classic에 포함된 것이며 Fiddler Everywhere와는 다릅니다. 버전에 따라 버튼 위치가 다를 수 있습니다.

Fiddler Classic을 열고 도구 모음에서 WinConfig를 클릭한 뒤 안내에 따라 관리자 권한을 허용합니다.
AppContainer 목록에서 대상 앱을 찾아 패키지 정보를 확인하세요. 표시 이름이 비슷하다는 이유만으로 판단하지 마세요.
대상 항목을 선택하고 Save Changes를 클릭해 저장한 다음, 대상 앱을 완전히 종료하고 다시 실행합니다.
관리자 터미널로 돌아가 CheckNetIsolation.exe LoopbackExempt -s를 실행해 시스템에 적용된 최종 목록을 확인합니다.

그래픽 도구와 명령줄 도구는 같은 종류의 시스템 예외 설정을 변경합니다. 두 방법을 모두 사용할 필요는 없으며, 편의를 위해 모든 앱을 선택하는 것도 권장하지 않습니다. 출처가 불분명한 원클릭 복구 스크립트는 방화벽, DNS, 프록시 설정까지 함께 바꿀 수 있습니다. 문제를 진단할 때는 여러 변수를 한꺼번에 바꾸지 마세요.

5. 루프백 예외와 TUN 모드: 트래픽 경로에 맞춰 선택

시스템 프록시는 앱이 프록시 인터페이스를 사용해야 작동합니다. 루프백 예외는 격리된 앱이 로컬 프록시 포트에 접근하도록 허용합니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 가로채므로, 앱이 먼저 127.0.0.1:7890에 연결할 필요가 없는 경우가 많습니다. 따라서 시스템 프록시를 무시하는 프로그램에는 TUN 모드를 시험해 볼 만하지만, TUN이 루프백 예외의 상위 버전인 것은 아닙니다.

방식	적합한 경우	주요 한계
시스템 프록시	앱이 사용자 프록시 설정을 지원하고 이를 읽는 경우	모든 프로그램과 UDP 트래픽을 가로채지는 못함
시스템 프록시 + 루프백 예외	격리된 앱이 로컬 프록시에 연결해야 하는 경우	접근 권한만 추가하며 앱이 프록시를 사용하도록 강제하지는 않음
mihomo TUN	앱이 시스템 프록시를 무시하거나 IP 트래픽을 가로채야 하는 경우	권한, 라우팅, DNS 설정이 필요하며 다른 VPN과 충돌할 수 있음

TUN 설정 예시와 활성화 조건

먼저 사용 중인 Windows 클라이언트의 TUN 설정 메뉴에서 활성화하고, 안내에 따라 서비스를 설치하거나 관리자 권한을 허용하세요. 클라이언트마다 메뉴 이름은 다를 수 있습니다. 직접 설정한다면 아래 mihomo용 TUN 설정 예시를 참고하세요. 기존 노드, 프록시 그룹, 규칙, DNS 설정은 그대로 유지합니다.

config.yaml · TUN 설정 예시

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack는 mihomo의 DNS 모듈이 활성화되어 정상 작동할 때 사용합니다. 완전한 DNS 설정이 아니며 모든 암호화 DNS를 가로챌 수도 없습니다. auto-route는 트래픽을 가로채도록 라우트를 자동 설정하고, auto-detect-interface는 출구 인터페이스를 식별합니다. 여러 네트워크 어댑터, 기업 VPN, 가상 머신 네트워크를 함께 사용하는 경우 자동 선택 결과가 예상과 다를 수 있으므로 별도로 확인해야 합니다.

효과를 비교하려면 시스템 프록시를 끄고 TUN만 켠 상태로 먼저 테스트해 보세요. 요청이 기존 로컬 프록시 경로를 계속 사용하지 않도록 하기 위한 방법입니다. 테스트 전에 기존 스위치 상태를 기록하고, 완료 후 필요한 설정으로 복원하세요. 여러 프록시 프로그램의 TUN이나 VPN 트래픽 가로채기를 동시에 켜지 마세요. 네트워크 확인을 위해 방화벽 전체를 끄는 것도 피하세요.

6. 예외를 추가해도 해결되지 않을 때: 연결 기록으로 원인 찾기

코어에 앱 연결이 표시되지 않음

앱을 완전히 다시 시작했는지, 실제로 네트워크 요청을 보내는 패키지에 예외를 추가했는지 먼저 확인하세요. 일부 앱은 로그인, 미디어, 업데이트를 별도 프로세스에 맡깁니다. 주 인터페이스 앱에 예외를 추가해도 이러한 구성 요소까지 해결되지 않을 수 있습니다. 앱이 원래 시스템 프록시를 사용하지 않는다면 루프백 주소를 바꾸는 대신 TUN 모드를 시험하세요.

연결은 코어에 들어오지만 DIRECT 또는 잘못된 프록시 그룹으로 처리됨

mode: rule이 적용되어 있는지 확인하고 해당 연결에 어떤 규칙이 적용되었는지 살펴보세요. Clash Meta의 rules는 위에서부터 순서대로 일치 여부를 확인하므로 앞선 규칙이 뒤의 규칙보다 우선할 수 있습니다. 앱 하나를 다시 연결하려고 전역 모드로 계속 전환하지 마세요. 대상 도메인과 정책을 확인한 뒤 구독 덮어쓰기에서 필요한 규칙만 수정해야 다음 구독 업데이트로 변경 사항이 덮어써지는 일을 막을 수 있습니다.

로그인, 다운로드 또는 동영상 기능만 실패함

이런 기능은 서로 다른 도메인, 프로세스 또는 전송 프로토콜을 사용할 수 있습니다. HTTP 시스템 프록시가 처리하는 경로와 앱이 UDP를 직접 보내는 경로는 다릅니다. 실패 시각, 대상 주소, 코어 로그를 기록한 뒤 DNS, 노드의 프로토콜 지원 여부, 분기 규칙을 각각 확인하세요. 루프백 예외 자체는 상위 노드의 프로토콜 지원을 바꾸지 않습니다.

한 번에 하나씩 변경하세요

현재 프록시 포트, 시스템 프록시 상태, TUN 상태, 기존 예외 목록을 기록합니다.
먼저 일반 데스크톱 프로그램에서 로컬 프록시를 통해 대상 사이트에 접속되는지 확인합니다.
대상 패키지 하나에 예외를 추가하고 앱을 다시 시작한 뒤 연결 기록을 확인합니다.
효과가 없다면 필요 없는 예외를 취소한 후 TUN 경로만 따로 테스트합니다.
계속 문제가 발생하면 오류 메시지와 적용된 규칙을 보관하세요. 로그를 공유하기 전에 구독 주소, 액세스 토큰, 개인정보를 삭제합니다.

문제가 해결되었는지 판단할 때는 앱 기능이 복구되었는지, 트래픽이 의도한 코어로 들어오는지, 규칙이 예상한 출구에 적용되는지를 함께 확인해야 합니다. ‘예외 추가 성공’ 메시지는 시스템이 설정을 받아들였다는 뜻일 뿐, 프록시 경로 전체가 정상이라는 의미는 아닙니다.