Zoom과 Google Meet이 끊기는 이유

재택근무 중 화상회의가 끊긴다고 해서 항상 노드의 속도만 문제인 것은 아닙니다. Zoom과 Google Meet은 영상·음성·화면 공유를 동시에 사용하므로 일반적인 웹페이지보다 지연 시간과 패킷 손실에 민감합니다. 다운로드 속도가 충분해도 순간적인 지연이 반복되거나 업로드 품질이 불안정하면 상대방의 목소리가 로봇처럼 들리고, 카메라 화면이 멈추며, 화면 공유가 늦게 따라오는 현상이 나타납니다.

Clash를 사용하는 환경에서는 몇 가지 원인이 겹칠 수 있습니다. 회의 서버와 멀리 떨어진 노드를 선택했거나, 모든 트래픽을 불필요하게 프록시로 보내고 있거나, 반대로 Zoom·Google Meet의 연결이 규칙에서 직접 연결로 분류될 수 있습니다. 또한 회사 VPN, Wi-Fi 절전 기능, 브라우저의 보안 DNS, 다른 VPN 앱이 동시에 작동하면 경로가 복잡해져 연결이 불안정해집니다.

이 글의 목표는 모든 인터넷 트래픽을 무조건 우회하는 것이 아닙니다. 업무에 필요한 회의 서비스만 안정적인 노드로 보내고, 일반적인 국내 웹사이트와 사내 시스템은 가능한 한 직접 연결해 지연과 부하를 함께 줄이는 것입니다. 회의 전후로 설정을 빠르게 바꿀 수 있도록 데스크톱의 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로 설명하되, 핵심 원리는 다른 Clash 클라이언트에도 적용할 수 있습니다.

시작 전 확인할 항목

먼저 아래 조건을 확인하세요.

최신 클라이언트와 커널: 오래된 Clash for Windows나 구버전 코어는 최신 구독 형식과 일부 프로토콜을 제대로 처리하지 못할 수 있습니다. 가능하면 유지 관리가 계속되는 Clash Verge Rev 또는 Mihomo 기반 클라이언트를 사용합니다.
정상적인 구독 프로필: 프로필을 업데이트했을 때 노드 이름, 지연 시간, 프록시 그룹이 정상적으로 표시되어야 합니다. 노드 목록이 비어 있다면 회의 설정 전에 구독부터 해결해야 합니다.
회의용 노드 후보: 거리가 가까운 지역의 노드를 두세 개 준비합니다. 같은 국가에 있어도 통신사와 서버의 피어링 품질이 다르므로 하나만 믿지 않는 것이 좋습니다.
충돌하는 네트워크 도구: 회사 VPN, 다른 프록시 앱, 광고 차단용 DNS, 게임 가속기를 동시에 켜면 라우팅 우선순위가 꼬일 수 있습니다. 테스트할 때는 불필요한 도구를 잠시 종료합니다.

화상회의는 다운로드보다 업로드가 중요할 때가 많습니다. 카메라 영상과 화면 공유는 계속 서버로 전송되기 때문입니다. 따라서 노드를 고를 때 단순한 핑 숫자만 보지 말고 회의에 참여한 뒤 음성 지연, 화면 공유 반응, 패킷 손실을 함께 확인해야 합니다. 20ms가 낮은 노드라도 피크 시간대에 업로드가 불안정하면 80ms이지만 안정적인 노드보다 실제 회의 품질이 나쁠 수 있습니다.

1단계: 회의에 맞는 노드 선택

Clash의 Proxies 또는 프록시 화면에서 먼저 자동 선택 그룹을 확인합니다. 제공업체 설정에 URLTest, 自动选择, Auto와 같은 그룹이 있다면 후보를 좁히는 데 사용할 수 있습니다. 다만 자동 테스트가 측정하는 주소와 Zoom·Google Meet의 실제 미디어 서버는 다를 수 있으므로, 자동 선택 결과를 최종 정답으로 생각하지는 마세요.

회의 시작 10~15분 전에 가까운 지역의 노드를 두 개 이상 측정합니다.
지연 시간뿐 아니라 연속 테스트 결과가 크게 흔들리는지 확인합니다.
첫 번째 노드로 회의에 참여해 음성 지연과 화면 공유를 시험합니다.
문제가 있으면 다른 노드로 전환한 뒤 같은 회의 또는 테스트 회의에서 비교합니다.

