Windows UWP 앱에서 Clash가 작동하지 않을 때: 루프백 제한 해제 및 점검 방법

루프백 제한이 일부 Windows 앱에만 영향을 주는 이유

루프백 주소는 현재 컴퓨터 자체를 가리킵니다. Clash가 로컬 프록시 포트를 실행하면 앱은 먼저 이 컴퓨터의 포트에 연결하고, 프록시 코어가 규칙에 따라 DIRECT, REJECT 또는 특정 프록시 그룹을 선택합니다. 앱 관점에서 첫 번째 연결은 대상 웹사이트로 직접 접속하는 과정이 아니라 로컬 프록시 서비스에 접속하는 과정입니다.

UWP 앱과 AppContainer 격리를 사용하는 일부 구성 요소에는 독립적인 네트워크 권한 경계가 있습니다. Windows는 격리된 앱과 로컬 서비스 사이의 무단 통신을 줄이기 위해 이러한 컨테이너의 로컬 루프백 인터페이스 접근을 기본적으로 제한합니다. 시스템 프록시에 로컬 프록시 주소가 기록되어 있어도 각 AppContainer 앱에 루프백 접근 권한이 자동으로 부여되지는 않습니다. 따라서 설정 화면에서 프록시가 켜져 있어도 모든 Microsoft Store 앱이 Clash의 수신 포트에 연결할 수 있다는 뜻은 아닙니다.

일반적인 증상

• Microsoft Store, 계산기의 온라인 기능, 날씨 앱 또는 다른 Microsoft Store 앱에서 연결할 수 없다는 메시지가 표시됩니다.
• Chrome, Firefox와 같은 브라우저 및 기존 데스크톱 클라이언트 등 Win32 프로그램은 정상적으로 인터넷에 접속됩니다.
• 문제가 있는 앱에서 새로 고침을 실행해도 Clash 로그에 대상 도메인에 대한 접근 기록이 나타나지 않습니다.
• 시스템 프록시를 끄면 앱이 직접 연결로 복구될 수 있지만, 프록시를 다시 켜면 또 실패합니다.
• 루프백 예외가 설정된 다른 컴퓨터에서는 같은 앱이 정상적으로 작동합니다.

Microsoft Store에서 설치한 모든 프로그램이 반드시 이 제한을 받는 것은 아닙니다. 일부 스토어 앱은 실제로 패키징된 기존 데스크톱 프로그램이고, 다른 앱은 서로 다른 네트워크 구성 요소를 사용합니다. 문제를 확인할 때는 설치 경로만 보지 말고 앱의 패키지 ID, 실제 로그와 연결 동작을 기준으로 판단해야 합니다.

변경 전에 Clash 수신 설정과 시스템 프록시 확인

루프백 예외는 AppContainer가 로컬 프록시 포트에 접근할 수 있도록 권한을 부여할 뿐입니다. Clash가 실행 중이 아니거나 포트가 다르거나 시스템 프록시가 이전 포트를 가리키고 있다면 예외를 추가해도 연결이 복구되지 않습니다. 먼저 다음 순서대로 기본 상태를 확인하는 것이 좋습니다.

1. 코어가 실행 중인지 확인합니다.현재 사용하는 Clash 그래픽 클라이언트를 열고 설정이 로드되었는지, 프록시 노드 또는 프록시 그룹의 지연 시간 테스트가 완료되는지 확인합니다.
2. 시스템 프록시가 활성화되어 있는지 확인합니다.클라이언트의 “시스템 프록시” 스위치가 켜져 있어야 합니다. 수동 설정을 사용하는 경우 Windows 프록시 주소가 클라이언트에 표시된 HTTP 또는 mixed-port와 일치해야 합니다.
3. 포트를 다른 프로세스가 사용하고 있지 않은지 확인합니다.클라이언트가 반복해서 시작되지 않거나 로그에 수신 오류가 표시되면 먼저 해당 프로세스를 종료하거나 포트를 변경해야 합니다.
4. 연결 로그를 확인합니다.정상 작동하는 데스크톱 브라우저로 웹페이지를 열어 Clash 로그에 연결 기록이 생성되는지 확인한 뒤, 문제가 있는 앱을 조작하며 새로운 요청이 나타나는지 비교합니다.
5. 규칙의 영향을 일시적으로 배제합니다.문제가 있는 앱의 요청이 이미 로그에 나타난다면 원인은 루프백 제한보다 규칙 매칭, 프록시 그룹, DNS 또는 노드에 있을 가능성이 큽니다.

