재택근무 Clash 설정법: Zoom·Slack·Meet 분할 라우팅 최적화

재택근무용 분할 라우팅의 목표부터 정하기

재택근무에서 Clash를 사용할 때 모든 트래픽을 프록시로 보내는 방식은 가장 간단하지만 항상 가장 좋은 방법은 아닙니다. Zoom 회의와 Google Meet 영상 통화, Slack 메시지와 파일 전송만 우회하고 국내 은행, 공공기관, 쇼핑몰, 사내 인트라넷은 직접 연결하면 지연 시간과 대역폭 사용량을 줄일 수 있습니다. 핵심은 애플리케이션 이름만 보고 판단하는 것이 아니라, 실제로 연결되는 도메인과 DNS 조회 경로, UDP 사용 여부를 함께 확인하는 것입니다.

Zoom과 Meet의 회의 품질은 단순한 다운로드 속도보다 패킷 손실, 지터, 왕복 지연 시간의 영향을 크게 받습니다. 반대로 Slack의 일반 메시지는 적은 대역폭만 사용하므로 반드시 TUN 전체 우회가 필요한 것은 아닙니다. 다만 Slack의 워크스페이스 접속, 파일 미리보기, 음성·영상 통화, 외부 연동 서비스는 서로 다른 도메인과 CDN을 사용할 수 있습니다. 따라서 처음부터 지나치게 넓은 규칙을 작성하기보다 업무에 필요한 기능을 확인하면서 범위를 단계적으로 넓히는 편이 안전합니다.

업무 서비스	우선 확인할 도메인	권장 정책	주의할 점
Zoom	`zoom.us`, `zoom.com` 및 회의 서버 도메인	업무용 프록시	회의 미디어는 UDP를 사용할 수 있음
Slack	`slack.com`, `slack-edge.com`, 워크스페이스 관련 주소	업무용 프록시	파일과 외부 앱은 별도 CDN을 사용할 수 있음
Google Meet	`meet.google.com`, `googleapis.com` 등	업무용 프록시	Google 공용 도메인을 전부 우회하면 범위가 지나치게 넓어짐
국내 일반 서비스	국내 도메인과 국내 IP	DIRECT	업무 예외 규칙을 국내 규칙보다 먼저 배치

정책 그룹과 모드 구성하기

먼저 업무 트래픽을 보낼 정책 그룹을 준비합니다. 구독에 이미 “노드 선택”이나 “자동 선택” 그룹이 있다면 새 노드를 복사하기보다 기존 그룹을 참조하는 것이 관리하기 쉽습니다. 예시에서는 실제 구독에 존재하는 노드 이름을 가정하지 않고, 사용자가 교체해야 하는 그룹 이름을 WORK-PROXY로 표시했습니다. 이 이름은 YAML의 proxy-groups에 실제로 존재해야 하며, 존재하지 않는 그룹을 규칙에서 호출하면 설정 검증이나 코어 시작에 실패할 수 있습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: WORK-PROXY
    type: select
    proxies:
      - 자동 선택
      - 노드 선택
      - DIRECT

위의 그룹 이름과 하위 정책 이름은 구독이 제공하는 실제 이름에 맞춰 바꿔야 합니다. 구독이 자동 선택 그룹을 제공하지 않는다면 지연 시간이 낮고 패킷 손실이 적은 노드를 직접 넣을 수 있습니다. 영상회의에는 단순히 핑이 가장 낮은 노드보다 안정적인 노드가 더 중요합니다. 60ms 노드에서 손실률이 3%라면 95ms이지만 손실이 없는 노드가 회의 음성과 화면 공유에 더 나은 경우가 많습니다.

모드는 rule로 설정합니다. Global 모드는 국내 서비스까지 전부 같은 정책으로 보내므로 이 글의 목적과 맞지 않고, Direct 모드는 업무 도메인 규칙을 적용하지 않습니다. FlClash에서는 설정을 적용한 뒤 모드 선택 메뉴에서 Rule을 확인하고, 시스템 프록시 또는 TUN을 필요한 범위에서만 활성화하세요. 브라우저와 Slack 데스크톱 앱처럼 시스템 프록시를 따르는 프로그램만 사용할 때는 먼저 시스템 프록시로 테스트하는 것이 좋습니다.

시스템 프록시와 TUN 중 무엇을 사용할까

시스템 프록시는 HTTP·HTTPS·SOCKS 프록시 설정을 읽는 애플리케이션에 적합합니다. 설정 화면에 표시된 로컬 포트가 7890이라고 해도 실제 포트는 현재 YAML의 mixed-port를 기준으로 확인해야 합니다. 일부 회의 프로그램은 시스템 프록시를 부분적으로만 사용하거나 회의 미디어 연결에 별도의 UDP 경로를 선택할 수 있습니다.