노드 이름에 표시된 지역만으로 품질을 판단하지 않는 것도 중요합니다. 실제 경로는 사용자의 인터넷 회선, 노드 운영자의 상위망, 회의 서비스의 접속 지점에 따라 달라집니다. 사무실이나 집의 인터넷 제공업체가 특정 해외망과 좋은 연결을 제공한다면 같은 지역의 다른 노드보다 더 멀리 있는 노드가 오히려 안정적일 수도 있습니다.

확인 기준	좋은 상태	주의할 상태
지연 시간	낮고 반복 측정 결과가 일정함	측정할 때마다 큰 폭으로 변함
음성 품질	말이 자연스럽게 들리고 끊김이 적음	로봇 음성, 반복 재생, 긴 지연
화면 공유	페이지 전환이 짧은 지연으로 반영됨	화면이 멈추거나 수 초 늦게 표시됨
규칙 로그	의도한 프록시 그룹으로 연결됨	회의 도메인이 직접 연결 또는 거부로 표시됨

2단계: Zoom과 Google Meet만 필요한 방식으로 라우팅

가장 간단한 방법은 클라이언트가 제공하는 규칙 모드에서 회의 관련 규칙을 확인하는 것입니다. 프로필에 이미 Zoom과 Google 서비스 규칙이 포함되어 있다면 먼저 Connections 또는 연결 화면에서 실제 매칭 결과를 확인하세요. 설정 파일에 임의의 규칙을 추가하기 전에 현재 규칙이 어떤 정책 그룹을 사용하는지 알아야 나중에 구독 업데이트로 규칙이 덮어써지는 문제를 피할 수 있습니다.

직접 규칙을 관리하는 고급 사용자는 회의 서비스의 기본 도메인을 별도 프록시 그룹으로 보내는 구성을 사용할 수 있습니다. 단, 서비스는 로그인, 인증, 이미지, 미디어, 알림을 서로 다른 도메인에서 처리할 수 있습니다. 대표 도메인 하나만 추가하면 회의가 연결되는 것처럼 보여도 음성이나 화면 공유만 실패할 수 있으므로 로그를 보면서 범위를 넓혀야 합니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,MEETING
  - DOMAIN-SUFFIX,zoom.com,MEETING
  - DOMAIN-SUFFIX,google.com,MEETING
  - DOMAIN-SUFFIX,googlevideo.com,MEETING
  - DOMAIN-SUFFIX,gstatic.com,MEETING
  - MATCH,DIRECT

위 예시는 개념을 설명하기 위한 형태입니다. 실제 프로필에서 사용하는 그룹 이름이 MEETING과 다르면 자신의 프록시 그룹 이름으로 바꾸어야 합니다. 제공업체가 이미 완성된 규칙 세트를 제공하는 경우에는 같은 도메인을 중복해서 추가하기보다 해당 규칙의 정책을 수정하는 편이 안전합니다.

주의

Google Meet은 Google 계정 로그인과 캘린더, 문서, 동영상 미디어가 함께 사용될 수 있습니다. 너무 좁은 규칙만 적용하면 회의 입장은 되지만 마이크 권한 확인, 녹화 저장, 화면 공유 연결이 실패할 수 있습니다. 반대로 DOMAIN-SUFFIX,google.com 전체를 무조건 프록시로 보내면 일반 Google 서비스까지 우회되어 속도가 느려질 수 있으므로 로그와 실제 사용 범위를 기준으로 조정하세요.

회사 내부 회의 링크나 사내 웹앱은 회사 정책을 우선해야 합니다. 회사 VPN이 필요한 서비스까지 Clash 규칙으로 우회하면 인증 세션이 끊기거나 보안 장비가 비정상 접속으로 판단할 수 있습니다. 회의 서비스와 사내 시스템의 경로가 다르다면 회사 VPN을 먼저 연결한 뒤 Clash의 TUN과 DNS 동작을 점검하고, 보안팀이 허용한 범위 안에서만 설정을 변경하세요.

3단계: 시스템 프록시와 TUN 모드 점검

Zoom 데스크톱 앱과 브라우저는 같은 방식으로 프록시를 사용하지 않을 수 있습니다. 브라우저는 운영체제의 HTTP 프록시 설정을 비교적 잘 따르지만, 데스크톱 회의 앱은 자체 네트워크 스택이나 UDP 연결을 사용할 수 있습니다. 그래서 브라우저에서 Google Meet이 정상이어도 Zoom 앱의 화면 공유가 실패하거나, 반대로 앱은 되는데 브라우저만 로그인에 실패하는 상황이 생깁니다.

