1. 증상을 네 가지 축으로 나누기

모두 “Zoom이 안 된다”로 느껴지지만 관찰 포인트는 다릅니다. 첫째, 회의 링크를 눌렀을 때 입장 화면에서 로딩만 길어지거나 참가 버튼 이후에도 검은 화면이 길게 유지되는 경우는 인증·회의 메타데이터 HTTPS 경로와의 TLS 지연·차단을 의심합니다. 둘째, 입장은 되는데 화면 공유를 시작하면 상대에게 검은 화면만 가거나 자신 쪽에서 바로 실패 메시지가 뜨는 경우는 미디어·캡처·인코딩 경로와 WebRTC 관련 UDP가 다른 정책으로 나가거나 방화벽에 막힌 패턴과 맞물립니다. 셋째, 음성만 끊기고 채팅은 되는 경우는 UDP·노드의 UDP 제한·지터가 원인인 경우가 많습니다. 넷째, 특정 노드로만 바꾸면 즉시 나아지는 경우는 규칙보다 노드 품질 이슈일 수 있습니다. 이후 단계에서는 이 네 축을 번갈아 재현하며 로그에 어떤 호스트가 붙는지 메모하는 습관이 중요합니다.

프로필이 아직 불안정하면 구독 가져오기 튜토리얼에서 프로필을 먼저 정리한 뒤 분류 단계로 넘어오는 편이 좋습니다.

2. 「전량 프록시」가 꼭 잘못은 아닙니다 — 다만 Zoom은 층이 여럿입니다

정책상 모든 트래픽을 한 노드로 보내야 한다면 원칙적으로는 단순합니다. 그러나 실무에서는 “전부 PROXY”로 두었는데도 증상이 남는 이유가 있습니다. Zoom은 브라우저 한 탭이 아니라 네이티브 클라이언트가 시스템 프록시를 일부만 따르거나, 백그라운드 모듈이 DIRECT로 새는 경우가 있습니다. 이때 사용자는 “전량 프록시인데 왜 직결이 섞이냐”로 느끼고, 관리자는 “프록시를 빼야 하나”로 결론 내리기 쉽습니다. 먼저 할 일은 도덕적 판단이 아니라 연결 로그에 실제로 어떤 출구가 찍히는지를 확인하는 것입니다. 일부만 직결이면 Zoom CDN 엣지와 API 호스트의 IP 일관성이 깨져 세션이 흔들립니다. 반대로 미디어까지 먼 회선만 고르면 WebRTC 지연이 커져 음성이 끊깁니다. 그래서 “한 세션을 구성하는 이름들을 한 줄로 맞춘 뒤 필요하면 세분화한다”는 순서가 안전합니다.

3. 권장 점검 순서: DNS → 모드(TUN/시스템) → 규칙 → UDP

  1. Clash가 실행 중인지, 시스템 프록시만 켰는지 TUN까지 켰는지 기록합니다. 다른 상시 VPN과 TUN이 겹치면 표본이 흔들립니다.
  2. 실시간 연결 패널을 연 상태에서 Zoom에서 같은 회의 입장을 두 번 반복하고, 화면 공유 시작·중지를 한 번씩 수행합니다.
  3. 로그에 나타난 zoom.us·zoom.com·zoomgov.com 접미사, cloudfront·Akamai 계열 CDN 문자열, 짧게 반복되는 미디어 호스트를 각각 정책 그룹과 매칭합니다.
  4. fake-ip 사용 여부와 DNS 해석 정책을 확인하고, TLS 핸드셰이크가 같은 호스트에서 반복되는지 봅니다.
  5. 필요하면 DOMAIN-SUFFIX 블록을 규칙 상단에 올리고, 공항 구독의 광범위 GEOIP·DIRECT와의 충돌을 정리합니다.
  6. 규칙이 맞는데도 음성만 불안정하면 노드의 UDP 허용 여부·Windows 방화벽·백신의 앱 제어를 추가로 확인합니다.

4. Windows에서 Zoom이 프록시를 타는 경로

