증상: 프록시는 켜졌는데 Copilot·사이드바만 실패할 때

Windows 11에서 작업 표시줄이나 단축키로 여는 Microsoft Copilot, 혹은 Microsoft Edge 오른쪽의 Discover·쇼핑·Bing 채팅류 사이드바는 겉으로 보기엔 “브라우저 한 조각” 같지만, 실제로는 WebView2·백그라운드 업데이트·계정 토큰 갱신이 서로 다른 호스트로 흩어질 수 있습니다. 그래서 일반 탭에서 bing.com이 열리는 것과 무관하게, 패널 안의 스크립트가 막히면 빈 화면, 무한 로딩, “이 지역에서는 사용할 수 없습니다” 류 메시지가 동시에 등장합니다.

Clash를 쓰는 사용자에게 흔한 착시는 “시스템 프록시 스위치만 본다”는 점입니다. Windows 설정의 프록시는 많은 Win32 앱과 Edge의 일부 경로를 따라가지만, ① 코어가 실제로 기대한 노드로 나가고 있는지, ② 분류 규칙에서 마이크로소프트 축이 DIRECT나 잘못된 그룹으로 먼저 먹히는지, ③ 프록시 서버를 사용하지 않는 주소(우회 목록)에 *.microsoft.com 같은 항목이 들어가 있지 않은지가 별개입니다. ChatGPT·Claude 중심의 AI 도메인 글과 달리, 여기서는 Edge·Copilot·Bing·계정 축에 초점을 맞춥니다.

Edge·Copilot 트래픽이 갈라지는 지점

문제를 네트워크 관점에서 쪼개면 다음 세 덩어리가 큽니다. 첫째, 사용자가 주소창에 치는 일반 탭 HTTPS. 둘째, 패널·사이드바를 그리는 임베디드 WebView와 그 안의 XHR·WebSocket. 셋째, Windows 자체의 Microsoft 계정·스토어·업데이트와 섞이는 백그라운드 호출입니다. 둘째와 셋째는 브라우저 확장 프로그램이나 “이 사이트만 직접 연결” 같은 로컬 규칙의 영향을 덜 받는 대신, 시스템 인증서 저장소와 WinHTTP/WinINET 스택 차이를 더 자주 탑니다.

Clash 로그를 볼 수 있다면, 증상이 날 때 msedge.exe·WebView2 관련 프로세스에서 나가는 SNI가 무엇인지 먼저 적어 두세요. 이름만 보고 추측하지 말고, 한두 번이라도 실제 세션에서 확인된 호스트를 규칙에 올리는 편이 안전합니다. 과도하게 넓은 DOMAIN-SUFFIX,cdn류는 다른 서비스까지 끌고 와 지연을 키울 수 있습니다.

출발점: 자주 거치는 마이크로소프트·Bing 축 도메인

엣지 구성은 시기와 빌드·채널(Stable/Beta)에 따라 바뀌므로 아래는 체크리스트용 출발점입니다. 구독의 GEOSITE·GITHUB 규칙 세트에 “microsoft” 류가 포함돼 있어도, 순서가 어긋나면 의미가 없습니다.

  • 브랜드·공통 API: microsoft.com, www.microsoft.com, microsoftonline.com, login.microsoftonline.com, login.live.com, account.microsoft.com
  • 클라우드·현대형 엔드포인트: windows.net, cloud.microsoft, azure.com 일부(테넌트·리전별 호스트는 로그로 확인)
  • 검색·Copilot·Bing: bing.com, www.bing.com, edgeservices.bing.com, copilot.microsoft.com, sydney.bing.com(빌드에 따라 상이), bingapis.com
  • Edge 자체: edge.microsoft.com, msedge.api.cdp.microsoft.com 등(클라이언트 업데이트·구성)
  • 텔레메트리·진단(선택): 증상과 직접 연관이 적을 수 있으나, 일부 네트워크에서 차단 목록과 충돌하면 이상 증상을 키우기도 합니다.

이 중 일부만 분류 규칙에 있고 나머지는 아래쪽 GEOIP,CN DIRECT나 광역 MATCH로 흡수되면, “로그인은 되는데 대화만 안 된다”처럼 부분 성공이 납니다. Gemini 글에서 말한 “제품마다 호스트 묶음이 다르다”는 원리를, 마이크로소프트 스택에 그대로 적용하면 됩니다.

