1 왜 GitHub Copilot·ChatGPT 글만으로는 부족한가
GitHub Copilot 문서는 github.com·개발 도구 체인의 로그인·API 호스트를 안정화하는 데 맞춰져 있습니다. ChatGPT 튜토리얼은 openai.com 축입니다. 반면 Microsoft 365 Copilot은 브라우저의 copilot.microsoft.com 같은 소비자용 표면과, Word·Excel·Outlook 안에서 돌아가는 엔터프라이즈 기능이 동일한 Microsoft 로그인·테넌트 설정·Microsoft Graph 권한에 묶여 있을 수 있습니다. 즉 «AI 호스트 한 줄»만 맞추어도 나머지가 DIRECT로 새면 토큰·리디렉션·장시간 폴링이 끊겨 증상이 겹칩니다.
Office 365 시대부터 쓰던 팀이라도 2026년에는 클라우드 파일·팀즈 미팅·웹앱 편집기가 더 많은 하위 도메인을 오갑니다. Clash 분할 설계 시 «모델 브랜드 이름»이 아니라 «제품이 실제로 붙는 FQDN 묶음»을 기준으로 잡는 편이 재현성이 높습니다. 프로파일은 다운로드 페이지에서 고른 뒤 Rule 모드를 켠 상태에서 Connections 로그를 확인하세요.
2 흔한 증상: 로그인 루프·동기 지체·Copilot만 멈춤
Microsoft 로그인 단계에서 브라우저와 네이티브 앱은 login.microsoftonline.com·login.live.com 계열과 정적 리소스·리디렉션 체인을 동시에 요청합니다. 일부만 다른 국가 노드로 나가면 세션이 성립하지 않아 «로그인 버튼만 돈다»는 패턴이 납니다. OneDrive 동기는 파일 본문뿐 아니라 썸네일·버전 이력·공유 링크가 sharepoint.com·지역화된 호스트를 함께 쓰기 때문에, 본문만 프록시하고 저장소 호스트는 직행이면 업로드 큐가 멈춘 것처럼 보일 수 있습니다.
Microsoft 365 Copilot는 문서 컨텍스트를 읽고 제안을 띄우는 과정에서 Microsoft Graph·Office 백엔드 호출이 묶입니다. 증상이 «편집·저장은 되는데 Copilot 패널만 오류»이면 AI 표면보다 graph.microsoft.com·테넌트별 SharePoint URL이 다른 프록시 그룹인지부터 비교해 보세요. 반대로 전 구간이 느리면 노드 품질·MTU·DNS를 먼저 의심합니다.
3 핵심 축 ①: Microsoft 로그인·아이덴티티·CDN
실무에서 먼저 한 블록으로 묶어두면 디버깅이 쉬운 축은 다음과 같습니다. 조직 계정은 login.microsoftonline.com·login.microsoft.com 트리가 중심이고, 소비자 Microsoft 계정이 섞이면 login.live.com·account.microsoft.com 요청이 추가됩니다. 브라우저의 로그인 페이지가 불러오는 정적 자산은 aadcdn.msauth.net·aadcdn.msftauth.net 같은 CDN 접미사로 퍼지기 때문에, 로그인 HTML만 프록시하고 CDN이 직행이면 스크립트 로드가 끊긴 것처럼 보일 수 있습니다.
조직에서 조건부 액세스·디바이스 규정을 쓰면 추가 호스트가 붙습니다. 문서의 고정 목록만 믿기보다 Mihomo Connections에서 실패 직전의 FQDN을 확인하는 편이 안전합니다. 넓은 DOMAIN-KEYWORD,microsoft 한 줄은 오탐이 커서, 팀 합의 아래 접미사 블록을 여러 줄로 나누는 방식이 운영에 유리합니다.
4 핵심 축 ②: Microsoft Graph와 Office 온라인 호스트
클라이언트·애드인·자동화 스크립트가 공통으로 거치는 API면 graph.microsoft.com이 대표적입니다. 브라우저에서 워드·엑셀 웹을 열면 office.com·www.office.com·microsoft365.com·테넌트별 -my.sharepoint.com 같은 호스트가 함께 등장합니다. 메일은 outlook.office.com·outlook.live.com 축이 겹치고, 팀즈 연동 시에는 별도의 Teams 호스트가 추가될 수 있습니다.
이런 호스트를 서로 다른 규칙 줄에 흩어 놓으면 «한 기능만 간헐적으로 실패»하기 쉽습니다. DOMAIN-SUFFIX로 상위 접미사를 묶되, 회사에서 허용한 SaaS 출구와 충돌하지 않게 프록시 그룹 이름을 팀에서 통일하세요. 노드가 자주 바뀌는 url-test 그룹은 장시간 세션에 불리할 수 있어, 필요하면 url-test·fallback 글을 참고해 전환 빈도를 낮춥니다.
5 핵심 축 ③: OneDrive·SharePoint·스토리지
OneDrive 데스크톱 동기 클라이언트는 onedrive.live.com·storage.live.com 등 저장소 API와, 조직 테넌트의 sharepoint.com 하위 사이트를 오갑니다. 웹에서 파일을 열면 동일한 파일에 대해 Graph 호출과 공유 링크용 호스트가 나란히 등장합니다. «동기만 느리고 웹은 된다»와 같이 경로별로 증상이 갈리면, 동기 전용 호스트가 다른 출구로 라우팅되었는지 확인합니다.
지리적으로 가까운 리전 노드를 쓰고 싶다고 해서 규칙을 과도하게 쪼개면 오히려 순환이 납니다. 우선 한 프록시 그룹 안에서 지연과 안정성을 맞춘 다음, 필요할 때만 저장소 축을 분리하는 편이 디버깅 비용이 적습니다.
6 Microsoft 365 Copilot 표면과 웹 Copilot
제품명이 비슷해도 호스트는 갈라질 수 있습니다. 브라우저의 소비자 Copilot 경험은 copilot.microsoft.com·bing.com 인접 호스트와 연결되는 경우가 있고, Word 안의 Microsoft 365 Copilot는 테넌트·라이선스·업데이트 채널에 따라 Office 온라인·Graph 호출 비중이 달라집니다. 본문은 모든 미래 호스트를 한 줄로 보장하지 않습니다. 대신 Connections에서 확인한 FQDN을 Rule Provider로 버전 관리하는 흐름을 권장합니다.
이미 Gemini 전용 그룹을 쓰고 있다면, Office 안의 Copilot이 그 외부 호스트를 직접 부르는지 로그로 검증한 뒤에만 규칙을 합치세요. 추측으로 묶으면 오히려 루프가 생깁니다.
7 DOMAIN-SUFFIX와 규칙 순서
Clash 분할에서 규칙은 위에서 아래로 적용됩니다. 거대한 GEOSITE 묶음이 좁은 제품용 줄보다 위에 있으면 의도한 전용 그룹에 닿기 전에 흡수됩니다. PROXY-M365 같은 그룹을 만들었다면 (1) 팀이 합의한 Microsoft·Office 관련 접미사 블록, (2) 그 아래에 더 일반적인 규칙 순으로 배치해 읽기 쉽게 정리하세요.
OpenRouter처럼 API 키 기반 서비스 글에서 쓰는 키워드 규칙과 섞일 때는, 좁은 접미사가 넓은 키워드보다 위에 오도록 순서를 재점검합니다. 현장 프로파일을 덧씌우려면 mixin·구독 덮어쓰기를 활용하세요.
8 Rule Provider로 목록을 버전 관리하기
호스트가 늘어날수록 YAML에 직접 붙여 넣기보다 사내 Git에 텍스트 목록을 두고 Rule Provider로 가져오는 편이 유지보수에 유리합니다. behavior: classical 목록을 올려 두고 RULE-SET,m365-2026,PROXY-M365처럼 참조하면 긴급 한 줄은 수동 규칙으로, 주간 동기화는 Provider로 나눌 수 있습니다.
외부 URL 목록을 그대로 신뢰하기 어렵다면 자체 미러를 두고 체크섬을 검증하세요. 구독 형식이 다르면 구독 변환 가이드로 맞춘 뒤 규칙 블록을 얹습니다.
9 YAML 예시 (개념 스니펫)
아래는 병합용 예시입니다. PROXY-M365는 본인의 proxy-groups 이름에 맞추고, 테넌트·지역·제품 조합에 따라 줄을 추가하세요. 배포 전에는 반드시 Connections 로그로 검증합니다.
# Identity & login (work + consumer overlap)
- DOMAIN-SUFFIX,microsoftonline.com,PROXY-M365
- DOMAIN-SUFFIX,microsoft.com,PROXY-M365
- DOMAIN-SUFFIX,live.com,PROXY-M365
- DOMAIN-SUFFIX,msauth.net,PROXY-M365
- DOMAIN-SUFFIX,msftauth.net,PROXY-M365
# Microsoft Graph
- DOMAIN-SUFFIX,graph.microsoft.com,PROXY-M365
# Office web & endpoints (add tenant-specific FQDNs as needed)
- DOMAIN-SUFFIX,office.com,PROXY-M365
- DOMAIN-SUFFIX,microsoft365.com,PROXY-M365
- DOMAIN-SUFFIX,sharepoint.com,PROXY-M365
- DOMAIN-SUFFIX,onedrive.com,PROXY-M365
- DOMAIN-SUFFIX,svc.ms,PROXY-M365
# Optional: browser Copilot surface (verify in your Connections log)
- DOMAIN-SUFFIX,copilot.microsoft.com,PROXY-M365
# Keep this block above overly broad GEO / keyword catch-all rules.
DOMAIN-SUFFIX,microsoft.com은 범위가 넓습니다. 팀 정책상 과하다면 로그에 자주 보이는 하위 접미사만 남기고 줄이세요. 반대로 누락이 잦다면 전용 Rule Provider 줄을 늘리는 편이 예측 가능합니다.
10 DNS·TUN·시스템 프록시
규칙이 맞아도 DNS가 ISP 쪽으로 새면 지역 응답이 어긋나 매칭 전에 실패하는 것처럼 보입니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. 회사 HTTP 프록시와 Clash 시스템 프록시가 이중으로 겹치지 않게 한 겹만 남기는 것도 로그인 플로우 안정에 중요합니다. 필요하면 TUN 모드로 경로를 통일합니다.
11 트러블슈팅 체크리스트
- 로그인만 실패:
login.microsoftonline.com·CDN 접미사·리디렉션이 같은 그룹인지 확인합니다. - 웹은 되는데 동기만 멈춤:
sharepoint.com·onedrive축이 다른 출구로 갈렸는지 봅니다. - Graph 호출만 403·401: 토큰·조건부 액세스·프록시 IP가 정책과 맞는지와 별도로, 규칙상 호스트가 끊기지 않았는지 확인합니다.
- 간헐적 신규 호스트: 로그를 캡처해 Rule Provider에 반영합니다.
12 정책·라이선스·올바른 사용
연결이 안정되어도 Office 365·Microsoft 365 라이선스 조건과 조직 IT 정책은 그대로 적용됩니다. 본문은 합법적인 업무 환경에서 Clash 분할을 정돈하는 방법을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. 테넌트 관리자 설정·데이터 상주 규정을 우선하세요. 클라이언트 소스는 공개 저장소에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
13 정리
2026년 Microsoft 365 Copilot과 Office 365 생산성 스택을 쓸수록, «범용 AI 사이트 한 줄»이나 «GitHub만 맞추면 된다»는 가정은 Microsoft 로그인·Microsoft Graph·OneDrive 문제를 놓치기 쉽습니다. DOMAIN-SUFFIX로 microsoftonline.com·office.com·sharepoint.com 등 핵심 접미사를 묶고, Rule Provider로 재현 가능한 출구를 유지하는 것이 핵심입니다. 개발 도구용 에디터 에이전트는 GitHub Copilot 글과 역할을 나누면 주제 중복을 피할 수 있습니다.
동일한 GUI에서 프로파일을 공유하면 팀이 같은 Clash 분할로 Microsoft 365 경로를 재현하기 쉽습니다. Rule 편집기와 로그 뷰가 한눈에 들어오는 클라이언트를 고르면 운영 부담이 줄어듭니다.
→ Clash를 무료로 내려받아 Microsoft 365 Copilot·Office 클라우드 경로를 한 규칙 세트로 맞춰 보세요
