Windows 11에서 Copilot이 안 열릴 때: Microsoft·Copilot 도메인을 Clash(mihomo)로 분기하는 실측 (2026)

1. 증상: 사이드바·Edge Copilot만 유독 불안정할 때

사용자가 겪는 그림은 대개 다음과 비슷합니다. 작업 표시줄의 Copilot 아이콘은 눌리는데 패널이 비거나, 잠시 후 지역에서 사용할 수 없습니다 류의 안내만 뜹니다. Edge 우측의 동일 기능은 웹 탭은 열리는데 사이드 패널만 스피너가 돌거나, Microsoft 계정 동의 화면에서만 반복됩니다. 이 패턴은 반드시 서비스 전체 장애만 의미하지 않고, Clash 분할에서 일부 호스트만 DIRECT·다른 정책 그룹으로 새는 경우가 매우 흔합니다.

mihomo 로그를 보면 한 화면을 채우기 위해 copilot.microsoft.com·bing.com·login.microsoftonline.com·정적 CDN·실험용 서브도메인이 연속으로 찍히는데, 그중 하나만 규칙 밖으로 나가면 UI는 반쯤 뜬 채 응답 스트림만 끊기는 식으로 보일 수 있습니다. 먼저 어떤 FQDN이 어떤 아웃바운드로 나갔는지 확정하는 것이 빠릅니다.

2. 스트리밍·보이스 글과 다른 Microsoft 통합 축

Disney+·Netflix 글은 재생·라이선스·Open Connect CDN 축을 다룹니다. Discord 글은 음성·UDP·게이트웨이 접미를 다룹니다. 반면 Windows 11의 Copilot 경험은 OS·브라우저·Microsoft 계정이 한 번에 얽히므로, 검색·위젯·인증·Edge 자동 업데이트까지 같은 세션에서 호스트가 갈라집니다. 따라서 다른 AI 글의 YAML을 그대로 가져와 붙이면 빈 규칙이 생기기 쉽습니다.

특히 Edge는 Chromium 기반이지만 Microsoft 전용 기능·확장·동기화가 추가로 붙습니다. 브라우저 일반 탭은 의도한 노드로 가는데, 사이드 패널만 다른 경로를 타면 증상이 「웹은 되는데 Copilot만」처럼 보입니다. 이는 Sniffer로 SNI·복원 도메인을 다시 확인할 가치가 있는 전형적인 케이스입니다.

3. 규칙에 넣기 좋은 Microsoft·Copilot 출발 도메인

아래는 출발점입니다. 실제로는 A/B 실험·CDN·기업용 테넌트에 따라 호스트가 늘거나 바뀔 수 있으므로, 개발자 도구 네트워크 탭·mihomo 로그·Windows 리소스 모니터에서 확인한 FQDN을 기준으로 목록을 보강하세요. 운영 단순화를 위해 DOMAIN-SUFFIX,microsoft.com처럼 너무 넓게 잡으면 Xbox·Office 업데이트까지 한꺼번에 끌고 가므로, 우선은 Copilot·Bing·인증에 자주 등장하는 축부터 쌓는 편이 안전합니다.

DOMAIN-KEYWORD,micro처럼 짧은 키워드는 다른 사이트까지 잡을 수 있어 비추천입니다. 반복되는 접미는 DOMAIN-SUFFIX로 쌓고, 예외만 DOMAIN으로 빼는 패턴이 안전합니다. 클라우드프론트 등 공용 CDN 호스트가 보이면, 여러 서비스에 공유되는지 확인한 뒤 규칙을 추가하세요.

4. mihomo rules 스니펫

전용 정책 그룹 이름을 예시로 🔷 Microsoft-Copilot라고 하면, rules에서 넓은 MATCH·지역 규칙보다 위쪽에 둡니다. 그룹·노드 이름은 본인 구독에 맞게 바꿉니다. 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # Microsoft Copilot / Bing / account — above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,copilot.microsoft.com,🔷 Microsoft-Copilot
  - DOMAIN-SUFFIX,bing.com,🔷 Microsoft-Copilot
  - DOMAIN-SUFFIX,microsoft.com,🔷 Microsoft-Copilot
  - DOMAIN-SUFFIX,live.com,🔷 Microsoft-Copilot
  - DOMAIN-SUFFIX,microsoftonline.com,🔷 Microsoft-Copilot
  # Add FQDNs from DevTools / mihomo logs (Edge update, CDN, experiments)

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

microsoft.com 전체를 한 그룹에 넣으면 업데이트·스토어 트래픽까지 같이 움직입니다. 범위가 과하면 로그에서 실제로 터진 호스트만 남기고 접미를 쪼개세요. 구독 갱신 시 커스텀 규칙이 덮어써지지 않게 하려면 구독 가져오기와 프로필 머지 순서를 확인합니다.

5. Edge·시스템 프록시·TUN(UWP 포함)

Windows 11에서 Clash를 처음 켤 때 시스템 프록시만 쓰면 일부 UWP·샌드박스된 프로세스는 예외 경로를 탈 수 있습니다. Clash Verge Rev 글에서 정리한 것처럼 TUN 모드는 이런 틈을 덜어 주는 편입니다. Copilot처럼 OS에 박힌 기능은 Edge·Shell 프로세스와 함께 움직이므로, 「브라우저 확장만 프록시」 같은 이중 스택과 겹치면 증상이 불규칙해집니다.

Edge 자체 설정에서 보안 DNS를 켜 두면 mihomo 밖으로 해석이 새어 규칙과 실제 연결이 어긋날 수 있습니다. 가능하면 테스트 동안에는 브라우저 보안 DNS를 끄고, Clash 쪽 DNS 스택으로만 맞춰 대조 실험하는 편이 재현을 좁히기 쉽습니다. 회사 PC라면 다른 보안 에이전트가 별도 프록시를 걸고 있을 수 있으니, 한 환경에서는 한 가지 출구 스택을 유지하는 것이 좋습니다.

6. DNS·fake-ip·DoH 누수

mihomo에서 enhanced-mode: fake-ip를 쓰면 도메인 규칙과 궁합이 좋지만, 운영체제·브라우저의 DNS over HTTPS가 우선하면 해석이 엔진 밖으로 나가 DOMAIN-SUFFIX 줄이 비는 것처럼 보일 수 있습니다. 특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. 아래는 예시이며 실제 업스트림은 본인 정책에 맞게 교체하세요.

# Optional — example only; use your own resolvers
dns:
  nameserver-policy:
    "+.copilot.microsoft.com":
      - https://dns.google/dns-query
    "+.bing.com":
      - https://dns.google/dns-query

전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것이 좋습니다. 서비스 약관·접속 정책은 사용자마다 다르므로 본문은 전송 경로만 다룹니다. 합법적으로 이용 가능한 환경에서 연결을 안정화하는 용도로만 활용하세요.

7. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, mihomo 로그에서 문제 요청이 의도한 DOMAIN-SUFFIX 줄에 매칭됐는지 확인합니다. 둘째, 🔷 Microsoft-Copilot에 묶인 노드의 지연·출구 지역이 기대와 맞는지 Proxies 화면에서 봅니다. 셋째, 작업 표시줄 Copilot과 Edge 사이드 패널을 같은 노드로 맞췄을 때 증상이 사라지는지 비교합니다. 넷째, DoH·다른 VPN·TUN 충돌을 점검합니다.

노드 품질·Microsoft 측 상태는 각자 다르므로, 구독이나 클라이언트를 갱신한 뒤에도 한 번씩 로그를 다시 확인하는 편이 좋습니다. 다른 AI 서비스용 YAML과 목록을 섞지 않도록 주의하세요.