회의 앱만 분리하는 이유
재택근무 중 Zoom 회의는 잘 들리는데 Slack 알림이 늦게 오거나, Google Meet에서 화면 공유를 시작한 뒤 음성이 끊기는 경우가 있습니다. 이런 증상은 단순히 프록시를 켜고 끄는 것만으로 설명되지 않습니다. 브라우저의 웹 페이지 요청, 앱의 WebSocket 연결, 음성·영상 미디어 스트림이 서로 다른 호스트와 전송 방식을 사용할 수 있기 때문입니다. 같은 PC에서도 Zoom 앱은 시스템 프록시를 따르지만, 브라우저의 Meet는 TUN 경로를 탈 수 있고, Slack 데스크톱 앱은 브라우저와 다른 연결을 만들 수 있습니다.
이 글은 Clash의 기본적인 프로필과 노드 사용법을 알고 있는 원격 근무자를 대상으로 합니다. 목표는 인터넷 전체를 한 프록시 노드로 보내는 것이 아니라 Zoom·Slack·Google Meet 트래픽만 적절한 정책 그룹으로 분기하고, 업무용 일반 사이트와 로컬 네트워크는 기존 경로를 유지하는 것입니다. 특정 구독이나 노드 이름에 의존하지 않으며, Clash Verge Rev 등 Mihomo 호환 클라이언트에서 규칙과 연결 로그를 확인하는 흐름으로 설명합니다. 사용하는 클라이언트에 따라 메뉴 이름과 사용자 규칙을 넣는 위치는 다를 수 있으므로, 활성 프로필과 코어가 실제로 읽는 설정을 기준으로 확인하세요.
분할 프록시를 적용하기 전에 먼저 증상을 구분해 두면 원인 파악이 빨라집니다. 앱 로그인이나 채팅 목록 로딩이 실패하는지, 회의 입장 이후 미디어만 끊기는지, 아니면 특정 Wi-Fi에서만 문제가 생기는지를 메모하세요. 로그인 화면이 열리지 않는 현상은 도메인 규칙이나 DNS 경로와 관련될 수 있지만, 회의 중 음성 지연은 노드의 UDP 지원, 손실률, 네트워크 혼잡과 관계가 더 깊을 수 있습니다. 모든 증상을 하나의 도메인 규칙으로 해결하려고 하면 원인을 놓치기 쉽습니다.
Zoom·Slack·Meet의 연결 특성
서비스별 도메인을 규칙에 넣기 전에 실제 연결 로그를 확인해야 합니다. 앱 버전, 조직 계정, 리전, 기능에 따라 접속 호스트가 달라질 수 있으며, 서비스가 사용하는 전체 도메인 목록을 몇 개의 예시로 완전히 고정할 수는 없습니다. 우선 회의 참가나 메시지 전송처럼 재현 가능한 동작을 한 뒤, 로그에서 해당 시각에 새로 나타나는 연결의 호스트와 현재 적용된 규칙을 살펴보세요. 로그에 IP 주소만 표시되는 경우에는 도메인 스니핑과 DNS 처리 상태도 함께 점검해야 합니다.
- Zoom: 회의 시작·로그인 과정에는
zoom.us계열 호스트가 보일 수 있지만, 음성·영상 미디어는 별도 연결이나 동적으로 선택되는 서버를 사용할 수 있습니다. 웹사이트 도메인 하나만 프록시로 보낸 뒤 미디어까지 모두 처리됐다고 단정하지 마세요. - Slack: 채팅과 파일 관련 요청은
slack.com및 관련 서비스 호스트로 나뉠 수 있습니다. 메시지 목록은 보이는데 새 메시지나 알림만 늦다면 실시간 연결이 어느 규칙을 타는지 확인하고, 파일 업로드·다운로드도 별도로 시험합니다. - Google Meet: 회의 입장에는
meet.google.com이 관여하지만, 로그인과 Workspace 기능은 다른 Google 호스트를 사용할 수 있습니다. Meet만 분리하려고 Google 전체 도메인을 한꺼번에 프록시로 보내면 Gmail, Drive 등 다른 업무 트래픽까지 영향을 받을 수 있습니다.
세 서비스의 앱과 웹 버전을 동시에 사용한다면 브라우저 탭만으로 테스트를 끝내지 마세요. 앱별 연결은 운영체제 프록시, TUN, 앱 자체 네트워크 구현의 영향을 서로 다르게 받을 수 있습니다. 특히 웹에서 회의에 들어갈 때는 브라우저의 카메라·마이크 권한 문제와 프록시 연결 문제를 분리해서 확인해야 합니다. 같은 계정으로 웹 버전과 데스크톱 앱을 번갈아 시험하면 문제의 범위가 앱에 국한되는지, 기기 전체의 네트워크에 공통으로 나타나는지 파악하기 쉽습니다.
정책 그룹과 서비스 규칙 구성하기
우선 안정적으로 연결되는 기본 프록시 그룹이 있는지 확인합니다. 이미 구독 설정에 자동 선택이나 수동 선택 그룹이 있다면 그것을 재사용하고, 없을 때만 회의용 그룹을 추가하는 편이 관리하기 쉽습니다. 회의 중 자동으로 노드가 바뀌면 통화가 끊기거나 재접속할 수 있으므로, 자동 지연 테스트 그룹보다 사용자가 직접 선택하는 안정적인 그룹이 더 적합한 상황도 있습니다. 그룹 이름은 예시와 다르게 구성해도 되지만, 규칙에서 참조하는 이름과 실제 그룹 이름은 정확히 일치해야 합니다.
사용자 규칙을 지원하는 프로필이라면 아래처럼 서비스별 규칙을 일반적인 광역 규칙보다 앞에 배치할 수 있습니다. 예시의 그룹 이름은 실제 YAML에 존재하는 이름으로 바꾸고, 로그에서 확인되지 않은 호스트를 무작정 추가하지 마세요.
rules:
- DOMAIN-SUFFIX,zoom.us,Meeting
- DOMAIN-SUFFIX,slack.com,WorkApps
- DOMAIN-SUFFIX,meet.google.com,Meeting
- DOMAIN,example-host-confirmed-in-logs.com,Meeting
- MATCH,Default이 설정은 규칙 배치 원리를 보여 주는 예시일 뿐, 모든 Zoom·Slack·Meet 연결을 포괄하는 완성 목록은 아닙니다. 실제 프로필의 마지막 규칙은 구독에서 제공하는 규칙 집합일 수 있으며, MATCH 같은 기본 규칙을 새로 넣어 기존 정책을 덮어쓰지 않도록 주의하세요. 구독 갱신 시 사용자 규칙이 유지되는 방식도 클라이언트마다 다릅니다. 프로필의 원본을 직접 편집하기 전에 복사본이나 오버라이드 기능을 사용할 수 있는지 확인하고, 변경 후 코어가 설정을 정상적으로 읽었는지 확인하세요.
일반 업무 사이트는 기존 분류 규칙을 유지하고, 사내 VPN·프린터·NAS·회의실 장비처럼 로컬 주소로 접근하는 대상은 기존의 직접 연결 정책을 유지하는 것이 보통 안전합니다. 회의 앱을 모두 하나의 프록시 그룹으로 묶으면 관리가 단순해지는 장점이 있지만, 한 그룹의 노드가 혼잡할 때 세 서비스가 동시에 영향을 받습니다. Zoom과 Meet에서 안정적인 미디어 연결이 우선이라면 회의용 그룹을 별도로 두고, Slack은 업무 앱 그룹에 포함하는 식으로 분리할 수 있습니다. 다만 그룹을 너무 잘게 나누면 어느 정책이 적용되는지 파악하기 어려워지므로 실제 장애 패턴과 운영 필요에 맞춰 구성하세요.
정책 그룹을 만들 때는 노드가 단순히 웹 페이지를 여는지만 확인하지 말고 회의에 필요한 연결을 감당할 수 있는지 살펴보세요. 특정 프록시 노드나 전송 방식이 UDP를 지원하지 않거나 품질이 불안정하면, 웹 로그인은 성공해도 음성·영상 품질이 나쁠 수 있습니다. 클라이언트가 제공하는 TUN 또는 네트워크 모드의 동작과 노드 측 지원 여부를 함께 확인하고, 지원 여부가 불확실하다면 회의용 그룹에 해당 노드를 무조건 포함하지 않는 편이 좋습니다. 업무용 서비스의 정책이나 조직 보안 설정도 우선 확인해야 합니다.
적용 후 매칭 규칙과 회의 품질 확인하기
아래 순서로 한 번에 한 요소씩 변경하면 문제가 생겨도 되돌리기 쉽습니다. 변경 전에는 활성 프로필 이름, 현재 모드, TUN이나 시스템 프록시 사용 여부, 기존 연결 상태를 기록해 두세요. 설정을 백업해 두면 규칙 순서 오류나 YAML 파싱 오류가 발생했을 때 원래 상태로 돌아갈 수 있습니다.
- 현재 경로를 기록합니다. Clash 연결 로그를 열고 Zoom, Slack, Meet 중 하나만 실행합니다. 회의 참가, Slack 메시지 전송, Meet 채팅처럼 재현 가능한 동작을 각각 한 번씩 수행하고, 관련 호스트와 로그에 표시된 규칙·정책 그룹을 기록합니다.
- 서비스 규칙을 추가합니다. 사용자 규칙을 넣을 수 있는 프로필 영역에 확인된 도메인을 좁게 추가합니다. 규칙은 더 포괄적인 도메인·지역 규칙보다 앞에서 검사되도록 배치합니다. 편집기가 규칙을 저장했더라도 활성 프로필에 적용되지 않았다면 트래픽 경로는 바뀌지 않으므로, 프로필을 다시 확인하고 필요한 경우 코어를 재시작합니다.
- 규칙 매칭을 검증합니다. 앱을 완전히 종료했다가 다시 열어 새 연결을 발생시킵니다. 연결 로그에서 예상한 호스트가 예상 그룹을 통과하는지 확인합니다. 규칙에 넣은 호스트와 다른 호스트가 발견되면 그 호스트가 실제 서비스 동작과 연관되는지 확인한 다음에만 규칙을 보완하세요.
- 회의 기능을 시험합니다. 짧은 테스트 회의에서 입장, 양방향 음성, 카메라 영상, 화면 공유를 차례로 점검합니다. Slack은 메시지 송수신과 파일 전송을 따로 시험하고, Meet는 회의 참여와 화면 공유를 확인합니다. 웹 브라우저와 데스크톱 앱을 모두 쓴다면 두 경로를 각각 확인합니다.
- 문제가 있으면 한 단계 되돌립니다. 연결이 되지 않으면 방금 추가한 규칙을 임시로 비활성화해 기존 동작과 비교합니다. 규칙 적용 전후의 로그, 시간대, 사용한 앱 버전, 네트워크 종류를 함께 기록하면 DNS 문제인지 그룹 선택 문제인지 구분하는 데 도움이 됩니다.
테스트 결과는 단순히 “회의가 열렸다”에서 끝내지 말고 기능별로 기록하세요. 예를 들어 로그인은 성공하지만 화면 공유만 멈춘다면, 인증 호스트 규칙을 더 넓히기보다 미디어 연결의 경로와 노드의 전송 지원을 확인해야 합니다. 반대로 앱 실행 직후 로그인이나 메시지 목록이 실패하고 관련 호스트가 DIRECT로 표시된다면 규칙 순서, 호스트 이름, 활성 프로필을 먼저 살펴보세요. 같은 증상이라도 로그에 나타나는 규칙과 연결 상태에 따라 해결 방향은 달라집니다.
회사 VPN이나 보안 에이전트가 함께 실행 중이라면 Clash 설정만으로 결론을 내리지 마세요. 기업용 VPN이 기본 경로와 DNS를 바꾸거나, 조직 정책이 특정 외부 프록시 사용을 제한할 수 있습니다. 업무 기기에서는 회사 IT 정책을 우선 확인하고, 허가되지 않은 방식으로 트래픽을 우회하지 않아야 합니다. 개인 네트워크와 회사 네트워크에서 결과가 다르면 네트워크를 바꿔 재현해 보고, 어떤 환경에서만 문제가 생기는지 분리해 기록하는 것이 유용합니다.
모든 트래픽을 글로벌 프록시로 보내면 처음에는 규칙을 작성할 필요가 없어 편해 보이지만, 국내 업무 서비스나 사내 자원까지 불필요하게 우회해 지연과 접근 오류가 생길 수 있습니다. 반대로 일부 앱의 내장 프록시 기능은 브라우저와 데스크톱 앱, 미디어 연결의 경로를 한곳에서 추적하기 어렵습니다. Clash는 서비스별 규칙과 정책 그룹을 조합하고 연결 로그에서 실제 매칭을 확인할 수 있어, 회의 앱과 일반 업무 트래픽을 분리해 관리하기 좋습니다. 여러 클라이언트와 설정을 비교하고 있다면 사용 중인 플랫폼에 맞는 Clash 다운로드 경로를 확인해 보세요.