Clash와 함께 쓸 때 흔한 Zoom·Teams 증상
대표적으로 연결은 됐는데 몇 초 뒤 끊긴다, 상대 영상만 멈춘다, 본인 마이크는 송신되는데 수신만 끊긴다, 화면 공유만 버벅인다 같은 패턴이 있습니다. 브라우저에서 여는 Teams와 데스크톱 앱, Zoom 클라이언트와 웹 클라이언트에 따라 프록시 인지 방식이 달라서, 재현 시에는 클라이언트 종류·OS·Clash 모드(Rule/Global)·TUN 여부를 메모해 두는 것이 좋습니다.
기업망에서는 상용 VPN·분할 터널·방화벽 UDP 제한이 동시에 걸리기도 합니다. 이때 «Clash만 꺼도 된다»가 아니라 «어느 계층에서 UDP·릴레이가 막혔는가»를 나눠 보는 것이 재발을 줄입니다. 스트리밍 지역 고정이 주제인 Netflix 분기와 달리, 화상 회의는 양방향 실시간과 NAT·릴레이에 더 민감합니다.
왜 «앱은 되는데 통화만» 깨지나: TCP·UDP·WebRTC
일정·로그인·탭 UI는 주로 HTTPS로 문제없이 올라옵니다. 실제 음성·영상은 WebRTC 계열로 미디어 경로를 잡고, 그 과정에서 UDP 비중이 큽니다. PC에서 시스템 프록시만 Clash에 연결하지 않고 켠 경우, 브라우저는 프록시를 따르더라도 UDP 세션은 OS 라우팅만 타고 직행하는 식으로 갈라질 수 있습니다. 그러면 «UI는 조용한데 통화만 불안정»이 됩니다.
또한 지터·소량 패킷 손실에 민감해 속도 테스트 숫자와 체감이 다르게 느껴집니다. 그래서 노드 하나만 바꿔도 음성은 나아지고 화면 공유는 그대로일 수 있습니다. 아래 단계는 이런 구조를 전제로 Clash 프로필에서 무엇을 순서대로 볼지 압축한 것입니다.
1단계: Rule/Global과 코어 로그로 출구 고정
먼저 Clash가 Rule인지 Global인지 확인합니다. Rule 모드라면 회의 시작 직후 코어 로그(또는 GUI 연결 패널)에서 zoom, teams, microsoft 등이 어느 정책 그룹으로 매칭되는지 봅니다. 의도와 다르면 그보다 위에 GEOIP·넓은 DOMAIN-SUFFIX·MATCH가 먼저 잡아 DIRECT로 새는지부터 점검합니다.
원격 근무 프로필을 최근에 안 바꿨다면 구독 링크 자동 갱신이 정상인지도 같이 봅니다. 규칙 세트가 비어 있으면 클라이언트만 바꿔도 같은 증상이 반복됩니다. 테스트 때는 불필요한 앱을 끄고, 회의 입장 후 1~2분만 로그를 모으면 재현이 쉬워집니다.
2단계: Zoom·Teams 관련 도메인을 규칙으로 묶기
Zoom은 zoom.us, zoom.com, zoomgov.com 등 조직 유형에 따라 호스트가 달라질 수 있고, 클라이언트·CDN은 cloud.zoom.us 같은 하위 이름으로 이어지기도 합니다. Teams는 teams.microsoft.com을 비롯해 microsoft.com, office.com, outlook.office.com 등 Microsoft 365 축과 함께 움직입니다. 레거시 Skype 계열 호스트가 로그에 남는 환경도 있습니다.
아래는 예시이며, 실제 운영에서는 코어 로그에 반복 등장하는 문자열을 우선 반영해야 합니다. 지나치게 넓은 접미사(예: 전역적인 CDN 접미사)는 다른 업무 트래픽까지 끌어와 부작용이 생길 수 있습니다.
rules: # Example: route meeting domains (adjust group names to your profile) - DOMAIN-SUFFIX,zoom.us,MEETING - DOMAIN-SUFFIX,zoom.com,MEETING - DOMAIN-SUFFIX,zoomgov.com,MEETING - DOMAIN-SUFFIX,teams.microsoft.com,MEETING - DOMAIN-SUFFIX,microsoft.com,MEETING - DOMAIN-SUFFIX,office.com,MEETING
MEETING은 proxy-groups에 선언된 이름과 정확히 같아야 합니다. 순서는 위에서 아래로 첫 매칭만 적용되므로, 회의 전용 블록을 넣었다면 GEOIP,CN,DIRECT 같은 광범위한 줄이 그보다 앞에서 미디어 API까지 직행으로 보내지 않는지 확인합니다. Discord 음성과 동일하게 UDP 관점이 중요한 주제는 Discord RTC 분기 글과 대조하면 감이 잡힙니다.
3단계: UDP와 TUN — 미디어가 프록시를 실제로 타는지
많은 경우 «전역 프록시 켰으니 다 된다»는 가정이 UDP 구간에서 깨집니다. 시스템 프록시만 사용 중이면 미디어 UDP가 Clash에 도달하지 않고 회선 그대로 나가, 신호만 프록시 노드 근처로 가는 비대칭이 생깁니다. 대응으로는 TUN 모드로 OS 라우팅 계층에서 트래픽을 끌어오는 방식을 검토합니다.
Windows·macOS에서 가상 NIC 권한·다른 VPN과의 충돌은 TUN·시스템 프록시 가이드에 정리된 순서와 같습니다. 사용 중인 빌드가 mihomo(Clash Meta) 계열인지, UDP relay 관련 옵션을 프로필에서 어떻게 쓰는지도 제조사 문서와 맞춰 보세요. 음성 품질은 지연 변동에 민감하므로 해당 정책 그룹 안에서만 노드를 바꿔 A/B 비교하는 편이 진단에 유리합니다.
4단계: TURN·STUN·미디어 엔드포인트를 로그로 보강
WebRTC는 STUN으로 공인 주소 후보를 모으고, 직접 경로가 안 되면 TURN 릴레이로 우회합니다. 이 때 보이는 호스트가 회사 문서의 «대표 도메인» 목록에 없을 수 있습니다. 이름이 로그에 찍히면 DOMAIN 또는 적절한 DOMAIN-SUFFIX로 올리고, IP만 보이는 릴레이는 규칙만으로 100% 표현하기 어려워 출구 노드·TUN 범위·GEOIP와 함께 해석해야 합니다.
일부 엔터프라이즈 환경에서는 고정 릴레이 주소를 방화벽 화이트리스트로 열어 두기도 합니다. Clash 쪽에서 막는지, 상위 장비에서 UDP를 제한하는지 구분하려면 동일 단말에서 Clash를 잠시 내리고 동일 회의에 들어가 비교하는 것도 방법입니다. 다만 보안 정책을 위반하지 않도록 IT 가이드 범위 안에서만 시도해야 합니다.
5단계: DNS enhanced-mode·fake-ip와 후보 수집
Clash DNS에서 fake-ip를 쓰면 애플리케이션이 보는 주소와 실제 연결 경로가 어플리케이션별로 달라질 수 있습니다. WebRTC는 후보 수집·체크 순서에 민감해, 일반 웹은 정상인데 통화만 간헐적으로 끊기는 형태로 드러나기도 합니다. 의심될 때는 회의 관련 도메인을 fake-ip-filter에 넣거나 redir-host와 비교 테스트합니다.
OS·브라우저·라우터가 DoH·다른 resolver를 동시에 쓰면 «어느 DNS가 승자인지」가 흐려져 로그 해석이 어려워집니다. 내부망 이름과의 관계는 fake-ip vs redir-host 가이드와 연결해 읽을 수 있습니다. 종종 문제는 노드가 아니라 resolver 지역이 회의 장비 리전과 어긋나는 경우입니다.
6단계: 노드 품질·이중 VPN·방화벽
규칙과 TUN을 맞춰도 끊긴다면 아웃바운드 자체를 의심합니다. 공유 IP의 혼잡, UDP 처리에 약한 중계, 지연 스파이크는 화상에서 바로 드러납니다. 회의 전용 정책 그룹을 두었다면 그 안에서만 노드를 바꿔 비교하세요.
PC 위에 전체 터널 VPN이 또 올라가 있으면 라우팅이 겹칩니다. 사내 준수 VPN이 필수라면 분할 터널 가능 여부·예외 목록을 먼저 확인하고, Clash TUN과의 인터페이스 우선순위를 정리해야 합니다. 가정용 공유기의 ALG·UDP 타임아웃 설정도 간헐 원인이 될 수 있어, 같은 노드로 테더링만 바꿔도 증상이 사라지는지 보면 힌트가 됩니다.
증상별 빠른 점검 표
| 증상 | 우선 확인 |
|---|---|
| 로그인·채팅은 되는데 음성·영상만 실패 | UDP 경로, TUN, 시스템 프록시 한계 |
| 규칙을 넣었는데 로그에 다른 아웃바운드 | 규칙 순서, GEOIP/MATCH, Rule Provider 충돌 |
| 브라우저 Teams는 괜찮고 앱만 이상 | 프로세스별 프록시 인지, TUN 적용 범위 |
| 외부 강연만 끊김 | TURN 릴레이 도메인/IP, UDP 포트 |
| 특정 노드에서만 품질 붕괴 | 해당 노드의 UDP·혼잡·지연 변동 |
자주 묻는 질문 (본문 요약)
회의 앱은 켜지는데 음성·영상만 없을 때 가장 흔한 원인은?
HTTPS와 UDP/WebRTC 경로가 달라진 경우입니다. 로그에서 UDP가 어느 아웃바운드로 나가는지와 TUN 여부를 함께 보세요.
대표 도메인 몇 줄만으로 충분한가요?
출발점일 뿐입니다. 로그에 반복되는 호스트를 기준으로 블록을 넓히되, 과도한 접미사는 피하세요.
TURN·STUN은 어떻게 분기하나요?
이름이 보이면 DOMAIN 규칙으로, IP 위주면 노드·TUN·GEOIP와 함께 봐야 합니다.
마무리
Zoom·Microsoft Teams는 기업 배포가 많아 원인이 네트워크·단말·정책으로 겹칠 수 있지만, Clash를 켠 상태에서 «한 레이어만 이상하다»면 TCP로 보이는 부분과 UDP·릴레이를 분리해서 보는 것이 첫 단추입니다. 규칙으로 로그에 찍힌 도메인을 묶고, TUN으로 투명 프록시 범위를 맞추고, DNS 모드를 의심한 뒤 노드·상위 VPN을 보는 순서가 현장에서 통합니다.
같은 RTC 문제를 음성 채팅 앱 관점에서 보고 싶다면 Discord RTC 점검 글과 흐름을 비교해 보세요. ClashNote 다운로드 페이지에서는 여러 Clash 계열 클라이언트를 한곳에서 비교할 수 있고, 무료로 배포되는 프로그램과 구독 링크를 프로필에 넣는 흐름까지 같은 맥락으로 정리되어 있습니다. 다른 주제는 기술 칼럼 목록에서 이어서 보시면 됩니다.