화상회의 트래픽만 분리하는 이유

재택근무 중 Zoom이나 Google Meet 연결이 불안정하면 회의 앱만 프록시로 보내고, 나머지 인터넷 트래픽은 직접 연결하는 구성을 고려할 수 있습니다. 전체 트래픽을 프록시로 보내는 방식은 설정이 단순하지만, 웹 검색이나 사내 서비스까지 먼 노드를 경유해 응답이 느려질 수 있습니다. 반대로 시스템 프록시만 켜면 브라우저 기반 회의는 연결되더라도 일부 데스크톱 앱의 미디어 트래픽이 프록시를 통과하지 않을 수 있습니다.

Clash의 규칙 모드에서는 도메인이나 IP 조건에 따라 연결 경로를 나눌 수 있습니다. 회의 서비스 도메인에는 전용 프록시 그룹을 지정하고, 그 밖의 연결은 기존 규칙을 따르게 하면 업무 회의와 평소 인터넷 사용을 한 설정에서 관리할 수 있습니다. 다만 회의 앱은 로그인·신호 교환·음성·영상에 서로 다른 서버와 전송 방식을 사용할 수 있으므로, 도메인 몇 개만 추가한다고 모든 회의 트래픽이 반드시 같은 경로로 흐르는 것은 아닙니다.

먼저 회의가 끊기는 원인을 구분하세요. 회의실 입장은 되지만 음성이나 영상만 불안정하다면 노드의 지연 시간과 UDP 지원 여부가 중요할 수 있습니다. 로그인 화면이나 회의 링크 자체가 열리지 않는 경우에는 DNS, 브라우저의 보안 DNS, 규칙 순서도 함께 점검해야 합니다. 프록시는 네트워크 경로를 바꾸는 도구이며, 불안정한 무선 네트워크나 회사 계정의 정책을 대신 해결해 주지는 않습니다.

클라이언트와 프록시 그룹 준비

Clash Verge, Clash Verge Rev, Mihomo 기반 클라이언트 등 사용 중인 앱에서 먼저 구독 프로필이 정상적으로 업데이트되는지 확인합니다. 메뉴 이름은 버전에 따라 다를 수 있지만, 일반적으로 프로필 화면에서 설정을 갱신하고 프록시 화면에서 노드의 연결 상태와 지연 시간을 확인할 수 있습니다. 회의 중에만 사용할 노드를 고를 때는 단순한 속도 테스트 결과뿐 아니라 실제 회의 앱에서 음성·영상이 안정적으로 유지되는지도 살펴보세요.

설정 전 체크리스트

프로필과 노드: 구독 설정이 최신 상태이고, 회의에 사용할 노드가 현재 선택 가능한지 확인합니다.
라우팅 모드: 전역 모드가 아니라 규칙 모드를 기준으로 구성합니다. 그래야 회의 서비스만 별도로 분리할 수 있습니다.
그룹 이름: 아래 예시의 Meeting은 설명용 이름입니다. 실제 설정의 프록시 그룹 이름과 정확히 일치하도록 바꾸세요.
기존 규칙: 구독 설정에 이미 Zoom·Google 관련 규칙이 있는지 확인합니다. 규칙이 중복되면 앞에 있는 항목이 먼저 적용될 수 있습니다.

새 프록시 그룹을 만들 수 있는 설정이라면 회의용 그룹을 따로 두는 편이 편리합니다. 사용자가 노드를 직접 선택할 수 있는 select 그룹을 두면 회의 전에 여러 노드를 비교하고, 문제가 생겼을 때 다른 노드로 빠르게 전환할 수 있습니다. 기존 구독에 이미 적절한 그룹이 있다면 같은 기능의 그룹을 중복해서 만들 필요는 없습니다.

proxy-groups:
  - name: Meeting
    type: select
    proxies:
      - "회의에 사용할 노드 이름"
      - DIRECT

노드 이름은 예시 문자열을 그대로 붙여 넣는 것이 아니라, 활성 설정의 proxies 또는 그룹 목록에 실제로 표시되는 이름으로 교체해야 합니다. DIRECT를 그룹 안에 두면 회의 서비스가 직접 연결되는 결과와 프록시 연결 결과를 비교할 수 있지만, 직접 연결이 네트워크 정책에 맞지 않는 환경에서는 이 선택지를 제거하세요.

Zoom·Google Meet 규칙 추가하기

