재택근무용 Clash 설정법: Zoom·Slack·Meet 연결 최적화

재택근무 설정의 목표: 업무 트래픽만 안정적으로 우회하기

재택근무 환경에서 Clash를 전역 프록시로 사용하면 Zoom 회의, Slack 메시지, Google Meet 접속은 쉽게 우회할 수 있지만, 국내 웹사이트와 사내 서비스까지 모두 프록시를 거치게 됩니다. 이 방식은 노드 대역폭을 빠르게 소모하고 지연을 키우며, 프린터·NAS·공유기 관리 페이지처럼 같은 집 네트워크에 있는 장치와의 연결도 방해할 수 있습니다. 따라서 업무용 설정은 “전부 우회”보다 “필요한 도메인과 트래픽만 우회”하는 분할 라우팅이 적합합니다.

기본 방향은 세 가지입니다. 첫째, 사설 네트워크와 국내 일반 트래픽은 DIRECT로 보냅니다. 둘째, Zoom·Slack·Meet처럼 해외 인프라를 사용하거나 직접 연결이 불안정한 업무 서비스는 프록시 정책 그룹으로 보냅니다. 셋째, 목록에 없는 나머지 트래픽은 사용 환경에 따라 직결 또는 프록시 중 하나를 기본값으로 정합니다. 국내 인터넷 사용이 많은 환경이라면 국내 직결을 기본값으로 두고 업무 도메인만 프록시로 보내는 편이 관리하기 쉽습니다.

먼저 확인할 항목: mihomo 커널, 정책 그룹, TUN

Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android는 화면을 제공하는 클라이언트이며 실제 규칙 처리와 DNS, TUN 동작은 내장된 커널이 담당합니다. 2026년 기준으로 업무용 분할 라우팅에는 Clash Meta 계열인 mihomo 커널이 편리합니다. GEOSITE, RULE-SET, 프로세스 매칭, TUN의 DNS 가로채기 같은 기능을 사용할 수 있기 때문입니다. 클라이언트의 정보 또는 코어 메뉴에서 커널 이름을 확인하고, 원조 Clash 커널이라면 mihomo 전용 옵션이 적용되지 않을 수 있다는 점을 기억해야 합니다.

정책 그룹은 실제 출구를 결정합니다. 아래 예시의 WORK는 직접 노드를 적는 이름이 아니라 사용자가 선택할 수 있는 선택형 그룹입니다. 노드 이름은 구독마다 다르므로 실제 구성에서는 현재 구독에 존재하는 이름으로 바꿔야 합니다.

proxy-groups:
  - name: WORK
    type: select
    proxies:
      - "업무용 노드"
      - "자동 선택"
      - DIRECT

  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - "노드 A"
      - "노드 B"

select 그룹은 사용자가 노드를 직접 고르는 방식이라 회의 중 경로를 예측하기 쉽습니다. url-test는 지정한 테스트 주소와 측정 방식에 따라 지연이 낮은 노드를 선택하지만, 웹페이지 지연과 화상회의 품질이 항상 일치하지는 않습니다. 회의가 중요한 날에는 자동 선택 결과를 그대로 믿기보다 미리 Zoom 또는 Meet 테스트 회의를 열어 음성 지연, 화면 공유, 패킷 손실을 확인하는 편이 안전합니다.

브라우저뿐 아니라 데스크톱 앱까지 동일한 규칙으로 처리하려면 TUN 모드가 유리합니다. 시스템 프록시만 켜면 HTTP·HTTPS 프록시를 따르는 앱만 Clash에 들어오고, 일부 앱의 자체 네트워크 연결이나 UDP 미디어 트래픽은 빠져나갈 수 있습니다. TUN을 켤 때는 관리자 권한, VPN 권한, 시스템 확장 허용 여부가 필요하며 기존 VPN이나 다른 가상 네트워크 도구와 동시에 사용하지 않는 것이 좋습니다.

실전 설정 순서: 업무 도메인과 국내 트래픽 나누기

이제 실제로 설정을 적용해보겠습니다. 메뉴 이름은 클라이언트마다 다르지만, 프로파일 편집기에서 YAML을 직접 수정하거나 규칙 제공자와 추가 규칙 입력란을 이용하면 됩니다. 기존 구성을 통째로 덮어쓰기보다 먼저 복사본을 만든 뒤 변경하세요. 들여쓰기 오류가 있으면 프로파일을 불러오지 못할 수 있으므로 YAML에서는 탭 대신 공백을 사용합니다.

