1. 증상을 네 축으로 나누기
겉으로는 모두 “Teams가 끊긴다”로 보이지만 관찰 포인트는 다릅니다. 첫째, 로그인·조직 전환이 느리거나 채팅 목록이 비어 있다가 채워지는 경우는 Microsoft 365 인증·디렉터리·조건부 액세스와 맞물린 HTTPS 경로를 의심합니다. 둘째, 회의에는 들어가는데 화면 공유만 실패하거나 상대 화면이 멈추는 경우는 미디어·TURN·UDP가 다른 정책 그룹으로 나가거나 회사 방화벽에 걸린 패턴과 맞닿습니다. 셋째, 첨부·파일 탭에서 미리보기만 무한 스피너인 경우는 SharePoint·OneDrive·다운로드 CDN이 프록시와 직결에 갈라진 경우가 많습니다. 넷째, 특정 노드로만 바꾸면 즉시 나아지는 경우는 규칙보다 노드 품질·UDP 제한 이슈일 수 있습니다. 이후 단계에서는 이 네 축을 번갈아 재현하며 로그에 어떤 호스트가 붙는지 메모하는 습관이 중요합니다.
프로필이 아직 불안정하면 구독 가져오기 튜토리얼에서 공항 규칙과 로컬 덮어쓰기 순서를 정리한 뒤 분류 단계로 넘어오는 편이 좋습니다.
2. Teams 트래픽 층: M365·Graph·Teams·CDN·미디어
한 줄 규칙으로 “microsoft.com 전부 같은 그룹”에 넣기 쉽지만, 실제로는 층이 나뉩니다. 인증과 토큰 브로커에 가까운 호스트, Teams 전용 신호·실시간 협업 API, 정적 자산·클라이언트 패키지에 가까운 Teams CDN, 그리고 UDP 기반 미디어가 서로 다른 지연 특성을 가집니다. “전량 프록시”로 두었는데도 증상이 남는 이유는 일부 프로세스가 시스템 프록시를 덜 따르거나, 공항 구독의 GEOIP 규칙 때문에 CDN만 의도치 않게 DIRECT로 빠지는 등 Clash 분류 결과가 사용자의 머릿속 모델과 다르기 때문입니다. 먼저 도덕적 판단이 아니라 연결 로그에 실제 출구가 무엇인지를 확인하세요.
3. 권장 점검 순서: DNS → 모드(TUN/시스템) → 규칙 → UDP
- Clash가 시스템 프록시만인지 TUN까지 켰는지 기록합니다. 다른 상시 VPN과 TUN이 겹치면 표본이 흔들립니다.
- 실시간 연결 패널을 연 상태에서 Teams에서 동일 채널 입장·카메라 켜기·화면 공유·첨부 미리보기를 각각 한 번씩 수행합니다.
- 로그에 나타난
teams.microsoft.com·teams.live.com계열,office.com·microsoft.com하위 호스트,sharepoint.com·onedrive접미사, CDN·엣지로 보이는 긴 호스트명을 정책 그룹과 매칭합니다. fake-ip사용 여부와 DNS 해석 정책을 확인하고, TLS 재시도가 같은 이름에서 반복되는지 봅니다.- 필요하면
DOMAIN-SUFFIX블록을 규칙 상단에 올리고, 광범위GEOIP·DIRECT와의 충돌을 정리합니다. - 규칙이 맞는데도 음성만 불안정하면 노드의 UDP 허용 여부·Windows 방화벽·백신 앱 제어를 추가로 확인합니다.
4. Windows에서 Teams가 프록시를 타는 경로
많은 조직 PC는 WinHTTP 시스템 프록시를 따르지만, Electron 기반 Teams나 백그라운드 모듈은 예외가 있습니다. “브라우저 Teams는 되는데 데스크톱만 이상하다”면 앱 프로세스가 프록시 테이블을 덜 읽는 케이스를 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. Microsoft Store·루프백 이슈가 겹치면 Windows UWP·Microsoft Store 글과 교차해 보는 것도 도움이 됩니다. 회사 단말에 분할 터널링이 금지되어 있다면 Clash 쪽 분류만으로는 한계가 있을 수 있어 IT 정책과의 정합도 함께 확인해야 합니다.
5. DNS와 fake-ip: 이름이 틀어지면 로그인·목록만 느리다
fake-ip는 체감 지연을 줄일 수 있지만, 규칙 엔진에 넘기는 이름과 실제 백엔드가 어긋나면 TLS 재시도가 반복됩니다. Microsoft 365는 지역 엣지와 테넌트별 리다이렉트가 많아 작은 어긋남도 “채팅은 되는데 파일만 안 열린다”로 보입니다. 상위 DNS가 신뢰 가능하고 Clash에서 도달 가능한지 먼저 확인한 뒤, 로그에 반복되는 접미사에 전용 해석 정책을 두는 방식을 검토하세요. 규칙을 고친 뒤에는 Windows DNS 캐시를 비우거나 Teams를 완전히 종료했다가 다시 열어 이전 세션을 걷어내는 것도 도움이 됩니다.
6. 도메인 수집: 로그로 Teams 전용 묶음 만들기
공유된 “완성된 Teams 도메인 목록”은 배포 시점·라이선스·지역에 따라 빠르게 달라질 수 있습니다. Clash Verge Rev 등 GUI의 연결 보기를 연 뒤 Teams에서 동일 시나리오를 두 번 반복하고, 새로 뜬 행만 시간순으로 적으면 어떤 동작이 어떤 호스트 묶음을 깨우는지 대응표가 생깁니다. Teams CDN으로 보이는 정적 자산 행, Graph·REST에 가까운 API 호스트, 첨부 미리보기 직후에만 보이는 스토리지 계열을 구분하세요. 실패한 연결(타임아웃·RST) 행을 우선 규칙에 올리면 체감 개선이 큽니다. Teams 프록시 조합에서 “노드만 바꾸기”보다 로그 문자열을 그대로 복사해 규칙에 반영하는 습관이 더 빠릅니다.
7. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름은 반드시 연결 로그로 검증해야 합니다.
| 구분 | 예시 패턴 | 메모 |
|---|---|---|
| 인증·M365 공통 | login.microsoftonline.com·microsoft.com 하위 | 로그인 루프·토큰 갱신과 함께 묶이는지 확인합니다. |
| Teams 앱·신호 | teams.microsoft.com·teams.live.com 계열 | 채널·회의 메타와 함께 움직이는지 봅니다. |
| 파일·미리보기 | sharepoint.com·onedrive 접미사 | 첨부 스피너만 길 때 이 층만 다른 노드로 가는지 확인합니다. |
| CDN·정적 자산 | 글로벌 CDN 접미사 | Teams CDN 다운로드·아이콘이 느릴 때 이 층을 점검합니다. |
| 미디어·TURN | UDP 행·짧은 릴레이 호스트 | 화면 공유 직후 로그가 바뀌는지 대조합니다. |
8. 규칙 예시 (정책 그룹 이름은 반드시 교체)
# Example only — replace M365_TEAMS with your policy group; verify in logs
rules:
- DOMAIN-SUFFIX,teams.microsoft.com,M365_TEAMS
- DOMAIN-SUFFIX,teams.live.com,M365_TEAMS
- DOMAIN-SUFFIX,skype.com,M365_TEAMS
- DOMAIN-SUFFIX,office.com,M365_TEAMS
- DOMAIN-SUFFIX,office365.com,M365_TEAMS
- DOMAIN-SUFFIX,microsoft.com,M365_TEAMS
- DOMAIN-SUFFIX,sharepoint.com,M365_TEAMS
- DOMAIN-SUFFIX,azureedge.net,M365_TEAMSDOMAIN-KEYWORD,microsoft처럼 과하게 넓히면 무관한 트래픽까지 잡힐 수 있으니, 로그에 근거해 접미사를 좁히세요. 먼저 같은 정책 그룹으로 묶여 안정화한 뒤, 필요하면 CDN과 미디어를 다른 그룹으로 나누어 실험합니다. 세션 중 출구가 바뀌면 조건부 액세스·지역 판정이 흔들릴 수 있으니 A/B 테스트는 회의 밖에서 진행하는 편이 안전합니다.
9. UDP·TURN·화면 공유: TUN과 방화벽을 함께 봅니다
음성과 화면 공유 품질 문제는 TCP 규칙만으로는 끝나지 않는 경우가 많습니다. Teams는 브라우저 한 탭이 아니라 클라이언트가 선택하는 미디어 경로가 UDP·TURN에 기대는 구간이 있습니다. TUN에서 UDP가 코어를 통과하는지, Windows Defender 방화벽이 Teams 실행 파일의 아웃바운드 UDP를 허용하는지 확인하세요. 공항 노드가 UDP를 제한하면 “채팅은 되는데 음성만 끊긴다” 패턴이 납니다. 이때는 규칙보다 노드 제약이 원인입니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
10. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,KR,DIRECT 같은 광범위 규칙이 있으면, 일부 글로벌 CDN 엣지만 의도치 않게 직결로 보내져 “인증은 프록시인데 패키지만 느리다”는 패턴이 납니다. 이럴 때는 Microsoft·Teams 관련 블록을 규칙 상단에 두거나, 공급자 규칙 뒤에서도 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요. 구독이 갱신되며 예전에 넣어 둔 로컬 규칙이 아래로 밀리는 경우도 흔합니다. “M365 전용 블록”을 파일 상단 근처에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.
11. GUI 워크플로: Clash Verge Rev
연결 패널에서 teams·microsoft·sharepoint 문자열을 필터링하면 잘못된 DIRECT를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. Windows 화상회의 일반론으로는 Zoom CDN·WebRTC 분류 글과 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.
12. Zoom 글과의 차이
Zoom 글은 zoom.us 우산과 WebRTC 후보가 중심입니다. Teams는 Microsoft 365 전반과 SharePoint·OneDrive까지 한 업무 세션에 걸쳐 열리므로, 규칙을 좁히지 않으면 “Office 전체가 한 노드로 간다”는 부작용이 생깁니다. 키워드 블록을 복사해 이름만 바꾸는 방식은 피하고, 본 글 6절의 절차대로 Teams 세션 로그를 다시 모으세요.
13. 그래도 안 될 때: 일반 트러블슈팅과의 교차
포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 혼합 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Teams 전용 단계로 돌아오세요.
14. 준수 안내
이 글은 불법 우회나 약관 위반을 돕는 방법이 아니라, 조직이 허용한 범위에서 네트워크 경로를 일관되게 맞추어 품질을 개선하는 데 초점을 둡니다. Microsoft 서비스 약관·데이터 보존·녹화 정책은 각 조직의 규정과 최신 약관을 따르세요.
15. 정리: 로그로 M365·Teams CDN·미디어 출구를 한 줄로 맞추기
Windows 화상회의 환경에서 Teams 음성·영상 끊김·화면 공유 실패·첨부 미리보기 지연은 단일 스위치가 아니라 프록시 모드·DNS·Clash 규칙 순서·UDP·노드 품질이 겹친 결과인 경우가 많습니다. 먼저 연결 로그로 Teams CDN과 인증·Graph·스토리지·미디어 후보가 서로 다른 출구를 보는지 증명하면, 불필요한 노드 순환과 잘못된 DIRECT를 빠르게 줄일 수 있습니다.
설정 파일을 매번 직접 고치기보다 Mihomo를 내장한 공식 클라이언트에서 로그·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash를 무료로 내려받고 Teams·Microsoft 365 세션을 같은 출구로 묶어 보세요