규칙은 위에서 아래로 평가되는 구성이 일반적이므로, Zoom과 Google Meet에 해당하는 구체적인 규칙을 넓은 해외 도메인 규칙이나 마지막 MATCH 규칙보다 위에 배치해야 합니다. 다음은 기본적인 예시입니다. 실제 구독 설정에 이미 같은 도메인을 처리하는 규칙이 있다면 기존 규칙을 수정하거나 중복 항목을 정리하세요.

rules:
  - DOMAIN-SUFFIX,zoom.us,Meeting
  - DOMAIN-SUFFIX,zoom.com,Meeting
  - DOMAIN-SUFFIX,zoomgov.com,Meeting
  - DOMAIN,meet.google.com,Meeting
  - DOMAIN-SUFFIX,meet.google.com,Meeting
  - MATCH,기존 기본 그룹

이 목록은 출발점이지, 모든 계정과 클라이언트에 적용되는 완전한 서비스 도메인 목록은 아닙니다. Google Meet은 회의 입장에 사용되는 도메인과 미디어 전달에 관여하는 호스트가 다를 수 있고, Google의 여러 서비스가 공통 도메인이나 CDN을 사용할 수 있습니다. Google 전체 도메인을 회의용 그룹에 넣으면 Gmail, 검색, 드라이브 등 회의와 무관한 연결까지 프록시로 갈 수 있으므로 광범위한 google.com 규칙을 무심코 추가하지 마세요.

Zoom도 로그인, 회의 제어, 미디어 연결에 서로 다른 호스트를 사용할 수 있습니다. 회의가 시작된 뒤 음성이나 영상만 실패한다면 도메인 규칙만으로 해결되지 않을 수 있습니다. 클라이언트의 연결 목록과 로그에서 실제로 접속하는 호스트를 확인하고, 해당 호스트가 어떤 규칙에 매칭됐는지 살펴보세요. 확인되지 않은 IP 대역을 임의로 추가하면 다른 서비스까지 잘못 분류하거나, 서비스 측 주소 변경 후 규칙이 작동하지 않을 수 있습니다.

규칙 확인 팁

회의에 입장한 상태에서 Clash의 연결 목록을 열고 관련 연결의 도메인, 프로세스, 선택된 규칙과 프록시 그룹을 확인하세요. 규칙이 예상과 다르면 기존 규칙보다 위에 배치했는지, 그룹 이름을 정확히 썼는지, 활성 프로필을 수정했는지부터 점검하면 원인을 좁히기 쉽습니다.

일부 클라이언트는 프로세스 이름을 기준으로 규칙을 적용하는 기능도 제공합니다. 이 기능을 쓸 경우 운영체제마다 실제 프로세스 이름이 다를 수 있고, 브라우저에서 회의에 참여하는 경우 브라우저 전체 트래픽이 회의용 그룹으로 분류될 수 있습니다. 따라서 프로세스 규칙은 앱의 연결을 식별하는 데 유용하지만, 다른 인터넷 사용까지 함께 프록시로 보낼 수 있다는 점을 먼저 고려해야 합니다.

TUN 모드와 회의 품질 확인

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 적합합니다. 반면 앱이 시스템 프록시를 무시하거나 UDP 연결을 별도로 사용하는 경우에는 트래픽이 Clash 규칙에 잡히지 않을 수 있습니다. 이런 환경에서는 TUN 모드가 앱의 네트워크 연결을 더 넓게 포착하는 데 도움이 될 수 있습니다. 다만 TUN은 가상 네트워크 인터페이스와 라우팅에 영향을 주므로, 회사 VPN·보안 프로그램·다른 VPN 클라이언트와 함께 사용할 때 충돌할 가능성도 있습니다.

확인할 항목	시스템 프록시	TUN 모드
적합한 상황	브라우저 등 시스템 프록시를 따르는 앱 위주	프록시 설정을 무시하는 앱이나 별도 네트워크 연결이 있는 경우
주의할 점	일부 앱의 UDP·직접 연결은 잡히지 않을 수 있음	관리자 권한, 가상 어댑터, VPN·방화벽과의 충돌 가능성
시험 방법	회의 연결이 규칙과 프록시 그룹을 통과하는지 확인	활성화 전후 회의 앱과 회사 내부 서비스가 모두 동작하는지 비교

