Outlook·Word 웹과 Copilot 패널이 한 화면처럼 보여도 호스트는 갈라진다

Microsoft 365를 브라우저로 쓰면 메일·문서 편집·우측 Copilot 패널이 하나의 제품처럼 느껴집니다. 그러나 실제 HTTPS는 outlook.office.com·office.com·microsoft.com 하위 제품 API, login.microsoftonline.com 등 Entra ID(구 Azure AD) 로그인 체인, 그리고 Copilot·텔레메트리·CDN에 해당하는 추가 서브도메인으로 나뉩니다. Clash 규칙이 이중 일부 도메인만 의도한 정책 그룹을 타고 나머지는 DIRECT나 다른 출구에 남으면, OAuth 리디렉션이 끊기거나 WebSocket·장시간 세션이 반쪽으로 남아 「로딩만 돈다」「방금 로그인했는데 또 로그인」처럼 보입니다. 브라우저가 OS·Clash와 TUN 중 무엇을 따르는지에 따라 같은 URL도 다른 경로로 나갈 수 있으니, 먼저 증상을 라우팅 문제로 한정할지부터 짚는 편이 빠릅니다.

연결은 위에서 아래로 규칙이 맞을 때마다 출구가 결정됩니다. 한 번의 「문서 열기 + Copilot 질문」에 필요한 모든 호스트가 같은 정책 의도를 타지 않으면 TLS 핸드셰이크·리다이렉트·토큰 갱신 단계에서 지연이 겹칩니다. 해결은 대역폭만 늘리는 것이 아니라 관측한 호스트명에 맞춘 도메인 분류와, Clash DNS가 규칙 판단과 어긋나지 않게 맞추는 일입니다. Microsoft는 엔드포인트를 자주 조정하므로 커뮤니티 예시 YAML만 복붙하기보다 본인 브라우저 네트워크 탭과 Clash 라이브 연결을 대조하는 습관이 안전합니다.

ℹ 증거 먼저: Edge·Chrome 등에서 F12 → 네트워크를 연 채 문제를 재현하고, 실패하거나 오래 걸린 요청의 호스트명을 적습니다. 동시에 Clash에서 해당 흐름이 어느 정책·프록시 그룹에 걸렸는지 확인하세요. 실패한 이름이 office인지 microsoftonline인지 microsoft.com의 다른 서비스인지에 따라 수정할 규칙이 달라집니다.

브라우저 M365와 VS Code·GitHub Copilot 분류 글은 무엇이 다른가

같은 「Microsoft·Copilot」이라도 데스크톱 에디터 확장과 브라우저 Office는 호스트 지도가 다릅니다. 이 사이트의 GitHub Copilot·VS Code 마켓플레이스 분류 글은 marketplace.visualstudio.com·github.com·확장 CDN 쪽 비중이 크고, 본문은 office.com·웹앱·조직 계정 로그인에 가깝습니다. 용도가 겹치는 login.microsoftonline.com 등은 두 글 모두에서 중요하지만, 우선순위로 잡을 호스트 묶음이 다르므로 규칙을 그대로 옮기지 말고 네트워크 탭으로 다시 확인하세요.

IDE·터미널 OAuth에 초점을 둔 Cursor 개발자 글과도 장면이 다릅니다. 브라우저 M365는 탭·서비스 워커·Third-party 쿠키·기업 조건부 액세스와 맞물리므로, Copilot만 느리다고 해서 단일 원인으로 단정하기 어렵습니다.

세 덩어리: Office 웹 앱, Entra·SSO, Copilot·CDN

운영 관점에서는 대략 세 묶음으로 나누면 설계가 단순해집니다. (1) Office 웹·호스티드 앱 — *.office.com, outlook.office.com, 일부 지역·테넌트별 호스트, 문서·메일 UI와 연관된 제품 경로. (2) Microsoft 계정·Entra·SSO — login.microsoftonline.com, login.microsoft.com, 필요 시 *.microsoft.com 인증·동의·디바이스 등록 관련 하위 도메인(조직마다 추가 호스트가 다릅니다). (3) Copilot·Graph·백엔드·CDN — 제품 업데이트에 따라 substrate.office.com·graph.microsoft.com·Copilot 전용 엔드포인트·Azure Front Door·CDN 이름이 끼는 경우가 많고, 시기마다 달라질 수 있습니다. 한 묶음만 기대 출구를 타고 다른 묶음만 느린 노드에 남으면 UI는 반쯤 뜬 채 특정 패널만 실패하는 패턴이 납니다.