분류 규칙 순서: 좁은 줄을 넓은 규칙보다 위에

Clash·mihomo 계열에서 규칙은 위에서 아래로 첫 매칭 우선입니다. GEOIP나 지역별 큰 덩어리가 먼저 오면, 그 아래의 DOMAIN-SUFFIX,bing.com는 평가되지 않습니다. Copilot·Edge 전용 전략 그룹(예: PROXY-MS)을 쓴다면 YAML의 그룹 이름과 규칙 줄의 이름이 완전히 일치하는지 GUI와 원본 프로필을 대조하세요. 

# Conceptual fragment — adjust names, nodes, and order to your profile
proxy-groups:
  - name: PROXY-MS
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,copilot.microsoft.com,PROXY-MS
  - DOMAIN-SUFFIX,bing.com,PROXY-MS
  - DOMAIN-SUFFIX,microsoft.com,PROXY-MS
  - DOMAIN-SUFFIX,microsoftonline.com,PROXY-MS
  - DOMAIN-SUFFIX,live.com,PROXY-MS
  # ... verified subdomains from your logs ...
  # broader GEOIP / MATCH below

구독에 “중국 본토 직연결” 같은 자동 분류가 들어 있다면, 그 줄이 마이크로소프트 호스트를 DIRECT로 보내 버리는지 반드시 확인하세요. 회사 LAN이나 교육망에서는 DIRECT가 곧 차단이기도 합니다. 반대로 해외 노드가 불안정하면 일시적으로 DIRECT로 내려 테스트해, 증상이 네트워크인지 정책(지역)인지 가늠할 수 있습니다.

TUN과 시스템 프록시: 둘 다 켜면 오히려 꼬인다

TUN 모드는 OS에 가깝게 트래픽을 받아 분류 규칙을 일관되게 태우기 좋습니다. 시스템 프록시는 Edge 같은 앱이 WinINET 경로로 잘 따르는 편입니다. 그런데 둘을 동시에 켠 뒤 서로 다른 포트·다른 코어 인스턴스를 가리키면, 한쪽은 성공하고 한쪽은 실패하는 이중 경로가 됩니다.

실무에서는 한 가지를 기준 모드로 정하고 나머지는 끄는 편이 디버깅에 유리합니다. TUN 위주라면 Windows 설정의 수동 프록시를 비우거나 Clash 클라이언트의 “시스템 프록시” 토글과 역할이 겹치지 않게 정리하세요. 반대로 TUN 없이 시스템 프록시만 쓴다면, 백그라운드 서비스가 프록시를 무시하는지 확인해야 합니다. 전체 개념은 TUN 모드 가이드와 Clash for Windows 튜토리얼을 먼저 맞춰 두면 속도가 납니다.

HTTP/3(QUIC)가 켜진 환경에서는 SNI만으로 규칙이 안 잡히는 경우가 있어, 필요 시 Meta Sniffer·QUIC 글의 설정을 함께 검토합니다.

Windows “프록시 서버를 사용하지 않는 주소”가 Copilot을 죽일 때

제어판·설정 앱의 인터넷 옵션 계열 화면에는 “로컬 주소에는 프록시 서버 사용 안 함”과 더불어, 세미콜론으로 구분하는 우회 목록이 있습니다. 여기에 *.microsoft.com, *bing*, 사내 도메인, 또는 과거에 남은 <local> 예외가 있으면, 겉으로는 시스템 프록시가 켜져 있어도 해당 패턴은 프록시를 타지 않습니다. 그 결과 브라우저 확장으로 우회한 탭만 되고, 시스템 스택을 타는 패널만 실패하는 그림이 나옵니다.

PAC 스크립트를 쓰는 조직망이라면, PAC 안의 DIRECT 분기가 마이크로소프트 호스트를 우연히 직연결로 보내고 있지 않은지도 봐야 합니다. 변경 후에는 Edge 프로세스를 완전히 종료했다가 다시 열어 캐시된 프록시 설정을 비우는 것이 좋습니다.

DNS·fake-ip: 이름이 먼저 깨지면 패널도 빈다

