📖 튜토리얼 2026년 4월 10일 ⏱ 약 15분 분량

재택·하이브리드 Zoom·Teams 연결 실패: Clash 분류·DNS 점검 순서(2026)

2026년에도 하이브리드 근무와 국경을 넘는 회의는 일상입니다. 한 PC에서 국내 협업 도구를 쓰면서 Zoom이나 Microsoft Teams 해외 회의에 들어가야 할 때, Clash를 글로벌 한 방으로만 켜 두거나 규칙이 너무 거칠면 화상 회의만 안 붙거나, 화면이 끊기고, 음성이 끊기는 현상이 나오기 쉽습니다. 반면 일반 웹만 볼 때는 괜찮아 보이기도 합니다. 이 글은 그런 실제 업무 장면에서 출발해 Clash 분류 규칙으로 화상 회의 관련 호스트를 알맞은 노드로 보내고, DNS와 시스템 프록시·TUN 선택을 맞춰 전체 기기 트래픽이 잘못된 출구로 몰리지 않게 하는 순서를 한국어로 정리합니다. 개발자 도구나 생성형 AI 위주 글과 달리, 여기서는 재택근무·화상회의 링크에 초점을 둡니다.

먼저 가르기: 「앱이 고장」인지, 「프록시가 길을 틀어」 놓은 건지

Zoom과 Teams는 증상이 비슷합니다. 회의에 못 들어가고, 「연결 중」에 멈추고, 화면 공유가 끊기고, 음성이 끊깁니다. 하지만 클라이언트를 재설치하거나 노드를 무작정 바꾸기 전에, 한 가지를 먼저 보세요: Clash를 끄거나 순수 직접 연결로 바꿨을 때만 회의가 살아나는지. 그렇다면 운영사가 서비스를 완전히 막은 것이라기보다 분류 규칙·DNS 해석 경로·가져오기 방식(시스템 프록시／TUN)이 화상 트래픽과 맞지 않았을 가능성이 큽니다.

또 다른 축은 기업 정책·계정 제한입니다. 특정 클라이언트 버전만 허용, 사내망에서만 입장, 게스트 링크 추가 검증 등은 앱 안에 메시지로 드러나는 경우가 많고, 프록시와 무관할 수 있습니다. 이 글은 네트워크 쪽에서 내가 조절할 수 있는 부분, 즉 Clash로 세밀하게 나눌 때 Zoom·Teams 호스트를 어떤 정책 그룹으로 보낼지, 그리고 DNS 동작이 규칙과 맞는지 다룹니다. 「규칙형 프록시」와 「전역 VPN」의 큰 그림은 Clash와 VPN의 차이 글을 먼저 보고 아래 단계로 내려오면 이해가 빨라집니다.

왜 「전역 프록시」가 화상 회의를 자주 망치나

글로벌 모드는 직접 가도 될 트래픽까지 한 노드에 몰아 넣기 쉽습니다. 그러면 두 가지가 생깁니다. 첫째, 지연·지터가 커집니다. 실시간 음성·영상은 RTT와 손실에 민감해서, 멀리 중계되는 한 방 터널에는 잘 안 맞습니다. 둘째, 나가는 IP와 지역 정책이 꼬입니다. 일부 회의 서비스는 지역별 접속 지점을 나누는데, 노드 지역이 조직 설정과 어긋나면 재연결이 반복되거나 기능이 제한될 수 있습니다.

그래서 도메인 단위 분류가 낫습니다. 국내 자주 쓰는 사이트, 사설망, 업무 내부망은 직접 연결이나 별도 정책으로 두고, 화상에 필요한 호스트만 지연 안정적인 프록시 그룹으로 보냅니다. 그룹 이름·계층은 프록시 그룹(proxy-groups) 가이드를 참고하고, rules에 쓴 이름이 YAML의 proxy-groups와 정확히 같아야 규칙이 먹습니다.

시스템 프록시, TUN, 「회의 앱이 프록시를 탈까」

데스크톱에서는 Zoom·Teams가 보통 독립 프로세스입니다. 시스템 프록시를 따를지는 앱·OS 설정에 따라 달라서, 「시스템 프록시만 켰다고 전부 Clash로 간다」고 가정하면 안 됩니다. 브라우저로는 회의가 되는데 클라이언트만 안 된다거나 반대인 경우, 일부 연결이 Clash에 안 잡히는 것일 수 있습니다. 이때 비교할 것은 두 가지입니다.

