Clash 원격근무 설정법: Zoom·Slack 연결 최적화 가이드

원격근무에서는 인터넷 속도 자체보다 지연 시간의 안정성, 패킷 손실, DNS 응답 일관성이 더 중요할 때가 많습니다. Zoom 회의가 시작될 때 화면은 나오지만 음성이 끊기거나, Slack 메시지가 몇 초 늦게 도착하고 파일 업로드가 반복해서 실패한다면 단순히 노드를 바꾸는 것만으로는 해결되지 않을 수 있습니다. Clash의 규칙과 DNS, 프록시 그룹을 업무 트래픽에 맞게 분리해야 합니다.

이 글에서는 Clash 또는 Mihomo를 사용해 Zoom과 Slack을 안정적인 프록시 경로로 보내고, 국내 서비스와 사내망 트래픽은 우회하지 않는 구성을 설명합니다. 특정 서비스 전체를 무조건 프록시로 보내는 방식이 아니라, 회의·메신저에 필요한 도메인만 선별하고 나머지는 직접 연결하여 속도와 안정성을 함께 확보하는 것이 목표입니다.

원격근무 트래픽을 분리해야 하는 이유

Zoom과 Slack은 하나의 도메인만 사용하는 단순한 서비스가 아닙니다. 로그인, API 요청, 채팅 동기화, 파일 저장, 음성·영상 미디어, 알림 연결이 서로 다른 호스트 이름과 연결 방식을 사용할 수 있습니다. 웹 페이지가 열렸다고 해서 회의 미디어 경로와 Slack 실시간 연결까지 정상이라는 뜻은 아닙니다.

또한 모든 트래픽을 같은 프록시로 보내면 국내 웹사이트, 사내 VPN, 프린터, NAS, 화상회의 외의 일반 업무 서비스까지 불필요하게 우회됩니다. 이 경우 국내 서비스의 응답 시간이 늘어나고, 사내 시스템이 허용된 IP 범위를 벗어나 인증에 실패할 수도 있습니다. 반대로 모든 트래픽을 직접 연결하면 특정 네트워크에서 Zoom이나 Slack의 일부 엔드포인트에 연결하지 못하거나 DNS 응답이 불안정해질 수 있습니다.

중요한 점은 서비스 이름만 보고 판단하지 않는 것입니다. Zoom 앱이 사용하는 실제 도메인은 버전, 지역, 기능에 따라 달라질 수 있고, Slack 워크스페이스는 조직별 사용자 정의 도메인이나 별도 파일 호스트를 사용할 수 있습니다. 따라서 설정 후 Clash 대시보드의 연결 목록에서 실제 요청 도메인과 적용된 규칙을 확인해야 합니다.

Zoom과 Slack에 맞는 프록시 그룹 선택

원격근무용 그룹은 단순한 select 그룹 하나보다 업무 목적에 따라 나누는 편이 관리하기 쉽습니다. 예를 들어 일반 웹 트래픽에는 자동 선택 그룹을 사용하고, 회의 트래픽에는 장애 전환이 가능한 그룹을 사용할 수 있습니다. 회의 중 노드가 바뀌면 연결이 끊길 수 있으므로, 너무 민감한 자동 전환은 피하는 것이 좋습니다.

Zoom 회의용 노드는 낮은 핑보다 지속적인 품질을 우선해야 합니다. 테스트 URL의 응답 시간이 30ms 낮더라도 실제 회의 서버까지의 경로가 다르면 결과가 달라질 수 있습니다. Slack은 메시지 연결이 장시간 유지되므로 짧은 순간의 속도보다 연결이 자주 끊기지 않는 노드가 더 적합합니다.

proxy-groups:
  - name: Work-Proxy
    type: select
    proxies:
      - node-jp-01
      - node-sg-01
      - node-us-01

  - name: Work-Fallback
    type: fallback
    proxies:
      - node-jp-01
      - node-sg-01
    url: https://www.gstatic.com/generate_204
    interval: 60

Clash에서 Zoom과 Slack 규칙 설정하기

규칙은 위에서 아래로 평가되므로 순서가 매우 중요합니다. 먼저 사내망과 로컬 네트워크를 직접 연결하고, 그 다음 Zoom과 Slack을 업무용 프록시 그룹에 연결한 뒤, 국내 IP를 직접 연결하는 규칙을 배치합니다. 마지막에는 나머지 트래픽을 처리하는 기본 규칙을 둡니다.

1. Clash Verge, Clash Verge Rev 또는 Mihomo에서 현재 사용 중인 설정 파일을 엽니다.
2. 회의 중 사용할 노드가 포함된 Work-Proxy 그룹을 확인하고, 필요하면 노드를 직접 선택합니다.
3. rules 항목에 로컬망, 사내 도메인, Zoom, Slack, 국내 IP 순서로 규칙을 추가합니다.
4. 설정을 저장한 뒤 프로필을 다시 적용하거나 변경 사항을 확인합니다.
5. Clash 대시보드의 연결 목록에서 실제 요청이 어느 규칙과 그룹을 사용했는지 점검합니다.
6. Zoom 테스트 회의에서 마이크와 카메라를 확인하고, Slack에서는 메시지와 작은 파일을 각각 전송합니다.