DNS는 “어떤 IP로 붙을지”의 전제를 만듭니다. fake-ip를 쓰면 도메인 기준 분류 규칙과 맞물리기 쉽지만, OS·브라우저·보안 제품의 DoH가 먼저 실제 IP를 고정하면 IP 기준 규칙 위주로만 판정될 수 있습니다. Copilot이 특정 CDN 엣지만 요구하는 빌드라면, 해석 결과가 세션마다 달라 TLS 오류나 빈 응답으로 이어지기도 합니다.

fake-ip-filter에 넣어야 할 호스트가 빠졌는지, redir-host 계열에서 IP-CIDR·GEOIP와 충돌하지 않는지는 규칙 심화 가이드의 흐름과 같습니다. “탭은 되는데 패널만 안 된다”면 DNS보다는 우회 목록·규칙 순서를 먼저 의심하고, 둘 다 정상인데도 지역 메시지가 뜨면 아래 절로 넘어갑니다.

지역 제한 메시지와 순수 네트워크 실패 구분하기

UI에 특정 언어로 “해당 지역에서 지원하지 않습니다” 류 문구가 명시되면, 프록시 품질 문제가 아니라 계정·빌드·정책 층일 수 있습니다. 이때 노드를 바꿔도 동일하면, Clash 설정을 넘어 Windows 지역 형식·Microsoft 계정 국가·조직 정책을 점검해야 합니다. 반면 타임아웃·ERR_CONNECTION·끊임없는 스피너는 대개 경로·DNS·우회 목록 쪽입니다.

실험할 때는 동일 PC에서 프로필 A(보수적 DIRECT 다수)와 프로필 B(마이크로소프트 축만 PROXY)를 번갈아 적용해 차이를 좁히면 원인 분리가 빨라집니다. 구독 갱신 절차는 구독 관리 글에 맡기고, 여기서는 경로만 다룹니다.

자가 점검 체크리스트

  • Copilot·Bing·계정 축 DOMAIN 규칙이 넓은 GEOIP·MATCH보다 위에 있는가.
  • 전략 그룹 이름이 규칙과 일치하고, 실제 로그에서 기대한 노드로 나가는가.
  • TUN과 시스템 프록시가 서로 다른 코어를 가리키며 이중으로 켜져 있지 않은가.
  • Windows 프록시 우회 목록·PAC에 마이크로소프트 호스트가 실수로 DIRECT로 빠지지 않는가.
  • DNS·fake-ip·DoH가 규칙 전제와 같은 축을 보고 있는가. 필요 시 Sniffer·QUIC를 검토했는가.
Clash는 로컬 프록시 엔진일 뿐이며, 타인의 서비스 약관·법령·기관·회사 정책을 위반하도록 안내하지 않습니다. 본인이 관리하는 기기에서, 적용 가능한 범위에서만 설정하세요.

정리: 데스크톱 AI 입구를 “한 줄기”로 맞추기

Windows 11에서 Microsoft Copilot과 Edge 사이드바는 2026년에도 대표적인 데스크톱 AI 진입점입니다. 시스템 프록시 표시만 믿지 말고, 분류 규칙 순서·전략 그룹·TUN과 시스템 프록시의 택일·프록시 우회 목록·DNS를 같은 전제로 맞추면 “탭은 되는데 패널만 안 된다” 류 증상을 많이 줄일 수 있습니다. ChatGPT·Claude·Gemini 글과 겹치지 않는 마이크로소프트·Bing 축을 명시해 두면, 구독 규칙이 바뀌어도 손볼 위치를 빠르게 찾을 수 있습니다.

같은 요구를 두고 비교해 보면, Clash·mihomo 계열은 제품별로 경로를 쪼개 저장하기에, 데스크톱 전체를 한 노드에 묶지 않고도 실험하기 좋습니다. 클라이언트 한 곳에서 프로필 전환과 로그를 동시에 볼 수 있으면 시행착오 시간이 줄어듭니다.

전체 기능 맥락은 문서 허브와 함께 읽으면 구성 요소 이름이 더 빨리 익숙해집니다.

→ Clash 공식 클라이언트 무료 다운로드 — Windows에서 Copilot·Edge 경로를 규칙으로 묶고 시스템 프록시와 함께 쓰고 싶다면, 최신 빌드를 받아 프로필을 직접 맞춰 보는 것이 가장 빠릅니다.