많은 조직 PC는 WinHTTP 시스템 프록시를 따르지만, Zoom 설치 방식·버전에 따라 예외가 있습니다. “브라우저로 열린 미리보기 회의는 되는데 데스크톱 앱만 이상하다”면 앱 프로세스가 프록시 테이블을 덜 읽는 케이스를 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. 다만 TUN은 가상 어댑터를 추가하므로 다른 VPN과 충돌할 수 있습니다. 한 번에 하나의 터널만 남기고 다시 측정하세요. 또한 회사 단말에 분할 터널링이 금지되어 있다면, Clash 쪽 분류만으로는 한계가 있을 수 있어 IT 정책과의 정합도 함께 확인해야 합니다.

5. DNS와 fake-ip: 이름이 틀어지면 “입장만 느리다”로 보입니다

fake-ip는 지연을 줄이는 데 도움이 될 수 있지만, 규칙 엔진에 넘기는 이름과 실제 연결 목적지가 어긋나면 TLS 재시도가 반복됩니다. Zoom은 서브도메인이 많고 지역 엣지가 자주 바뀌므로 작은 어긋남도 체감상 회의 지연으로 보입니다. 상위 DNS가 신뢰 가능하고 Clash에서 도달 가능한지 먼저 확인한 뒤, 로그에 반복되는 접미사에 전용 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다르므로 최신 문서와 GUI 설명을 함께 보는 것이 안전합니다. 규칙을 고친 뒤에는 Windows DNS 캐시를 비우거나 Zoom을 완전히 종료했다가 다시 열어 이전 세션을 걷어내는 것도 도움이 됩니다.

6. 도메인 수집: Zoom 전용으로 로그를 모으기

인터넷에 공유된 “완성된 Zoom 도메인 목록”은 배포 시점과 계정 유형(상용·정부·교육)에 따라 빠르게 달라질 수 있습니다. 그래서 이 글은 암기보다 절차를 권장합니다. Clash Verge Rev 등 GUI의 연결 보기를 연 뒤 Zoom에서 회의 입장, 카메라 켜기, 화면 공유, 녹화 시작을 각각 시도합니다. 각 동작 직후에 새로 뜬 행만 시간순으로 적으면 어떤 동작이 어떤 호스트 묶음을 깨우는지 대응표가 생깁니다. zoom.us 아래의 API·웹소켓 성격 호스트, 정적 자산·업데이트 패키지에 가까운 CDN 이름, 짧은 TTL로 바뀌는 미디어 후보를 구분하세요. 실패한 연결(타임아웃·RST) 행을 우선 규칙에 올리면 체감 개선이 큽니다.

Zoom Clash 조합에서 “노드만 바꾸기”보다 로그 문자열을 그대로 복사해 규칙에 반영하는 습관이 더 빠릅니다.

7. 규칙에 올리기 전 체크리스트

아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름은 반드시 연결 로그로 검증해야 합니다.

구분예시 패턴메모
웹·API·로그인zoom.us·zoom.com 하위 API회의 메타·참가자 목록과 함께 묶이는지 확인합니다.
CDN·정적 자산CloudFront·Akamai 등 접미사Zoom CDN 다운로드가 느릴 때 이 층만 다른 노드로 가는지 봅니다.
미디어·WebRTC짧은 호스트명·UDP 행음성·영상·화면 공유 직후 로그가 바뀌는지 확인합니다.
업데이트·크래시 리포트업데이터·텔레메트리 계열회의 중이 아닐 때만 보이는지 대조합니다.

8. 규칙 예시 (정책 그룹 이름은 반드시 교체)

# Example only — replace ZOOM with your policy group; verify in logs
rules:
  - DOMAIN-SUFFIX,zoom.us,ZOOM
  - DOMAIN-SUFFIX,zoom.com,ZOOM
  - DOMAIN-SUFFIX,zoomgov.com,ZOOM
  - DOMAIN-SUFFIX,zoomus.cn,ZOOM
  - DOMAIN-KEYWORD,zoomcdn,ZOOM

