Notion·Figma·Miro 업무 속도를 높이는 Clash 설정법

전체 프록시보다 선택적 라우팅이 나은 이유

Notion으로 문서를 관리하고 Figma와 Miro로 협업하는 환경에서는 모든 트래픽을 하나의 프록시로 보내는 것보다, 필요한 서비스만 분리하는 선택적 라우팅이 더 안정적인 경우가 많습니다. 업무 중에는 Notion 페이지를 열어 둔 채 Figma 파일을 동기화하고, Miro 보드에서 실시간으로 커서를 움직이는 일이 동시에 발생합니다. 이때 브라우저의 모든 요청이 먼 서버를 거치면 국내 서비스까지 불필요하게 우회되어 지연 시간이 늘어나고, 이미지·폰트·파일 미리보기 같은 정적 리소스가 늦게 로드될 수 있습니다.

반대로 업무 도메인만 프록시로 보내면 일반 웹 검색, 사내 시스템, 국내 SaaS는 직접 연결로 유지하면서 Notion·Figma·Miro의 해외 리소스와 협업 세션만 별도로 처리할 수 있습니다. 중요한 점은 단순히 웹사이트의 메인 주소만 등록하는 것이 아닙니다. 로그인, API, 파일 업로드, WebSocket, 이미지 CDN처럼 서비스가 실제로 사용하는 보조 도메인까지 규칙에 포함해야 합니다.

이 방식은 속도를 무조건 높이는 만능 설정이 아닙니다. 사용 중인 네트워크와 프록시 노드의 위치, 회사 방화벽, DNS 응답, 브라우저의 보안 DNS 설정에 따라 결과가 달라집니다. 따라서 처음부터 모든 트래픽을 복잡하게 바꾸기보다, 업무 서비스에 필요한 도메인만 추가하고 로그로 실제 매칭 결과를 확인하는 것이 안전합니다.

Clash 프로필을 준비하는 방법

먼저 Clash Verge Rev 또는 Mihomo 기반 클라이언트에서 정상적으로 불러올 수 있는 프로필을 준비합니다. 구독 링크를 등록한 뒤 노드 목록이 표시되는지 확인하고, Rule 모드를 선택합니다. Global 모드는 모든 요청을 같은 프록시 그룹으로 보내므로 이번 목적에 맞지 않고, Direct 모드는 규칙을 무시해 업무 서비스가 연결되지 않을 수 있습니다.

구독 제공업체가 원격 프로필을 관리하는 경우에는 로컬 파일을 수정해도 다음 업데이트에서 내용이 덮어써질 수 있습니다. 이때는 클라이언트의 모듈·스크립트·규칙 추가 기능을 사용하거나, 제공업체가 지원하는 프리미엄 그룹과 사용자 규칙 기능을 이용하는 편이 좋습니다. 직접 편집한 파일을 사용할 때는 YAML의 들여쓰기를 반드시 공백으로 유지하고, 탭 문자는 사용하지 마세요.

Notion·Figma·Miro 규칙 추가하기

업무용 규칙은 일반적으로 DOMAIN-SUFFIX를 중심으로 작성합니다. 이 방식은 하위 도메인에도 적용되므로 서비스가 여러 지역별 주소나 API 주소를 사용할 때 관리가 편합니다. 다만 너무 넓은 도메인을 등록하면 불필요한 요청까지 프록시로 전달될 수 있으므로, 실제 연결 로그에서 확인한 도메인만 점진적으로 추가하는 것을 권장합니다.

아래 예시는 특정 프록시 그룹 이름이 WORK-PROXY라고 가정한 기본 형태입니다. 실제 프로필에 있는 그룹 이름과 정확히 일치하도록 바꾸어야 하며, 그룹 이름에 한글이나 특수문자가 포함되어 있다면 YAML 문자열 표기 문제도 확인해야 합니다.