각 묶음에 DIRECT가 맞는지 특정 정책 그룹이 맞는지는 테넌트·리전·회사 VPN 정책에 따라 다릅니다. 중요한 것은 세 묶음이 서로 다른 의도로 섞이지 않게 YAML에 이름을 붙이고, 이유를 주석으로 남기는 것입니다. 규칙 가독성·순서는 규칙 분류 모범 사례와 함께 점검하세요.

시스템 프록시·DoH·기업 SSO와 헷갈리지 않기

Copilot·웹 Office 문제가 항상 Clash 규칙 불일치만은 아닙니다. OS의 수동 프록시·브라우저 확장·회사 제로트러스트 클라이언트가 먼저 트래픽을 잡으면 Clash 로그에 해당 흐름이 안 보일 수 있습니다. 브라우저 DoH(DNS over HTTPS)를 켜 두면 이름 해석이 Clash 쪽 DNS와 달라져 fake-ip 기반 규칙 판단과 어긋나기도 합니다. 이때는 Meta DNS·fake-ip·필터 글의 축으로 클라이언트 DNS 설정과 브라우저 설정을 같이 맞춥니다.

기업 SSO·조건부 액세스·디바이스 규정 준수는 라우터 한 대로 설명되지 않습니다. 특정 국가 IP·비관리 디바이스·토큰 만료 시 재로그인 루프가 나는데, 이때 Clash를 꺼도 동일하면 우선 계정·조직 정책 측을 의심하는 것이 순서입니다. Clash로 출구를 맞출 때도 무단 우회를 뜻하지 않으며, 허용된 망·약관 안에서만 적용하세요.

M365_STACK 같은 정책 그룹으로 출구 고정

예를 들어 M365_WEB·MS_AUTH·MS_COPILOT(이름은 자유)처럼 정책 그룹을 나누고, 각 뒤에 select·url-test 등을 붙입니다. 장시간 편집 세션에 견디는 노드와, 짧은 핸드셰이크가 중요한 로그인 전용 노드를 분리하고 싶다면 그룹을 쪼개되, 몇 달 뒤에도 읽히도록 YAML 옆에 한 줄 설명을 남깁니다. 라이브 연결 UI가 읽기 쉬운지는 클라이언트 선택에서도 다룹니다.

Entra 로그인은 리디렉트와 토큰 교환이 길어 login.microsoftonline.com만 맞추고 동의·디바이스 등록·추가 microsoft.com 호스트를 놓치기 쉽습니다. 브라우저 팝업과 메인 탭이 서로 다른 출구를 타면 「한 번은 됐는데 Copilot만 실패」가 될 수 있으니, 인증 흐름에 나온 호스트를 한꺼번에 모아 같은 정책 의도로 묶였는지 확인합니다.

정책이 맞아도 노드가 불안정하면 TLS 단계에서 멈춘 것처럼 보입니다. 이 경우 연결 로그의 timeout·TLS로 출구 건강을 먼저 의심한 뒤 도메인 구멍을 좁히세요.

관측 우선·예시 DOMAIN-SUFFIX YAML

아래는 형태를 보여 주는 예시입니다. 테넌트·지역·제품 빌드에 따라 실제로는 추가 호스트가 필요합니다. 반드시 본인 환경에서 관측한 이름을 더하세요. Office 웹·공통 UI에는 DOMAIN-SUFFIX,office.com,M365_WEB 같은 패턴이 자주 쓰이고, 인증 체인에는 DOMAIN-SUFFIX,microsoftonline.com,MS_AUTH·DOMAIN-SUFFIX,live.com,MS_AUTH 등이 출발점이 됩니다. DOMAIN-SUFFIX,microsoft.com,...는 범위가 매우 넓어 Xbox·Windows 업데이트·다른 MS 서비스까지 한꺼번에 잡힐 수 있으니, 팀 허용 범위와 함께 신중히 쓰고 가능하면 로그로 좁힌 DOMAIN 규칙을 병행합니다.