1. Clash의 프로파일 또는 설정 페이지에서 현재 사용 중인 구성을 백업합니다. 노드와 구독 주소는 그대로 보관하되, 구독 URL이 화면에 노출된 캡처를 공유하지 않습니다.
2. 업무용 정책 그룹을 확인합니다. 이름이 WORK가 아니라면 아래 규칙에서 실제 그룹 이름을 사용하고, 회의 전에 연결할 노드를 하나 선택합니다.
3. mihomo 커널이라면 DNS와 TUN을 먼저 점검합니다. 시스템 프록시만으로 앱을 처리할 때는 일부 UDP 연결이 규칙에서 빠질 수 있으므로, 데스크톱 회의 앱은 TUN을 켠 상태에서 테스트합니다.
4. 업무 도메인 규칙을 국내 직결 규칙보다 위쪽에 넣습니다. 마지막에는 기본 규칙을 배치해 목록에 없는 요청이 어디로 갈지 명확하게 합니다.
5. Clash 로그를 열어 Zoom, Slack, Meet를 각각 실행합니다. 실제로 어떤 호스트가 WORK로 매칭되는지 확인한 뒤, 누락된 도메인만 추가합니다.
6. 회의 테스트에서 음성, 카메라, 화면 공유, 채팅, 파일 전송을 각각 확인합니다. 한 기능만 정상이라고 전체 업무 경로가 정상인 것은 아닙니다.

다음은 대표 도메인을 기준으로 작성한 출발점입니다. 서비스의 서버 구성은 변경될 수 있으므로 이 목록을 완성된 공식 목록으로 간주하지 말고 로그와 함께 사용하세요.

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK
  - DOMAIN-SUFFIX,zoom.com,WORK
  - DOMAIN-SUFFIX,zoomgov.com,WORK
  - DOMAIN-SUFFIX,slack.com,WORK
  - DOMAIN-SUFFIX,slack-edge.com,WORK
  - DOMAIN-SUFFIX,slack-msgs.com,WORK
  - DOMAIN-SUFFIX,google.com,WORK
  - DOMAIN-SUFFIX,googleapis.com,WORK
  - DOMAIN-SUFFIX,gstatic.com,WORK
  - DOMAIN-SUFFIX,meet.google.com,WORK

  - GEOSITE,private,DIRECT
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

위 예시에서 Google 전체 도메인을 모두 우회하는 것이 부담스럽다면 google.com, googleapis.com, gstatic.com을 무조건 추가하기 전에 로그를 확인하세요. Google Workspace를 함께 사용하는 조직에서는 Gmail, Drive, 문서 편집기, 인증 서버가 별도 호스트를 사용하므로 일부만 우회하면 로그인은 되지만 문서 저장이나 화면 공유가 실패할 수 있습니다. 반대로 개인적인 Google 검색까지 모두 프록시로 보낼 필요가 없다면 업무 전용 브라우저나 프로세스 규칙으로 범위를 좁히는 방법도 있습니다.

규칙 순서도 중요합니다. Clash는 위에서 아래로 검사하다가 처음 매칭된 규칙에서 멈춥니다. 예를 들어 GEOSITE,cn,DIRECT를 Zoom 규칙보다 위에 두면 어떤 관련 호스트가 국내 분류에 포함되는 순간 직결될 수 있습니다. 업무 도메인을 먼저 배치하고, 그 아래에 사설망과 국내 일반 규칙을 배치하는 것이 기본 원칙입니다. 다만 로컬 장치 접근을 확실히 보장해야 하는 환경에서는 사설망 규칙을 최상단에 두어야 합니다.

DNS와 화상회의 호환성 조정

도메인 분할 라우팅은 DNS 결과와 밀접하게 연결됩니다. mihomo의 fake-ip 모드에서는 애플리케이션에 198.18.0.0/16 대역의 가상 주소를 돌려주고, Clash가 원래 도메인을 기억한 뒤 규칙을 적용합니다. 이 방식은 도메인 기반 규칙을 빠르게 처리하고 DNS 요청이 운영체제 밖으로 새는 것을 줄이는 데 유리하지만, 일부 보안 프로그램이나 오래된 회의 앱이 가상 주소를 제대로 처리하지 못할 수 있습니다.

