Notion·Figma·Miro가 동시에 느려지는 이유

Notion, Figma, Miro를 업무에 함께 사용하는 환경에서는 “브라우저만 프록시를 켜면 되겠지”라고 생각하기 쉽습니다. 하지만 실제 연결은 웹 페이지 하나로 끝나지 않습니다. Notion은 문서 본문과 이미지·파일 저장소, 실시간 동기화 채널을 함께 사용하고, Figma는 디자인 파일 외에도 폰트·이미지·플러그인·실시간 협업 데이터를 별도로 요청합니다. Miro 역시 보드 데이터, 미디어 파일, 댓글과 커서 동기화가 분리되어 있어 특정 도메인 하나만 우회한다고 문제가 해결되지 않을 수 있습니다.

전형적인 증상은 서비스마다 조금씩 다릅니다. Notion은 로그인은 되지만 페이지가 늦게 열리거나 “업데이트 중” 상태가 오래 지속되고, Figma는 캔버스가 빈 화면으로 남거나 팀 파일을 불러오는 데 시간이 걸립니다. Miro에서는 보드 진입은 성공해도 스티커·이미지·커서가 늦게 나타나거나 협업 중 연결이 끊길 수 있습니다. 이때 모든 트래픽을 한 노드로 보내면 간단해 보이지만, 국내 서비스나 사내 시스템까지 불필요하게 우회되어 속도와 안정성이 오히려 나빠질 수 있습니다. 그래서 필요한 것은 전역 우회가 아니라 업무 서비스별 Clash 분할 라우팅입니다.

세 서비스의 트래픽을 먼저 분류하기

규칙을 만들기 전에 어떤 요청이 실제로 발생하는지 관찰해야 합니다. 서비스 이름만 보고 DOMAIN-KEYWORD,figma처럼 넓은 규칙을 넣으면 관련 없는 CDN이나 광고·분석 트래픽까지 같은 노드로 들어갈 수 있습니다. 가장 좋은 순서는 앱을 완전히 종료한 뒤 Clash의 연결 로그를 열고, 한 서비스만 실행하여 로그인·파일 열기·편집·동기화를 차례로 재현하는 것입니다. 이때 호스트 이름, 매칭된 규칙, 선택된프록시 그룹, 연결이 끊긴 시점을 함께 기록합니다.

초기 분류에서는 아래와 같은 서비스 전용 그룹을 따로 두는 편이 관리하기 쉽습니다. 실제 도메인은 클라이언트와 서비스 버전에 따라 달라질 수 있으므로, 다음 목록을 고정된 완성본으로 보기보다 로그를 확인하기 위한 출발점으로 사용하세요.

• Notion: notion.so, www.notion.so와 로그인·파일·동기화 과정에서 로그에 나타나는 관련 호스트를 확인합니다. notion.site는 공개 페이지를 열 때만 필요할 수 있으므로 업무 계정 트래픽과 분리해 판단합니다.
• Figma: figma.com, www.figma.com, 로그인 호스트와 파일·이미지 CDN을 관찰합니다. 플러그인이나 외부 리소스는 Figma 본체와 다른 도메인으로 연결될 수 있습니다.
• Miro: miro.com, www.miro.com 및 보드 진입 후 나타나는 실시간 연결 호스트를 확인합니다. WebSocket 또는 장기 연결이 사용된다면 해당 요청이 매번 같은 정책 그룹으로 나가는지 살펴봅니다.
• 공통 인프라: 인증·폰트·이미지·정적 파일 CDN이 별도 호스트로 나타날 수 있습니다. 무관한 대형 CDN 전체를 강제로 우회하기보다 실제 로그에 반복해서 등장하는 호스트만 추가합니다.

세 서비스는 모두 HTTPS를 사용하므로 일반적인 HTTP 주소를 브라우저 주소창에서 찾는 것만으로는 충분하지 않습니다. Clash 로그의 FQDN을 기준으로 확인하고, 한 번의 페이지 로드에 여러 지역 도메인이 나타나면 먼저 핵심 도메인과 부속 도메인을 분리해 테스트하세요. 규칙을 지나치게 넓히면 Notion·Figma·Miro의 품질이 좋아지는 대신 다른 업무 트래픽이 느려질 수 있습니다.