시스템 프록시: 프록시를 존중하는 앱 위주로 부담이 적고, 브라우저 중심이면 편할 때가 많습니다. 다만 회의 클라이언트는 예외가 있어 연결 로그로 확인해야 합니다.
TUN 모드: 더 아래에서 트래픽을 잡아 규칙 적용 범위가 넓어지는 편입니다. 대신 회사 VPN·다른 터널과 충돌할 수 있고, DNS·fake-ip 설정에 더 민감합니다. 원리와 함정은 TUN 모드 심화 글을 함께 보세요.

실무 팁: 로그로 회의 트래픽이 코어에 들어오는지 먼저 확인한 뒤, 시스템 프록시를 강화할지 TUN을 켤지 정합니다. 서로 라우팅을 빼앗는 소프트웨어를 겹치지 말고, 예외 규칙 없이 여러 터널을 동시에 켜면 원인 찾기가 매우 어려워집니다.

Zoom·Teams 관련 도메인: 고정 목록보다 연결 로그가 기준

화상은 버전·CDN·지역 스케줄에 따라 호스트가 바뀝니다. 「영원한 완전 목록」은 금방 낡습니다. 아래는 점검할 때 자주 보이는 유형이니, 반드시 본인 PC Clash 연결 로그에 실제로 뜬 목적지 도메인을 기준으로 규칙을 늘려 가세요.

Zoom 쪽: zoom.us, zoom.com 및 여러 업무 서브도메인. 회의가 붙은 뒤에는 미디어 전송용 호스트가 추가로 나올 수 있습니다. 웹만 열리고 회의만 안 붙으면, 미디어 경로 도메인이 규칙에서 빠졌을 가능성이 큽니다.
Microsoft Teams·Microsoft 365: teams.microsoft.com, teams.live.com 및 넓게는 microsoft.com, office.com, office365.com, sharepoint.com, skype.com 등(테넌트·기능에 따라 다름). Teams는 로그인·OneDrive·Outlook 등과 인프라를 일부 공유해, 로그에 마이크로소프트 계열 호스트가 여럿 찍히는 것이 흔합니다.

원칙: 이상한 호스트를 볼 때마다 규칙을 보강하고, 처음부터 거대한 도메인 세트를 통째로 넣지 않기입니다. 관계없는 MS 트래픽까지 한 노드로 보내면 오히려 지연만 커질 수 있습니다. 문법과 순서는 사용자 정의 규칙 튜토리얼과 맞춰 보시면 됩니다.

DNS, fake-ip, 「해석 경로가 갈라질 때」

간헐적 증상의 흔한 원인은 DNS입니다. OS DNS, 브라우저 DoH, Clash 내장 DNS가 동시에 개입하면 해석 결과와 규칙이 매칭하는 도메인 정보가 어긋날 수 있습니다. fake-ip 모드에서는 커널이 후속 처리를 위해 로컬 대역 주소를 돌려줄 수 있어, no-resolve·규칙 순서·DNS 섹션이 한 세트로 맞아야 합니다.

회의 문제를 볼 때는 한 번에 한 종류만 바꾸는 것이 좋습니다. DNS 상류와 Clash DNS 블록을 먼저 정리할지, 규칙 적중부터 손볼지 정하고, 노드·규칙·DoH를 동시에 뒤집지 마세요. 특정 회선(유선만, 테더링만)에서만 깨지면 UDP·포트 정책일 수도 있어, 규칙만으로는 안 고쳐질 때가 있습니다. 그래도 로그에는 「해석 실패」인지 「링크 품질」인지 구분하는 단서가 남습니다.

분류 규칙 예시: 앞쪽 직접 연결 + 회의 도메인만 전용 그룹

아래는 구조 예시입니다. PROXY_MEETING은 실제 프로필의 프록시 그룹 이름으로 바꾸고, 도메인은 로그를 보며 추가하세요. 그대로 「만능 설정」으로 쓰면 안 됩니다.

# Example only — replace PROXY_MEETING with your proxy-groups name
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,zoom.us,PROXY_MEETING
  - DOMAIN-SUFFIX,zoom.com,PROXY_MEETING
  - DOMAIN-SUFFIX,teams.microsoft.com,PROXY_MEETING
  - DOMAIN-SUFFIX,teams.live.com,PROXY_MEETING
  - DOMAIN-SUFFIX,microsoft.com,PROXY_MEETING
  - DOMAIN-SUFFIX,office.com,PROXY_MEETING
  - DOMAIN-SUFFIX,office365.com,PROXY_MEETING
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

넓은 접미사(예: microsoft.com 전체)는 편하지만 회의와 무관한 트래픽까지 같은 출구로 보낼 수 있습니다. 프록시 면적을 최소로 쓰려면 로그에 반복되는 구체 서브도메인으로 좁히고, 국내·내부망은 규칙 앞쪽에 안정적으로 두세요. 마지막 MATCH는 예시이며, 실제 기본 정책에 맞춥니다. 한국 사용자라면 예시의 GEOIP,CN 대신 GEOIP,KR,DIRECT처럼 로컬에 맞는 GEOIP 규칙을 쓰는 편이 자연스럽습니다.

