---

현상: 일반 앱은 프록시가 되는데 스토어 앱만 연결되지 않는다

Windows에서 Clash나 mihomo 코어의 시스템 프록시를 켜거나 심지어 TUN 모드를 활성화해도, 대부분의 데스크톱 앱(브라우저, 커맨드라인 도구, 전통적인 exe 프로그램)은 정상적으로 프록시 규칙을 타고 나갑니다. 하지만 Microsoft Store에서 설치한 일부 앱—예를 들어 특정 메일 클라이언트, 일부 브라우저의 스토어 버전, 크로스 플랫폼 채팅 도구의 UWP 패키지 버전—은 전형적인 "프록시가 적용되지 않는" 증상을 보입니다. 직접 접속되는 사이트는 열리지만, 프록시를 거쳐야만 접근할 수 있는 주소는 시스템 프록시 설정에 로컬 포트가 정확히 입력되어 있어도 예외 없이 타임아웃이나 네트워크 오류가 발생합니다.

이런 문제는 원인 파악에서 쉽게 방향을 잘못 잡습니다. 많은 사람이 처음에는 구독 노드 실패, 코어 충돌, 규칙 오류를 의심하며 클라이언트를 반복해서 재시작하거나 구독을 다시 불러오지만 아무 효과가 없습니다. 이유는 간단합니다. 문제는 프록시 서비스 쪽에 있지 않고, Windows 시스템이 UWP(Universal Windows Platform) 앱의 네트워크 접근에 일반 프로세스와는 별개의 격리 제한을 두고 있기 때문입니다. 이 제한은 기본적으로 UWP 앱과 127.0.0.1 / localhost 간의 루프백 통신을 차단하는데, 대부분의 로컬 프록시 클라이언트(Clash 계열 코어 포함)는 바로 이 본체 루프백 주소를 리스닝해서 HTTP/SOCKS5 프록시 포트를 제공합니다.

원리: UWP 샌드박스와 루프백 통신 격리

이 제한을 이해하려면 UWP 앱의 실행 방식이 전통적인 Win32 프로그램과 완전히 다르다는 점을 먼저 알아야 합니다. UWP 앱은 AppContainer라 불리는 샌드박스 환경에서 실행되며, Microsoft는 각 UWP 앱에 고유한 보안 식별자(SID)를 부여하고, 네트워크 격리(Network Isolation) 메커니즘을 통해 어떤 네트워크 리소스에 접근할 수 있는지를 엄격히 제어합니다. 이 메커니즘의 설계 목적은 보안입니다. 스토어 앱이 선언 없이 로컬 네트워크나 같은 기기의 다른 프로세스가 열어둔 포트에 임의로 접근하는 것을 막아, 수평 침투와 정보 유출 위험을 낮추려는 것입니다.

네트워크 격리 정책에는 핵심 규칙이 하나 있습니다. UWP 앱은 기본적으로 같은 기기에서 루프백 주소(loopback, 즉 127.0.0.1 또는 ::1)로 리스닝 중인 서비스에 접근할 수 없습니다, 단 해당 서비스 자체도 UWP 앱으로 패키징되어 실행되는 경우는 예외입니다. 이것이 왜 이 문제가 스토어 앱에서만 발생하는지를 설명해줍니다. 전통적인 데스크톱 프로그램은 AppContainer의 제약을 받지 않아 로컬 머신의 어떤 포트에도 자유롭게 연결할 수 있지만, UWP 앱은 시스템 프록시 설정이 전역적으로 적용되어 있더라도 발생하는 모든 연결 요청이 네트워크 계층에 도달하기 전에 이 격리 검사에서 먼저 거부됩니다. 특히 연결 대상이 127.0.0.1:7890 같은 로컬 프록시 포트일 때 이 현상이 두드러집니다.

주목할 점은, 이 제한은 프록시 소프트웨어 자체가 "LAN 연결 허용"을 켰는지, 리스닝 주소를 0.0.0.0으로 했는지 127.0.0.1로 했는지와는 크게 관계가 없다는 것입니다. 프록시가 모든 네트워크 인터페이스에서 리스닝하고 있어도, UWP 앱이 보내는 루프백 요청은 여전히 시스템 수준의 격리 정책에 의해 차단됩니다. 이는 운영체제 계층의 동작이므로 클라이언트 설정 파일에는 이를 우회할 수 있는 옵션이 전혀 없습니다.

먼저 확인: 루프백 제한이 원인인지

제한을 해제하기 전에, 오판을 막기 위해 다음 두 가지 간단한 검증을 먼저 해보는 것을 권장합니다:

