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

시스템 프록시, 앱 샌드박스, 프록시 규칙의 차이

브라우저에서는 Clash로 인터넷에 접속되지만 특정 Microsoft Store 앱에서 계속 연결 오류가 발생한다면 UWP의 루프백 제한이 원인일 수 있습니다. 일반적으로 클라이언트에서 시스템 프록시를 켜고 프록시 서버를 127.0.0.1:7890로 지정했지만, 대상 앱은 제한된 AppContainer 샌드박스에서 실행되는 경우입니다. 앱이 로컬 프록시에 연결하려 해도 요청이 Clash 코어에 도달하기 전에 Windows 네트워크 격리 정책에 의해 차단됩니다.

UWP는 Universal Windows Platform(유니버설 Windows 플랫폼)의 약자이며, AppContainer는 Windows의 앱 격리 방식입니다. 루프백 주소는 현재 컴퓨터를 가리키며 IPv4의 127.0.0.1과 IPv6의 ::1이 여기에 해당합니다. 루프백 예외를 설정하면 지정한 앱 컨테이너가 로컬 네트워크 서비스에 접속할 수 있습니다. Windows 방화벽 전체를 끄는 것과는 다릅니다.

Microsoft Store에서 설치했다고 해서 반드시 UWP 앱인 것은 아닙니다. 스토어에서는 일반 Win32 데스크톱 프로그램과 패키징된 데스크톱 앱도 배포합니다. 앱 패키지와 실행 방식, 연결 로그를 확인해 원인을 판단해야 하며, 모든 ‘스토어 앱 인터넷 연결 오류’를 루프백 제한 탓으로 돌려서는 안 됩니다.

세 가지 기능은 각각 무엇을 해결할까?

시스템 프록시: Windows 프록시 설정을 참조하는 앱에 HTTP 프록시 주소를 제공합니다. 모든 프로그램의 TCP·UDP 트래픽을 자동으로 가로채지는 않습니다.
루프백 예외: 지정한 앱 컨테이너가 로컬 프록시에 연결하도록 허용합니다. 단, 앱이 실제로 해당 프록시 설정을 사용해야 합니다.
규칙 모드: 트래픽이 Clash 또는 mihomo에 도달한 뒤 rules에 따라 직접 연결하거나 프록시를 사용합니다. 요청이 코어에 도달하기 전에 샌드박스에서 차단되는 문제는 해결하지 못합니다.

따라서 브라우저가 정상 작동한다는 사실은 프록시 연결 경로 하나가 작동한다는 뜻일 뿐, 대상 앱도 같은 로컬 포트에 접속할 수 있음을 보장하지 않습니다. 반대로 앱이 클라이언트 연결 목록에 표시되더라도 원격 노드를 통과한다고 단정할 수는 없습니다. 적용된 규칙과 최종 연결 경로도 확인해야 합니다.

작업 전 확인: 포트, 시스템 프록시, 연결 기록

먼저 클라이언트가 사용하는 로컬 수신 포트를 확인합니다. 여기서는 HTTP와 SOCKS5가 같은 포트를 사용하는 mixed-port: 7890을 예로 듭니다. 실제 설정이 7897이라면 이후 주소와 확인 명령에 모두 실제 값을 사용해야 합니다. 외부 컨트롤러 포트를 프록시 포트로 착각하지 말고, 로컬 앱 접속을 위해 먼저 allow-lan을 켜지도 마세요.

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 ‘수동 프록시 설정’의 주소와 포트를 확인합니다. Windows 10에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘프록시 서버 사용’을 확인하면 됩니다. PAC 자동 구성 스크립트를 사용한다면 수동 프록시를 추가로 설정하지 말고 스크립트가 반환하는 프록시 주소를 확인하세요.
클라이언트 코어가 실행 중인지, 선택한 노드를 사용할 수 있는지 확인하고 현재 규칙 모드와 전역 모드 중 어느 쪽인지 기록합니다.
클라이언트의 연결 목록이나 로그를 열고 대상 앱에서 콘텐츠 새로고침 등 확실한 네트워크 작업을 한 번 실행합니다. 연결 기록이 전혀 없는 경우와 연결은 표시되지만 실패하는 경우를 구분하세요.
우선 트래픽을 처리하는 방식을 하나만 유지합니다. 시스템 프록시를 확인할 때는 어떤 경로가 작동하는지 혼동하지 않도록 기존 TUN을 기록한 뒤 꺼 둡니다.

