Windows에서 Clash 또는 mihomo 기반 클라이언트를 사용할 때 브라우저는 대체로 프록시에 정상적으로 연결되지만, Microsoft Store 앱, Xbox 관련 구성 요소, 사진, 메일 및 기타 UWP 앱은 계속 오프라인으로 표시될 수 있습니다. 이런 현상은 구독이 만료된 것으로 오해하기 쉽지만, 실제로는 앱이 로컬 프록시 포트에 연결되기 전에 발생할 수 있습니다. Windows의 앱 컨테이너에는 기본적으로 루프백 접근 제한이 적용되어 있어, 로컬 컴퓨터의 127.0.0.1 또는 localhost에서 실행 중인 서비스에 임의로 연결할 수 없습니다.
여기서 ‘루프백’은 장치가 자신의 네트워크 인터페이스에 접속하는 경로를 의미합니다. Clash의 HTTP, SOCKS 또는 혼합 포트는 대개 로컬 주소에서 수신 대기합니다. 일반 데스크톱 프로그램은 바로 연결할 수 있지만, UWP 앱은 AppContainer의 네트워크 격리 정책도 거쳐야 합니다. 해당 앱의 루프백 예외를 허용한 뒤 시스템 프록시, 포트 및 규칙 모드를 다시 확인하면 대개 문제 발생 지점을 구체적으로 좁힐 수 있습니다.
1. UWP 루프백 제한은 어떻게 나타나는가
UWP 앱은 앱 컨테이너에서 실행되며, 각 앱은 독립된 ID와 권한 경계를 가집니다. 시스템 프록시 설정은 요청을 특정 프록시로 전달하도록 앱에 알려줄 수 있지만, 로컬 수신 주소에 접근할 수 있는지는 네트워크 격리 규칙의 영향도 받습니다. Clash가 정상적으로 실행 중이라고 해서 모든 앱에 로컬 프록시 접근 권한이 부여된 것은 아닙니다.
대표적인 증상은 다음과 같습니다. Microsoft Store는 열리지만 앱 다운로드가 계속 대기 상태로 남고, Xbox·게임 런처·날씨 앱은 서비스에 연결할 수 없다고 표시됩니다. Windows 설정에서는 계정 동기화가 실패할 수 있으며, 브라우저는 Clash를 통해 정상적으로 접속되는데 Store에서 설치한 앱만 네트워크 없음으로 표시되기도 합니다. Clash의 혼합 포트를 LAN 주소로 변경하면 일부 요청에 변화가 생길 수 있지만, 이는 우선 권장되는 해결책이 아닙니다. 수신 범위, 방화벽 및 LAN 노출이라는 새로운 변수가 함께 생기기 때문입니다.
UWP 앱과 일반 데스크톱 앱도 구분해야 합니다. 앱 이름이 같아도 네트워크 구현 방식까지 같은 것은 아닙니다. 예를 들어 Microsoft Store에서 설치한 버전은 앱 컨테이너에서 실행될 수 있지만, 공식 웹사이트의 설치 패키지는 Win32 데스크톱 프로그램인 경우가 많습니다. 전자는 루프백 격리의 영향을 더 쉽게 받으며, 후자는 대체로 시스템 프록시를 사용하거나 로컬 포트에 직접 연결할 수 있습니다.
2. 먼저 Clash의 수신 주소와 포트 확인하기
루프백 제한을 해제하기 전에 클라이언트에 실제로 사용할 수 있는 로컬 프록시 진입점이 있는지 확인합니다. Clash 클라이언트마다 메뉴 이름은 다를 수 있지만, 핵심 설정에는 보통 HTTP 포트, SOCKS 포트 및 혼합 포트가 포함됩니다. 혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있어 시스템 프록시 진입점이 하나뿐인 경우에 적합합니다.
- Clash 클라이언트의 설정 또는 일반 페이지를 열고 현재 활성화된 HTTP, SOCKS 또는 혼합 포트를 기록합니다.
- 수신 주소가
127.0.0.1과 같은 로컬 루프백 주소인지 확인하고, 해당 포트를 다른 프로그램이 사용하고 있지 않은지도 점검합니다. - Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시가 동일한 주소와 포트를 가리키는지 확인합니다.
- Clash의 연결 또는 로그 페이지에서 UWP 앱을 실행할 때 요청이 표시되는지 확인합니다.
시스템 프록시에 HTTP 포트를 입력해야 하는데 SOCKS 포트를 잘못 지정하면 일부 앱에서 바로 연결 오류가 발생합니다. 반대로 HTTP 프록시만 지원하는 일부 시스템 구성 요소는 SOCKS 포트를 일반 HTTP 프록시처럼 사용할 수 없습니다. 포트 번호는 현재 클라이언트 화면이나 설정 파일에 표시된 실제 값을 기준으로 확인하고, 다른 장치의 기본 설정을 그대로 사용하지 마세요.
시스템 프록시를 다른 프로그램이 관리하고 있지는 않은지도 확인해야 합니다. VPN, 네트워크 가속기, 패킷 캡처 도구 및 기업 관리 정책이 Windows 프록시 설정을 변경할 수 있습니다. Clash 로그에 UWP 앱 요청이 전혀 없다면 문제는 대개 프록시 진입점, 앱 권한 또는 시스템 프록시 선택 단계에서 발생합니다. 로그에 요청이 이미 표시된다면 규칙 매칭과 노드 응답을 계속 확인하세요.
3. Windows 도구로 루프백 접근 제한 해제하기
Windows는 CheckNetIsolation 명령으로 앱 컨테이너의 네트워크 격리 예외를 관리할 수 있습니다. 핵심은 데스크톱 바로 가기에 표시되는 이름이 아니라 대상 앱의 Package Family Name, 즉 패키지 패밀리 이름을 찾는 것입니다. 패키지 이름을 잘못 입력하면 명령이 실패하거나 이름이 비슷한 다른 앱에 예외가 적용될 수 있습니다.
방법 1: 그래픽 루프백 예외 도구 사용하기
신뢰할 수 있는 출처에서 제공하는 Windows 루프백 예외 관리 도구를 사용해 인터넷 연결이 필요한 앱을 선택하고 설정을 적용할 수 있습니다. 도구 목록에는 일반적으로 앱 이름과 패키지 식별자가 표시됩니다. 대상 앱을 선택해 저장한 뒤 앱을 완전히 종료하고 다시 실행하세요. 앱 업데이트 후에도 패키지 ID는 대체로 유지되지만, 다른 배포 경로의 버전을 설치했다면 실제 패키지 식별자를 다시 확인해야 합니다.
그래픽 도구는 명령줄에 익숙하지 않은 사용자에게 적합하지만, 사용하기 전에 다운로드 출처, 도구 설명 및 대상 앱 이름을 확인해야 합니다. 루프백 예외는 로컬 네트워크 권한 설정이므로 로컬 프록시에 연결해야 하는 앱만 선택하세요. 목록의 모든 앱을 무조건 허용하는 것은 권장하지 않습니다.
방법 2: PowerShell 또는 명령 프롬프트 사용하기
일반 사용자 권한으로 PowerShell 또는 명령 프롬프트를 열고 현재 루프백 예외 목록을 먼저 확인합니다.
CheckNetIsolation LoopbackExempt -s대상 앱의 Package Family Name을 확인한 뒤 다음 형식으로 예외를 추가합니다.
CheckNetIsolation LoopbackExempt -a -n=앱의PackageFamilyName여기서 앱의PackageFamilyName은 실제 값으로 바꿔야 하며 예시 문구를 그대로 입력하면 안 됩니다. PowerShell로 설치된 앱 패키지 정보를 조회한 다음 표시 이름으로 필터링할 수도 있습니다. 예를 들면 다음과 같습니다.
Get-AppxPackage | Select-Object Name, PackageFamilyName추가를 완료한 뒤 CheckNetIsolation LoopbackExempt -s를 다시 실행해 항목이 표시되는지 확인할 수 있습니다. 그런 다음 대상 앱을 종료하고, 필요하다면 작업 관리자에서 백그라운드 프로세스를 끝낸 뒤 다시 시작하세요. 창만 닫아서는 UWP 앱의 백그라운드 인스턴스가 완전히 종료되지 않을 수 있습니다. 재시작 후에도 변화가 없다면 먼저 앱을 완전히 종료하세요.
4. 제한 해제 후에도 인터넷에 연결되지 않을 때의 점검 순서
루프백 예외를 적용한 뒤에도 UWP 앱이 오프라인 상태라면 ‘앱 진입점—프록시 포트—클라이언트 로그—규칙 및 노드’ 순서로 확인하세요. 먼저 요청이 Clash에 도달했는지 판단한 다음 설정을 수정할 수 있다는 점이 이 순서의 장점입니다.
1. 앱이 시스템 프록시를 사용하는지 확인하기
모든 앱이 Windows의 수동 프록시 설정을 따르는 것은 아닙니다. 일부 앱은 시스템 WinINet 프록시를 사용하고, 일부는 WinHTTP를 사용하며, 앱 내부에 별도의 네트워크 옵션을 제공하는 경우도 있습니다. 먼저 Windows의 프록시 스위치와 주소를 확인한 다음 앱 자체에 프록시, 네트워크 또는 다운로드 설정이 있는지 살펴보세요. 앱이 시스템 프록시를 완전히 우회한다면 Clash의 HTTP 포트만 변경해도 효과가 없습니다.
2. 포트 유형과 수신 상태 확인하기
시스템 프록시는 일반적으로 HTTP 프록시 진입점을 사용합니다. 클라이언트에서 SOCKS 포트만 활성화되어 있다면 혼합 포트를 켜거나 호환되는 HTTP 포트를 올바르게 설정해야 합니다. 다른 서비스가 포트를 사용 중이거나, 클라이언트 재시작 후 포트가 변경되거나, 설정 파일과 현재 화면에서 사용하는 설정이 서로 다를 때도 간헐적으로 보이는 연결 실패가 발생할 수 있습니다.
3. 로그를 확인해 요청 도달 여부 판단하기
UWP 앱을 실행한 뒤 한 번 새로 고침하고 Clash의 연결 기록에서 해당 도메인을 찾습니다. 기록이 전혀 없다면 앱의 프록시 진입점, 루프백 예외 및 방화벽으로 돌아가 확인하세요. 기록은 있지만 거부 또는 시간 초과로 표시된다면 정책 그룹, 노드 지연 시간 및 DNS 결과를 계속 점검합니다. 기록에 직접 연결로 표시되는데 서비스에 연결되지 않는다면 규칙 매칭 또는 직접 연결 네트워크 자체의 문제일 수 있습니다.
4. 규칙 모드와 정책 그룹 확인하기
규칙 모드에서는 요청이 설정의 규칙 순서에 따라 매칭된 뒤 해당 정책 그룹으로 전달됩니다. 규칙에 따라 Microsoft, 로그인 서비스, 업데이트 서비스 또는 정적 리소스가 서로 다른 정책 그룹으로 분류될 수 있습니다. 테스트할 때는 일시적으로 전역 모드로 전환해 문제가 규칙 분기에 의한 것인지 확인할 수 있습니다. 테스트가 끝나면 일상적인 사용에 적합한 모드로 되돌리고 로그를 바탕으로 규칙을 조정하세요. 전역 모드에 장기간 의존해서는 안 됩니다.
5. DNS, 시간 및 시스템 보안 정책 확인하기
앱이 프록시 포트에는 연결되지만 도메인을 해석하지 못한다면 Clash의 DNS 설정, 시스템 DNS 및 현재 네트워크가 관련 조회를 차단하는지 확인합니다. 시스템 시간이 크게 틀리면 HTTPS 연결과 앱 스토어 인증에 영향을 줄 수 있습니다. 기업 관리 장치는 그룹 정책, 프록시 자동 구성 스크립트 또는 보안 소프트웨어를 통해 앱의 네트워크 접근을 제한할 수도 있으므로 장치 관리 규정에 따라 처리해야 합니다.
5. TUN 모드를 고려할 시점
TUN 모드는 가상 네트워크 인터페이스를 통해 더 낮은 계층의 트래픽을 가로채므로 시스템 프록시를 따르지 않는 일부 프로그램도 Clash의 처리 경로로 보낼 수 있습니다. 여러 앱, 게임 또는 시스템 구성 요소를 함께 지원해야 하는 경우에 적합하지만, 활성화하면 가상 네트워크 어댑터, 라우팅, DNS 및 관리자 권한이 관련되어 문제 해결이 더 복잡해집니다.
목표가 하나의 UWP 앱에서 로컬 HTTP 프록시에 접근하도록 하는 것이라면 먼저 루프백 예외와 시스템 프록시를 처리하세요. 여러 앱이 시스템 프록시를 읽지 않거나 앱 자체에 프록시 설정이 없을 때 TUN을 고려하면 됩니다. 활성화하기 전에 현재 설정을 기록하고 클라이언트가 지원하는 TUN 구현을 확인하며, 다른 VPN·가상 네트워크 어댑터·LAN 공유 소프트웨어와의 충돌에도 주의하세요.
TUN을 켠 뒤에도 Clash 로그와 규칙 매칭 결과를 확인해야 합니다. 트래픽이 TUN으로 들어왔다고 해서 반드시 프록시 노드를 사용하는 것은 아닙니다. 규칙에 따라 직접 연결, 거부 또는 특정 정책 그룹으로 배정될 수 있습니다. LAN 장치에 접근할 수 없거나 DNS 순환 또는 네트워크 끊김이 발생하면 먼저 TUN을 비활성화해 영향 범위를 확인한 뒤 라우팅과 DNS 설정을 하나씩 점검하세요.
6. 저장해 두기 좋은 빠른 점검 목록
- 브라우저가 Clash를 통해 정상적으로 접속되는지, 클라이언트가 실행 중으로 표시되는지 확인합니다.
- UWP 앱이 Microsoft Store에서 설치되었는지, 앱 컨테이너 환경에서 실행되는지 확인합니다.
- 대상 앱의 Package Family Name이 올바른지, 루프백 예외 목록에 항목이 표시되는지 확인합니다.
- Windows 시스템 프록시의 주소, 포트 및 프록시 유형이 Clash의 현재 수신 설정과 일치하는지 확인합니다.
- 앱을 실행하고 새로 고칠 때 Clash 연결 로그에 대상 도메인이 표시되는지 확인합니다.
- 요청이 들어온 뒤 규칙이 프록시, 직접 연결 또는 거부 정책 중 어디로 매칭되는지 확인합니다.
- 다른 VPN, 프록시 소프트웨어, 기업 정책 또는 방화벽이 네트워크 경로를 변경하고 있지 않은지 확인합니다.
- 시스템 프록시로 앱을 지원할 수 없다는 점을 확인한 뒤 TUN 모드와 가상 네트워크 어댑터 방안을 검토합니다.
이 문제의 핵심은 구독을 반복해서 바꾸는 것이 아니라 요청이 어느 계층을 통과했는지 확인하는 데 있습니다. UWP 루프백 제한은 ‘앱이 로컬 프록시 진입점에 접근할 수 있는가’를 해결하고, 포트 설정은 ‘앱이 어떤 프록시 서비스에 연결하는가’를 결정하며, 규칙과 노드 점검은 ‘요청이 Clash에 들어온 뒤 어떻게 전달되는가’를 확인합니다. 계층별로 차례차례 검증하면 권한, 프록시 진입점 및 설정 분기를 한꺼번에 바꾸는 일을 피할 수 있습니다.