Notion·Figma·Miro 원격 협업을 위한 Clash 분할 프록시 설정 가이드

앱 도메인과 라우팅 정책부터 구분하기

Notion·Figma·Miro만 프록시로 보내고 국내 사이트는 직접 연결하려면, 앱별 도메인 규칙을 기본 규칙보다 앞에 배치해야 합니다. Clash 클라이언트는 구독과 규칙을 관리하는 인터페이스이고, 실제 트래픽 분기는 실행 중인 Clash 또는 mihomo 코어가 YAML 설정에 따라 처리합니다. 따라서 규칙을 작성하기 전에 사용 중인 코어가 해당 규칙 문법을 지원하는지, 구독 업데이트가 로컬 변경 사항을 덮어쓰는지 확인하세요.

여기서 “앱만 프록시”는 앱의 대표 도메인과 관련 리소스 도메인을 지정된 정책 그룹으로 보내는 방식입니다. 웹앱은 로그인, 이미지, 파일 업로드, 알림 등에 별도 도메인이나 외부 인증 서비스를 사용할 수 있습니다. 대표 사이트가 열리더라도 일부 기능이 실패한다면 모든 트래픽을 프록시로 돌리기보다, 로그에서 실제로 접속한 도메인과 적용된 규칙을 확인해 필요한 도메인만 추가하는 편이 안전합니다.

서비스	규칙 예시 도메인	점검할 기능
Notion	`notion.so`, `notion.site`, `notionusercontent.com`, `notion-static.com`	로그인, 페이지 콘텐츠, 이미지와 첨부 파일
Figma	`figma.com`, `figmausercontent.com`, `figma.net`	파일 열기, 에셋 로딩, 실시간 편집
Miro	`miro.com`, `mirostatic.com`	보드 접속, 이미지와 정적 리소스, 공동 편집

표는 시작점이지 서비스의 고정된 전체 도메인 목록은 아닙니다. 각 서비스의 도메인과 CDN 구성은 바뀔 수 있고, 로그인 과정에서 외부 인증 도메인이 사용될 수도 있습니다. 특히 DOMAIN-SUFFIX 규칙을 광범위한 CDN이나 클라우드 도메인에 적용하면 관련 없는 사이트의 트래픽까지 프록시로 보낼 수 있으므로, 실제 로그에서 확인한 도메인만 추가하세요.

정책 그룹을 정하고 규칙을 추가하기

아래 예시는 Notion·Figma·Miro를 하나의 선택 그룹으로 보내는 mihomo 형식의 일부 설정입니다. WORK와 AUTO는 예시 그룹 이름이며, Node A와 Node B는 실제 구독에 존재하는 프록시 이름으로 바꿔야 합니다. 구독이 이미 정책 그룹을 제공한다면 새 그룹을 만들기 전에 기존 그룹을 재사용할 수 있는지 확인하세요.

proxy-groups:
  - name: WORK
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Node A
      - Node B
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,notion.so,WORK
  - DOMAIN-SUFFIX,notion.site,WORK
  - DOMAIN-SUFFIX,notionusercontent.com,WORK
  - DOMAIN-SUFFIX,notion-static.com,WORK
  - DOMAIN-SUFFIX,figma.com,WORK
  - DOMAIN-SUFFIX,figmausercontent.com,WORK
  - DOMAIN-SUFFIX,figma.net,WORK
  - DOMAIN-SUFFIX,miro.com,WORK
  - DOMAIN-SUFFIX,mirostatic.com,WORK
  # 여기에 기존 규칙을 이어서 배치합니다.
  # 기존 MATCH 또는 최종 기본 규칙은 맨 아래에 둡니다.

DOMAIN-SUFFIX,figma.com,WORK는 figma.com과 그 하위 도메인에 적용됩니다. 따라서 일반적으로 같은 서비스에 대해 apex 도메인과 모든 하위 도메인을 각각 나열할 필요는 없습니다. 예외 도메인이나 특정 호스트만 처리하고 싶을 때는 DOMAIN 규칙을 사용하고, 하위 도메인 전체를 포함해야 할 때는 DOMAIN-SUFFIX를 사용하세요.

국내 사이트는 직접 연결하되 과도하게 분기하지 않기

국내 사이트를 직접 연결하는 방법은 크게 두 가지입니다. 첫째, 자주 사용하는 사이트의 정확한 도메인이나 확인된 하위 도메인에 DIRECT 규칙을 추가합니다. 둘째, 사용 중인 규칙 데이터베이스와 코어가 제공하는 한국 도메인 분류 규칙을 활용합니다. 구독에 이미 국내 직접 연결 규칙이 포함되어 있다면 별도 규칙을 중복으로 추가하지 말고, 해당 규칙이 앱별 프록시 규칙보다 앞에 있는지와 충돌하는지 살펴보세요.

국내 직접 연결 규칙을 앱 규칙보다 무조건 앞에 두면 안 됩니다. 예를 들어 특정 서비스가 국내 IP 주소를 사용하더라도, 해당 서비스 도메인을 프록시로 보내려는 목적이라면 서비스별 규칙이 먼저 일치하도록 배치해야 합니다. 반대로 국내 도메인 분류 규칙이 먼저 광범위하게 일치하면 앱별 규칙이 적용되지 않을 수 있습니다. 정책은 “업무 앱 도메인 → 명시적으로 직접 연결할 국내 도메인 → 기존 국가·지역 규칙 → 최종 기본 규칙”처럼 우선순위를 정해 구성하고, 실제 적용 로그로 검증하세요.