rules:
  # 로컬 및 사내망은 항상 직접 연결
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,company.example,DIRECT

  # 회의 및 메신저 서비스는 업무용 그룹으로 전달
  - 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-SUFFIX,slack-msgs.com,Work-Proxy

  # 국내 IP는 직접 연결; 앞의 서비스 규칙보다 뒤에 배치
  - GEOIP,KR,DIRECT
  - MATCH,Work-Proxy

위 예제의 도메인은 일반적인 출발점일 뿐입니다. 회사의 Slack 환경이나 Zoom 클라이언트 버전에 따라 추가 호스트가 나타날 수 있습니다. 연결 목록에서 REJECT가 발생하거나 MATCH로 기본 그룹에 빠지는 도메인을 발견하면, 해당 도메인의 소유 서비스와 기능을 확인한 뒤 필요한 경우에만 규칙을 추가하세요. 무작정 키워드 규칙을 사용하면 다른 서비스까지 함께 프록시될 수 있습니다.

GEOIP,KR,DIRECT는 국내 IP에 대한 일반적인 분리 규칙입니다. 그러나 사내 시스템이 도메인 기반으로 동작한다면 회사 도메인 규칙을 GEOIP보다 앞에 두어야 합니다. 반대로 해외 CDN을 사용하는 국내 서비스는 IP 위치만으로 정확히 분류되지 않을 수 있으므로, 해당 서비스의 도메인을 별도의 DOMAIN-SUFFIX 규칙으로 직접 지정하는 편이 안전합니다.

DNS와 UDP 설정으로 회의 품질 점검하기

Zoom과 Slack 연결이 불안정할 때는 규칙만 확인하지 말고 DNS 모드도 살펴봐야 합니다. fake-ip 모드는 도메인 기반 규칙을 빠르게 적용하고 프록시 대상의 DNS 조회를 분리하는 데 유리합니다. 다만 로컬 장치 검색, 일부 VPN, 직접 IP 연결을 요구하는 프로그램은 fake-ip-filter에 넣어 실제 IP를 받도록 해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
    - 'WORKSTATION-*.local'
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Zoom 회의에서 음성은 들리지만 영상이 끊긴다면 UDP가 차단되었거나 노드가 UDP를 제대로 전달하지 못하는 상황일 수 있습니다. 사용 중인 프록시 노드에 udp: true가 지원되는지 확인하고, Clash 클라이언트의 TUN 모드와 시스템 방화벽 권한도 점검하세요. UDP를 사용할 수 없는 네트워크에서는 회의 품질이 떨어질 수 있으므로, 다른 노드나 직접 연결을 비교하는 테스트가 필요합니다.

연결 문제 진단과 최종 체크리스트

Zoom 로그인은 되지만 회의에 입장할 수 없다면 로그인 도메인과 미디어 도메인의 경로가 서로 다른지 확인하세요. Slack에서 메시지는 전송되지만 파일 업로드만 실패한다면 파일 저장소 도메인이 별도 규칙을 타고 있을 가능성이 있습니다. 반대로 모든 기능이 느리다면 특정 서비스 규칙보다 노드의 국제 회선, DNS 응답, 로컬 네트워크 혼잡을 먼저 의심하는 것이 좋습니다.

• 대시보드에서 Zoom과 Slack 요청이 의도한 그룹으로 연결되는지 확인합니다.
• 사내 도메인과 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 대역이 DIRECT인지 확인합니다.
• DNS 조회 실패가 있는지 보고, fake-ip를 사용하는 경우 예외 도메인을 점검합니다.
• Zoom에서는 테스트 회의의 지연 시간, 지터, 패킷 손실을 확인합니다.
• Slack에서는 실시간 메시지, 이모지 반응, 파일 업로드를 각각 테스트합니다.
• 문제가 특정 노드에서만 발생하는지 다른 노드와 비교합니다.
• 규칙을 추가한 뒤에는 반드시 기존 규칙보다 앞에 배치되었는지 확인합니다.

가장 안정적인 구성은 “모든 것을 프록시”하는 구성이 아닙니다. 로컬과 국내 트래픽은 직접 연결하고, 원격근무에 필요한 Zoom과 Slack만 검증된 그룹으로 보내며, 회의에 필요한 UDP와 DNS 동작을 별도로 확인하는 구성입니다. 처음에는 적은 수의 도메인과 노드로 시작하고, 대시보드 로그에서 실제 사용 패턴을 확인하면서 규칙을 조금씩 보완하세요.