PowerShell에서 현재 사용자의 Internet 프록시 설정을 확인할 수 있습니다. 이 명령은 확인만 수행하며 설정을 변경하지 않습니다.

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

ProxyEnable이 활성화되어 있고 ProxyServer가 로컬 주소를 가리킨다면 수동 시스템 프록시가 설정된 것입니다. 일부 클라이언트는 PAC 스크립트를 사용할 수 있으므로 이때는 AutoConfigURL도 함께 확인해야 합니다. 또한 Windows의 WinHTTP 프록시는 현재 사용자의 Internet 프록시와 별도의 설정이므로 netsh winhttp show proxy 결과만으로 Clash 시스템 프록시의 작동 여부를 판단해서는 안 됩니다.

UWP 앱의 패키지 패밀리 이름 확인

CheckNetIsolation에서 사용하는 값은 Package Family Name, 즉 패키지 패밀리 이름입니다. 시작 메뉴에 표시되는 한국어 이름이나 전체 버전 번호가 포함된 Package Full Name이 아닙니다. 잘못된 필드를 선택하면 명령이 대상 앱에 적용되지 않을 수 있습니다.

PowerShell로 조회하기

Windows 계산기를 예로 들면 PowerShell을 열고 다음 명령을 실행할 수 있습니다.

Get-AppxPackage -Name "*WindowsCalculator*" |
  Select-Object Name, PackageFamilyName

출력되는 PackageFamilyName은 Microsoft.WindowsCalculator_8wekyb3d8bbwe와 같은 형태입니다. 앱마다 값이 다르므로 이 컴퓨터에서 조회한 결과를 사용해야 합니다. 패키지 이름을 모르면 현재 사용자에게 설치된 앱을 나열하고 이름순으로 정렬할 수 있습니다.

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

설치된 앱이 많다면 이름의 일부를 사용해 범위를 좁힐 수 있습니다. 예를 들어 Microsoft Store를 찾으려면 다음과 같이 실행합니다.

Get-AppxPackage -Name "*WindowsStore*" |
  Select-Object Name, PackageFamilyName

두 패키지 식별자를 혼동하지 않기

컴퓨터에 여러 Windows 사용자가 있다면 실제로 앱을 실행하는 계정에서 조회해야 합니다. 일부 패키지는 특정 사용자에게만 설치되므로 관리자 계정에서 확인한 앱 목록이 평소 사용하는 계정과 완전히 같지 않을 수 있습니다.

CheckNetIsolation으로 루프백 예외 추가

대상 앱과 Clash의 기본 연결이 정상인지 확인한 후 Windows에 기본 포함된 CheckNetIsolation.exe로 AppContainer 루프백 예외를 관리할 수 있습니다. 먼저 대상 앱을 종료한 다음 관리자 권한으로 PowerShell 또는 Windows 터미널을 여는 것이 좋습니다.

단일 앱에 권한 추가

다음 PowerShell 명령은 먼저 계산기 패키지를 조회한 뒤, 이 컴퓨터에서 실제로 확인한 패키지 패밀리 이름을 시스템 도구에 전달합니다.

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -a -n="$($pkg.PackageFamilyName)"

조회 결과가 여러 개라면 바로 일괄 실행하지 마세요. 각 항목의 Name과 PackageFamilyName을 먼저 확인한 뒤 대상이 맞을 때 추가해야 합니다. 이미 확인한 패키지 패밀리 이름을 명령에 직접 입력할 수도 있습니다.

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

명령의 -a는 추가를 의미하고 -n 뒤에는 패키지 패밀리 이름을 입력합니다. 실행이 끝나면 대상 앱을 완전히 종료한 뒤 다시 엽니다. 창만 닫는 것으로는 백그라운드 프로세스가 종료되지 않을 수 있으므로 작업 관리자에서 앱이 중지되었는지 확인할 수 있습니다.

현재 예외 목록 확인

CheckNetIsolation.exe LoopbackExempt -s