rules:
  - DOMAIN-SUFFIX,notion.so,WORK-PROXY
  - DOMAIN-SUFFIX,notion.site,WORK-PROXY
  - DOMAIN-SUFFIX,figma.com,WORK-PROXY
  - DOMAIN-SUFFIX,figmausercontent.com,WORK-PROXY
  - DOMAIN-SUFFIX,miro.com,WORK-PROXY
  - DOMAIN-SUFFIX,mirostatic.com,WORK-PROXY
  - MATCH,DIRECT

notion.so는 Notion 웹 앱과 API 요청에 사용되는 대표 도메인이고, notion.site는 공개 페이지 주소에서 자주 확인됩니다. Figma는 본체 도메인 외에 이미지와 파일 미리보기를 전달하는 CDN이 사용될 수 있어 figmausercontent.com을 함께 점검하는 것이 좋습니다. Miro 역시 보드 화면과 정적 리소스가 서로 다른 호스트에서 제공될 수 있으므로 mirostatic.com 같은 리소스 도메인을 로그에서 확인해야 합니다.

다만 이 도메인 목록은 모든 계정과 지역에서 항상 동일하지 않습니다. 로그인 화면이 반복되거나 Figma의 이미지가 빈칸으로 보이거나 Miro 보드가 로드되지 않는다면, Clash의 Connections 또는 Logs 화면을 열고 실패한 요청의 호스트 이름을 찾습니다. 새 호스트가 확인되면 메인 서비스와 관련성이 있는지 검토한 뒤 한 줄씩 규칙에 추가하세요. 광고·분석·업데이트 서버까지 무분별하게 넣으면 오히려 연결 수와 지연이 커질 수 있습니다.

업무 서비스별 라우팅 범위 조절

세 서비스를 모두 같은 그룹으로 보내는 것이 가장 간단하지만, 업무 성격에 따라 그룹을 나누면 장애 원인을 찾기 쉽습니다. 예를 들어 문서 열람은 안정적인 저지연 노드, 대용량 Figma 파일과 Miro 이미지 동기화는 전송 품질이 좋은 노드를 사용하도록 구성할 수 있습니다. 처음부터 그룹을 여러 개 만들기보다는 하나의 업무 그룹으로 시작한 뒤 서비스별 품질 차이가 확인될 때 분리하는 것이 관리 부담을 줄여 줍니다.

브라우저만 사용하는 환경이라면 시스템 프록시로도 충분할 수 있습니다. 그러나 데스크톱 Figma 앱이나 별도 협업 클라이언트는 운영체제의 HTTP 프록시를 따르지 않는 경우가 있습니다. 이런 앱까지 동일한 규칙을 적용해야 한다면 Mihomo의 TUN 모드를 검토할 수 있습니다. TUN은 더 많은 애플리케이션 트래픽을 포착하지만 DNS와 라우팅 테이블에 영향을 주므로, 회사 VPN이나 가상 네트워크 어댑터와 충돌할 가능성이 있습니다.

DNS와 실시간 동기화 문제 점검

Notion·Figma·Miro의 문제는 단순한 웹페이지 로딩보다 늦게 드러나는 경우가 많습니다. 메인 화면은 열리지만 파일 저장이 지연되거나, Miro에서 다른 사용자의 커서가 보이지 않거나, Figma 공동 편집 상태가 오프라인으로 바뀌는 식입니다. 이러한 현상은 규칙 자체뿐 아니라 DNS 해석과 장시간 연결 유지가 함께 영향을 받습니다.

먼저 Clash 로그에서 해당 서비스 요청이 실제로 WORK-PROXY로 매칭되는지 확인합니다. 직접 연결로 표시된다면 규칙 순서나 도메인 누락이 원인일 수 있습니다. 프록시로 표시되는데도 시간 초과가 발생한다면 선택한 노드의 품질, 서버 지역, WebSocket 지원 여부를 바꾸어 비교하세요. 노드 하나만의 문제인지 모든 노드에서 같은지 구분하는 것이 핵심입니다.

