Notion·Figma·Miro를 빠르게 쓰는 Clash 업무용 분할 설정법

업무 트래픽을 먼저 나누는 기준

Notion, Figma, Miro를 업무에 사용하면서 모든 인터넷 트래픽을 프록시로 보내면 국내 웹사이트와 사내 서비스까지 우회되어 접속 지연이 커질 수 있습니다. 반대로 국내 연결을 모두 직접 연결로 고정하면 해외 리소스, 외부 API, 협업 문서와 디자인 자산을 불안정하게 불러올 수 있습니다. 가장 관리하기 쉬운 방법은 “업무용 해외 서비스는 프록시”, “한국 국내 트래픽은 직접 연결”, “판단할 수 없는 나머지 트래픽은 업무용 프록시”라는 세 단계로 나누는 것입니다.

이 설정은 클라이언트의 이름보다 mihomo 또는 Clash 코어가 읽는 rules의 순서가 중요합니다. 규칙은 위에서 아래로 평가되며, 먼저 일치한 항목에서 처리가 끝납니다. 따라서 Notion과 Figma에 필요한 도메인을 먼저 프록시 그룹으로 보내고, 사설 IP와 한국 IP를 그 다음에 직접 연결하도록 배치해야 합니다. 마지막 MATCH는 앞의 규칙에서 분류하지 못한 트래픽을 처리하는 기본값입니다.

트래픽 종류	권장 처리	이유
Notion, Figma, Miro	업무프록시	문서, 디자인 파일, 보드 리소스의 연결 안정성 확보
사설 주소와 로컬 장치	DIRECT	공유기, 프린터, 사내망 접근을 외부 노드로 보내지 않음
한국 IP 대역	DIRECT	국내 검색, 결제, 공공기관과 사내 서비스의 지연 감소
분류되지 않은 해외 트래픽	업무프록시	기본값을 명확히 해 누락된 해외 연결을 줄임

프록시 그룹과 핵심 규칙 작성하기

먼저 구독에서 제공하는 실제 정책 그룹 이름을 확인해야 합니다. 예시에서는 여러 노드를 선택할 수 있는 그룹을 업무프록시라고 가정합니다. 이미 구독에 “Proxy”, “节点选择” 또는 “자동 선택”과 같은 그룹이 있다면 새 그룹을 중복해서 만들기보다 기존 그룹을 rules에서 참조하는 편이 좋습니다.

proxy-groups:
  - name: 업무프록시
    type: select
    proxies:
      - 자동 선택
      - 노드 선택
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,업무프록시
  - DOMAIN-SUFFIX,notion.site,업무프록시
  - DOMAIN-SUFFIX,notion-static.com,업무프록시
  - DOMAIN-SUFFIX,figma.com,업무프록시
  - DOMAIN-SUFFIX,figmausercontent.com,업무프록시
  - DOMAIN-SUFFIX,miro.com,업무프록시
  - DOMAIN-SUFFIX,mirostatic.com,업무프록시
  - DOMAIN-SUFFIX,miro.com,업무프록시
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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
  - GEOIP,KR,DIRECT
  - MATCH,업무프록시

위 예시는 구조를 설명하기 위한 기본형입니다. notion.site는 공개 페이지 주소에 사용될 수 있고, notion-static.com은 정적 파일을 불러오는 과정에서 나타날 수 있습니다. Figma는 문서 화면 외에 이미지와 디자인 파일을 위한 figmausercontent.com 연결이 필요할 수 있습니다. Miro 역시 보드 화면, 정적 리소스와 실시간 기능이 서로 다른 호스트를 사용할 수 있으므로 브라우저 개발자 도구나 Clash 연결 로그에서 실제 호스트를 확인해야 합니다.

DOMAIN과 DOMAIN-SUFFIX의 차이

DOMAIN,figma.com,업무프록시는 정확히 figma.com에만 적용됩니다. 반면 DOMAIN-SUFFIX,figma.com,업무프록시는 기본 도메인과 하위 도메인을 함께 대상으로 삼습니다. 업무 서비스는 여러 하위 도메인에서 API, 정적 파일, 인증, 웹소켓을 제공하는 경우가 많으므로 처음에는 DOMAIN-SUFFIX가 편리합니다. 단, 너무 넓은 suffix를 추가하면 관련 없는 서비스까지 프록시로 들어갈 수 있으므로 figma.com처럼 등록 가능한 주 도메인 단위로 작성해야 합니다.

IP-CIDR의 no-resolve는 해당 규칙을 평가하기 위해 도메인을 다시 DNS 조회하지 않도록 하는 옵션입니다. 사설 IP 대역은 도메인 조회가 필요하지 않으므로 이 옵션을 붙이는 편이 자연스럽습니다. 반대로 GEOIP,KR,DIRECT는 도메인이 해석된 결과의 IP 국가를 기준으로 합니다. CDN이나 글로벌 클라우드 주소는 실제 서비스 이용 지역과 IP 등록 국가가 다를 수 있으므로, 업무 서비스의 도메인 규칙을 반드시 GEOIP 규칙보다 위에 두어야 합니다.

DNS와 TUN 모드에서 확인할 항목

