재택근무에서 모든 트래픽을 프록시로 보내면 생기는 문제
재택근무 환경에서 Zoom, Slack, Google Meet를 사용하다 보면 “화상회의만 안정적으로 연결하고 나머지 웹사이트는 평소처럼 직접 접속하고 싶다”는 요구가 생깁니다. 이때 Clash를 켜고 모든 트래픽을 하나의 프록시 노드로 보내면 처음에는 간단해 보이지만, 실제 업무에서는 여러 문제가 나타날 수 있습니다. 국내 웹사이트와 사내 시스템까지 먼 해외 노드를 거치면서 페이지 응답이 느려지고, 대용량 파일 업로드가 불필요하게 우회되며, 화상회의와 일반 다운로드가 같은 대역폭을 놓고 경쟁하게 됩니다.
특히 영상회의는 단순한 다운로드 속도보다 지연 시간, 지터, 패킷 손실, 업로드 경로의 안정성이 중요합니다. 웹 브라우징이 빠르다고 해서 회의 품질도 반드시 좋은 것은 아닙니다. 반대로 회의 서버에만 적절한 노드를 사용하고 뉴스, 검색, 국내 클라우드 서비스는 DIRECT로 남겨 두면 전체 체감 속도와 회의 안정성을 함께 개선할 수 있습니다. 핵심은 “프록시를 켤 것인가”가 아니라 “어떤 업무 트래픽을 어떤 정책 그룹으로 보낼 것인가”입니다.
먼저 Clash의 연결 로그에서 실제 접속 호스트를 확인해야 합니다. Zoom이나 Meet의 모든 서버 주소를 처음부터 완벽하게 추측하려고 하면 서비스 업데이트 때마다 규칙이 흔들릴 수 있습니다. 회의에 입장한 뒤 로그를 열고 zoom, slack, google, meet 같은 문자열을 검색하세요. 같은 서비스라도 로그인, 채팅, 파일 공유, 영상 미디어가 서로 다른 CDN이나 하위 도메인을 사용할 수 있으므로 관측한 결과를 기준으로 범위를 조금씩 넓히는 방식이 안전합니다.
Zoom·Slack·Google Meet를 업무 단위로 묶기
재택근무용 프로필은 서비스 이름만 나열하는 것보다 업무 흐름을 기준으로 설계하는 편이 관리하기 쉽습니다. 예를 들어 Zoom은 회의 참가와 음성·영상 스트림이 중심이고, Slack은 메시지·파일·알림·허들 기능이 함께 움직입니다. Google Meet는 Google 계정 인증, 회의 화면, 미디어 전송이 여러 호스트로 나뉠 수 있습니다. 따라서 세 서비스를 한 줄의 무조건적인 도메인 규칙으로 처리하기보다, 먼저 서비스별 정책 그룹을 만들고 실제 로그에 나타난 호스트를 연결하세요.
| 업무 트래픽 | 우선 확인할 항목 | 권장 정책 | 주의할 점 |
|---|---|---|---|
| Zoom 회의 | 로그인, 회의 연결, 음성·영상 스트림 | 안정적인 수동 선택 그룹 | 지연 시간보다 끊김과 업로드 안정성을 우선 |
| Slack | 메시지, 파일, 알림, 허들 | Zoom과 같은 업무용 그룹 또는 별도 그룹 | 파일 CDN이 별도 호스트인지 로그로 확인 |
| Google Meet | Google 계정, 회의 페이지, 미디어 연결 | Google 관련 규칙과 회의용 그룹 조합 | Google 전체 도메인을 넓게 프록시하지 않기 |
| 일반 국내 웹 | 은행, 공공기관, 국내 검색·쇼핑 | DIRECT |
사내 보안 정책과 DNS 예외를 별도로 확인 |
정책 그룹은 보통 select 또는 url-test에서 시작하면 됩니다. select는 사용자가 회의 전에 직접 노드를 고를 수 있어 예측 가능성이 높고, 장시간 회의 중 자동으로 출구가 바뀌는 위험이 적습니다. url-test는 여러 노드의 측정 결과를 참고해 빠른 노드를 고르지만, 측정용 URL의 응답 속도와 실제 회의 품질이 항상 일치하지는 않습니다. 회의 중 세션이 끊기지 않는 것이 중요하다면 자동 선택보다 안정적인 노드를 직접 고정하는 편이 낫습니다.
Slack은 텍스트 메시지만 사용할 때와 파일 업로드, 화면 공유, 허들까지 사용할 때 필요한 경로가 달라질 수 있습니다. 모든 Slack 관련 호스트를 넓게 묶으면 편하지만, 회사 내부 Slack 앱이나 사내 파일 링크까지 예상하지 못한 경로로 나갈 수 있습니다. 처음에는 앱을 실행한 직후 로그를 확인하고, 필요한 호스트만 DOMAIN-SUFFIX 또는 정확한 DOMAIN 규칙으로 추가하세요. 규칙을 추가할 때는 날짜와 확인한 기능을 주석으로 남겨 두면 나중에 구독 갱신이나 서비스 변경 때 정리하기 쉽습니다.
Clash에서 업무용 분리 라우팅을 직접 설정하는 순서
아래 절차는 Clash Verge, Clash Verge Rev, Mihomo 계열 클라이언트에서 YAML 프로필을 편집할 때 적용할 수 있는 일반적인 흐름입니다. 메뉴 이름은 클라이언트마다 다르지만, 핵심 구조는 정책 그룹을 만들고, 서비스 규칙을 위에서부터 배치한 다음, 마지막에 기본 규칙을 두는 것입니다. 원격 구독이 갱신될 때 로컬 수정이 사라지는 클라이언트도 있으므로, 가능하면 오버라이드나 로컬 패치 기능을 사용하세요.
- 현재 프로필을 백업합니다. 먼저 활성 YAML을 복사해 별도 파일로 저장합니다. 잘못된 들여쓰기나 지원하지 않는 필드 때문에 코어가 프로필을 거부할 수 있으므로, 한 번에 많은 줄을 바꾸지 않는 것이 좋습니다.
-
업무용 정책 그룹을 확인합니다. 기존에 있는 프록시 그룹 중 안정적인 노드를 선택할 수 있는 그룹을 찾거나, 회의 전용 그룹을 새로 만듭니다. 그룹 이름은
WORK-MEETING처럼 다른 구독 항목과 겹치지 않게 지정하세요. -
서비스 규칙을 추가합니다. 로그에서 확인한 Zoom, Slack, Meet 관련 도메인을 업무용 그룹으로 보냅니다. 규칙은 일반적인 규칙보다 위에 있어야 하며, 이미 앞에서
DIRECT또는 다른 그룹으로 잡히는 항목이 없는지 확인합니다. - 프로필을 저장하고 코어를 다시 불러옵니다. 오류가 없다면 Clash의 연결 모드와 활성 프로필을 확인합니다. 시스템 프록시만 사용하는지, TUN 모드까지 사용하는지에 따라 앱이 규칙을 통과하는 방식이 달라질 수 있습니다.
- 회의 테스트를 진행합니다. 먼저 카메라를 켜지 않은 상태로 회의에 입장하고 로그에서 정책명을 확인합니다. 이후 마이크, 카메라, 화면 공유를 차례로 켜면서 정책이 바뀌거나 새로운 호스트가 나타나는지 관찰하세요.
예시 구조는 다음과 같은 개념으로 이해하면 됩니다. 실제 도메인과 그룹 이름은 사용하는 프로필에 맞춰 바꾸어야 하며, 아래 예시를 그대로 넓은 규칙으로 복사하는 것은 권장하지 않습니다.
proxy-groups:
- name: WORK-MEETING
type: select
proxies:
- Stable-Node
- DIRECT
rules:
- DOMAIN-SUFFIX,zoom.us,WORK-MEETING
- DOMAIN-SUFFIX,slack.com,WORK-MEETING
- DOMAIN-SUFFIX,meet.google.com,WORK-MEETING
- MATCH,DIRECT
여기서 가장 중요한 부분은 WORK-MEETING에 어떤 노드를 넣는가입니다. 회의 전용 노드는 단순히 핑이 가장 낮은 노드보다, 일정 시간 동안 연결이 유지되고 업로드가 안정적인 노드가 적합합니다. 여러 노드를 넣어 두되 회의 시작 전에 한 번 선택하고, 통화 중에는 자동 전환을 피하는 운영 방식이 실용적입니다. 반대로 짧은 메시지와 알림만 사용하는 Slack은 자동 선택 그룹에 넣어도 문제가 적을 수 있습니다.
규칙 순서와 DNS 모드 점검
Clash는 위에서부터 먼저 일치하는 규칙을 적용합니다. 따라서 광범위한 GEOIP,CN,DIRECT나 특정 서비스 전체를 포괄하는 규칙이 Zoom·Slack·Meet 규칙보다 앞에 있으면, 뒤에 추가한 업무 규칙이 실행되지 않습니다. 연결 로그에서 서비스 요청의 최종策略과 규칙 이름을 확인하고, 예상과 다른 정책이 표시되면 노드보다 규칙 순서를 먼저 수정하세요.
DNS도 자주 놓치는 부분입니다. 도메인 규칙은 이름을 기준으로 판단하지만, DNS 설정이 다른 터널이나 운영체제 캐시와 섞이면 접속 위치와 응답 시간이 달라질 수 있습니다. Fake-IP와 Redir-Host의 동작 차이를 이해하지 못한 상태에서 DNS 옵션을 여러 개 바꾸면 원인을 찾기 더 어려워집니다. 회의 품질이 갑자기 나빠졌다면 먼저 한 가지 DNS 모드로 고정하고, Clash 로그와 시스템 네트워크 상태를 함께 비교하세요.
회의 품질을 측정하고 문제를 분리하는 방법
“화면이 끊긴다”는 표현만으로는 프록시 문제인지 Wi-Fi 문제인지 판단하기 어렵습니다. 회의 전후로 세 가지를 나누어 기록하세요. 첫째는 회의 입장과 로그인에 걸리는 시간, 둘째는 음성 지연과 화면 멈춤이 발생한 시점, 셋째는 같은 시간에 다른 웹사이트와 파일 업로드가 정상인지입니다. 다른 웹사이트도 모두 느리다면 노드보다 회선이나 공유기 문제일 가능성이 높고, 회의만 끊긴다면 서비스 규칙과 노드 경로를 우선 확인할 수 있습니다.
노드를 바꿀 때도 한 번에 여러 조건을 바꾸지 마세요. 같은 회의방에서 노드만 변경하고, 동일한 시간 동안 카메라 해상도와 화면 공유 조건을 유지해야 비교가 가능합니다. 핑 수치가 낮아도 해외 구간의 업로드가 불안정하면 상대방에게는 내 음성이 끊기는 것처럼 들릴 수 있습니다. 반대로 다운로드가 조금 느린 노드라도 지터가 낮고 장시간 연결이 유지되면 회의에는 더 적합할 수 있습니다.
- 입장은 되지만 영상만 멈춤: 미디어 CDN이나 UDP 관련 경로가 별도인지 확인합니다.
- Slack 메시지는 되지만 파일이 실패함: 파일 저장소와 CDN 호스트가 다른지 연결 로그를 확인합니다.
- Meet 로그인만 반복됨: Google 계정 인증 호스트와 회의 호스트가 서로 다른 정책을 받지 않는지 봅니다.
- 회의 중 갑자기 끊김: 자동 노드 전환, 노드의 연결 제한, Wi-Fi 절전 모드를 함께 점검합니다.
- 국내 사이트까지 느려짐: 업무 규칙보다 앞선 전체 프록시 모드나 TUN 라우팅 설정을 확인합니다.
화면 공유를 자주 한다면 업로드 대역폭을 별도로 살펴보세요. 가족 구성원이 같은 시간에 클라우드 동기화나 대용량 업로드를 실행하면 Clash 규칙이 정확해도 회의 품질은 떨어집니다. 이 경우 회의 앱만 프록시로 보내는 것과 함께 공유기의 트래픽 우선순위, 노트북의 백그라운드 동기화, 카메라 해상도도 조정해야 합니다. 기술적인 라우팅은 네트워크 전체의 병목을 없애는 것이 아니라, 중요한 트래픽이 불필요한 경로를 거치지 않도록 정리하는 작업에 가깝습니다.
마지막으로 설정을 오래 유지하려면 회의용 그룹과 일반 프록시 그룹의 역할을 분리하고, 실제로 사용하지 않는 도메인 규칙은 주기적으로 삭제하세요. Clash for Windows의 오래된 빌드는 최신 Mihomo 규칙이나 TUN 동작을 충분히 지원하지 않을 수 있고, 일부 단순 VPN 앱은 서비스별 분리 라우팅이나 세밀한 규칙 확인 기능이 부족합니다. 반면 Clash V.CORE는 업무 서비스별 정책 그룹, 연결 로그 확인, 노드 선택과 직접 연결을 한 흐름에서 조정할 수 있어 Zoom·Slack·Meet를 분리해 관리하기 좋습니다. 재택근무 환경에 맞는 세밀한 라우팅을 바로 시험해 보고 싶다면 Clash V.CORE 다운로드에서 시작해 보세요.