목록을 통해 예외가 기록되었는지 확인하고 이전에 남은 설정도 찾을 수 있습니다. 출력 형식은 시스템 식별자에 가까울 수 있어 시작 메뉴 이름과 일치하지 않을 수 있으므로 PowerShell 조회 결과와 함께 대조해야 합니다.

권한 부여 후 프록시·규칙·DNS 확인

루프백 권한 추가에 성공했다는 것은 앱이 로컬 프록시에 연결을 시도할 수 있다는 뜻일 뿐, 이후 프록시 경로가 반드시 정상이라는 의미는 아닙니다. 앱, Clash 로그, 규칙 매칭과 대상 서비스의 네 단계에서 순서대로 확인해야 합니다.

1. 대상 앱을 다시 시작합니다.로그인, 새로 고침 또는 콘텐츠 로드를 다시 실행하고 오류 메시지가 달라졌는지 확인합니다.
2. Clash 로그를 확인합니다.대상 도메인 또는 연결 기록이 나타나기 시작하면 앱이 로컬 프록시 포트에 접근할 수 있게 된 것입니다.
3. 적중한 규칙을 확인합니다.요청이 예상한 프록시 그룹에 들어갔는지, REJECT나 잘못된 도메인 규칙 또는 적용되지 않는 직접 연결 규칙에 의해 차단되지 않았는지 확인합니다.
4. 사용 가능한 프록시 정책으로 전환합니다.프록시 그룹에서 연결이 확인된 노드를 선택해 노드 장애와 루프백 권한 문제를 혼동하지 않도록 합니다.
5. DNS를 확인합니다.로그에 도메인 확인 실패가 표시되면 Clash DNS 설정, 시스템 DNS, Fake IP 호환성과 앱의 특수한 이름 확인 방식 사용 여부를 점검해야 합니다.

연결 기록은 나타나지만 앱에 여전히 실패 메시지가 표시된다면 규칙이 더 단순한 설정으로 일시 전환해 비교해 보세요. 목적은 장기적으로 라우팅을 우회하는 것이 아니라 문제가 규칙 계층에 있는지 앱 계층에 있는지 확인하는 것입니다. 테스트가 끝나면 원래 설정으로 되돌리고 실제 도메인에 맞게 규칙을 조정해야 합니다.

일부 앱은 인증, 콘텐츠 전송, 원격 측정 또는 인증서 상태 확인 서비스에 동시에 접속합니다. 주 도메인만 허용하는 것으로는 충분하지 않을 수 있습니다. 이때는 로그를 바탕으로 전체 요청 목록을 파악하고 이름만 보고 도메인을 추측하지 마세요. 직접 연결이 필요한 Windows 서비스에는 명확한 DIRECT 규칙을 만들고, 프록시가 필요한 콘텐츠 도메인은 해당 프록시 그룹에 넣어야 합니다.

시스템 프록시와 TUN 모드의 차이

시스템 프록시는 앱이 Windows 프록시 설정을 직접 읽고 Clash가 제공하는 로컬 HTTP 또는 혼합 포트에 연결하는 방식입니다. UWP 루프백 제한은 바로 이 연결 단계에 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채므로 시스템 프록시를 따르지 않는 일부 앱까지 처리할 수 있습니다.

하지만 TUN은 루프백 문제를 만능으로 대체하는 방법이 아닙니다. TUN을 활성화하면 관리자 권한, 가상 네트워크 어댑터, 라우팅, DNS 가로채기, 방화벽과 다른 VPN 소프트웨어의 호환성까지 고려해야 합니다. 소수의 UWP 앱만 기존 시스템 프록시를 사용하게 하려는 목적이라면 정확한 루프백 예외를 추가하는 편이 검증하기 쉽습니다. 시스템 프록시를 읽지 않는 앱이 많고 라우팅과 DNS 설정을 충분히 이해하고 있다면 mihomo 코어가 지원하는 TUN 모드를 고려하는 것이 적절합니다.

여전히 연결되지 않을 때의 단계별 점검

Clash 로그에 요청이 전혀 나타나지 않음