1. 영향을 받는 앱이 스토어 앱인지 확인합니다. 시작 메뉴에서 앱 아이콘을 우클릭했을 때 "제거" 외에 "고급 옵션"이 보인다면 대체로 UWP 앱이라는 뜻입니다. 전통적인 Win32 프로그램은 대체로 제거 항목만 있습니다. 설정의 "앱 및 기능" 목록에서 출처 표시를 확인할 수도 있습니다.
2. 프록시 서비스 자체가 정상적으로 동작하는지 확인합니다. 브라우저나 커맨드라인 도구로 같은 프록시 포트가 사용 가능한지 직접 테스트합니다. 예를 들어 curl로 프록시를 지정해 프록시가 필요한 주소에 접근해봅니다. 이런 전통적인 프로그램이 정상적으로 나갈 수 있다면 프록시 설정이나 노드 자체의 문제는 거의 배제할 수 있고, 문제의 초점은 UWP 네트워크 격리로 좁혀집니다.

두 가지 모두 해당한다면 루프백 제한으로 인한 연결 실패라고 거의 확신할 수 있으며, 이제 해당 UWP 앱에 대해 개별적으로 루프백 예외를 열어주기만 하면 됩니다.

방법 1: CheckNetIsolation 명령으로 해제하기

Windows에는 CheckNetIsolation.exe라는 명령줄 도구가 기본 내장되어 있으며, AppContainer의 네트워크 격리 화이트리스트를 관리하는 전용 도구입니다. 이는 공식에서 제공하는 표준 해결 방식이며 추가 소프트웨어 설치가 필요 없습니다.

1단계: 앱의 Package Family Name 찾기

관리자 권한으로 PowerShell을 열고 다음 명령을 실행해 현재 시스템에 설치된 모든 UWP 앱과 패키지 이름을 나열합니다:

Get-AppxPackage | Select-Object Name, PackageFamilyName

반환된 목록에서 대상 앱에 해당하는 항목을 찾아 PackageFamilyName 필드를 기록합니다. 형식은 12345Publisher.AppName_abcdefghijk1m과 유사하며, 이 문자열은 다음 명령에 필수적인 정확한 식별자이므로 앱의 표시 이름으로 대체할 수 없습니다.

2단계: 루프백 예외 추가

PowerShell을 닫고 관리자 권한으로 명령 프롬프트(cmd)를 열어 다음을 실행합니다:

CheckNetIsolation.exe LoopbackExempt -a -n="12345Publisher.AppName_abcdefghijk1m"

명령 실행 후 오류가 나지 않으면 추가가 성공한 것이며, 별도의 성공 알림 팝업은 뜨지 않습니다. 이 명령의 효과는 지정한 앱을 루프백 예외 목록에 추가해, 이후 본체 127.0.0.1에서 리스닝 중인 서비스—프록시 클라이언트가 열어둔 HTTP/SOCKS5 포트 포함—에 정상적으로 접근할 수 있게 허용하는 것입니다.

확인 및 취소

현재 예외 처리된 앱 목록을 확인하려면 다음을 실행합니다:

CheckNetIsolation.exe LoopbackExempt -s

이후 특정 앱의 예외를 취소해야 한다면(예를 들어 다른 문제를 조사할 때 기본 격리 상태로 되돌리고 싶은 경우), 매개변수 -a를 -d로 바꾸면 됩니다:

CheckNetIsolation.exe LoopbackExempt -d -n="12345Publisher.AppName_abcdefghijk1m"

주의할 점은, 이 예외 목록은 기기 간 동기화되지 않으며 앱을 제거 후 재설치하면 자동으로 유지되지 않으므로, 재설치 후에는 추가 명령을 다시 실행해야 합니다.

방법 2: 그래픽 도구로 처리하기

명령어 입력에 익숙하지 않거나 패키지 이름을 잘못 적을까 걱정된다면 그래픽 인터페이스 도구로 같은 작업을 수행할 수 있습니다. Microsoft 커뮤니티에서 널리 퍼진 EnableLoopback은 오픈소스 소형 도구로, 본질적으로 CheckNetIsolation.exe에 인터페이스를 씌운 것이며 하위 메커니즘을 변경하지 않고 명령줄과 완전히 같은 논리로 동작합니다:

1. 관리자 권한으로 이 도구를 실행하면, 프로그램이 시작되면서 현재 시스템에 설치된 모든 UWP 앱 목록을 자동으로 읽어와 각각의 현재 루프백 예외 상태를 표시합니다.
2. 목록에서 제한을 해제할 앱을 선택합니다(다중 선택 가능하며, 영향을 받는 여러 스토어 앱을 일괄 처리할 수 있습니다). "Modify"를 클릭해 변경 사항을 적용합니다.
3. 도구가 수행하는 작업은 명령어를 직접 입력하는 것과 완전히 동일합니다. 체크하면 예외가 추가되고 체크를 해제하면 예외가 취소되며, 패키지 이름을 외우거나 복사할 필요가 없습니다.

