재택근무 Zoom·Slack 연결 개선하는 Clash 분할 프록시 설정법

전체 프록시 대신 업무 앱만 분리 라우팅하기

재택근무 중 Zoom이나 Slack 연결만 프록시를 사용하고 나머지 웹사이트와 로컬 네트워크는 기존 경로로 유지하려면, Clash의 rule 모드에서 서비스 도메인에 해당하는 규칙을 추가하는 방법이 적합합니다. 전체 트래픽을 한 경로로 보내는 전역 모드와 달리, 규칙 모드는 연결 정보를 위에서부터 확인해 처음 일치하는 규칙이 지정한 정책으로 전달합니다.

여기서 먼저 구분해야 할 것은 트래픽을 Clash로 가져오는 방식과 가져온 연결의 출구를 결정하는 방식입니다. 시스템 프록시는 운영체제 프록시 설정을 따르는 앱의 연결을 전달하고, TUN은 운영체제의 라우팅과 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 전달할 수 있습니다. 그다음 규칙이 해당 연결을 프록시 그룹 또는 DIRECT로 보냅니다. 따라서 Zoom 규칙을 써도 Zoom 트래픽이 Clash에 들어오지 않는다면 그 규칙은 적용되지 않습니다.

업무 앱	시작할 규칙 범위	주의할 점
Zoom	`zoom.us`, `zoom.com` 계열 도메인	회의 미디어 연결은 UDP를 사용할 수 있습니다. 규칙만으로 UDP 지원이 보장되지는 않습니다.
Slack	`slack.com` 및 실제 연결 기록에서 확인한 관련 도메인	메시지, 파일, 알림 등 기능에 따라 연결 대상이 다를 수 있습니다.
Google Meet	`meet.google.com`에서 시작해 필요한 대상만 추가	`google.com`이나 `googleapis.com` 전체를 지정하면 다른 Google 서비스까지 포함될 수 있습니다.

프록시 그룹을 확인하고 도메인 규칙 추가하기

규칙이 참조하는 정책 이름은 현재 설정의 proxy-groups에 등록되어 있어야 하며, 대소문자와 띄어쓰기를 포함해 정확히 일치해야 합니다. 아래에서는 기존 설정에 업무 프록시라는 그룹이 있다고 가정합니다. 실제 설정에 그런 그룹이 없다면 사용 중인 노드 선택 그룹 이름으로 바꾸세요. 구독에서 내려받은 원본 파일을 직접 수정하면 업데이트 때 변경 내용이 사라질 수 있으므로, 클라이언트에서 제공하는 오버라이드나 병합 기능을 우선 이용합니다.

mode: rule

rules:
  - DOMAIN-SUFFIX,zoom.us,업무 프록시
  - DOMAIN-SUFFIX,zoom.com,업무 프록시
  - DOMAIN-SUFFIX,slack.com,업무 프록시
  - DOMAIN,meet.google.com,업무 프록시
  - MATCH,기존 기본 정책

이 코드는 기존 설정에 병합하는 규칙 예시이며 완성된 구독 파일이 아닙니다. 기존 기본 정책은 실제 설정에서 마지막에 사용하는 정책 이름으로 바꿔야 합니다. 이미 MATCH 규칙이 있다면 새 규칙을 그 앞에 넣으세요. MATCH가 먼저 있으면 뒤의 Zoom·Slack·Meet 규칙은 검사되지 않습니다. 기존에 로컬 주소나 회사 내부 서비스에 대한 예외 규칙이 있다면 함께 보존해야 합니다.

DOMAIN-SUFFIX,zoom.us는 zoom.us와 그 하위 도메인에 적용됩니다. zoom.com도 별도 규칙으로 넣어야 해당 범위가 포함됩니다.
DOMAIN,meet.google.com은 해당 호스트 이름에만 적용하는 시작점입니다. Meet 연결 기록에서 다른 미디어 호스트가 확인되면 먼저 해당 연결이 회의에 필요한지 살펴본 다음 개별 규칙으로 추가하세요.
google.com이나 googleapis.com을 접미사 규칙으로 추가하면 Meet 외의 Google 서비스도 함께 매칭될 수 있습니다. 범위를 넓히기 전에 연결 기록을 확인하세요.
규칙은 프록시 서버를 만들거나 선택하지 않습니다. 업무 프록시 그룹 안에서 연결 가능한 노드가 선택되어 있어야 합니다.

규칙 모드와 정책 선택 확인

Clash Verge, Clash Verge Rev 등 GUI 클라이언트에서는 메뉴 이름이 다를 수 있지만, 모드 설정에서 규칙 모드를 선택하고 프록시 또는 정책 화면에서 참조한 그룹의 현재 선택값을 확인합니다. 규칙 모드인데도 업무 앱 연결이 직접 연결되는 경우, 먼저 실제 설정의 그룹 이름과 규칙 순서를 확인하세요. 그룹 자체가 DIRECT를 선택하고 있다면 규칙은 정상 매칭되어도 연결은 직접 나갈 수 있습니다.

직접 적용하기: 저장부터 회의 연결 확인까지

설정을 한 번에 크게 바꾸기보다 Zoom, Slack, Meet을 차례로 확인하면 어느 규칙이나 전송 경로에서 문제가 생겼는지 찾기 쉽습니다. 작업 전에 현재 설정을 백업하고, 규칙이 적용된 뒤에는 새 연결을 만들어 결과를 확인하세요. 이미 열려 있는 회의나 앱은 기존 연결을 계속 사용할 수 있습니다.