먼저 예외 목록 명령을 다시 실행해 대상 패키지가 있는지 확인합니다. 그런 다음 앱이 다른 패키지에 속하는지, 업데이트 후 패키지 ID가 바뀌었는지, 현재 실행 사용자와 패키지 정보를 조회한 사용자가 같은지 확인합니다. 시스템 프록시 주소가 실제로 루프백 주소인지, 앱이 시스템 프록시를 우회하고 있지는 않은지도 점검해야 합니다.

로그에는 요청이 있지만 연결 시간이 초과됨

이는 일반적으로 루프백 단계는 통과했다는 뜻입니다. 다음으로 노드 연결 상태, 프록시 그룹 선택, 대상 포트와 네트워크 환경을 확인하세요. 같은 서비스를 데스크톱 브라우저에서 열어 비교할 수 있지만 브라우저와 앱이 접근하는 도메인 목록은 다를 수 있다는 점에 주의해야 합니다.

로그에 DIRECT로 표시된 뒤 실패함

규칙 순서를 확인합니다. Clash는 설정에 적힌 순서대로 규칙을 매칭하므로 범위가 넓은 직접 연결 규칙이 대상 규칙보다 먼저 적용될 수 있습니다. 수정할 때는 규칙의 의미를 명확하게 유지하고 목록 마지막에 MATCH에 대응하는 프록시 그룹과 같은 합리적인 최종 처리 정책이 있는지 확인해야 합니다.

TUN을 활성화해도 작동하지 않음

TUN이 실제로 시작되었는지, 다른 VPN이나 보안 소프트웨어가 라우팅 테이블을 변경하지 않았는지, DNS 요청이 예상한 확인 경로로 들어가는지 확인합니다. 가상 네트워크 어댑터를 생성하는 도구를 여러 개 동시에 켜지 마세요. 다른 네트워크 도구를 끈 뒤 복구된다면 라우팅 우선순위 또는 드라이버 충돌일 가능성이 큽니다.

Microsoft Store는 탐색되지만 다운로드되지 않음

스토어 페이지 로드와 앱 패키지 다운로드는 서로 다른 서비스를 거칠 수 있습니다. 이때는 Clash 규칙뿐 아니라 Windows Update, Background Intelligent Transfer Service 및 관련 시스템 서비스의 상태도 확인해야 합니다. 루프백 예외는 컨테이너의 로컬 컴퓨터 접근에만 영향을 주며, 중지된 시스템 서비스나 계정 권한 또는 스토어 캐시를 복구하지는 않습니다.

루프백 예외 철회 및 설정 복구

앱이 더 이상 Clash를 거칠 필요가 없거나 이미 제거되었거나, 점검 결과 문제가 루프백과 무관한 것으로 확인되었다면 해당 예외를 철회할 수 있습니다. 명령에서 -d를 사용하면 삭제됩니다.

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -d -n="$($pkg.PackageFamilyName)"

이미 확인한 패키지 패밀리 이름을 사용할 수도 있습니다.

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

철회한 뒤 CheckNetIsolation.exe LoopbackExempt -s를 다시 실행해 대상 항목이 목록에서 제거되었는지 확인합니다. 그런 다음 앱을 재시작하고 네트워크 동작을 확인합니다. 점검 중 시스템 프록시, Clash 포트, DNS, 규칙 모드 또는 TUN 스위치를 변경했다면 루프백 예외만 삭제하지 말고 각 설정을 하나씩 원래대로 복구해야 합니다.

남겨 두면 좋은 점검 기록

• 대상 앱 이름과 Package Family Name
• Clash에서 사용하는 코어, 수신 포트와 프록시 모드
• 예외 추가 전후의 로그 차이
• 요청이 적중한 규칙과 프록시 그룹
• TUN, 다른 VPN 또는 네트워크 필터링 소프트웨어의 활성화 여부
• 최종 해결 단계와 철회 명령

이러한 기록은 “앱이 로컬 프록시에 접근하지 못하는 문제”와 “프록시가 요청을 받았지만 이후 연결에 실패하는 문제”를 구분하는 데 도움이 됩니다. 전자는 AppContainer와 루프백 권한을 중심으로 확인하고, 후자는 규칙, DNS, 노드와 대상 서비스를 중심으로 확인해야 합니다. 연결 경로를 단계별로 나누어 판단하면 클라이언트를 반복해서 재설치하거나 구독을 바꾸는 것보다 원인을 빠르게 찾을 수 있습니다.