DNS 설정에서는 가짜 IP 모드와 실제 호스트 해석 방식이 현재 프로필의 규칙과 맞아야 합니다. 특정 앱이 IP 주소를 직접 사용하거나 인증서의 호스트 이름을 엄격하게 확인하는 환경에서는 fake-ip 예외가 필요할 수 있습니다. 반대로 브라우저와 웹 협업 서비스 중심이라면 fake-ip가 규칙 분류에 편리한 경우가 많습니다. 이미 안정적으로 동작하는 프로필이라면 이번 작업을 위해 DNS 모드까지 한꺼번에 바꾸지 않는 것이 좋습니다.

1. Notion 페이지를 열고 편집 후 새로고침했을 때 변경 사항이 유지되는지 확인합니다.
2. Figma에서 작은 파일과 큰 파일을 각각 열어 이미지·폰트·공동 편집 상태를 비교합니다.
3. Miro 보드에서 다른 사용자와 댓글을 작성하고, 실시간 변경이 지연 없이 반영되는지 확인합니다.
4. Clash Connections에서 각 요청의规则 매칭 그룹과 연결 시간을 기록합니다.
5. 문제가 생기면 규칙 추가, 노드 변경, TUN 활성화 같은 변경을 한 번에 하나씩 되돌려 원인을 좁힙니다.

브라우저에서 보안 DNS 또는 DoH를 강제로 사용하면 Clash의 DNS 정책과 별도의 질의 경로가 생길 수 있습니다. 이때 도메인은 브라우저에서 해석되지만 실제 연결은 프록시 규칙과 다르게 처리될 수 있습니다. 브라우저의 보안 DNS 설정을 일시적으로 확인하고, 회사 보안 프로그램의 HTTPS 검사나 네트워크 가속 기능도 테스트 중에는 잠시 제외해 보세요. 개인정보 보호와 보안 정책에 맞지 않는 기능을 영구적으로 끄기보다는, 원인을 확인한 뒤 필요한 예외만 적용하는 방식이 바람직합니다.

운영 중 유지 관리와 되돌리기

업무 도메인은 서비스 개편이나 CDN 변경에 따라 달라질 수 있습니다. 따라서 한 번 작성한 규칙을 영구적인 정답으로 생각하지 말고, 프로필 업데이트 후에도 로그인·파일 동기화·실시간 편집을 짧게 확인하는 습관을 들이세요. 특히 구독 업데이트가 기존의 사용자 규칙을 삭제하는지 살펴보고, 로컬 오버라이드가 지원된다면 그 영역에 업무 규칙을 보관하는 편이 안전합니다.

변경 기록에는 날짜, 추가한 도메인, 사용한 노드 그룹, 테스트 결과를 간단히 남기면 좋습니다. 문제가 발생했을 때 모든 규칙을 지우는 대신 마지막으로 정상 작동하던 버전과 비교할 수 있기 때문입니다. YAML을 수정한 뒤에는 클라이언트의 설정 검증 기능으로 문법을 검사하고, 프로필을 다시 로드한 다음 한 서비스씩 확인하세요.

일부 경쟁 프록시 도구는 전체 트래픽을 한 번에 전환하는 데는 편하지만, Notion·Figma·Miro처럼 API와 CDN, WebSocket이 섞인 업무 서비스에서는 예외 규칙과 진단 기능을 세밀하게 관리하기 어렵고 앱마다 프록시 동작도 달라질 수 있습니다. Clash는 규칙 순서와 연결 로그를 직접 확인하면서 필요한 도메인만 분리하고, 시스템 프록시와 TUN을 환경에 맞게 선택할 수 있다는 장점이 있습니다. 업무 트래픽을 더 예측 가능하게 관리하고 싶다면 Clash 무료 다운로드 후 이 글의 최소 규칙부터 적용해 보세요.