DOMAIN-SUFFIX가 DOMAIN-KEYWORD보다 예측 가능합니다. 키워드는 임시로만 쓰고, 확인된 접미사로 옮기세요.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,office.com,M365_WEB
  - DOMAIN-SUFFIX,office365.com,M365_WEB
  - DOMAIN-SUFFIX,microsoftonline.com,MS_AUTH
  - DOMAIN-SUFFIX,microsoft.com,M365_STACK
  - DOMAIN-SUFFIX,live.com,MS_AUTH
  - DOMAIN-SUFFIX,sharepoint.com,M365_WEB
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

위 예시의 M365_STACK는 설명 편의를 위한 이름이며, 실제 프로필에서는 M365_WEB·MS_AUTH처럼 더 잘게 나누는 경우가 많습니다. MATCH가 DIRECT인 구성에서는 목록 밖의 새 엔드포인트가 직행하다 특정 API만 막혀 Copilot만 비는 것처럼 보일 수 있어, 관측 기반 보강이 핵심입니다.

브라우저·시스템 프록시·TUN 우선순위

Chromium·Edge 계열 브라우저는 OS 시스템 프록시를 따르는 경우가 많지만, 확장·앱 모드·보안 정책에 따라 예외가 생깁니다. Clash가 「시스템 프록시 설정」만 켜면 일반 탭은 잘 나가는데 특정 PWA·사이드 패널만 다른 경로를 탈 수 있습니다. 이때 TUN 모드는 커널 라우팅으로 흐름을 한 레이어에서 모으는 편이 확실하지만, 회사 VPN·다른 TUN 클라이언트와 라우팅 메트릭이 충돌하면 기대와 다르게 동작합니다. 「시스템 프록시만」「TUN만」을 바꿔 가며 실제로 어떤 정책이 적중했는지 로그로 확정하세요.

이론상 우선순위는 환경마다 다르고, 중요한 것은 Clash 연결 화면에 찍힌 정책 적중입니다. Copilot 기능 라이선스·조직 정책 때문에 비활성화된 경우와 착각하지 않도록, 동일 호스트에 대해 먼저 출구 일관성을 확인합니다.

규칙 세트·구독 갱신과 신뢰 경계

M365 호스트는 변동이 잦아 손으로만 YAML을 유지하기 어렵습니다. Clash 규칙 공급자로 원격 규칙 세트를 주기 갱신하면 부담을 줄일 수 있지만, 출처는 신뢰 자산이며 과하게 넓은 목록은 다른 트래픽까지 잡거나 사용자 정의 세부 규칙을 가릴 수 있습니다. RULE-SET을 넣을 때는 규칙 테이블에서의 위치, 넓은 GEOIP·차단 목록보다 위인지 아래인지를 함께 설계하세요.

구독 URL·규칙 갱신 자체도 안정 출구가 필요합니다. 갱신만 실패하면 노드 목록이 낡아 모든 사이트가 동시에 불안해 보입니다. 운영 점검은 구독·노드 유지보수와 같은 맥락입니다.

Clash DNS·fake-ip·브라우저 DoH 정렬

브라우저가 이름을 풀고 Clash가 경로를 고르는 과정이 어긋나면 「DNS는 됐는데 TCP만 안 붙는다」는 패턴이 납니다. fake-ip를 쓰면 로컬 판단은 단순해지지만, DOMAIN 규칙 커버리지와 DNS가 같이 가야 합니다. OS·브라우저 DoH를 Clash와 동시에 켜 두면 우선순위가 꼬여 증상만 복잡해집니다. Meta DNS nameserver·fallback·fake-ip 필터 글의 축으로 클라이언트 설정을 정리한 뒤, 필요하면 브라우저 쪽 DoH를 잠시 끄고 대조 실험을 해 보세요.

웹앱이 백그라운드에서 *.blob.core.windows.net·스토리지·분석 엔드포인트를 추가로 열면, 한 번의 저장·Copilot 호출에도 새 호스트가 잡힙니다. 로그에 이름이 보이면 DOMAIN 한 줄을 더하는 편이 안전합니다. 분기마다 네트워크 탭을 샘플링하면 유지보수 비용이 줄어듭니다.