DOMAIN-KEYWORD,zoom처럼 과하게 넓히면 다른 서비스까지 잡힐 수 있으니, 로그에 근거해 접미사를 좁히세요. 먼저 같은 정책 그룹으로 묶여 안정화한 뒤, 필요하면 CDN과 미디어를 다른 그룹으로 나누어 실험합니다. 세션 중 출구가 바뀌면 인증·지역 판정이 흔들릴 수 있으니 A/B 테스트는 회의 밖에서 진행하는 편이 안전합니다.

9. WebRTC·UDP·화면 공유: TUN과 방화벽을 함께 봅니다

음성과 화면 공유 품질 문제는 TCP 규칙만으로는 끝나지 않는 경우가 많습니다. Zoom은 브라우저 기반 RTC와 달리 클라이언트가 선택하는 미디어 경로가 UDP에 기대는 구간이 있습니다. Mihomo를 쓰는 환경이라면 TUN에서 UDP가 코어를 통과하는지, Windows Defender 방화벽이 Zoom 실행 파일의 아웃바운드 UDP를 허용하는지 확인하세요. 공항 노드가 UDP를 제한하면 “채팅은 되는데 음성만 끊긴다” 패턴이 납니다. 이때는 규칙보다 노드 제약이 원인입니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.

10. GEOIP·대륙 직결 규칙과의 충돌

공항 구독에 GEOIP,KR,DIRECT 같은 광범위 규칙이 있으면, 일부 글로벌 CDN 엣지만 의도치 않게 직결로 보내져 “API는 프록시인데 패키지만 느리다”는 패턴이 납니다. 이럴 때는 Zoom 관련 블록을 규칙 상단에 두거나, 공급자 규칙 뒤에서도 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요. 구독이 갱신되며 예전에 넣어 둔 로컬 규칙이 아래로 밀리는 경우도 흔합니다. “Zoom 전용 블록”을 파일 상단 근처에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.

11. GUI 워크플로: Clash Verge Rev

연결 패널에서 zoom 문자열을 필터링하면 잘못된 DIRECT를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. Windows에서 대용량 CDN을 로그로 모은 경험이 있다면 Steam 상점·CDN 분류 글과 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.

12. Discord RTC 글과의 차이

Discord·음성 RTC 분류 글은 게이트웨이·CDN 접미사가 Discord 생태에 특화되어 있습니다. Zoom은 회의 링크·Webinar·Phone Connector 등 제품군이 넓어 호스트 집합이 1:1로 대응하지 않습니다. 키워드 블록을 복사해 이름만 바꾸는 방식은 피하고, 본 글 6절의 절차대로 Zoom 세션 로그를 다시 모으세요.

13. 그래도 안 될 때: 일반 트러블슈팅과의 교차

포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 혼합 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Zoom 전용 단계로 돌아오세요.

14. 준수 안내

이 글은 불법 우회나 약관 위반을 돕는 방법이 아니라, 조직이 허용한 범위에서 네트워크 경로를 일관되게 맞추어 품질을 개선하는 데 초점을 둡니다. Zoom 이용약관·녹화·데이터 주체 권리는 각 조직의 정책과 최신 약관을 따르세요.

15. 정리: 로그로 “전량 프록시 오해”와 “CDN·WebRTC 미분류”를 가르기

Zoom Windows 환경에서 회의 지연·화면 공유 실패·음성 끊김은 단일 스위치가 아니라 프록시 모드·DNS·Clash 규칙 순서·UDP·노드 품질이 겹친 결과인 경우가 많습니다. 먼저 연결 로그로 Zoom CDN과 API·WebRTC 후보가 서로 다른 출구를 보는지 증명하면, 불필요한 노드 순환과 잘못된 DIRECT를 빠르게 줄일 수 있습니다.

설정 파일을 매번 직접 고치기보다 Mihomo를 내장한 공식 클라이언트에서 로그·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash를 무료로 내려받고 Zoom 세션을 같은 출구로 묶어 보세요