TUN을 켜기 전에는 클라이언트가 요구하는 권한이나 서비스 모드가 준비됐는지 확인하고, 다른 VPN이나 가상 네트워크 도구를 동시에 사용 중이라면 하나씩 꺼서 충돌 여부를 비교하세요. 설정 변경 직후 인터넷 전체가 끊긴다면 회의 규칙만 더 추가하기보다 TUN을 잠시 끄고 시스템 프록시로 되돌려 원인을 분리하는 편이 안전합니다. 회사 내부 사이트나 화상회의 장비가 직접 연결되어야 하는 환경에서는 사내 주소를 무조건 회의용 프록시 그룹으로 보내지 않도록 별도 규칙을 점검해야 합니다.

회의 전 테스트 순서

회의용 프록시 그룹에서 지연이 낮고 연결이 안정적인 노드를 선택합니다.
Zoom 또는 Google Meet 테스트 회의에 접속해 마이크와 카메라 권한, 음성·영상 재생을 확인합니다.
Clash 연결 목록에서 회의 관련 연결이 예상한 규칙과 그룹을 사용하는지 확인합니다.
짧은 시간 동안 화면 공유와 음성 전환을 시험한 뒤, 문제가 있으면 다른 노드 또는 직접 연결 결과와 비교합니다.
회의가 끝난 뒤에도 다른 웹사이트와 사내 서비스가 정상적으로 연결되는지 점검합니다.

노드의 지연 시간은 측정 시점과 대상 서버에 따라 달라집니다. 숫자가 낮은 노드가 실제 회의에서도 반드시 가장 좋은 것은 아니며, 패킷 손실이나 순간적인 지연 변화가 크면 체감 품질이 나빠질 수 있습니다. 회의 중에만 끊김이 발생하면 노드를 바꿔 재현 여부를 확인하고, 가능하다면 Wi-Fi 대신 유선 연결을 시험하세요. 회의가 끝난 뒤에는 로그의 timeout이나 연결 재설정 기록을 살펴보되, 계정 정보나 구독 주소가 노출된 로그를 외부에 공유하지 않도록 주의합니다.

자주 묻는 질문

규칙을 추가했는데도 회의 앱이 프록시를 사용하지 않는 이유는 무엇인가요?

규칙이 활성 프로필에 반영되지 않았거나, 해당 연결이 도메인 규칙에 매칭되지 않았거나, 앱이 시스템 프록시를 우회하는 경우가 흔합니다. 연결 목록에서 실제 호스트와 매칭된 규칙을 확인하고, 필요한 경우 TUN 모드와 앱의 네트워크 경로를 따로 시험하세요.

프록시를 켠 뒤 회의 지연이 더 커지면 어떻게 하나요?

프록시 경유는 연결 경로를 늘릴 수 있으므로 언제나 지연이 줄어드는 것은 아닙니다. 다른 노드를 선택해 비교하고, 직접 연결이 허용되는 환경이라면 같은 회의를 DIRECT와 비교해 보세요. 무선 신호, 회의 서버와의 거리, 노드 혼잡도도 함께 영향을 줍니다.

Google 도메인을 모두 프록시로 보내도 되나요?

권장하지 않습니다. Google 전체 도메인을 대상으로 하면 Meet 이외의 검색, 메일, 저장 공간 등도 함께 프록시로 연결될 수 있습니다. 우선 회의에 필요한 범위만 규칙에 넣고, 연결 목록에서 실제로 사용된 호스트를 확인한 뒤 필요한 항목만 추가하세요.

Zoom이나 Meet을 쓰려면 TUN 모드를 반드시 켜야 하나요?

아닙니다. 시스템 프록시만으로 정상 동작하는 환경도 있습니다. 앱의 미디어 연결이 규칙에 잡히지 않거나 시스템 프록시를 따르지 않을 때 TUN을 시험할 수 있지만, 회사 VPN이나 보안 프로그램과 충돌하지 않는지 확인해야 합니다.

회의 앱마다 도메인 처리 방식이 다르거나 규칙 설정이 복잡한 클라이언트에서는 필요한 연결만 분리하기가 번거로울 수 있습니다. Clash는 도메인 규칙과 프록시 그룹을 함께 사용해 회의 트래픽과 일반 인터넷 연결을 나누고, 연결 목록에서 실제 경로를 확인할 수 있습니다. 이런 방식으로 회의 품질과 평소 사용을 직접 비교해 보고 싶다면 지금 Clash 받기에서 사용 중인 플랫폼에 맞는 클라이언트를 확인해 보세요.

재택 화상회의 안정화, Clash Zoom·Google Meet 분할 설정법