웹 브라우저 회의: Clash의 시스템 프록시를 켜고 브라우저를 완전히 종료한 뒤 다시 실행합니다. 기존 연결이 남아 있으면 새 규칙이 적용되지 않을 수 있습니다.
Zoom 데스크톱 앱: 앱 설정의 연결 옵션과 시스템 프록시 적용 여부를 확인합니다. 회사에서 배포한 버전은 관리 정책이 우선할 수 있습니다.
TUN 모드: 시스템 프록시를 무시하는 앱까지 처리해야 할 때 유용하지만, 회사 VPN이나 다른 가상 어댑터와 충돌할 수 있습니다.
UDP 처리: 음성·영상 품질이 TCP보다 불안정하다면 로그에서 UDP 오류와 시간 초과를 확인합니다. 노드가 UDP를 지원하지 않으면 다른 노드나 제공업체 설정이 필요할 수 있습니다.

처음부터 TUN을 켜기보다 시스템 프록시만으로 브라우저 회의를 테스트한 다음 필요한 경우 TUN을 추가하는 순서가 문제를 좁히기 쉽습니다. TUN을 켠 뒤 인터넷 전체가 끊기면 즉시 다른 설정을 여러 개 바꾸지 말고, TUN을 끄고 정상 복구되는지부터 확인하세요. 복구된다면 서비스 모드 권한, 가상 어댑터, IPv6 경로, 기존 VPN과의 충돌을 하나씩 점검해야 합니다.

팁

회의 전에는 Clash의 Logs 창을 열어 두고 새 연결이 어느 그룹으로 들어가는지 확인하세요. 같은 도메인이 예상과 다른 정책으로 매칭되면 규칙 순서를 확인합니다. Clash 규칙은 위에서 아래로 평가되므로 넓은 DOMAIN-SUFFIX 규칙이 세부 규칙보다 위에 있으면 원하는 회의용 그룹에 도달하지 못할 수 있습니다.

4단계: DNS와 Wi-Fi 환경 안정화

화상회의 연결 실패가 항상 프록시 노드의 문제는 아닙니다. DNS가 불안정하면 회의 서버 주소를 늦게 찾거나 잘못된 주소를 받아 초기 연결 시간이 길어질 수 있습니다. Clash의 DNS를 사용하는 경우에도 브라우저의 보안 DNS, 운영체제의 DNS 캐시, 공유기의 DNS 리다이렉트가 별도로 작동할 수 있습니다. 따라서 설정을 바꾼 뒤에는 브라우저를 재시작하고 기존 DNS 캐시의 영향을 줄여야 합니다.

fake-ip 모드를 사용하는 프로필은 앱별 호환성 예외가 필요할 수 있습니다. 회의 앱이 특정 도메인의 실제 주소를 직접 확인해야 하는 경우 fake-ip-filter에 해당 도메인을 추가하면 도움이 될 수 있지만, 정확한 도메인을 모른 채 예외를 크게 늘리면 DNS 분류 효과가 약해집니다. 설정을 바꿀 때마다 회의 입장, 마이크, 카메라, 화면 공유를 각각 확인하는 것이 좋습니다.

Wi-Fi도 함께 살펴보세요. 2.4GHz 대역은 벽을 통과하는 데 유리하지만 주변 공유기와 간섭이 많고, 5GHz 대역은 빠르지만 거리와 장애물의 영향을 크게 받습니다. 공유기에서 멀리 떨어진 방이라면 속도 측정값보다 순간적인 패킷 손실이 더 큰 문제가 될 수 있습니다. 가능하다면 회의 중에는 공유기에 가까이 앉거나 유선 연결을 사용하고, 대용량 업로드·클라우드 동기화·게임 업데이트를 잠시 중단하세요.

회의 품질이 갑자기 나빠졌다면 다음 순서로 비교하면 원인을 빠르게 분리할 수 있습니다.

같은 노드에서 시스템 프록시를 켠 브라우저와 다른 브라우저의 회의 품질을 비교합니다.
현재 노드를 바꾸고 같은 회의 테스트를 반복합니다.
Clash를 잠시 끈 상태에서 직접 연결 품질을 확인합니다.
직접 연결만 정상이라면 규칙, 노드, DNS 순서로 범위를 좁힙니다.
모든 모드에서 문제가 있으면 Wi-Fi, ISP 업로드 품질, 회의 서비스 장애를 확인합니다.