Clash 분할 규칙과 프록시 그룹 설계

서비스별로 그룹을 만드는 목적은 단순히 이름을 예쁘게 정리하는 데 있지 않습니다. Notion은 긴 문서 작성과 동기화가 많고, Figma는 실시간 캔버스와 대용량 자산을 다루며, Miro는 협업 보드의 장기 연결 안정성이 중요합니다. 세 서비스를 모두 같은 노드에 넣으면 한 서비스의 혼잡이나 노드 변경이 다른 서비스의 작업에도 영향을 줍니다. 처음에는 하나의 WORK-APPS 그룹으로 시작하되, 문제가 계속되면 NOTION, FIGMA, MIRO로 나누는 단계적 접근이 현실적입니다.

# 예시 구조: 실제 호스트는 Clash 로그로 검증
proxy-groups:
  - name: WORK-APPS
    type: select
    proxies:
      - 업무용 저지연 노드
      - 업무용 안정 노드
      - DIRECT

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

위 예시는 구조를 이해하기 위한 기본형입니다. 제공업체 구독에 이미 RULE-SET, 지역별 그룹, 광고 차단 규칙이 포함되어 있다면 같은 도메인이 아래쪽에서 다시 매칭되지 않도록 업무 서비스 규칙을 더 위에 배치해야 합니다. Clash 규칙은 일반적으로 위에서 아래로 평가되므로, 넓은 GEOIP나 MATCH가 먼저 나오면 Notion·Figma·Miro 전용 규칙이 실행되지 않습니다.

1. 현재 설정 백업: 사용 중인 YAML을 복사해 날짜를 붙인 파일로 저장합니다. 문제가 생겼을 때 전체 구독을 다시 가져오는 것보다 변경 전후를 비교하는 편이 빠릅니다.
2. 업무 그룹 생성: 먼저 WORK-APPS를 만들고 저지연 노드와 안정성 중심 노드를 함께 넣습니다. 자동 선택 그룹을 사용한다면 짧은 지연 시간만 보지 말고 장시간 연결이 유지되는지도 확인합니다.
3. 도메인 규칙 추가: 실제로 관찰한 호스트에 한해 DOMAIN-SUFFIX 또는 정확한 DOMAIN 규칙을 넣습니다. Figma나 Miro의 부속 호스트는 로그에서 반복성과 서비스 연관성을 확인한 뒤 추가합니다.
4. 규칙 순서 확인: 업무 규칙을 지역 규칙, 광고 규칙, 최종 MATCH보다 위에 둡니다. 같은 도메인을 다른 프록시 그룹으로 보내는 중복 규칙도 제거합니다.
5. 한 서비스씩 재현: Notion 페이지 열기, Figma 팀 파일 편집, Miro 보드 이동처럼 실제 작업을 수행하고 연결 로그에서 올바른 그룹이 선택되는지 확인합니다.

TUN과 DNS를 함께 조정해야 하는 경우

브라우저에서 Notion·Figma·Miro를 사용할 때는 시스템 프록시만으로 충분한 경우가 많습니다. 그러나 데스크톱 앱, Figma의 별도 헬퍼 프로세스, 다른 브라우저, 사내 문서 도구를 동시에 사용하는 환경에서는 앱이 시스템 프록시 설정을 무시할 수 있습니다. 이때는 TUN 모드로 운영체제의 연결을 Clash 가상 인터페이스로 가져오는 방법을 고려할 수 있습니다.

TUN을 켜면 브라우저만이 아니라 터미널과 일부 백그라운드 프로세스도 규칙의 영향을 받습니다. 편리하지만 범위가 넓어지므로, 먼저 기존 VPN·보안 에이전트·다른 프록시 클라이언트를 종료하고 충돌 여부를 확인해야 합니다. Windows에서는 서비스 모드와 관리자 권한, macOS에서는 네트워크 확장 승인과 로그인 항목을 점검하세요. TUN을 켠 뒤 인터넷 전체가 끊긴다면 곧바로 규칙을 더 추가하지 말고 TUN을 끈 상태와 비교해 DNS·라우팅·권한 중 어느 층에서 문제가 생겼는지 분리합니다.

