분할 라우팅의 기준: 업무 도메인과 일반 트래픽 나누기
재택근무 중 Zoom 회의는 괜찮은데 Slack 파일이 늦게 열리거나, 반대로 업무 도구는 잘 되지만 일반 웹 탐색이 불필요하게 느려지는 경우가 있습니다. 규칙 모드에서는 Clash가 연결을 규칙 순서대로 검사하고, 먼저 일치한 규칙에 지정된 정책으로 보냅니다. Zoom·Slack·Google Meet 관련 도메인은 선택한 프록시 그룹으로 보내고, 나머지는 기존 기본 규칙에 맡기면 업무 트래픽과 일반 트래픽을 분리할 수 있습니다.
도메인 규칙은 특정 앱을 식별하는 기능이 아닙니다. 같은 도메인을 여러 앱이 함께 사용한다면 해당 도메인으로 가는 연결 전체가 같은 정책을 적용받습니다. 또 회의 연결은 신호 교환, 오디오·비디오 전송, 화면 공유에 서로 다른 도메인이나 IP를 사용할 수 있습니다. 따라서 도메인 목록을 한 번 넣는 것으로 모든 회의 트래픽이 반드시 같은 경로를 사용한다고 단정하지 말고, 실제 연결 기록을 함께 확인하세요.
서비스별 도메인 규칙과 노드 선택
아래는 업무 도구의 대표적인 도메인 접미사를 업무용 프록시 그룹으로 보내는 규칙 조각입니다. 현재 설정의 rules 안에 병합하고, 일반적으로 포괄적인 국가·IP 규칙이나 MATCH보다 앞에 배치하세요. 기존에 더 구체적인 규칙이 먼저 있다면 그 규칙도 검토해야 합니다. 규칙 파일 전체를 이 예시로 교체하지 말고 마지막 기본 규칙은 기존 설정대로 보존하세요.
rules:
- DOMAIN-SUFFIX,zoom.us,Work
- DOMAIN-SUFFIX,zoom.com,Work
- DOMAIN-SUFFIX,zoomcdn.net,Work
- DOMAIN-SUFFIX,slack.com,Work
- DOMAIN-SUFFIX,slack-edge.com,Work
- DOMAIN-SUFFIX,slack-files.com,Work
- DOMAIN-SUFFIX,slack-msgs.com,Work
- DOMAIN-SUFFIX,meet.google.com,Work
# 기존의 지역 규칙과 최종 MATCH 규칙을 이어서 유지서비스의 도메인과 연결 방식은 앱 버전, 계정, 회의 기능, 네트워크 환경에 따라 달라질 수 있습니다. Zoom의 zoom.us와 zoom.com, Slack의 파일·메시지 관련 도메인, Meet의 meet.google.com은 시작점으로 삼을 수 있지만 완전한 목록은 아닙니다. 연결 기록에서 회의 시간대에 반복적으로 나타나는 관련 도메인을 확인한 뒤 필요한 규칙만 추가하세요.
Google 서비스는 여러 제품이 도메인을 공유합니다. google.com, googleapis.com, gstatic.com을 통째로 프록시 그룹에 보내면 Meet뿐 아니라 검색, 문서, 계정 로그인 등 다른 Google 서비스의 연결도 함께 바뀔 수 있습니다. Meet에서 문제가 재현될 때만 로그를 확인해 좁은 범위의 규칙을 추가하고, 공유 도메인을 넣었을 때 달라지는 서비스 범위도 기록하세요.
| 업무 도구 | 우선 확인할 도메인 | 주의할 점 |
|---|---|---|
| Zoom | zoom.us, zoom.com, zoomcdn.net |
회의 미디어 연결이 로그에 보이는지 확인하고, 웹 로그인만으로 테스트를 끝내지 마세요. |
| Slack | slack.com, slack-edge.com, slack-files.com, slack-msgs.com |
메시지, 파일, 허들 연결이 서로 다른 도메인을 사용할 수 있습니다. |
| Google Meet | meet.google.com |
Google 공용 도메인은 다른 제품과 공유될 수 있으므로 무조건 추가하지 마세요. |
노드 선택은 단순한 지연 시간 숫자보다 회의 중의 안정성을 기준으로 하세요. 같은 노드에서 짧은 시간 동안 지연이 크게 흔들리거나 패킷 손실이 발생하면 음성 끊김, 화면 정지, 재접속이 생길 수 있습니다. 회의가 없는 시간에 표시되는 지연이 낮더라도 실제 업무 시간의 혼잡도와 UDP 처리 상태가 다를 수 있으므로, 후보 노드를 두세 개로 좁혀 같은 시간대에 시험하는 편이 유용합니다.
동작 절차: 설정을 적용하고 회의로 검증하기
- 기준 상태를 기록합니다. 사용 중인 클라이언트와 코어 이름·버전, 운영체제, 현재 모드, 선택한 노드, TUN 활성화 여부를 적어 둡니다. 한 번에 여러 설정을 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다.
- 업무용 그룹을 확인합니다. 기존
proxy-groups에서 선택 가능한 노드 그룹 이름을 확인합니다. 이름이Work가 아니라면 예시 규칙의 그룹명을 실제 이름으로 바꾸고, 그룹에서 회의에 쓸 노드를 선택합니다. - 규칙을 병합합니다. 업무 도메인 규칙을 기존
rules에 추가해 일반적인 포괄 규칙보다 앞에 둡니다. 같은 도메인을 앞선 규칙이 다른 그룹이나DIRECT로 보내고 있는지 검색하세요. YAML의 들여쓰기와 쉼표 구분도 확인합니다. - 설정을 적용하고 문법을 검사합니다. 클라이언트에서 설정을 저장한 뒤 다시 로드하거나 검증 기능을 실행합니다. 파싱 오류가 나면 오류 줄뿐 아니라 바로 위 항목의 들여쓰기, 콜론, 목록 기호를 살펴보세요. 시작 로그에 설정 오류가 없는지도 확인합니다.
- 로그에서 실제 경로를 확인합니다. Zoom 회의나 Slack 허들을 시작하고 연결 기록에서 도메인, 매칭된 규칙, 사용된 정책 그룹을 확인합니다. 기대한 규칙이 아니라면 더 앞선 규칙과 실제 도메인을 비교한 뒤 필요한 항목만 보완합니다.
- 회의 품질을 비교합니다. 같은 회의 환경에서 노드를 바꿔 음성 끊김, 영상 정지, 화면 공유 지연, 재접속 여부를 기록합니다. 테스트 후 브라우저나 앱을 재시작해야 새 연결에 변경 경로가 적용되는 경우도 있습니다.
시스템 프록시만 사용하는 환경에서는 해당 프록시 설정을 따르지 않는 앱이나 UDP 기반 미디어 연결이 코어를 거치지 않을 수 있습니다. 이때 도메인 규칙이 올바르더라도 회의 미디어가 예상한 경로를 따르지 않을 수 있습니다. TUN은 앱의 IP 트래픽을 가상 인터페이스로 받아 처리하는 데 도움이 될 수 있지만, 권한, 라우팅 제외, 다른 VPN, 방화벽, 클라이언트 구현의 영향을 받습니다. TUN을 켜기 전에는 운영체제에서 권한을 허용하고, 다른 VPN과 동시에 실행하지 않은 상태에서 작은 범위로 확인하세요.
회의 품질 문제를 구분하고 설정 되돌리기
규칙을 추가한 뒤에도 회의가 불안정하다면 DNS 문제, 노드 상태, 트래픽 수집 방식, 규칙 우선순위를 따로 점검합니다. 웹사이트가 열리는 것만으로 음성·영상 연결이 정상이라는 뜻은 아닙니다. 브라우저 로그인, 앱 연결, 실제 회의 참여를 각각 확인하고, 문제가 발생한 시각의 연결 로그를 보관하면 원인을 좁히기 쉽습니다.
- 규칙 로그에 업무 도메인이 나타나지 않음: 앱이 다른 도메인을 사용했거나 연결이 코어로 들어오지 않았을 수 있습니다. 연결 기록을 켜고 실제 접속 도메인을 확인하세요.
- 규칙은 일치하지만 회의가 끊김: 다른 노드를 시험하고, 같은 네트워크에서 프록시를 끈 상태와 비교하세요. UDP 미디어가 처리되는지와 TUN·방화벽 상태도 점검합니다.
- 앱 로그인은 되지만 파일·화면 공유가 실패함: 기능별 연결 도메인이 다를 수 있습니다. 로그에서 해당 기능을 실행한 시점의 연결을 찾아 공유 도메인을 무작정 추가하지 말고 필요한 범위만 반영하세요.
- 일반 인터넷까지 느려짐: 업무 규칙이 너무 넓은 도메인을 대상으로 하는지 확인합니다.
google.com같은 공유 범위 규칙을 추가했다면 제거 전후로 업무 앱과 일반 사이트를 각각 시험하세요. - 구독 갱신 후 설정이 사라짐: 원본 구독 파일이 덮어써졌는지 확인하고 클라이언트의 오버라이드·병합 방식으로 규칙을 다시 적용합니다. 같은 규칙을 여러 번 중복 삽입하지 마세요.
변경 전의 설정을 별도 파일로 보관하면 문제가 생겼을 때 빠르게 되돌릴 수 있습니다. 하나의 규칙을 추가한 뒤 결과를 확인하고, 다음 규칙으로 넘어가는 방식이 안전합니다. 특히 업무용 프록시 그룹을 DIRECT로 바꾸거나 기본 정책을 수정하면 업무 도구뿐 아니라 일반 트래픽도 함께 달라질 수 있으므로, 수정 범위를 명확히 기록하세요.
분할 라우팅은 모든 연결을 무조건 빠르게 만드는 기능이 아니라, 정한 기준에 따라 트래픽의 경로를 나누는 설정입니다. 도메인 규칙, 실제 트래픽 수집 방식, 안정적인 노드를 함께 점검하고 업무 도구별로 결과를 검증하면 예상하지 못한 전체 트래픽 변경을 줄이면서 회의 환경을 조정할 수 있습니다.