5단계: 회의 전후 점검 절차

원격근무에서 중요한 것은 복잡한 설정을 한 번 만드는 것보다 회의마다 재현 가능한 점검 절차를 갖추는 것입니다. 업무 시작 전에 노드 지연을 확인하고, 선택한 그룹이 실제로 활성화되어 있는지 살펴보세요. 프로필이 새로 업데이트되면 정책 그룹 이름이나 규칙 순서가 바뀔 수 있으므로, 자동 업데이트 직후에는 중요한 회의가 없는 시간에 테스트하는 편이 안전합니다.

회의 5분 전 체크리스트

Clash가 실행 중이고 올바른 프로필이 활성화되어 있는지 확인합니다.
회의용 프록시 그룹에 안정적인 노드가 선택되어 있는지 확인합니다.
시스템 프록시 또는 TUN이 필요한 상태로 켜져 있는지 확인합니다.
Logs에서 Zoom·Google Meet 연결이 예상한 정책으로 매칭되는지 봅니다.
카메라와 마이크를 테스트하고, 업로드를 사용하는 다른 프로그램을 닫습니다.
첫 노드에서 문제가 있으면 회의 중간이 아니라 시작 전에 준비한 두 번째 노드로 전환합니다.

회의 중 연결이 나빠졌을 때는 여러 스위치를 동시에 조작하지 마세요. 우선 카메라를 잠시 끄고 음성이 회복되는지 확인한 다음, 노드를 한 번만 바꾸어 비교합니다. 노드 전환 직후에는 기존 TCP·UDP 세션이 정리되는 시간이 필요할 수 있습니다. 그래도 회복되지 않으면 브라우저나 회의 앱을 재시작하고, 시스템 프록시와 TUN 중 하나만 사용하도록 단순화합니다.

회의가 끝난 뒤에는 Clash의 연결 기록을 확인해 어떤 도메인이 실패했는지 메모해 두면 다음 설정에 도움이 됩니다. timeout이 반복되면 노드나 회선 문제일 가능성이 있고, rule match가 예상과 다르면 규칙 순서 문제일 가능성이 큽니다. 인증서 오류나 회사 네트워크 차단 메시지가 보이면 보안 정책을 우회하려 하기보다 관리자에게 허용된 연결 방법을 문의해야 합니다.

속도와 안정성을 함께 얻는 구성

모든 트래픽을 하나의 해외 노드로 보내는 방식은 처음에는 단순하지만, 일반 업무 사이트까지 멀리 돌아가게 만들어 지연과 노드 부하를 키울 수 있습니다. 반대로 모든 것을 직접 연결하면 특정 네트워크에서 회의 서비스의 로그인이나 미디어 연결이 불안정해질 수 있습니다. Clash의 규칙 모드는 이 두 극단 사이에서 서비스별 경로를 나누고, 문제가 발생한 흐름만 확인할 수 있다는 장점이 있습니다.

권장 구성은 회의에 사용하는 도메인을 별도 그룹으로 관리하고, 일반 국내 업무 사이트는 직접 연결하는 방식입니다. 노드는 한 개가 아니라 주 노드와 예비 노드로 나누며, 회의 전에 실제 마이크와 화면 공유를 테스트합니다. DNS는 프로필의 기본 동작을 우선 사용하고, 특정 앱에서만 문제가 확인될 때 예외를 최소한으로 추가하세요. 이렇게 하면 설정 파일을 과도하게 복잡하게 만들지 않으면서도 재택근무 환경에 필요한 안정성을 확보할 수 있습니다.

일부 경쟁 프록시 도구는 전체 연결을 단순히 켜고 끄는 데 집중해 서비스별 규칙, 노드별 비교, 상세 로그를 한 화면에서 관리하기 어렵습니다. 이 때문에 회의가 끊길 때 노드 문제인지 DNS 문제인지 앱 자체 문제인지 구분하는 데 시간이 걸릴 수 있습니다. Clash는 규칙 모드와 그룹 정책, 연결 로그, TUN 지원을 조합해 Zoom과 Google Meet만 선택적으로 조정하고 일반 업무 트래픽은 직접 연결할 수 있습니다. 원격근무 중 회의 품질과 웹사이트 속도를 함께 관리하고 싶다면 Clash 무료 다운로드로 자신의 플랫폼에 맞는 클라이언트를 확인해 보세요.

Clash 원격근무 설정법: Zoom·Google Meet 끊김 줄이기