기존 설정을 보존합니다. 클라이언트의 설정 내보내기 기능을 이용하거나, 구독 설정과 로컬 오버라이드를 구분해 백업합니다. 구독 주소에는 인증 정보가 들어갈 수 있으므로 공개된 곳에 붙여 넣지 마세요.
업무용 정책 그룹을 확인합니다. 프록시 그룹에 연결 가능한 노드가 있는지 확인하고, 선택 후 노드 지연 검사 결과만으로 실제 회의 품질을 단정하지 않습니다. 노드가 연결되어도 UDP나 장시간 미디어 전송이 원활하다는 뜻은 아닙니다.
규칙을 기존 목록에 추가합니다. 서비스 도메인 규칙은 포괄적인 기본 규칙보다 앞에 두고, 마지막 MATCH 규칙은 유지합니다. 설정 검사에서 오류가 나오면 쉼표, 들여쓰기, 정책 이름을 확인합니다.
규칙 모드로 적용합니다. 클라이언트에서 수정된 설정을 현재 설정으로 선택하거나 업데이트한 뒤 코어를 다시 불러옵니다. 설정 목록에 파일이 보이는 것만으로 적용이 완료된 것은 아닙니다.
연결 기록에서 매칭을 확인합니다. Zoom 회의에 접속하거나 Slack에서 새 메시지를 보내고, 연결 기록에 표시된 도메인과 선택된 규칙·정책을 살펴봅니다. Meet은 실제 회의에 입장한 상태에서 오디오와 화면 공유를 각각 시험합니다.
필요한 연결만 추가합니다. 예상한 서비스 도메인이 아니라 다른 호스트가 기록에 나타나면 해당 연결의 프로세스, 도메인, 목적지와 사용 기능을 확인합니다. 관련성이 확인된 경우에만 구체적인 도메인 규칙을 추가하고 다시 검사합니다.

먼저 브라우저에서 Meet만 테스트하고 문제가 없으면 Zoom 데스크톱 앱도 별도로 확인하는 방식이 유용합니다. 브라우저와 데스크톱 앱은 서로 다른 프로세스와 네트워크 경로를 사용할 수 있습니다. 연결 기록에 업무 앱 트래픽이 아예 나타나지 않는다면 규칙을 더 추가하기 전에 시스템 프록시가 앱에 적용되는지 확인하세요. 앱이 시스템 프록시를 따르지 않는 경우 TUN이 필요할 수 있지만, 권한과 다른 VPN·가상 어댑터와의 충돌도 함께 고려해야 합니다.

회의 음성·영상과 DNS 문제를 따로 점검하기

화면은 열리는데 음성이 끊기거나 영상이 멈추는 경우에는 도메인 규칙만으로 진단이 끝나지 않습니다. 회의 미디어는 UDP를 사용할 수 있고, 앱이나 브라우저가 시스템 HTTP 프록시를 따르지 않는 UDP 연결은 시스템 프록시만 켠 상태에서 Clash로 전달되지 않을 수 있습니다. 이때 TUN 사용 여부, 앱 트래픽이 코어에 들어오는지, 선택한 프록시 노드가 UDP를 지원하는지를 각각 확인해야 합니다.

다음 표처럼 증상을 단계별로 나누면 전체 모드를 전역으로 바꾸거나 모든 Google 도메인을 프록시로 보내는 식의 큰 변경을 피할 수 있습니다.

증상	먼저 확인할 항목	다음 조치
앱은 열리지만 규칙 기록에 연결이 없음	시스템 프록시 적용 여부, 앱 자체 프록시 설정, TUN 상태	테스트 앱에서 새 연결을 만들고, 필요한 경우 트래픽 진입 방식을 검토합니다.
연결은 보이지만 직접 연결로 표시됨	규칙 순서, 실제 매칭 규칙, 도메인 범위	기본 규칙보다 앞에 정확한 서비스 규칙을 넣고 다시 확인합니다.
정책은 맞지만 회의 미디어가 불안정함	UDP가 Clash에 전달되는지, 선택한 노드의 UDP 지원 여부	TUN 경로와 노드 지원을 점검하고 다른 노드와 비교합니다.
로그인 또는 파일 로딩만 실패함	Slack 기능별 연결 도메인, DNS 응답, 앱과 브라우저의 차이	로그에서 실제 실패 호스트를 찾아 필요한 범위만 추가합니다.

광범위한 규칙과 DNS 변경은 마지막에

Google 서비스 전체를 프록시로 보내면 Meet 외의 검색, 문서, 동기화 연결까지 영향을 받을 수 있습니다. Slack도 메시지와 파일 전송 등 기능별 연결 대상이 다를 수 있으므로, 확인되지 않은 도메인을 한꺼번에 추가하는 방식은 권장하지 않습니다. 도메인 규칙이 실제로 매칭되지 않는다고 해서 곧바로 DNS 설정을 바꿀 필요도 없습니다. 먼저 앱 연결이 코어에 들어오는지와 연결 기록에 표시되는 도메인을 확인하고, DNS 문제라는 근거가 있을 때만 DNS 모드와 캐시를 점검하세요.

회의 전에는 규칙 모드가 활성화되어 있는지, 업무 프록시 그룹에서 의도한 노드가 선택되어 있는지, TUN을 사용한다면 권한과 인터페이스가 정상인지 확인합니다. 짧은 테스트 회의에서 음성·영상과 화면 공유를 각각 점검하고, 끝난 뒤 전체 프록시 모드로 임시 변경했다면 원래 설정으로 되돌리세요. 이 순서를 지키면 업무 앱만 분리 라우팅하면서 일반 웹과 사내 LAN 연결에 미치는 영향을 줄일 수 있습니다.