회의 연결이 실패하면 먼저 fake-ip 전체를 redir-host로 바꾸기보다, 문제가 되는 도메인만 fake-ip-filter에 추가해 예외 처리하세요. 예외 항목에는 사내 인증 도메인, 로컬 장치 이름, 특정 회의 서비스의 연결 호스트를 넣을 수 있습니다. 단, 너무 많은 도메인을 예외로 두면 DNS 요청이 실제 주소를 직접 반환하게 되어 분할 규칙이 예상과 다르게 동작할 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://dns.example.invalid/dns-query
    - tls://1.1.1.1:853
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.local"
    - "intranet.example.invalid"

example.invalid은 실제 서비스 주소가 아닌 문서용 예시입니다. 자신의 DNS 서버 주소와 사내 도메인으로 교체해야 합니다. 사내 DNS가 필요한 경우에는 회사 네트워크 정책에 맞춰야 하며, 회사가 지정한 DNS를 임의의 공용 DNS로 바꾸면 내부 서비스 주소가 해석되지 않거나 보안 정책을 위반할 수 있습니다.

Zoom과 Meet에서 연결은 되지만 음성이 끊긴다면 DNS보다 UDP 경로와 노드 품질을 먼저 확인하세요. Clash 로그에서 연결이 반복적으로 재시도되는지, 노드가 UDP를 지원하는지, TUN의 스택이 현재 운영체제와 맞는지 확인합니다. Slack의 메시지는 정상인데 파일 업로드만 실패하는 경우에는 파일 저장 호스트가 별도 도메인일 가능성이 크므로 해당 시점의 로그에서 실제 목적지를 찾아 업무 그룹 규칙에 추가합니다.

적용 후 검증과 유지 관리

설정을 저장한 뒤 바로 업무에 사용하지 말고, 서비스별로 경로와 기능을 나누어 검증하세요. 먼저 Clash의 연결 로그에서 국내 포털 하나와 Zoom, Slack, Meet 각각의 요청을 실행합니다. 국내 포털은 DIRECT, 업무 서비스의 핵심 요청은 WORK로 표시되어야 합니다. 단순히 노드가 연결되어 있다는 표시만으로는 규칙이 제대로 적용되었다고 판단할 수 없습니다.

그다음 실제 회의와 비슷한 조건을 만듭니다. 카메라를 켜고 10분 이상 음성 통화를 진행하며, 화면 공유와 채팅을 번갈아 사용합니다. 가능하면 다른 사람이 회의에 참여해 양쪽에서 음성과 화면을 확인합니다. 모바일 핫스팟과 가정용 Wi-Fi에서 결과가 다르면 회선 자체의 MTU, UDP 차단, IPv6 경로가 원인일 수 있으므로 네트워크를 바꿔 비교하면 원인 범위를 빠르게 좁힐 수 있습니다.

• 규칙 변경은 한 번에 하나씩 적용하세요. 여러 도메인을 동시에 넣으면 어떤 항목이 문제를 해결했는지 알기 어렵습니다.
• 구독 갱신 뒤 정책 그룹을 확인하세요. 일부 클라이언트는 프로파일을 다시 가져오면서 수동 규칙이나 그룹 수정 내용을 덮어쓸 수 있습니다.
• 회의 전 노드를 미리 선택하세요. 회의 중 자동 그룹이 노드를 바꾸면 순간적인 재연결이나 음성 끊김이 발생할 수 있습니다.
• 업무 시간 외에는 TUN을 끄는 것도 방법입니다. 로컬 개발 도구, 게임, 프린터 검색처럼 프록시와 맞지 않는 트래픽이 많은 경우 별도 프로파일을 만들어 전환하세요.
• 로그에 계정 정보가 남지 않도록 주의하세요. 설정 파일과 로그에는 구독 주소, 요청 경로, 조직 도메인이 포함될 수 있으므로 외부에 그대로 공유하지 않습니다.

가장 안정적인 운영 방식은 “업무용 프로파일”과 “일반 인터넷 프로파일”을 분리하는 것입니다. 업무용 프로파일에는 TUN, 업무 정책 그룹, 필요한 DNS 예외만 넣고, 일반 프로파일에는 국내 직결 중심의 가벼운 규칙을 둡니다. 이렇게 하면 회의가 없는 시간에 불필요한 프록시 사용을 줄이고, 문제가 생겼을 때 어느 설정이 원인인지도 쉽게 추적할 수 있습니다.