먼저 연결 경로와 실행 모드 확인하기
Notion이나 Figma에만 프록시를 적용하려면 규칙을 추가하기 전에 두 가지를 구분해야 합니다. 첫째, 해당 앱의 연결이 Clash 코어에 들어오는지 확인합니다. 둘째, 코어에 들어온 연결이 어떤 규칙과 정책 그룹을 거쳐 나가는지 확인합니다. 규칙은 코어에 도착한 연결의 출구를 정할 뿐, 모든 앱의 연결을 자동으로 코어에 전달하지는 않습니다.
브라우저에서 Notion과 Figma를 주로 사용하고 시스템 프록시를 따르도록 설정했다면, 우선 클라이언트에서 시스템 프록시를 켜고 Rule／규칙 모드를 선택하세요. Global／전역 모드는 국내 사이트까지 모두 같은 프록시 출구로 보낼 수 있고, Direct／직결 모드는 도메인별 규칙을 시험하는 방법이 아닙니다. 데스크톱 앱처럼 시스템 프록시를 따르지 않는 프로그램의 연결까지 처리해야 한다면 TUN을 검토할 수 있습니다. 다만 TUN은 연결을 코어로 전달하는 경로를 넓히는 기능이지, Notion과 Figma만 프록시로 보내는 규칙 그 자체는 아닙니다.
- 규칙 모드: 각 연결에 처음 일치하는 규칙이 출구를 선택합니다.
- 시스템 프록시: 운영체제 프록시 설정을 사용하는 브라우저와 앱의 연결을 코어로 전달합니다.
- TUN: 시스템 프록시를 따르지 않는 앱도 처리할 수 있지만, 권한·DNS·라우팅 설정을 함께 점검해야 합니다.
설정을 바꾸기 전에는 현재 프로필을 백업하고, 클라이언트의 연결 목록에서 Notion 또는 Figma 접속이 실제로 표시되는지 확인하세요. 연결 목록에 대상이 전혀 나타나지 않는다면 규칙을 더 추가하기 전에 앱의 프록시 사용 여부와 트래픽 진입 경로부터 확인해야 합니다.
도메인 규칙과 프록시 정책 그룹 준비하기
Notion과 Figma의 도메인만 프록시로 보내고 나머지는 직접 연결하려면, 해당 서비스의 도메인 규칙을 국내 사이트 직결 규칙보다 먼저 배치해야 합니다. 아래 예시는 기존 설정의 rules에 병합하는 조각입니다. 전체 설정이 아니며, 업무 프록시는 예시 정책 그룹 이름입니다. 실제 구독에 이미 있는 그룹 이름으로 바꾸고 그 그룹에서 사용할 수 있는 노드를 선택하세요.
mode: rule
rules:
# 내부 서비스와 로컬 주소를 먼저 직결
- DOMAIN,localhost,DIRECT
- DOMAIN-SUFFIX,lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# Notion 관련 도메인
- DOMAIN-SUFFIX,notion.so,업무 프록시
- DOMAIN-SUFFIX,notion.site,업무 프록시
- DOMAIN-SUFFIX,notion-static.com,업무 프록시
- DOMAIN-SUFFIX,notionusercontent.com,업무 프록시
# Figma 관련 도메인
- DOMAIN-SUFFIX,figma.com,업무 프록시
- DOMAIN-SUFFIX,figmausercontent.com,업무 프록시
# 나머지 연결은 직결
- MATCH,DIRECTDOMAIN-SUFFIX는 해당 도메인과 그 하위 도메인을 매칭합니다. 예를 들어 DOMAIN-SUFFIX,figma.com,업무 프록시는 www.figma.com처럼 figma.com으로 끝나는 이름에 적용됩니다. 이 규칙은 모든 Figma 기능이 반드시 위 도메인만 사용한다는 뜻은 아닙니다. 로그인, 파일 미리보기, 업로드, 플러그인, 외부 연동에서 다른 호스트가 관찰되면 연결 목록에 표시된 실제 도메인을 확인한 뒤 필요한 범위만 추가하세요.
중간 점검: 규칙을 적용하고 앱별로 시험하기
처음부터 여러 도메인과 네트워크 옵션을 한꺼번에 바꾸기보다, 한 단계씩 적용하면 누락과 오분기를 찾기 쉽습니다. 아래 순서로 테스트하고 각 단계의 결과를 기록하세요.
- 프로필을 복제하거나 백업합니다. 현재 모드, 시스템 프록시 상태, TUN 상태, 선택한 정책 그룹을 적어 둡니다. 원래 상태로 되돌릴 수 있어야 합니다.
- 정책 그룹을 확인합니다.
업무 프록시를 기존 그룹 이름으로 바꾸고, 해당 그룹을 열어 연결 가능한 노드를 선택합니다. 그룹이 자동 선택형이라면 현재 선택 결과도 확인하세요. - 규칙을 병합한 뒤 설정을 다시 불러옵니다. YAML 들여쓰기와 쉼표를 확인하고, 클라이언트가 프로필을 다시 적용한 뒤 규칙 모드가 유지되는지 살펴봅니다.
- Notion과 Figma를 각각 새로 연결합니다. 이미 열린 페이지는 기존 연결을 유지할 수 있으므로 새 탭을 열거나 앱을 다시 시작해 새 요청을 발생시킵니다. 연결 목록에서 대상 도메인, 매칭 규칙, 정책 그룹, 최종 노드를 확인합니다.
- 국내 사이트도 시험합니다. 국내 서비스 하나를 열어 연결 목록에서
MATCH와 직결 정책이 선택되는지 확인합니다. 이 설정에서 마지막 규칙이MATCH,DIRECT이므로 별도 예외 규칙이 없는 나머지 연결은 직결이 기본값입니다.
| 시험 대상 | 확인할 정보 | 예상 결과 |
|---|---|---|
| Notion 페이지 열기 | 도메인, 매칭 규칙, 정책 그룹 | Notion 도메인 규칙과 업무 프록시 그룹 |
| Figma 파일 열기 | 문서와 리소스 요청의 연결 기록 | 확인된 Figma 관련 도메인이 프록시 정책에 매칭 |
| 국내 사이트 열기 | 최종 매칭 규칙과 출구 | 다른 예외 규칙이 없다면 MATCH와 DIRECT |
| 연결 목록에 항목이 없음 | 시스템 프록시, TUN, 앱별 프록시 설정 | 규칙 편집 전에 트래픽 진입 경로부터 점검 |
사이트가 열린다는 사실만으로 의도한 규칙이 적용됐다고 판단하지 마세요. 이미 로그인된 앱의 연결이나 캐시된 콘텐츠는 새 네트워크 요청 없이 표시될 수 있습니다. 반대로 연결 목록에 프록시 정책이 표시되는데도 로딩이 멈춘다면, 매칭 규칙과 출구 노드의 상태를 따로 확인해야 합니다.
도메인 누락과 규칙 순서 관리하기
서비스는 기능별로 서로 다른 호스트를 사용할 수 있고, CDN이나 외부 로그인 제공자와 통신할 수도 있습니다. 따라서 도메인 목록을 한 번 작성한 뒤 영구적으로 완전하다고 가정하기보다, 실제 사용 중 누락이 확인될 때 필요한 항목만 추가하는 편이 안전합니다. 연결 기록에서 앱 이름만 보고 도메인을 단정하지 말고 요청 시각, 대상 호스트, 매칭 규칙을 함께 보세요. 회사 내부 주소나 개인 데이터가 포함된 기록을 다른 사람과 공유할 때는 민감한 내용을 가려야 합니다.
- 특정 기능만 실패: 해당 기능을 다시 실행하면서 새로 발생한 연결을 확인합니다. 파일 업로드나 미리보기처럼 실패한 동작과 관계없는 도메인을 한꺼번에 추가하지 마세요.
- 잘못 직결됨: 연결 목록에서 실제로 매칭된 규칙을 확인합니다. 포괄적인 직결 규칙이나 규칙 세트가 Notion·Figma 도메인보다 앞에 있는지 살펴봅니다.
- 국내 사이트도 프록시로 나감:
MATCH가 직결인지, 더 앞에 있는 규칙이 넓은 범위의 도메인을 프록시로 보내는지, 정책 그룹의 현재 선택이 무엇인지 확인합니다. - 규칙을 바꿨는데 결과가 그대로임: 실행 설정이 갱신됐는지 확인하고 새 연결을 만들어 시험합니다. 구독 업데이트가 오버라이드를 덮어썼는지도 점검하세요.
회사 내부 Notion 워크스페이스나 사내 Figma 서비스가 별도 도메인을 사용한다면, 그 주소가 공용 서비스와 같다고 가정하지 말고 조직의 접속 안내를 확인하세요. 내부 주소를 직접 연결해야 한다면 구체적인 사내 도메인을 앞쪽에 DIRECT로 추가하고, 공용 도메인 규칙과 충돌하지 않는지 연결 기록으로 검증합니다. 넓은 범위의 DOMAIN-SUFFIX를 무조건 추가하면 관계없는 서비스까지 같은 정책으로 묶일 수 있습니다.
속도와 안정성은 출구·DNS·앱 설정을 나눠 점검하기
분할 프록시는 모든 요청을 같은 경로로 보내지 않으므로, Notion이나 Figma가 느릴 때도 원인을 규칙 하나로 단정하기 어렵습니다. 프록시 노드의 지연과 혼잡, 앱의 기존 연결, DNS 응답, 업로드 경로, 서비스 측 상태가 각각 영향을 줄 수 있습니다. 규칙을 시험할 때는 노드를 하나 선택해 같은 작업을 반복하고, 그다음 다른 노드와 비교하면 변수를 줄일 수 있습니다.
프록시 그룹의 노드를 바꾼 뒤에도 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 테스트는 새 탭이나 새 연결로 수행하고, 필요할 때만 앱을 재시작하세요. 여러 노드에서 같은 문제가 발생하면 도메인 누락, DNS, 앱 연결이 코어에 전달되는지부터 살펴봅니다. 한 노드에서만 문제가 생긴다면 해당 노드의 연결 상태나 경로를 비교합니다. 테스트 결과를 정확히 기록하려면 접속 시각, 대상 도메인, 매칭 규칙, 선택 노드를 함께 남기세요.
DNS 설정은 별도 계층입니다. 규칙이 도메인에 매칭되더라도 앱이 DNS 조회를 완료하지 못하면 연결이 성립하지 않습니다. 반대로 DNS 조회가 성공했다고 해서 규칙이 예상한 출구를 선택했다는 뜻도 아닙니다. DNS 관련 변경은 현재 클라이언트의 DNS 재정의와 코어 설정을 확인한 뒤 적용하고, 이름 해석 문제와 프록시 연결 문제를 각각 재현해 구분하세요.
마지막으로, Notion과 Figma만 프록시로 보내려는 목적이라면 MATCH,DIRECT가 그 범위를 명확하게 만듭니다. 기존 설정에서 마지막 규칙이 이미 다른 정책을 가리킨다면 새 규칙 조각의 마지막 줄을 그대로 덧붙이지 말고 전체 규칙 순서와 기본 경로를 먼저 검토하세요. 정책 그룹과 도메인 목록을 작게 유지하고, 실제 연결 기록을 근거로 갱신하면 국내 사이트의 불필요한 우회와 업무 앱의 접속 문제를 함께 줄일 수 있습니다.