일반적인 DNS·연결성 질문은 FAQ를 먼저 보고 규칙을 손대면 시행착오가 줄어듭니다.

규칙 순서·광범위 RULE-SET·MATCH

규칙은 위에서 아래로 먼저 맞은 것이 이깁니다. 광고·추적 차단용 원격 세트가 너무 위에 있으면 웹앱이 기다리는 텔레메트리·실험 호스트를 건드려 멈춘 UI를 만들 수 있습니다. GEOIP·IP 기반 규칙이 office.com·microsoft.com 접미사보다 먼저 걸리면 M365 트래픽이 의도와 다른 출구로 나갑니다. 세트를 갱신한 뒤 깨졌다면 이전 리비전과 비교해 한 단계씩 되돌려 보세요.

MATCH는 잡히지 않은 흐름의 최종 승자입니다. 기본이 DIRECT인 프로필은 국내 트래픽에 유리하지만, 새 호스트를 벤더가 빨리 추가하면 커버리지를 따라잡는 운영이 필요합니다. 모든 트래픽을 프록시로 보내는 MATCH는 부작용이 크므로 M365용 명시 규칙과 보수적 기본값의 균형이 안전합니다.

검증: 브라우저 네트워크 탭·Clash 라이브 연결

재현 절차를 고정하세요. Outlook 또는 Word 웹에서 문제 동작을 한 번 재현한 뒤, 네트워크 탭의 실패·지연 요청 호스트와 Clash 라이브 연결의 정책 적중을 대조합니다. office.com·microsoftonline.com·substrate.office.com·graph.microsoft.com 등(환경마다 다름)이 기대한 정책 그룹인지 확인합니다. 기대와 다르면 규칙을 고치고, 정책이 맞는데도 실패하면 TLS·TCP 타임아웃 로그로 내려갑니다.

변경을 적용할 때 날짜와 호스트 한 줄이라도 메모해 두면 기기 간 프로필 동기화가 쉬워집니다. 예: 「2026-04-21, 네트워크 탭에서 호스트 X를 확인해 office.com 묶음에 DOMAIN 한 줄 추가」.

준수·회사·캠퍼스 네트워크

⚠ 준수 알림: 현지 법령·Microsoft 서비스 약관·고용주·교육기관의 허용 사용 정책을 준수하세요. 본문은 허용된 네트워크에서의 라우팅 위생을 설명하며, 무단 접근·계정 공유·정당한 보안 통제 우회를 조장하지 않습니다.

기업망은 분할 터널, 강제 DNS, SSL 검사, 조건부 액세스를 둘 수 있어 집에서의 YAML만으로는 동일하게 재현되지 않을 수 있습니다. 기술 경로가 정책 면제를 뜻하지 않으니, 제한이 있으면 IT 절차를 따르는 것이 안전합니다.

맺음말: 365 웹·Copilot는 도메인 지도가 맞아야 안정한다

Microsoft 365 Copilot과 브라우저 Office는 단일 호스트 서비스가 아닙니다. office.com·microsoft.com·로그인·Graph·CDN이 한 화면 경험으로 묶일 뿐이며, Clash는 그 흐름을 정책 그룹과 도메인 규칙으로 서술하게 해 줍니다. 서술이 실제 트래픽과 다르면 사용자는 「MS 서버가 느리다」보다 먼저 무한 로딩·재로그인을 보게 되고, 원인은 종종 라우팅·DNS 불일치입니다.

생산적인 대응은 브라우저와 Clash 로그로 호스트를 모은 뒤 접미사 규칙을 보강하고, Meta DNS·fake-ip·브라우저 DoH를 정렬하며, 시스템 프록시와 TUN 중 실제로 적중한 경로를 확정하고, 원격 규칙 세트를 신뢰 경계 안에서 갱신하는 것입니다. VS Code·GitHub Copilot 글과 달리 이 글은 브라우저 M365·Copilot 장면에 맞춘 분기입니다.

→ Clash를 무료로 다운로드해 Office 웹·Copilot이 막힐 때 호스트별 출구를 빠르게 맞춰 보세요.