이 글이 맞는 사용 시나리오
Notion·Figma·Miro를 업무 도구로 사용하는데 문서가 늦게 열리거나, Figma 공동 편집이 자주 끊기거나, Miro 보드의 이미지와 첨부 파일이 한참 뒤에 표시되는 경우가 있습니다. 세 서비스 모두 단순한 웹페이지처럼 보이지만 실제로는 로그인, API 요청, 정적 리소스, 이미지 CDN, 실시간 공동 편집 연결을 여러 호스트에서 나누어 처리합니다. 브라우저에서 서비스 화면이 열렸다고 해서 모든 요청이 같은 경로를 사용하는 것은 아닙니다.
이 글에서는 Clash Verge Rev 또는 Mihomo 코어를 사용하는 환경을 기준으로, 해외 협업 서비스만 프록시 그룹으로 보내고 국내 웹사이트·사내 시스템·일반 파일 다운로드는 DIRECT로 남기는 분할 라우팅 구성을 설명합니다. 모든 트래픽을 글로벌 모드로 보내는 방식보다 국내 서비스의 지연을 줄이고, 문제가 생겼을 때 어떤 도메인이 어느 경로를 탔는지 확인하기 쉽다는 장점이 있습니다. 다만 실제 도메인은 서비스 버전, 리전, 로그인 제공자, CDN 구성에 따라 달라질 수 있으므로 예시 규칙을 그대로 믿기보다 연결 로그로 검증해야 합니다.
이 구성의 목표는 단순히 프록시 사용량을 줄이는 것이 아닙니다. Notion 데이터베이스 조회, Figma 파일 로딩, Miro 보드 동기화처럼 서로 성격이 다른 요청을 하나의 정책으로 정리하고, 국내 회선이 더 빠른 요청까지 해외 노드로 우회하지 않도록 경로를 분리하는 데 있습니다. 특히 회사 VPN, 보안 DNS, 사내 프록시를 함께 사용하는 노트북에서는 연결 순서가 성능과 안정성에 직접 영향을 줍니다.
Notion·Figma·Miro 트래픽을 나누어 이해하기
분할 라우팅을 시작하기 전에 세 서비스가 어떤 요청을 만드는지 구분해야 합니다. 브라우저 개발자 도구를 처음부터 모두 분석할 필요는 없지만, Clash의 연결 로그에서 서비스에 접속한 직후 나타나는 호스트와 정책 그룹을 확인하면 규칙을 훨씬 정확하게 만들 수 있습니다.
- Notion: 로그인과 워크스페이스 요청, 페이지 데이터, 이미지·파일 미리보기, 외부 인증 서비스가 서로 다른 호스트로 나뉠 수 있습니다. 페이지 본문은 열리는데 첨부 파일만 느리다면 기본 도메인보다 파일 CDN 또는 저장소 도메인이 원인일 가능성이 큽니다.
- Figma: 파일 목록과 프로젝트 화면 외에 이미지 리소스, 폰트, 플러그인, 실시간 공동 편집 연결이 함께 동작합니다. 한 호스트만 프록시로 보내면 파일은 열리지만 커서 위치나 변경 사항 반영이 늦어질 수 있습니다.
- Miro: 보드 HTML, 썸네일, 업로드 파일, 실시간 협업 채널이 별도 요청으로 처리됩니다. 보드 자체는 정상인데 다른 사용자의 커서나 카드 변경이 늦게 보이면 장시간 연결 또는 WebSocket 계열 요청을 의심할 수 있습니다.
이 때문에 DOMAIN-KEYWORD,figma처럼 짧은 키워드만 사용하면 관련 없는 호스트까지 넓게 잡힐 수 있습니다. 반대로 공식 서비스 도메인 하나만 추가하면 로그인 공급자나 파일 저장소가 DIRECT로 빠질 수 있습니다. 가장 안전한 순서는 서비스에 로그인한 뒤 새 파일이나 보드를 열고, 파일 업로드와 공동 편집을 차례로 실행하면서 실제 로그를 기록하는 것입니다.
1단계: Clash 프로필과 기본 모드 정리
먼저 Clash Verge Rev에서 실제로 사용 중인 프로필을 확인합니다. 구독을 갱신한 뒤 예전 규칙 프로바이더가 사라졌거나, 모드가 Global로 바뀌어 있으면 분할 라우팅을 테스트해도 결과가 달라집니다. 프로필이 정상적으로 파싱되고 코어가 재시작되지 않는지 확인한 다음, 현재 모드를 Rule로 선택하세요. Rule 모드에서는 상단 규칙부터 순서대로 평가하므로, 새 규칙을 어느 위치에 넣는지가 중요합니다.
프록시 그룹은 목적에 맞게 단순하게 시작하는 편이 좋습니다. 예를 들어 해외 협업 서비스를 위한 그룹을 WORKFLOW, 국내 직접 연결을 DIRECT로 두고, 처음부터 여러 지역과 자동 선택 그룹을 겹겹이 만들지 않는 방식입니다. 자동 선택은 편리하지만 테스트 중에는 매 요청마다 노드가 달라져 지연 원인을 추적하기 어렵습니다. 한 노드를 고정해 기본 성능을 확인한 뒤, 안정적인 노드를 그룹에 추가하는 순서가 효율적입니다.
DNS 설정도 함께 확인해야 합니다. 브라우저가 국내 DNS로 서비스 호스트를 해석하고 Clash가 다른 경로로 연결하면, 규칙은 맞아도 지역별 CDN 선택이 달라질 수 있습니다. 처음부터 복잡한 DNS 변조 설정을 바꾸기보다, 동일한 프로필과 동일한 DNS 모드에서 규칙만 변경해 전후 결과를 비교하세요. 설정을 한 번에 여러 곳에서 바꾸면 무엇이 개선되었는지 판단하기 어렵습니다.
2단계: 협업 서비스만 프록시로 보내기
규칙을 작성할 때는 가장 구체적인 서비스 규칙을 일반 규칙보다 위에 배치합니다. 아래 예시는 구조를 이해하기 위한 형태이며, 실제 사용 중인 도메인은 연결 로그와 각 서비스의 공식 안내를 기준으로 보완해야 합니다.
rules:
- DOMAIN-SUFFIX,notion.so,WORKFLOW
- DOMAIN-SUFFIX,notion.site,WORKFLOW
- DOMAIN-SUFFIX,figma.com,WORKFLOW
- DOMAIN-SUFFIX,miro.com,WORKFLOW
- DOMAIN-SUFFIX,mirostatic.com,WORKFLOW
- DOMAIN-SUFFIX,googleapis.com,WORKFLOW
- DOMAIN-SUFFIX,회사내부도메인,DIRECT
- GEOIP,KR,DIRECT
- MATCH,DIRECT예시의 googleapis.com처럼 넓은 규칙은 주의해서 사용해야 합니다. 특정 협업 서비스가 Google 계정이나 Google 저장소를 사용한다고 해서 모든 Google API 트래픽을 하나의 프록시 그룹으로 보내면, 국내 서비스와 개발 도구까지 예상치 못하게 우회할 수 있습니다. 실제 로그에서 협업 서비스의 파일 요청이 해당 접미사를 사용한다는 사실을 확인한 경우에만 추가하고, 가능하면 더 좁은 호스트 규칙을 우선하세요.
GEOIP,KR,DIRECT는 국내 IP로 분류된 연결을 직접 보내는 보조선입니다. 이 규칙은 서비스 도메인 규칙보다 아래에 있어야 합니다. 순서가 반대라면 국내 IP로 해석된 협업 서비스가 프록시를 거치지 않을 수 있습니다. 또 회사 시스템이나 사내 Git이 별도의 사설 주소를 사용한다면 DOMAIN-SUFFIX, IP-CIDR, no-resolve 조합을 조직 환경에 맞게 추가해야 합니다.
Notion·Figma·Miro의 모든 하위 도메인을 무조건 한 그룹에 넣는 것이 항상 최선은 아닙니다. 특정 서비스의 일반 화면은 직접 연결해도 되지만 파일 CDN만 프록시가 필요할 수 있고, 반대로 로그인은 되는데 실시간 편집 채널만 차단될 수도 있습니다. 따라서 첫 번째 버전에서는 서비스 전체를 하나의 그룹으로 묶어 성공 여부를 확인하고, 안정화된 뒤 로그를 바탕으로 예외를 좁혀 가는 것이 좋습니다.
3단계: 브라우저와 시스템 프록시 연결 확인
Clash 규칙이 정확해도 브라우저가 Clash를 사용하지 않으면 아무 변화가 없습니다. Clash Verge Rev의 시스템 프록시 활성화 상태와 mixed-port 값을 확인하고, 브라우저에 별도 프록시 확장 기능이 있다면 충돌 여부를 점검합니다. 브라우저 확장이 다른 SOCKS 포트를 사용하거나, 회사 보안 프로그램이 시스템 프록시를 덮어쓰면 Clash 로그에 요청이 나타나지 않을 수 있습니다.
먼저 Notion 페이지, Figma 파일, Miro 보드를 각각 새로고침하면서 Clash 연결 로그에 요청이 들어오는지 확인합니다. 로그가 전혀 없다면 규칙 문제가 아니라 브라우저가 다른 네트워크 경로를 사용하는 것입니다. 로그는 보이지만 DIRECT로 표시된다면 규칙 순서나 도메인 패턴을 살펴보고, REJECT라면 상위 차단 규칙 또는 광고 차단 프로바이더의 영향을 확인해야 합니다.
Figma와 Miro의 공동 편집은 짧은 HTTP 요청만으로 끝나지 않을 수 있습니다. 파일을 연 직후에는 정상인데 다른 사용자의 변경 사항이 늦게 반영되면, 연결 로그에서 장시간 유지되는 호스트와 정책 그룹을 확인하세요. WebSocket 또는 유사한 실시간 연결을 지원하지 않는 중간 프록시를 사용하면 일반 페이지보다 공동 편집에서 문제가 먼저 드러납니다. 이때 무작정 TUN을 켜기보다, 현재 프록시 그룹의 노드와 연결 유지 상태를 먼저 바꾸어 비교하는 편이 안전합니다.
4단계: 속도보다 재현성을 먼저 확인하기
설정 전후를 비교할 때 단순히 페이지가 빨리 열리는지만 보지 말고 같은 작업을 반복해야 합니다. 동일한 브라우저 프로필에서 Notion 데이터베이스를 열고, Figma에서 큰 파일을 불러오고, Miro 보드의 이미지를 확대하는 순서로 테스트합니다. 각각 첫 로딩 시간, 이미지 표시 지연, 편집 변경 반영 시간, 오류 발생 여부를 기록하면 체감만으로 판단하는 실수를 줄일 수 있습니다.
- Clash를 Rule 모드로 두고 협업 서비스 그룹에 고정된 노드를 선택합니다.
- 브라우저 캐시를 무조건 삭제하기보다 먼저 같은 문서와 보드를 열어 기존 상태를 기록합니다.
- 서비스별로 로그인, 파일 열기, 업로드 또는 공동 편집을 순서대로 실행합니다.
- Clash 로그에서 각 호스트의 최종 정책과 연결 실패 여부를 확인합니다.
- 같은 작업을 프록시 그룹과 직접 연결에서 반복해 차이를 비교합니다.
국내 사이트까지 느려졌다면 GEOIP,KR,DIRECT의 위치, 일반 규칙의 기본값, DNS 응답을 점검하세요. 반대로 협업 서비스는 여전히 간헐적으로 끊기는데 로그에 여러 노드가 섞여 있다면 자동 선택 그룹이 원인일 수 있습니다. 우선 하나의 안정적인 노드로 고정하고, 일정 시간 동안 같은 작업을 반복한 뒤 자동 선택으로 되돌리는 방식이 원인 파악에 유리합니다.
업무 환경에서 오래 유지하는 관리 방법
규칙 프로바이더가 자동 갱신되면 직접 작성한 규칙의 위치가 바뀌거나, 같은 도메인을 처리하는 상위 규칙이 새로 생길 수 있습니다. 갱신 후에는 Notion·Figma·Miro를 각각 한 번씩 열어 매칭 결과가 이전과 같은지 확인하세요. 문제가 생겼을 때는 전체 YAML을 다시 만드는 것보다 마지막으로 정상 작동한 프로필을 복사해 규칙 한 부분씩 되돌리는 편이 복구가 빠릅니다.
팀에서 사용하는 노트북이라면 구독 URL과 개인 토큰을 문서나 채팅에 그대로 남기지 마세요. 공유해야 하는 것은 서비스별 정책의 원리와 예외 목록이지, 인증 정보가 포함된 전체 프로필이 아닙니다. 또한 회사 보안 정책이나 서비스 약관이 프록시 사용을 제한할 수 있으므로, 업무용 계정의 데이터가 어떤 경로를 거치는지 조직의 규정과 함께 확인해야 합니다.
브라우저 확장 프로그램, 회사 VPN, Clash TUN을 동시에 켜면 세 계층이 서로 다른 DNS와 라우팅 테이블을 만들 수 있습니다. 문제가 재현될 때는 확장 프록시를 끄고 시스템 프록시만 사용한 상태, TUN을 끄고 브라우저 프록시만 사용한 상태처럼 한 번에 하나의 경로만 남겨 비교하세요. 이렇게 하면 규칙 자체의 오류와 중복 프록시 문제를 구분할 수 있습니다.
일부 전용 프록시 도구는 앱별 설정은 간단하지만, 서비스의 하위 도메인이나 실시간 연결을 세밀하게 추적하기 어렵고 플랫폼별 기능 차이도 큽니다. 반면 Clash는 Rule 모드에서 Notion·Figma·Miro를 하나의 정책 그룹으로 관리하면서 국내 트래픽은 직접 연결하고, 연결 로그와 YAML 규칙으로 실패한 호스트를 재현할 수 있습니다. 특정 서비스만 안정적으로 우회하고 나머지 업무 환경은 그대로 유지하려는 목적이라면, 이러한 분할 라우팅을 직접 조정할 수 있는 Clash 구성이 더 유연하므로 각 플랫폼에 맞는 클라이언트를 내려받아 적용해 보세요.