예외 상태를 자주 조정해야 하거나 한 번에 여러 앱을 처리해야 하는 경우, 그래픽 도구가 명령어를 반복 입력하는 것보다 편리합니다. 하지만 단일 앱의 문제를 임시로 해결하려는 것이라면 명령줄을 바로 사용하는 것이 대개 더 빠르고, 추가로 타사 도구를 다운로드해 설치할 필요도 없습니다.

해제 후 적용 확인 방법

예외 설정을 완료했다면, 다음 순서로 검증하는 것을 권장합니다. "앱 실행이 빨라진 것 같다" 같은 주관적인 느낌만으로 판단하지 마세요:

• 앱을 완전히 종료한 뒤 다시 실행합니다. UWP 앱의 네트워크 세션은 보통 시작 시점에 이미 수립되므로, 예외 설정이 앱 실행 중에는 즉시 적용되지 않는 경우가 많습니다. 프로세스를 완전히 종료한 뒤 재시작해야 새 격리 정책이 반영됩니다.
• 프록시를 거쳐야만 열리는 주소에 접근해서 확인합니다. 로컬 캐시가 있을 수 있는 앱 홈 화면 같은 콘텐츠로는 판단하지 말고, 반드시 실시간으로 네트워크를 통해 로드되고 프록시 규칙의 분기 범위에 명확히 포함되는 기능을 선택해 테스트합니다.
• 프록시 클라이언트의 연결 로그나 활성 연결 패널을 다시 확인합니다. 클라이언트 화면에서 해당 앱이 시작한 연결 기록이 보인다면 트래픽이 실제로 프록시 경로에 들어갔다는 뜻입니다. 로그에 관련 기록이 전혀 나타나지 않는다면 예외가 적용되지 않은 것이므로, 패키지 이름을 잘못 적었는지, 명령을 관리자 권한으로 실행했는지를 다시 확인해야 합니다.

또한 놓치기 쉬운 세부 사항이 있습니다. 일부 UWP 앱은 루프백 격리를 해제해도 자체 "네트워크 기능 선언"(Capability)에 전용 네트워크 접근 권한이 선언되어 있지 않아 여전히 제한을 받을 수 있습니다. 이런 경우는 대체로 기업용으로 맞춤 배포된 앱에서 나타나며 일반 스토어 앱에서는 드뭅니다. 격리를 해제한 뒤에도 여전히 효과가 없다면 앱 매니페스트의 권한 항목을 추가로 확인해볼 수 있습니다.

루프백 제한을 회피하는 다른 방법

앱마다 일일이 격리를 해제하고 싶지 않거나, 영향을 받는 앱 수가 많고 자주 바뀌는 경우, 근본적으로 이 제한을 우회할 수 있는 두 가지 방법이 더 있습니다:

TUN 모드로 전환하기

앞서 언급했듯이 루프백 제한은 앱이 본체의 프록시 포트에 직접 연결하는 방식을 대상으로 합니다. 클라이언트가 TUN 모드를 지원한다면, 활성화 시 시스템에 가상 네트워크 카드가 생성되어 모든 프로세스(격리 제약을 받는 UWP 앱 포함)의 트래픽이 네트워크 카드 계층에서 일괄적으로 인터셉트되어 전달됩니다. 앱이 직접 127.0.0.1의 프록시 포트에 연결할 필요가 없어지므로 자연히 루프백 격리 정책의 영향을 받지 않습니다. 스토어 앱 연결 문제를 자주 겪는 사용자라면 TUN 모드로 바로 전환하는 것이 앱마다 화이트리스트를 추가하는 것보다 훨씬 편합니다.

리스닝 주소와 방화벽 규칙을 조정해 시스템 프록시와 병행하기

일부 상황에서는 시스템 프록시의 적용 범위를 더 하위 네트워크 설정까지 포괄하도록 조정하는 방법도 고려할 수 있지만, 이런 조정은 대체로 다른 호환성 비용을 동반하므로 앞의 두 방법보다 직접적이지 않습니다. 일반적으로 우선 선택지로 삼지 않으며, TUN 모드와 앱별 예외 처리 모두 적용하기 어려운 특수한 환경에서만 고려하는 것이 좋습니다.

---

루프백 제한은 Windows 시스템 차원의 보안 설계이며 프록시 클라이언트의 결함이 아닙니다. 이 점을 이해하면 불필요한 원인 조사 시간을 크게 줄일 수 있습니다. "스토어 앱만 프록시에 연결되지 않는다"는 특징이 명확한 문제를 마주하면, 패키지 이름을 기준으로 CheckNetIsolation 명령이나 그래픽 도구로 바로 예외를 해제하면 대부분 몇 분 안에 해결됩니다. 앱 수가 많거나 화이트리스트를 관리하고 싶지 않다면 TUN 모드로 전환하는 것이 더 편리한 장기적 방안입니다.