TUN은 시스템 프록시를 읽지 않는 프로그램의 트래픽까지 가상 네트워크 인터페이스를 통해 코어로 전달할 수 있습니다. Zoom 회의의 미디어가 규칙에 잡히지 않거나 Meet 브라우저 연결은 되지만 화면 공유가 불안정하다면 TUN을 시험할 수 있습니다. 다만 TUN을 켜면 DNS 하이재킹, 자동 라우팅, 운영체제 권한이 추가되므로 문제 발생 시 원인을 찾기 어려워집니다. 먼저 시스템 프록시에서 도메인 규칙을 검증한 뒤 TUN을 단계적으로 추가하세요.

실전 YAML 규칙 작성과 확인 순서

이제 실제로 업무용 도메인만 WORK-PROXY로 보내는 규칙을 작성합니다. 아래 예시는 mihomo 계열에서 사용하는 일반적인 도메인 규칙 형식입니다. 업무 서비스의 전체 도메인 목록은 조직의 보안 정책과 서비스 제공업체 문서를 기준으로 보완해야 하며, 예시 목록을 그대로 완전한 허용 목록으로 간주해서는 안 됩니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK-PROXY
  - DOMAIN-SUFFIX,zoom.com,WORK-PROXY
  - DOMAIN-SUFFIX,slack.com,WORK-PROXY
  - DOMAIN-SUFFIX,slack-edge.com,WORK-PROXY
  - DOMAIN,meet.google.com,WORK-PROXY
  - DOMAIN-SUFFIX,googleapis.com,WORK-PROXY
  - DOMAIN-SUFFIX,gstatic.com,WORK-PROXY
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

설정 백업: FlClash에서 현재 적용 중인 YAML 또는 오버라이드 내용을 먼저 복사합니다. 들여쓰기는 탭이 아닌 공백을 사용하고, 기존 rules를 통째로 덮어쓰지 않도록 병합 위치를 확인합니다.
정책 그룹 확인: WORK-PROXY가 실제 정책 그룹 이름과 일치하는지 확인합니다. 이름에 공백이나 특수문자가 있다면 YAML 문자열 처리와 실제 표시 이름을 그대로 맞춰야 합니다.
예외 규칙 추가: Zoom과 Slack 규칙을 국내 직접 연결 규칙보다 위에 배치합니다. Meet에 필요한 Google 도메인은 먼저 좁게 시작하고, 로그에서 추가 연결을 확인한 뒤 필요한 도메인만 추가합니다.
설정 검증: 클라이언트의 설정 검사 또는 코어 재시작 기능을 사용합니다. “proxy group not found”, YAML 구문 오류가 나타나면 규칙 이름, 콜론, 하이픈과 들여쓰기를 먼저 확인합니다.
기능별 테스트: 회의 입장, 음성 송수신, 카메라, 화면 공유, Slack 파일 업로드를 각각 실행합니다. 단순히 Zoom 홈페이지가 열리는 것만으로 회의 미디어가 같은 경로를 사용한다고 판단하면 안 됩니다.
로그 대조: 연결 로그에서 도메인, 매칭된 규칙, 선택된 정책 그룹을 확인합니다. 규칙에 잡히지 않는 호스트가 반복적으로 나타날 때만 해당 호스트의 성격을 확인한 뒤 추가합니다.

테스트 중에는 한 번에 하나의 요소만 바꾸세요. 먼저 DOMAIN-SUFFIX,zoom.us 규칙을 추가하고 회의 입장과 음성을 확인한 뒤 Slack, Meet 순서로 확대하면 어떤 규칙이 효과가 있었는지 추적할 수 있습니다. 수정 후에는 기존 연결이 캐시에 남아 있을 수 있으므로 Zoom과 Slack을 완전히 종료하고 다시 시작하세요. 브라우저는 탭만 닫는 것보다 새 시크릿 창이나 새 프로필로 테스트하는 편이 DNS와 로그인 세션의 영향을 줄이는 데 도움이 됩니다.

서비스 도메인을 너무 넓게 잡지 않는 방법

DOMAIN-SUFFIX,google.com,WORK-PROXY처럼 상위 도메인 전체를 우회하면 검색, 지도, 동기화와 일반 웹 콘텐츠까지 프록시로 전송될 수 있습니다. Meet의 접속이 성공했다는 이유만으로 Google 전체를 우회할 필요는 없습니다. 반대로 특정 워크스페이스의 Slack 파일이 열리지 않는다면 파일 호스트가 slack.com 외부에 있을 수 있으므로 로그에 표시된 실제 호스트를 확인해야 합니다.