PowerShell에서 포트가 수신 대기 중인지 확인한 다음 HTTP 프록시 연결을 직접 테스트할 수 있습니다. 아래 두 번째 명령은 예시 사이트의 응답 헤더만 가져와 포트와 기본 프록시 경로를 확인합니다. 대상 앱에 루프백 권한이 부여됐는지를 확인하는 명령은 아닙니다.

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

포트가 수신 대기 중이 아니라면 먼저 클라이언트 실행이나 설정 문제를 해결하세요. 프록시를 명시한 요청도 실패한다면 노드, 인증, 규칙을 먼저 확인해야 합니다. 수신 대기 중인 포트가 작동하도록 해 주는 기능은 아니므로 이 단계에서 앱 예외를 반복해서 추가하지 마세요.

방법 1: CheckNetIsolation으로 앱 하나만 예외 추가

CheckNetIsolation.exe는 Windows에 기본 포함된 네트워크 격리 관리 도구입니다. 로컬 프록시가 꼭 필요한 앱에만 예외를 추가하고, 수정 전에 기존 목록을 저장하는 것이 좋습니다. 아래 명령은 관리자 권한 PowerShell에서 실행합니다. 앱 패키지 조회는 기본적으로 현재 로그인한 사용자를 대상으로 하므로 다른 관리자 계정으로 권한을 높였다면 원래 사용자 계정의 앱이 조회되지 않을 수 있습니다.

1단계: 기존 예외와 앱 패키지 확인

CheckNetIsolation.exe LoopbackExempt -s

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

-s는 현재 예외 목록을 표시합니다. PackageFamilyName은 패키지 이름과 게시자 식별자로 구성되는 패키지 계열 이름입니다. 버전과 아키텍처 정보 등이 포함된 PackageFullName과는 다릅니다. -n에 값을 전달할 때는 패키지 계열 이름을 사용하고, 앱에 표시되는 이름을 그대로 복사하지 마세요.

2단계: 패키지를 정확히 확인하고 예외 추가

아래에서는 패키지 이름이 Microsoft.WindowsStore인 Microsoft Store 앱 자체를 예로 들어 설명합니다. 다른 앱에서 문제가 발생했다면 먼저 앞 단계의 목록에서 해당 앱의 Name을 확인한 뒤 조회 조건을 바꾸세요. 앱을 스토어에서 설치했다는 이유만으로 스토어 앱 자체에만 예외를 추가해서는 안 됩니다.

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

if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
} else {
    Write-Warning "앱 패키지를 하나로 특정할 수 없습니다. 현재 사용자와 앱 패키지 이름을 확인하세요."
}

CheckNetIsolation.exe LoopbackExempt -s

-a는 추가를 뜻하며, -n= 바로 뒤에 패키지 계열 이름을 입력합니다. 명령이 성공했다고 보고하면 -s로 해당 항목이 목록에 있는지 다시 확인합니다. 그런 다음 대상 앱을 백그라운드 프로세스까지 완전히 종료하고 다시 실행한 뒤 네트워크 작업을 해 보세요. 창을 최소화하는 것만으로는 충분하지 않습니다.

3단계: 필요하면 앱 예외 하나만 삭제