GEOIP,KR,DIRECT 같은 IP 기반 규칙은 국내 IP로 판정된 연결을 직접 보낼 때 사용할 수 있지만, “국내 사이트”와 “한국 IP”는 같은 뜻이 아닙니다. 국내 사이트가 해외 CDN을 사용하거나, 도메인 해석 결과가 예상과 다르면 IP 규칙만으로 원하는 동작을 보장할 수 없습니다. 또한 no-resolve 옵션을 쓰는 경우 아직 IP가 확인되지 않은 도메인 연결에는 이 규칙이 바로 적용되지 않을 수 있습니다. 이런 규칙은 도메인 기반 분기를 대체하는 만능 해결책으로 사용하지 마세요.

회사 VPN, 사내 DNS, 보안 에이전트가 설치된 기기에서는 네트워크 정책이 Clash 설정과 별도로 적용될 수 있습니다. 업무 장비에서 직접 연결 규칙을 추가하기 전에 조직의 보안 정책을 확인하세요. 사내 주소를 외부 프록시로 보내거나 관리되는 VPN 경로를 우회하면 서비스 접근이 차단되거나 보안 규정에 어긋날 수 있습니다.

구독 업데이트 후에도 규칙을 보존하기

구독 설정 파일을 직접 수정하면 다음 업데이트에서 변경 내용이 사라질 수 있습니다. Clash Verge Rev 등 클라이언트별로 설정 병합, 오버라이드, 스크립트 기능의 이름과 지원 범위가 다르므로 메뉴 이름을 다른 클라이언트에 그대로 적용하지 마세요. 기능을 사용할 수 없다면 원본 구독의 백업을 만든 뒤 로컬 설정 파일을 별도로 관리하고, 업데이트 전후의 최종 설정을 비교하는 방법도 있습니다.

현재 설정을 내보내거나 복사하고, 구독 주소와 인증 정보는 공개되지 않는 안전한 위치에 보관합니다.
규칙과 그룹을 추가할 위치를 정합니다. 그룹 이름과 프록시 이름의 대소문자, 공백이 실제 설정과 일치하는지 확인합니다.
구독을 갱신한 뒤 최종 설정에 사용자 규칙이 남아 있는지, 앱 규칙이 기본 규칙보다 앞에 있는지 확인합니다.
코어가 설정을 정상적으로 읽었는지 로그를 살펴봅니다. 파싱 오류가 발생하면 들여쓰기, 콜론, 목록의 하이픈과 참조하지 않는 그룹 이름부터 점검합니다.

YAML에서는 들여쓰기에 탭 대신 공백을 사용하고, 같은 단계의 항목을 동일한 간격으로 맞추세요. 위 예시는 기존 구독 전체를 대체하는 완성 설정이 아니라 proxy-groups와 rules에 병합할 예시입니다. 이미 해당 키가 있다면 같은 키를 두 번 선언하지 말고 기존 목록 안에 항목을 추가해야 합니다. 구독에 그룹 정의가 없는데 규칙에서 WORK를 참조하면 설정 오류가 나거나 규칙을 적용할 수 없습니다.

클라이언트에서 경로와 기능을 검증하기

규칙을 저장한 뒤에는 프록시 모드와 그룹 선택 상태를 확인하세요. 규칙 모드가 아니라 전역 모드라면 모든 연결이 선택한 프록시로 갈 수 있고, 직접 연결 모드라면 앱별 규칙이 기대대로 작동하지 않을 수 있습니다. 클라이언트의 연결 또는 로그 화면에서 Notion·Figma·Miro를 열 때 기록된 요청 도메인과 매칭된 정책을 확인합니다. 메뉴 이름과 로그 형식은 클라이언트 및 버전에 따라 다릅니다.

페이지 자체가 열리지 않음: 도메인 규칙이 존재하는지, WORK 그룹이 선택 가능한 프록시를 포함하는지, 해당 노드가 연결 가능한지 확인합니다.
페이지는 열리지만 이미지나 파일이 누락됨: 로그에서 실패한 요청의 도메인을 찾고, 실제로 해당 서비스에 속하는지 확인한 뒤 제한적으로 규칙을 추가합니다.
편집이나 공동 작업만 불안정함: 선택한 노드의 연결 안정성, 지연 시간, 네트워크가 장시간 연결을 제한하는지 확인합니다. URL 테스트 통과만으로 실시간 편집까지 보장되지는 않습니다.
국내 사이트도 프록시를 사용함: 일치한 규칙과 그 위에 있는 선행 규칙을 살펴봅니다. 특히 넓은 도메인 접미사 규칙이나 최종 기본 규칙의 순서를 확인하세요.

테스트할 때는 한 번에 여러 변경을 적용하지 않는 것이 좋습니다. 먼저 앱 규칙을 추가하고 세 서비스의 기본 접속을 확인한 다음, 문제가 확인된 도메인만 하나씩 보완하세요. 각 변경 전후의 규칙과 로그를 기록하면 구독 갱신이나 클라이언트 변경 뒤에도 원인을 비교하기 쉽습니다. 프록시 설정만으로 서비스의 계정 권한, 회사 네트워크 제한, 웹앱 자체의 오류가 해결되는 것은 아니므로, 같은 계정과 네트워크에서 프록시를 끈 상태의 동작도 비교해 보세요.