DNS, UDP와 회의 안정성 점검하기

분할 라우팅에서 DNS는 규칙만큼 중요합니다. 도메인은 국내 DNS로 해석했지만 실제 연결은 프록시로 보내거나, 반대로 해외 업무 도메인을 국내 DNS가 잘못된 주소로 응답하면 연결이 느려지거나 실패할 수 있습니다. TUN을 사용하는 경우에는 FlClash와 mihomo의 DNS 설정, 운영체제 DNS, 공유기 DNS가 서로 충돌하지 않는지 확인하세요. 설정을 크게 바꿀 때는 먼저 현재 DNS 주소와 fake-ip 또는 redir-host 사용 여부를 기록하는 것이 좋습니다.

회의가 연결되지만 음성이 끊기거나 화면 공유가 멈춘다면 TCP 연결만 확인해서는 부족합니다. Zoom과 Meet은 환경에 따라 UDP 미디어를 사용할 수 있고, 회사 방화벽이나 공유기가 UDP를 제한하면 자동으로 TCP 또는 다른 경로로 전환할 수 있습니다. 이때 지연 시간이 증가하거나 영상 품질이 낮아질 수 있습니다. TUN을 켠 상태에서만 문제가 생긴다면 자동 라우팅, 엄격한 라우팅, DNS 하이재킹을 한 항목씩 바꾸며 비교하세요.

증상	우선 확인할 항목	권장 조치
Zoom 로그인은 되지만 회의 음성이 끊김	UDP 손실, 선택된 노드, TUN 라우팅	안정적인 노드로 변경하고 회의 미디어 로그 확인
Meet 화면은 열리지만 화면 공유 실패	추가 Google 호스트와 브라우저 권한	로그에서 실제 호스트를 확인하고 필요한 도메인만 추가
Slack 메시지는 되지만 파일이 열리지 않음	파일 CDN, DNS 응답, 정책 그룹 연결	파일 요청의 호스트를 확인한 뒤 해당 서비스 범위를 보완
국내 사이트까지 느려짐	Global 모드, 과도한 suffix, TUN 우회 범위	Rule 모드와 마지막 `MATCH,DIRECT`를 확인

회의 전에는 노드 지연 시간만 보지 말고 10분 이상 연결을 유지하면서 패킷 손실과 지터 변화를 관찰하세요. 회의 중 노드를 수동으로 자주 바꾸면 연결이 재수립되어 오히려 품질이 나빠질 수 있습니다. 업무용 정책 그룹에는 검증된 두세 개의 노드만 넣고, 자동 선택 기능을 사용할 때도 측정 URL과 테스트 주기를 지나치게 짧게 설정하지 않는 것이 좋습니다.

보안과 유지관리 체크리스트

재택근무용 설정에서는 allow-lan: false를 기본값으로 유지하는 편이 안전합니다. 같은 Wi-Fi의 다른 기기가 로컬 프록시 포트에 접근해야 하는 특별한 이유가 없다면 LAN 수신을 열지 마세요. 외부 제어 인터페이스를 활성화할 때도 external-controller: 127.0.0.1:9090처럼 로컬 주소에 바인딩하고, API 비밀번호에 해당하는 secret을 설정해야 합니다. 제어 포트와 mixed 포트는 서로 다른 용도이므로 브라우저 프록시 주소에 9090을 입력하면 안 됩니다.

업무용 규칙은 구독 업데이트 후에도 유지되는 오버라이드 또는 별도 설정 파일에 보관합니다.
Zoom·Slack·Meet의 실제 연결 호스트가 바뀌면 로그를 기준으로 규칙을 갱신합니다.
국내 서비스가 느려졌다면 먼저 Global 모드가 켜졌는지, 마지막 규칙이 MATCH,DIRECT인지 확인합니다.
회의 품질 문제를 노드 속도 하나로 판단하지 말고 손실률, 지터, UDP 상태를 함께 비교합니다.
구독 URL과 외부 제어 비밀키는 로그나 화면 공유에 노출하지 않습니다.
업데이트 전에는 현재 YAML과 정책 선택 상태를 백업해 문제가 생겼을 때 즉시 되돌릴 수 있게 합니다.

최종적으로 좋은 재택근무 설정은 모든 연결을 복잡한 규칙으로 감싸는 설정이 아니라, 필요한 업무 도메인만 명확히 우회하고 나머지는 예측 가능한 경로로 보내는 설정입니다. 시스템 프록시에서 먼저 규칙을 검증하고, 누락된 프로그램이 확인될 때만 TUN을 추가하세요. 이렇게 하면 회의 안정성을 확보하면서도 국내 일반 서비스의 불필요한 우회와 속도 저하를 줄일 수 있습니다.