Zoom·Slack 회의가 끊길 때 먼저 확인할 것
재택근무 중 Zoom은 연결되지만 화면 공유가 멈추거나, Slack 허들이 간헐적으로 끊기거나, Google Meet에서 음성과 영상의 지연이 커지는 경우가 있습니다. 이런 증상은 모두 프록시 노드를 바꾸면 해결되는 문제가 아닙니다. 회사 VPN과 Clash가 동시에 켜져 있는지, 회의 앱이 운영체제 프록시를 따르는지, Wi-Fi 신호나 업로드 대역폭이 충분한지도 함께 확인해야 합니다.
이 글은 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로 업무 회의 트래픽만 선택적으로 프록시로 보내고, 국내 웹사이트와 일반적인 국내 서비스는 직접 연결하는 분할 라우팅 방법을 설명합니다. 앱 버전에 따라 메뉴 이름이나 로그 화면은 달라질 수 있으므로, 여기서는 특정 화면을 전제하기보다 규칙의 원리와 확인 순서를 중심으로 안내합니다. 회사에서 지정한 VPN이나 네트워크 정책이 있다면 개인 프록시를 추가하기 전에 사내 IT 지침을 우선 확인하세요.
글로벌 모드 대신 규칙 모드부터 시작하기
글로벌 모드에서는 웹 브라우징과 회의 앱을 포함한 대부분의 트래픽이 선택된 프록시 경로를 이용합니다. 설정은 간단하지만 국내 사이트 접속까지 멀리 우회할 수 있고, 회의 미디어 트래픽이 혼잡한 노드를 지나면서 오히려 지연되거나 음성이 끊길 수도 있습니다. 반면 규칙 모드에서는 도메인이나 IP 등의 조건에 따라 업무 앱, 국내 사이트, 나머지 트래픽의 경로를 나눌 수 있습니다.
회의 연결이 이미 안정적이고 업무상 프록시가 필요하지 않다면, 회의 앱을 무조건 프록시로 보내는 것이 정답은 아닙니다. 가능한 경우 먼저 직접 연결을 기준으로 시험하고, 해당 서비스에 직접 접속할 때 오류가 나거나 회사 정책상 지정된 경로가 필요한 경우에만 업무용 프록시 그룹을 적용하세요. 회의는 웹페이지를 여는 것과 달리 음성·영상 스트림이 계속 오가므로, 노드의 단순 핑 숫자만으로 실제 품질을 판단하기 어렵습니다.
설정 전에는 현재 프로필을 복사하거나 별도 프로필로 저장해 두세요. 기존 규칙을 덮어쓰지 않고 되돌릴 수 있어야 하며, 회사 VPN을 사용하는 환경에서는 VPN 연결 전후의 동작을 따로 비교하는 것이 좋습니다. 두 도구가 같은 트래픽을 가로채면 경로가 이중화되어 로그인이나 미디어 연결이 실패할 수 있습니다.
회의 앱의 도메인을 로그에서 확인하기
규칙을 만들기 전에 실제로 어떤 호스트가 연결되는지 살펴봅니다. Zoom, Slack, Google Meet은 로그인, 채팅, 파일, 회의 제어, 음성·영상 전달에 여러 도메인과 전송 방식을 사용할 수 있습니다. 앱 업데이트, 조직 계정, 리전 및 회의 기능에 따라 연결 대상도 달라질 수 있으므로, 인터넷에서 찾은 도메인 목록을 통째로 복사하기보다 본인 환경의 연결 기록을 기준으로 좁히는 편이 안전합니다.
- Clash 클라이언트에서 규칙 모드를 켜고, 연결 로그 또는 연결 기록 화면을 엽니다.
- Zoom 회의, Slack 허들, Google Meet을 각각 한 번씩 실행하고, 시작 시각과 문제가 나타난 시각을 기록합니다.
- 해당 시각에 새로 나타난 호스트와 현재 선택된 정책 그룹을 확인합니다. 앱 이름만으로 도메인을 단정하지 말고, 호스트가 회의 기능과 관련 있어 보이는지 확인합니다.
- 한 번에 한 도메인 규칙만 추가한 뒤 앱을 다시 연결해 차이가 있는지 비교합니다. 연결 대상이 불분명하면 광범위한 도메인 접미사 규칙을 추가하지 않습니다.
Zoom에서는 서비스의 웹사이트와 회의 미디어 연결이 서로 다른 경로를 사용할 수 있습니다. Slack 역시 메시지 화면이 열린다는 사실만으로 허들 음성·영상이 같은 규칙을 탔다고 볼 수 없습니다. Meet은 Google 계정 로그인과 회의 연결이 함께 보일 수 있지만, 모든 Google 도메인을 프록시로 보내면 문서, 검색, 다른 업무 서비스까지 영향을 받을 수 있습니다. 따라서 확인된 회의 관련 호스트만 대상으로 삼고, 규칙을 넓힐 때는 연결 로그에서 실제 매칭 결과를 다시 점검하세요.
업무 앱만 프록시 그룹으로 보내기
프로필에 이미 자동 선택 또는 수동 선택이 가능한 프록시 그룹이 있다면, 예시의 Work-Proxy를 실제 그룹 이름으로 바꾸어 사용합니다. 그룹 이름은 대소문자와 문장부호까지 YAML에 정의된 값과 일치해야 합니다. 아래 항목은 규칙의 형태를 보여 주는 예시이며, 프로필의 규칙 목록에서 더 일반적인 규칙이나 최종 규칙보다 앞에 배치해야 합니다.
rules:
- DOMAIN-SUFFIX,zoom.us,Work-Proxy
- DOMAIN-SUFFIX,zoom.com,Work-Proxy
- DOMAIN,meet.google.com,Work-Proxy
- DOMAIN-SUFFIX,slack.com,Work-Proxy
# Add only domains confirmed in your connection log.
# Keep the profile's existing rules below these entries.예시 도메인이 현재 앱의 모든 연결을 포함한다고 가정해서는 안 됩니다. 특히 Slack이나 Zoom의 부가 연결이 다른 호스트로 나타난다면 해당 연결이 실제 회의 기능에 필요한지 로그와 앱 동작으로 확인한 뒤 추가하세요. DOMAIN-SUFFIX는 해당 접미사 아래의 여러 하위 도메인에 적용되므로, 필요 이상으로 넓은 서비스 도메인을 선택하면 업무 외 트래픽까지 프록시를 탈 수 있습니다.
국내 사이트를 직접 연결하려면 먼저 프로필에 이미 있는 국내 도메인·지역 규칙을 확인하세요. 많은 구독 프로필은 국내 트래픽을 직접 연결하도록 기본 규칙을 포함하지만, 앞에서 추가한 넓은 프록시 규칙이 그 예외를 덮으면 기대한 경로가 바뀔 수 있습니다. “국내 사이트 전체”를 하나의 임의 도메인 규칙으로 처리하기보다는, 기존 프로필이 제공하는 분류 규칙을 유지하고 필요한 도메인만 좁게 예외 처리하는 편이 관리하기 쉽습니다. 수정 후에는 국내 은행, 검색, 업무 포털 등 자주 쓰는 사이트가 실제로 DIRECT로 매칭되는지 연결 기록에서 확인하세요.
회의용 노드는 핑보다 안정성과 전송 지원을 본다
회의용 노드를 고를 때는 측정된 지연 시간만 낮은 노드보다 끊김 없이 지속 연결을 유지하고, 회의에 필요한 전송 방식을 지원하는 노드를 우선합니다. 영상 통화는 업로드 품질과 왕복 지연, 패킷 손실에 민감합니다. 짧은 속도 측정에서 높은 다운로드 속도가 나오더라도, 저녁 시간대에 업로드가 흔들리거나 긴 연결이 자주 재설정되면 회의 품질은 나쁠 수 있습니다.
| 확인 항목 | 확인 방법 | 판단할 때 주의할 점 |
|---|---|---|
| 지연과 변동 | 같은 회의 시간대에 여러 차례 연결해 비교 | 한 번의 낮은 핑보다 반복 측정의 일관성이 중요 |
| 업로드 품질 | 회의 중 카메라를 켜고 화면 공유도 시험 | 다운로드 속도만으로 송출 품질을 예측하지 않기 |
| UDP 지원 | 클라이언트와 노드의 지원 여부를 확인하고 실제 회의로 검증 | 모든 노드나 전송 방식이 UDP를 지원하는 것은 아님 |
| 시간대별 혼잡 | 업무 시간과 저녁 시간에 같은 조건으로 비교 | 사용자 수나 회선 혼잡에 따라 결과가 달라질 수 있음 |
특히 음성·영상의 실시간 미디어가 일반 웹 요청과 같은 방식으로 프록시를 통과한다고 단정하면 안 됩니다. 사용하는 Clash 코어, 노드 프로토콜, 클라이언트의 TUN 또는 시스템 프록시 설정에 따라 처리 방식이 달라질 수 있고, UDP를 지원하지 않는 경로에서는 회의 앱이 다른 전송 방식으로 전환하거나 연결에 실패할 수 있습니다. 화면 공유와 음성만 각각 시험하고, 앱의 네트워크 진단 정보와 Clash 로그를 함께 확인하세요.
회의 앱별로 검증하고 문제를 분리하기
규칙을 저장한 뒤에는 Zoom, Slack 허들, Google Meet을 한꺼번에 시험하지 말고 하나씩 확인합니다. 먼저 앱을 완전히 종료했다가 다시 실행해 새 연결을 만들고, 2~3분간 음성 통화와 카메라 송출을 확인하세요. 그다음 화면 공유를 켜고, 회의 중 잠시 Wi-Fi에서 유선 연결이나 다른 네트워크로 바꿀 수 있다면 변화도 비교합니다. 네트워크를 바꿀 때 회의 연결이 재수립될 수 있으므로 중요한 업무 회의 중에는 테스트하지 않는 편이 좋습니다.
회의 화면이 열리지만 상대방에게 내 목소리나 영상이 전달되지 않는다면, 규칙뿐 아니라 마이크·카메라 권한, 업로드 대역폭, 회사 VPN, 방화벽, 노드의 UDP 지원을 점검합니다. 앱 전체가 로그인 단계에서 멈춘다면 인증 도메인이 회의 도메인과 다른 경로를 탔을 수 있습니다. 반대로 국내 사이트만 느려졌다면 업무 규칙이 너무 넓거나 기존 국내 직접 연결 규칙보다 앞에 배치됐을 가능성이 있습니다.
문제를 재현할 때는 한 번에 한 요소만 바꾸세요. 먼저 같은 노드에서 규칙만 조정하고, 다음에는 규칙을 유지한 채 노드만 바꿉니다. 변경마다 앱을 새로 연결하고 결과를 기록하면 “프록시를 켜니 나아진 것 같다”는 인상에 의존하지 않고 원인을 좁힐 수 있습니다. 프로필 업데이트 뒤 증상이 생겼다면 규칙 공급자나 그룹 이름이 바뀌었는지도 확인하고, 이전에 저장한 설정과 비교하세요.
자주 묻는 질문
Zoom 회의는 항상 프록시를 거쳐야 하나요?
아닙니다. 직접 연결이 안정적이고 회사 정책에도 문제가 없다면 회의 트래픽을 굳이 우회할 이유가 없습니다. 특정 네트워크에서 접속이 불안정하거나 허용된 업무 경로가 정해져 있을 때만 해당 호스트를 프록시 그룹에 넣고, 직접 연결과 같은 조건으로 비교해 선택하세요.
Google Meet을 위해 모든 Google 도메인을 프록시로 보내야 하나요?
그럴 필요는 없습니다. 넓은 Google 도메인 규칙은 검색, 문서, 계정 인증 등 관련 없는 트래픽까지 바꿀 수 있습니다. 먼저 Meet을 실행했을 때의 연결 로그를 확인하고, 실제로 필요한 호스트만 제한적으로 추가하세요. 로그인과 회의 미디어가 서로 다른 경로를 쓰는지 확인하는 것도 중요합니다.
회의 화면은 괜찮은데 영상과 음성만 끊기면 무엇을 봐야 하나요?
규칙 매칭 결과와 함께 업로드 품질, 무선 신호, 노드 혼잡, UDP 지원 여부를 확인하세요. 웹페이지 로딩이 정상이라는 사실만으로 실시간 미디어 연결까지 정상이라고 볼 수 없습니다. Clash 로그에 관련 연결이 보이지 않는다면 회의 앱이 시스템 프록시를 따르지 않거나 다른 네트워크 경로를 이용하는 경우도 고려해야 합니다.
회사 VPN과 Clash를 함께 사용할 수 있나요?
환경에 따라 가능 여부와 허용 범위가 다릅니다. VPN 클라이언트가 기본 경로, DNS 또는 방화벽 정책을 관리하면 Clash 규칙과 충돌하거나 조직 정책을 위반할 수 있습니다. 회사에서 제공한 지침을 확인하고, 허용되지 않은 경우 두 도구를 동시에 사용하지 마세요.
재택근무 환경에 맞게 경로를 단순하게 유지하기
일부 앱은 업무용 도메인과 국내 트래픽을 세밀하게 나누기 어렵고, 연결이 흔들릴 때 어느 경로를 탔는지 확인할 수 있는 기록도 제한적입니다. Clash는 규칙 모드에서 확인된 도메인만 지정한 그룹으로 보내고, 기존 국내 직접 연결 정책을 유지하며, 로그로 실제 매칭 결과를 점검할 수 있어 회의 문제를 단계별로 좁히기 좋습니다. 다만 프록시를 추가한다고 회선 품질이나 회의 서비스의 장애까지 해결되는 것은 아니므로, 직접 연결과 비교하고 회사의 네트워크 정책을 지키는 것이 우선입니다. 업무 앱별 규칙과 회의용 노드를 직접 관리하려면 사용 중인 운영체제에 맞는 Clash 클라이언트를 확인해 보세요.