권장 점검 순서: 장애 티켓처럼 로그를 남기기

변수 줄이기: 브라우저 프록시 확장·다른 VPN·가속기를 잠시 끄고 Clash만 남깁니다.
가져오기 방식 확인: 시스템 프록시와 TUN을 번갈아 보며 회의 클라이언트 연결이 Clash 로그에 찍히는지 봅니다.
재현 후 호스트 수집: 입장부터 끊김까지 목적 도메인과 적중 규칙을 기록합니다.
규칙 또는 DNS 조정: 잘못된 정책이면 규칙 순서·그룹명을 고치고, 해석이 의심되면 Clash DNS와 OS·브라우저 DoH를 맞춘 뒤 다시 측정합니다.
동일 노드로 반복: 같은 노드로 여러 번 재현해 「노드 품질」과 「규칙·DNS」를 가릅니다. 그다음 노드를 바꿔 비교합니다.

이 방법은 개발자용 분류 글과 같은 로그 기반 접근이며, 관찰 대상만 원격 협업·화상회의 호스트로 바꾼 것입니다.

사내망·회사 VPN과 같이 쓸 때

회사 VPN이나 제로 트러스트 에이전트가 있으면 라우팅 테이블이 기업 정책으로 덮일 수 있고, Clash TUN과 충돌하는 경우도 많습니다. 보안 규정을 우선하고, 허용된다면 내부 대역·포털은 직접 연결로 남기며 회의에 필요한 공인 도메인만 프록시 규칙에 넣으세요. IT 부서에 PAC·분할 터널 안내가 있다면 그것과 내가 쓴 사용자 규칙이 빠지거나 겹치지 않는지 대조해 보는 것이 좋습니다.

자주 묻는 질문

zoom.us 규칙을 넣었는데도 회의에 못 들어가요.

회의가 붙은 뒤에는 다른 서브도메인이나 프로토콜 경로가 추가될 수 있습니다. 연결 로그에 나온 실제 호스트를 기준으로 규칙을 보완하고, 더 앞선 규칙이 직접 연결이나 다른 그룹으로 잡고 있지 않은지 확인하세요.

Teams 로그인은 되는데 회의만 들어가면 끊깁니다. 노드 문제인가요?

미디어 경로 도메인이 빠졌거나 UDP가 막혔거나, 노드가 실시간 트래픽에 불리할 수 있습니다. 고정 노드와 로그로 호스트·규칙 적중을 먼저 확인하고, 글로벌 직접 연결은 되는데 규칙 모드만 깨지면 규칙과 DNS를 우선 의심하세요.

TUN 켜니까 국내 사이트가 느려졌어요.

GEOIP로 국내 직접 연결과 사설 대역이 앞쪽에서 먹는지, MATCH가 국내 트래픽을 실수로 프록시로 보내지 않는지 확인하세요. 사용자 정의 규칙으로 기본 정책을 조이는 것도 도움이 됩니다.

정리

재택·하이브리드 환경에서 Zoom과 Microsoft Teams가 안정적인지는, 화상 트래픽을 「전역 프록시 한 덩어리」에서 떼어 내고, 검증 가능한 분류 규칙과 일관된 DNS 동작으로 묶었는지에 달린 경우가 많습니다. 호스트 목록은 클라이언트와 로그가 바뀔 때마다 갱신할 수 있는 자산으로 두고, 「트래픽이 코어에 들어왔는가, 어떤 규칙에 맞았는가」를 로그로 답하는 것이 노드를 무작정 바꾸는 것보다 문제 위치를 빨리 찾게 합니다.

클라이언트 설치가 처음이거나 유지보수되는 앱을 쓰려면 릴리스 페이지만 쫓기보다 사이트 안내를 따르는 편이 버전 혼선이 적습니다. 다운로드 페이지에서 설치 파일을 받고, 입문 튜토리얼로 구독과 기본 분류를 맞춘 뒤, 이 글 순서로 회의용 도메인과 DNS를 덧붙이면 됩니다. 단순 글로벌 프록시보다 Clash는 오케스트레이션 가능한 분류와 관측 가능성에서 장기적으로 하이브리드 근무에 잘 맞습니다. 규칙을 분명히 쓰면 국경을 넘는 회의와 일상 협업이 한 기기에서 오래 공존할 수 있습니다. → Clash를 무료로 내려받고, Zoom·Teams 위주 분류와 DNS를 맞춰 보세요.