더 이상 로컬 서비스에 접속할 필요가 없다면 같은 앱 패키지 변수를 사용해 해당 항목을 삭제할 수 있습니다. 아래 명령은 다른 앱의 설정을 유지합니다. 앱 하나의 예외를 취소하기 위해 전체 예외 목록을 비우지 마세요.

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($pkg.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

액세스 거부 메시지가 표시될 때: PowerShell을 관리자 권한으로 실행했는지, 기기가 조직 정책에 따라 관리되는지 확인하세요.
조회 결과가 없을 때: 패키지 이름의 철자와 현재 사용자, 앱 설치 상태를 확인하세요. 대상이 일반 데스크톱 앱이라면 이 조회 방법을 사용할 수 없습니다.
추가에 성공했지만 여전히 연결되지 않을 때: 앱이 시스템 프록시를 사용하는지, 실제 연결이 코어에 도달하는지 확인하세요. 성공 메시지만으로 네트워크가 복구됐다고 판단하지 마세요.

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

일부 Windows 클라이언트에는 UWP 루프백 예외 도구가 있으며, 메뉴 이름은 ‘UWP 루프백’, ‘Loopback’, ‘앱 컨테이너 예외’ 등으로 표시될 수 있습니다. 클라이언트와 버전에 따라 메뉴 위치가 다르므로 현재 버전의 설정 화면과 안내를 확인하세요. 다른 클라이언트의 메뉴 경로를 그대로 적용해서는 안 됩니다.

클라이언트 설정에서 루프백 관련 도구를 찾아 안내에 따라 관리자 권한을 허용합니다. 사용 중인 클라이언트에 이 기능이 없다면 앞서 소개한 시스템 명령을 사용하세요.
목록에서 대상 앱의 이름과 패키지 식별 정보를 확인합니다. 로컬 프록시를 통해 인터넷에 접속해야 하는 앱만 선택한 뒤 저장 또는 적용을 누르세요.
대상 앱을 완전히 종료한 뒤 다시 실행하고 클라이언트에 새 연결이 표시되는지 확인합니다.
필요하다면 CheckNetIsolation.exe LoopbackExempt -s를 실행해 시스템 수준의 예외가 실제로 등록됐는지 확인합니다.

이런 도구는 대개 같은 시스템 설정을 그래픽 인터페이스로 제공할 뿐, 노드를 자동으로 제공하거나 구독을 복구하거나 규칙을 바꾸지는 않습니다. 도구에 프로세스 이름만 표시되고 대상 앱의 패키지가 명확히 표시되지 않는다면 관련 없는 앱까지 허용되지 않도록 주의 깊게 확인하세요.

앱별로 필요한 권한만 부여하는 것이 좋습니다. 모든 앱을 선택하면 로컬 서비스에 접근할 수 있는 범위가 넓어지고 이후 문제를 추적하기도 어려워집니다. 앱을 삭제 후 재설치했거나 패키지 식별 정보가 바뀌었다면 기존 항목이 여전히 유효하다고 가정하지 말고 목록을 다시 확인하세요.

방법 3: mihomo TUN으로 앱 트래픽 처리

대상 프로그램이 시스템 프록시를 읽지 않는다면 루프백 예외를 추가해도 127.0.0.1:7890을 사용하도록 강제할 수는 없습니다. 이때는 TUN 모드를 검토할 수 있습니다. 가상 네트워크 인터페이스와 라우팅을 이용해 원래 원격 서버로 직접 전송되던 트래픽을 mihomo로 전달한 뒤 규칙에 따라 연결 경로를 정합니다. mihomo는 Clash Meta에서 이어져 개발된 코어이며, 클라이언트의 TUN 지원 여부는 통합된 코어와 시스템 서비스에 따라 달라집니다.

Windows에서 TUN을 켜려면 일반적으로 관리자 권한이 필요하며, 클라이언트가 미리 설치해 실행 중인 서비스가 필요할 수도 있습니다. 우선 클라이언트에서 제공하는 스위치로 설정하고 인터페이스 생성, 라우팅 설정, DNS 처리가 정상적으로 시작됐는지 확인하세요. 기존 설정을 충분히 파악하지 않은 상태에서 구독 설정 전체를 덮어쓰지 마세요.

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

다음은 mihomo TUN 설정 일부이며, 그대로 실행할 수 있는 완성된 설정은 아닙니다. auto-route는 라우팅을 설정하고 auto-detect-interface는 출구 인터페이스를 자동으로 감지합니다. dns-hijack은 지정된 일반 DNS 요청을 코어의 DNS 모듈로 전달하며, 유효한 dns 설정도 함께 필요합니다. 여기서 any:53은 모든 DoH 또는 DoT 암호화 DNS까지 가로챈다는 뜻이 아닙니다.

TUN 테스트 중 기존 루프백 제한에 다시 걸리지 않도록 주의

앱이 계속 시스템 프록시를 읽어 로컬 루프백 주소에 직접 연결한다면 TUN을 켜도 샌드박스에서 차단된 연결을 우회할 수 있다고 보장할 수 없습니다. TUN을 테스트할 때는 먼저 기존 시스템 프록시 설정을 기록하고 일시적으로 끈 뒤, 앱이 원격 서버에 직접 연결을 시도하도록 해 TUN이 트래픽을 처리하게 합니다. 이후 앱을 완전히 다시 시작하고 실제 연결 상태를 확인하세요. 로컬 프록시를 명시적으로 사용해야 하는 앱에는 여전히 루프백 예외가 필요할 수 있습니다.

먼저 일반 웹페이지와 대상 앱이 모두 인터넷에 연결되는지 확인한 다음 적용된 규칙을 살펴보세요. 연결은 됐지만 의도치 않게 직접 연결되는 상황을 방지할 수 있습니다.
다른 VPN, 가상 네트워크 어댑터 또는 기업 보안 소프트웨어를 함께 사용 중이라면 기본 경로와 인터페이스 충돌을 확인하세요. 여러 전역 트래픽 처리 방식을 한꺼번에 켜지 마세요.
도메인 이름 확인에 실패한다면 DNS를 별도로 점검하세요. TUN을 켜도 모든 DNS 업스트림에 자동으로 연결되는 것은 아닙니다.
테스트가 끝나면 사용할 시스템 프록시 설정으로 복구하고 새 라우팅이 로컬 네트워크, 프린터, 사내망에 영향을 주는지 확인하세요.

세 가지 해결 방법의 적용 범위

처리 방법	적합한 상황	주요 제한 사항
CheckNetIsolation 명령	앱 컨테이너가 로컬 프록시에 접속해야 한다는 사실을 확인한 경우	앱이 시스템 프록시를 사용하도록 강제하지 않으며, 패키지 계열 이름을 정확히 알아야 합니다.
클라이언트 내장 예외 도구	인터페이스에서 앱별 권한을 관리하려는 경우	클라이언트가 해당 기능을 제공해야 하며, 실제 적용은 시스템 권한과 정책의 영향을 받습니다.
mihomo TUN 모드	앱이 시스템 프록시를 사용하지 않아 라우팅으로 트래픽을 처리해야 하는 경우	권한, 라우팅, DNS 설정이 필요하며, 명시적인 루프백 연결 제한을 우회한다고 보장할 수 없습니다.

문제가 한 앱에서만 발생한다면 먼저 패키지 식별 정보와 개별 예외를 확인하세요. 변경 범위를 최소화할 수 있습니다. 시스템 프록시를 따르지 않는 여러 프로그램의 트래픽을 처리해야 한다면 TUN을 검토하세요. 기업 기기에서는 기기 관리 정책을 따라야 하며, 문제를 파악하는 대신 방화벽을 끄거나 보안 정책을 제거해서는 안 됩니다.

예외 추가 후에도 연결되지 않을 때 확인할 순서

먼저 코어에 요청이 도달하는지 확인: 기록이 없다면 앱의 프록시 사용 방식, 앱 재시작 여부, 패키지 식별 정보, TUN 라우팅을 다시 확인합니다. 로그 필터 때문에 기록이 숨겨져 있을 수도 있습니다.
다음으로 적용된 규칙 확인: 연결에 DIRECT가 표시된다면 현재 규칙에 따라 직접 연결 중입니다. 예외를 더 추가하기보다 대상 도메인과 규칙 순서를 확인하세요.
출구와 프로토콜 확인: 로그인, 이미지, 미디어 콘텐츠는 서로 다른 도메인을 사용할 수 있으며 일부 기능은 UDP도 사용합니다. 브라우저에서 홈페이지가 열린다고 앱이 사용하는 모든 서비스에 연결할 수 있는 것은 아닙니다.
마지막으로 계정 문제와 네트워크 문제 구분: 로그인 토큰 만료, 잘못된 시스템 시간, 서비스 지역 제한, 서버 장애도 연결 오류처럼 보일 수 있습니다. 이를 해결하겠다며 출처가 불분명한 인증서를 가져오거나 인증서 검증을 끄지 마세요.

한 번에 변수 하나만 바꾸고 변경 전후 상태를 기록하세요. 로컬 포트, 시스템 프록시, 예외 목록, TUN 설정, 적용된 규칙을 확인합니다. 복구 여부는 명령이 성공했는지가 아니라 대상 앱이 정상 작동하고 의도한 연결 경로를 사용하는지로 판단해야 합니다. 설정 가져오기와 규칙 모드를 다시 살펴보려면 시작 가이드를 확인하세요. 적절한 트래픽 처리 방식을 지원하는 클라이언트가 필요하다면 플랫폼별 다운로드 페이지를 살펴보세요.