이 글의 목차
로그인, 파일과 회의 미디어가 각각 어느 경로를 사용하는지 먼저 구분
Zoom, Teams와 Slack은 모두 업무 앱처럼 보이지만 로그인, 채팅, 파일 다운로드, 회의 음성·영상과 기업 내부망은 같은 연결을 사용하지 않습니다. 모든 업무 도메인을 노드 그룹 하나에 넣지 말고 로그인을 먼저 안정화한 뒤 UDP 회의와 WebSocket을 별도로 검증하세요. 그러면 '로그인은 되지만 회의에 들어갈 수 없음'과 '회의는 정상이지만 첨부 파일을 열 수 없음'에 각각 맞는 점검 경로를 만들 수 있습니다.
공식 네트워크 요구 사항에서 주목할 차이
| 앱 | 핵심 트래픽 | 2026년에도 참고해야 할 공식 정보 |
|---|---|---|
| Zoom | 로그인과 웹은 TCP 443을 사용하고 회의 미디어는 UDP를 우선 사용 | 회의는 일반적으로 UDP 3478-3479와 8801-8810을 사용하며 IP 대역은 업데이트됨 |
| Teams | Microsoft 365 로그인, 채팅, 파일과 미디어는 서로 분리됨 | 미디어는 UDP 3478-3481 직접 연결을 권장하며 엔드포인트 목록은 매월 업데이트됨 |
| Slack | 메시지는 TCP 443의 지속 WebSocket에 의존 | SSL 검사는 WebSocket을 지원하거나 공식 목록의 wss 도메인을 제외해야 함 |
도메인 규칙은 로그인과 일반 HTTPS 처리에 적합하지만 미디어 요청에는 UDP, 기업 방화벽과 앱 프로세스도 고려해야 합니다. 공식 IP 목록을 개인 YAML에 영구 복사하지 마세요. Zoom과 Microsoft 모두 대역을 업데이트하므로 기업 환경에서는 관리자가 공식 목록을 구독해야 합니다.
업무 웹페이지와 실시간 회의를 두 정책 그룹으로 분리
채팅, 파일과 로그인에는 안정적인 외부 경로가 필요하고 회의는 UDP, 업로드와 지터에 더 민감합니다. 일반 요청은 Work-Web로 관리하고 Meeting에서는 UDP를 검증한 노드를 선택할 수 있습니다. 회사 네트워크에서 Zoom 또는 Teams 미디어 직접 연결을 허용한다면 Meeting 그룹에도 DIRECT를 남겨 두세요.
proxy-groups:
- name: Work-Web
type: select
proxies: [REPLACE_WITH_WORK_NODE, DIRECT]
- name: Meeting
type: select
proxies: [DIRECT, REPLACE_WITH_UDP_NODE]
rules:
- DOMAIN-SUFFIX,zoom.us,Meeting
- DOMAIN-SUFFIX,zoom.com,Meeting
- DOMAIN-SUFFIX,teams.microsoft.com,Work-Web
- DOMAIN-SUFFIX,teams.cloud.microsoft,Work-Web
- DOMAIN-SUFFIX,slack.com,Work-Web
- DOMAIN-SUFFIX,slack-edge.com,Work-Web
- MATCH,DIRECT두 REPLACE_WITH 이름은 모두 현재 구성에 실제로 있는 노드 이름으로 바꿔야 합니다. 기존 구성에 최종 정책이 있다면 마지막 MATCH,DIRECT를 기존 MATCH 규칙으로 되돌리세요. 회의 도중 외부 경로가 자동으로 바뀌지 않도록 정책을 수동으로 먼저 고정합니다.
Zoom 로그인은 되지만 Connecting에서 멈추면 미디어 UDP 확인
브라우저에서 zoom.us가 열린다는 것은 HTTPS 로그인 진입점에 접근할 수 있다는 것만 증명합니다. 회의 입장 후 계속 Connecting 상태이거나 화면은 보이지만 소리가 들리지 않거나 공유를 시작한 지 몇 분 뒤 끊긴다면 Clash 연결 페이지와 방화벽 로그에서 UDP를 확인해야 합니다. Zoom의 현재 공식 회의 미디어 포트에는 UDP 3478-3479와 8801-8810이 포함됩니다.
개인 네트워크에서는 같은 노드로 Zoom 오디오와 공유를 먼저 테스트할 수 있습니다. 기업 네트워크에서는 IP 허용 목록 전체를 직접 복사하지 말고 관리자가 Zoom 공식 페이지를 기준으로 관리하게 하세요. 노드가 UDP를 지원하지 않는다면 웹 프록시 전환으로 회의 미디어를 고칠 수 없습니다.
Teams 파일은 정상인데 회의가 끊긴다면 같은 경로 문제가 아닙니다
Teams 로그인은 Microsoft 인증 서비스를 거치고 채팅과 파일은 SharePoint 또는 OneDrive로도 연결될 수 있으며 실시간 미디어는 별도 엔드포인트를 사용합니다. Microsoft 2026년 네트워크 가이드에서도 미디어는 프록시를 우회하고 가능한 한 짧은 경로를 유지하며 UDP 3478-3481을 허용하라고 계속 권장합니다.
회사에서 프록시 또는 SSL 검사를 강제한다면 조직 정책을 따라야 합니다. 개인 Clash 규칙으로 회사 VPN이 배포한 사설 대역과 내부 DNS를 덮어쓰면 안 됩니다. 웹과 채팅이 이미 정상이라면 회의 지연을 줄이려고 Microsoft 365 트래픽 전체를 다른 지역으로 바꾸지 마세요.
Slack의 회색 막대에서 재연결이 반복되면 공식 WebSocket 테스트 실행
Slack에서 가장 구별하기 쉬운 문제는 웹페이지가 열리지 않는 것이 아니라 메시지 영역 상단에서 재연결 알림이 반복되는 현상입니다. 공식 연결 테스트로 WebSocket부터 확인한 뒤 관리자에게 SSL 검사를 조정하도록 요청할지 결정하세요.
Slack 전용 확인
my.slack.com/help/test 열기
현재 워크스페이스에서 연결 테스트를 실행하고 Primary와 Backup WebSocket을 확인합니다.
SSL 복호화 확인
프록시가 WebSocket을 지원하지 않는다면 관리자가 wss-primary.slack.com, wss-backup.slack.com과 wss-mobile.slack.com을 제외해야 합니다.
Net Logs 수집
데스크톱에서 Help → Troubleshooting → Restart and Collect Net Logs를 사용하면 실제로 끊긴 연결을 기록할 수 있습니다.
Huddle 구분
텍스트는 안정적이지만 Huddle이 실패한다면 Audio & video 설정에서 음성·영상 테스트를 실행하고 워크스페이스는 재설정하지 않습니다.
회사 VPN이 이미 내부망을 인수한다면 두 번째 TUN을 추가하지 않기
컴퓨터에서 회사 VPN에도 연결해야 한다면 회사가 배포한 사설 대역과 내부 DNS를 우선 보존하세요. Clash는 실제로 필요한 외부 웹페이지만 처리하는 편이 가상 네트워크 인터페이스 두 개가 기본 경로를 놓고 충돌하는 것보다 안정적입니다.
브라우저는 로그인했지만 데스크톱 클라이언트가 로그인 페이지로 돌아감
인증, 콜백과 앱 요청을 같은 Work-Web 외부 경로로 유지하고 시스템 시간과 기본 브라우저 복귀를 확인하세요. 로그인 도중 노드를 바꾸지 않습니다.
회사 웹페이지는 정상인데 Clash TUN을 켜면 바로 작동하지 않음
Clash 시스템 프록시로 돌아가고 사설 대역과 내부 DNS는 계속 회사 VPN에 맡깁니다.
텍스트 메시지는 정상인데 첨부 파일을 열 수 없음
SharePoint, Slack 파일 도메인 또는 CDN의 실제 요청을 확인하고 회의 UDP는 수정하지 않습니다.
모바일 핫스팟에서는 회의가 정상이고 회사 Wi-Fi에서는 실패
결과를 네트워크 관리자에게 전달하고 UDP와 SSL/WebSocket 검사를 중점적으로 확인합니다.
회의 도중 노드가 자동으로 바뀐 뒤 연결 끊김
Meeting 그룹을 고정 선택으로 바꾸고 회의에 다시 들어가 새 세션을 만듭니다.
트래픽 분기 완료 후 실제 검증
- Zoom 로그인을 완료하고 오디오, 비디오와 화면 공유를 연속으로 테스트할 수 있음
- Teams에서 메시지를 보내고 파일을 열며 테스트 회의에 한 번 들어갈 수 있음
- Slack 공식 테스트에서 Primary와 Backup WebSocket이 통과하고 파일과 Huddle을 각각 사용할 수 있음
- 회사 내부 웹페이지와 내부 DNS는 계속 회사 VPN이 처리하고 Clash를 종료하면 시스템 프록시가 남지 않음