시스템 프록시 모드에서는 브라우저가 운영체제의 HTTP 또는 SOCKS 프록시 설정을 따르는지 확인해야 합니다. FlClash에서 시스템 프록시를 켠 뒤 브라우저를 완전히 다시 시작하고 Notion, Figma, Miro에 접속하세요. 연결 로그에 notion.so, figma.com, miro.com 또는 관련 자산 도메인이 표시되고 선택한 정책 그룹으로 전달되면 기본 동작은 정상입니다.

TUN 모드는 시스템 프록시를 읽지 않는 데스크톱 앱, 명령줄 도구와 일부 협업 프로그램까지 가상 네트워크 인터페이스에서 받아 처리합니다. 대신 운영체제에 네트워크 확장 또는 VPN 권한이 필요하고 DNS와 라우팅에 영향을 줍니다. 단순히 웹 브라우저에서 세 서비스를 사용하는 상황이라면 먼저 시스템 프록시로 검증한 뒤 TUN을 켜는 것이 문제 범위를 줄이는 방법입니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.0.0.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - localhost.ptlogin2.qq.com

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true

위 DNS와 TUN 값은 모든 환경에 그대로 적용해야 하는 고정 정답이 아닙니다. 사내 DNS, 내부 도메인, 프린터와 NAS를 사용한다면 해당 도메인을 fake-ip-filter 또는 DNS 정책에서 제외해야 할 수 있습니다. TUN을 켠 뒤 사내 시스템이나 공유기 관리 페이지가 열리지 않으면 먼저 192.168.0.0/16, 10.0.0.0/8 등의 사설 대역이 DIRECT로 처리되는지 확인하세요.

연결 로그로 누락된 도메인 찾기

FlClash에서 코어를 시작하고 연결 로그를 엽니다.
Notion에서 로그인, 문서 열기, 이미지 삽입과 검색을 각각 실행합니다.
Figma에서 파일 열기, 댓글 작성, 이미지 내보내기를 차례로 테스트합니다.
Miro에서 보드 열기, 포스트잇 추가, 협업자 커서 표시를 확인합니다.
실패한 요청의 도메인과 현재 선택된策略를 기록한 뒤 필요한 도메인만 규칙에 추가합니다.

특정 서비스가 열리지 않을 때 무작정 MATCH,DIRECT로 바꾸면 원인은 가려지고 국내 트래픽 분할이라는 목표도 무너집니다. 연결 로그에서 DNS 실패인지, TCP 또는 TLS 연결 실패인지, 정책 그룹에서 노드 연결이 실패한 것인지 구분하세요. 같은 노드를 다른 웹사이트에서도 사용할 수 없다면 서비스 규칙보다 노드 품질이나 네트워크 경로를 먼저 점검해야 합니다.

업무용 분할 설정 검증과 운영

설정을 저장한 뒤에는 한 번의 페이지 로딩만으로 성공 여부를 판단하지 않는 것이 좋습니다. 세 서비스 모두 로그인, 기존 문서 열기, 새 콘텐츠 저장, 파일 또는 이미지 로딩, 실시간 협업을 각각 확인해야 합니다. Notion은 데이터베이스와 첨부 파일이 함께 로드되는지, Figma는 파일 미리보기와 댓글이 동작하는지, Miro는 보드 동기화와 다른 참여자의 변경 사항이 즉시 표시되는지를 확인하세요.

증상	우선 확인할 항목	권장 조치
로그인은 되지만 문서가 비어 있음	정적 파일 또는 API 도메인	연결 로그에서 누락된 하위 도메인을 확인
Figma 파일이 오래 로딩됨	노드 품질, 웹소켓, DNS	다른 업무 노드로 변경하고 관련 연결을 비교
Miro 보드가 갱신되지 않음	웹소켓 또는 TUN 라우팅	시스템 프록시와 TUN을 각각 테스트
국내 사이트까지 느려짐	GEOIP 규칙과 MATCH 순서	KR DIRECT 규칙이 업무 도메인 아래에 있는지 확인

업무 시간 중에는 노드 자동 선택 그룹이 지나치게 자주 바뀌지 않도록 주의하세요. url-test 그룹의 테스트 URL과 간격이 너무 공격적이면 연결이 잠깐씩 끊기거나 업무 세션이 재수립될 수 있습니다. 한 노드가 안정적이라면 업무 그룹을 수동 선택으로 두고, 장애가 발생했을 때만 다른 노드로 바꾸는 방식이 문서 편집과 실시간 회의에 더 적합할 수 있습니다.

이처럼 서비스 도메인 규칙, 국내 직접 연결, 명확한 기본값을 분리하면 모든 트래픽을 한 경로로 몰지 않고도 원격 협업 도구의 안정성을 높일 수 있습니다. 구독을 갱신하거나 코어를 변경할 때는 현재의 사용자 정의 규칙을 먼저 백업하고, 변경 후 연결 로그와 실제 편집 동작을 다시 테스트하세요. 설정의 목적은 규칙을 많이 추가하는 것이 아니라 업무에 필요한 연결만 예측 가능한 경로로 보내는 데 있습니다.