DNS 설정은 분할 라우팅의 또 다른 핵심입니다. 도메인은 올바른 IP로 해석되었는데 연결이 DIRECT로 나가거나, 반대로 로컬 DNS가 잘못된 응답을 반환해 서비스가 지역·인증 상태를 다르게 판단할 수 있습니다. fake-ip와 redir-host 중 무엇을 쓸지는 클라이언트와 네트워크에 따라 달라지므로 한 가지를 무조건 권장하기보다 연결 로그와 실제 작업 결과로 결정해야 합니다. DNS 누수나 사내 도메인 장애가 발생하면 업무용 내부 도메인은 명시적으로 직결하고, Notion·Figma·Miro 관련 호스트는 동일한 정책으로 일관되게 처리하세요.

• DNS 오류만 발생: 서비스가 열리지 않거나 로그인 화면이 반복되면 DNS 응답, 캐시, DoH 설정과 시스템 DNS를 비교합니다.
• 페이지는 열리지만 동기화 실패: 본체 도메인과 실시간 연결·파일 호스트가 서로 다른 그룹으로 빠지는지 로그를 확인합니다.
• 앱만 실패: 시스템 프록시를 따르지 않는 프로세스일 수 있으므로 TUN 적용 여부와 앱 재시작 순서를 확인합니다.
• 전체 네트워크 불안정: TUN·DNS·다른 VPN의 중복을 의심하고 한 번에 하나씩 비활성화하여 차이를 기록합니다.

업무 흐름별 테스트와 장기 유지보수

설정이 끝났다고 바로 성공으로 판단하지 말고, 실제 업무에서 사용하는 동작을 순서대로 점검해야 합니다. Notion에서는 로그인, 페이지 이동, 이미지 업로드, 오프라인 상태에서 작성한 내용의 동기화를 확인합니다. Figma에서는 팀 파일 열기, 여러 페이지 이동, 이미지 배치, 폰트 로딩과 공동 편집을 차례로 테스트합니다. Miro에서는 보드 진입, 확대·축소, 이미지와 PDF 첨부, 댓글 작성, 다른 사용자의 커서와 변경 사항 반영을 확인합니다.

각 테스트 직후 Clash 로그를 저장하면 어떤 요청이 어느 그룹으로 갔는지 나중에 비교할 수 있습니다. 페이지는 열리지만 이미지가 늦다면 CDN 규칙을, 편집은 되지만 공동 작업이 끊기면 장기 연결 호스트와 노드 안정성을, 로그인만 반복된다면 인증 호스트와 DNS를 우선 살펴보세요. 오류 메시지를 보고 무작정 도메인 전체를 추가하는 것보다, 한 번에 한 규칙만 바꾸고 같은 동작을 다시 재현하는 방식이 훨씬 정확합니다.

구독이 갱신되면 사용자 규칙이 덮어써지거나 그룹 이름이 바뀔 수 있습니다. 따라서 수동으로 추가한 업무 규칙은 제공업체가 관리하는 원본과 분리된 오버라이드 영역에 보관하고, 업데이트 후 WORK-APPS 그룹과 규칙 순서가 남아 있는지 확인하세요. 노드가 바뀌면 최소 한 번은 Notion 파일 동기화, Figma 실시간 편집, Miro 보드 협업을 다시 테스트하는 것이 좋습니다. 업무 중에는 자동 노드 변경이 세션을 끊을 수 있으므로 중요한 회의나 디자인 리뷰 전에는 안정성이 검증된 노드를 고정하는 편이 안전합니다.

일부 범용 프록시 앱은 서비스별 규칙을 직접 넣기 어렵거나, TUN·DNS·WebSocket 동작을 한 화면에서 확인하기 힘들어 Notion·Figma·Miro를 함께 쓰는 업무 환경에서 원인 파악이 번거롭습니다. 반대로 Clash 공식 사이트는 구독과 규칙을 분리해 관리하고, 연결 로그와 TUN·DNS 설정을 단계적으로 점검할 수 있어 필요한 트래픽만 업무용 노드로 보내는 흐름을 만들기 좋습니다. 모든 트래픽을 무조건 우회하지 않고 이 글의 순서대로 서비스별 도메인을 확인해 보고 싶다면, Clash 공식 사이트를 다운로드해 본인 환경에 맞는 분할 설정부터 차근차근 적용해 보세요.