증상: 캔버스·실시간 협업 쪽을 어떻게 읽을까
흔한 패턴만 골라도 네 가지는 넘어갑니다. 첫째, 로그인·대시보드는 되는데 특정 파일을 열 때만 캔버스가 회색·스피너에서 벗어나지 않는 경우입니다. 둘째, 브라우저는 나아졌다가 데스크톱 앱(Electron)에서만 반복되거나, 그 반대로 한쪽만 불안한 경우로, 시스템 프록시·앱 자체 프록시 설정이 갈라진 신호로 볼 수 있습니다. 셋째, 협업 상대의 커서·댓글만 늦거나 끊기는데, 정적 UI 자산(아이콘·썸네일)은 비교적 괜찮은 경우입니다. 넷째, 특정 회사망·지역에서만 재현되고, 모바일 테더링으로 바꾸면 사라지는 경우입니다. 공통으로 의심할 것은, 한 화면 뒤에서 짧은 REST와 수 분 이상 유지되는 wss가 서로 다른 IP·노드를 보면서도 화면만은 하나로 보여야 한다는 점입니다. WebSocket은 프록시·NAT·불안정한 노드에 특히 민감하고, 한번 끊기면 “갑자기 협업이 죽었다”로 느껴집니다.
Clash 관점에서는 “figma·관련 도메인이 실제로 어떤 정책 그룹으로 이어졌는지”를 먼저 선명히 해야 합니다. GEOIP나 거대 RULE-SET이 위에서 먼저 매칭되면, 하단에 적어 둔 Figma 전용 줄이 실행되지 않을 수 있습니다. 또 HTTPS로 보이는 첫 응답은 나오는데 wss만 다른 출구를 타는 현상이 있으면, 앱은 같은 파일을 편집하는 것 같아도 백엔드 뷰가 엇갈린 상황에 가깝습니다. 따라서 “빠른 노드”를 찾기 전에 규칙 적중 로그·DNS·실제 아웃바운드를 같은 축에 두는 것이 먼저입니다.
이 글은 일반 “가속”이 아닙니다
트래픽을 아무 곳이나 PROXY로 밀어 넣는 방식이나, 체감 지연만 줄이는 문구는 범위 밖입니다. 여기서의 안정은 디자인 협업이 요구하는 일관된 경로, 즉 같은 계정·같은 파일에서 캔버스·실시간·부가 API가 서로 모순 없이 열리는 상태에 가깝습니다. 회사·클라이언트 정책·개인정보를 어기는 우회는 다루지 않으며, 합법적이고 본인이 권한 있는 네트워크에서의 트러블슈팅을 전제로 합니다.
1어떤 호스트·WebSocket이 붙는가
고정 명단보다 본인 환경에서 관측한 이름이 우선입니다. 브라우저 개발자 도구 Network에서 figma·livegraph 등으로 필터하고, WS·Fetch·Img·EventSource를 같이 봅니다. figma.com·www.figma.com 접두의 HTTPS와, wss로 열리는 실시간 스트림이 동시에 존재하는 경우가 일반적이며, CDN·인증·업로드용 서브도메인이 더해질 수 있습니다. 데스크톱 앱은 웹과 엔드포인트 묶음이 다를 수 있으므로, 웹에서 잡은 규칙을 앱에 그대로 복제하기 전에 앱 쪽 연결·로그로 한 번 더 대조하는 편이 안전합니다.
이렇게 모은 목록을 Clash 클라이언트의 연결·로그와 맞춰 보면, “왜 wss만 다른 정책이 찍혔는가”를 빠르게 좁힐 수 있습니다. 로그에 IP만 남고 도메인이 비면 아래 Sniffer 절과 같이 읽어야 DOMAIN 규칙이 살아납니다.
WebSocket·Livegraph 쪽이 민감한 이유
디자인 협업에서 동시 편집·커서·프레젠스는 WebSocket 등 장기 TCP를 자주 씁니다. 장기 연결은 중간에 프록시·회선 품질에 의해 조용히 끊기고, 클라이언트는 재접속·재시도를 반복하므로 사용자 눈에는 “캔버스가 잠시 멈췄다”·“협업이 갑자기 안 된다”로만 보이기 쉽습니다. 짧은 HTTP 실패보다 원인 추적이 어려운 이유이기도 합니다. 분류 규칙이 편집 중에 바뀌거나·url-test가 노드를 자주 갈아탈 때는 기존 wss가 함께 재수립되어야 하므로, 체감으로는 무한 로딩에 가깝게 느껴질 수 있습니다.
요약: Figma 문제를 볼 때는 “첫 화면이 열렸는지”뿐 아니라, wss·Livegraph 계열이 어떤 정책으로 이어졌는지를 한 세트로 봅니다.
2분류 규칙 최소 예시(illustration)
아래는 설명용 스케치입니다. PROXY 자리에는 구독에 정의된 실제 정책 그룹 이름을 넣고, 상단에 GEOIP·MATCH가 있다면 규칙 순서를 함께 조정하세요. 엔드포인트는 제품 업데이트로 바뀔 수 있으니, 이 접미사는 출발점이고 관측으로 보완합니다.
# Illustration — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,figma.com,PROXY
- DOMAIN-SUFFIX,figmafile.com,PROXY
- MATCH,DIRECT
DOMAIN-SUFFIX는 같은 접미사 아래 여러 서브도메인을 한꺼번에 덮기에 편합니다. 반대로 너무 넓은 접미사를 쓰면 무관 트래픽까지 같은 노드로 몰릴 수 있으니, 로그에 자주 뜨는 이름부터 시작해 점진적으로 좁히는 편이 안전합니다. 유지보수를 위해 Rule Provider로 묶어 두면 엔드포인트가 늘어도 파일만 갈아끼울 수 있습니다. 대규모 규칙 세트 선택은 ACL4SSR·rule provider 글을 참고하세요.
규칙 순서: 첫 매칭이 결론
Clash 계열은 rules를 위에서 아래로 읽으며 처음 맞는 줄이 결론입니다. 그 위 한 줄이 먼저 매칭되면, 아래의 Figma 전용 줄은 실행되지 않을 수 있습니다. “파일엔 figma 줄이 있는데 로그엔 다른 정책만 찍힌다”면 이 순서부터 의심합니다. 국내 직결이 낫다는 환경이면 같은 접미사를 DIRECT로 두되, 문제가 재현되는지 다시 확인하세요. 핵심은 본인 회선에서 로그로 증명하는 것입니다.
3Sniffer: HTTPS·wss가 IP로만 찍힐 때
로그에 IP만 있고 호스트가 비면 DOMAIN 규칙이 빗나갑니다. Clash Meta(Mihomo)의 Sniffer는 TLS SNI·HTTP/2 등에서 도메인을 복원해 매칭을 안정화합니다. 설정 흐름·주의점은 Clash Meta Sniffer 가이드에 정리되어 있으며, Figma처럼 장기 세션이 많은 앱일수록 “이름이 보이는지”가 규칙 품질과 직결됩니다.
4DNS·FakeIP·DoH를 분류와 맞추기
FakeIP를 쓰는 프로필에서는 내부 IP 풀과 터널 목적지가 엇갈리면 규칙 매칭이 흔들릴 수 있습니다. DoH를 OS나 브라우저에 별도로 켜 두면 “같은 이름인데 응답 경로가 다르다”는 상황도 생깁니다. 단계별 체크리스트와 설정 패턴은 Meta 코어 DNS 유출 방지 가이드를 먼저 따르고, 변경은 한 겹씩만 적용해 재현 실험을 반복하는 편이 디버깅 비용을 줄입니다.
5TUN·브라우저·데스크톱: 캡처 범위
브라우저만 시스템 프록시를 따르고, Figma Electron 앱이 다른 경로로 나가면 캔버스·협업 상태가 플랫폼마다 제각각일 수 있습니다. 이때 TUN은 시스템 라우팅에 가깝게 개입해 누락 트래픽을 규칙 표 안으로 끌어오는 데 유리합니다. 가상 어댑터·권한까지 맞추는 절차는 Clash Verge Rev TUN 모드 가이드를, Windows 초기 설치는 Windows Clash 설치 글과 함께 보는 순서가 안전합니다. UDP 음성이 겹치는 메신저는 Discord·UDP·TUN 글과 대조해 읽으면, TCP·장기 연결과 UDP의 차이를 정리하기 쉽습니다.
주의: 사내 VPN·엔드포인트 보안·공유기 DNS 가로채기가 동시에 켜 있으면 Clash만 고쳐도 증상이 남을 수 있습니다. 단일 경로로 줄인 뒤 다시 재현해 보세요.
노드·url-test·자동 전환과 장기 연결
규칙이 맞아도 출구 노드가 불안정하면 WebSocket이 중간에 끊깁니다. 지연이 낮아 보여도 손실·지터가 크면 체감 협업 끊김은 커집니다. url-test·fallback류 정책 그룹은 편리하지만, 전환 순간 기존 wss 세션이 함께 재수립되어야 하므로, 과도한 잦은 스위칭은 오히려 로딩처럼 보일 수 있습니다. 자동 전환 임계값은 보수적으로 두고, 먼저 규칙·DNS가 안정일 때만 url-test·fallback을 세밀하게 조정하는 편이 낫습니다.
6검증 순서
- Network·클라이언트 로그에서 Figma 관련 호스트와 정책 이름을 목록으로 남깁니다.
- 분류 규칙을 최소 세트로 올린 뒤, 같은 동작을 반복해 적중이 바뀌었는지 확인합니다.
- DNS·FakeIP·스니퍼를 한꺼번에 건드리지 않고 한 층씩 맞춥니다.
- 웹과 데스크톱 앱을 번갈아 시험해 캡처 범위(시스템 프록시 vs TUN) 차이를 비교합니다.
- 다른 회선(테더링 등)에서 같은 절차를 밟아 “규칙 문제인지 회선·노드 문제인지”를 나눕니다.
팀 파일·댓글 내용은 로그에 남지 않게 주의하고, 회사 자산을 다루는 경우 IT 정책을 우선합니다.
오픈소스 정보와 설치 패키지
Mihomo와 GUI 포크의 라이선스·이슈는 GitHub에서 확인할 수 있지만, 클라이언트 설치 파일의 주 경로로는 이 사이트의 Clash 다운로드 페이지를 권장합니다. 소스는 신뢰 확인용으로 두고 업무용 업데이트는 허브에 맞추면 혼선이 줄어듭니다. 전체 옵션 지도는 문서·설정 허브 목차와도 연결됩니다.
맺음말
Figma의 캔버스가 느리거나 협업이 끊기는 느낌은, 종종 단일 호스트의 지연이 아니라 캔버스·Livegraph·CDN·인증이 한 화면에서 동시에 돌아가며 서로 다른 네트워크 조건을 만날 때 크게 드러납니다. Clash로 이를 다루는 핵심은 감으로 노드를 바꾸는 것이 아니라, 어떤 이름이 어떤 정책을 탔는지 로그로 확인하고, DNS·FakeIP·Sniffer·TUN을 같은 전제로 정렬하는 일입니다. 이 틀은 다른 UI SaaS·장기 WebSocket 앱에도 그대로 이식할 수 있습니다.
Notion·동기·WebSocket을 다룬 글과 병행해 읽으면, 문서 동기와 디자인 캔버스의 불만 패턴을 구분하기 쉽습니다. Clash Meta 계열은 정책 이름과 로그 대응이 읽기 쉬운 편이라, “가끔만” 터지는 현상을 재현 가능한 사실로 바꾸기에 유리합니다.
→ Clash를 무료로 다운로드하고, Figma·figma.com·WebSocket 경로를 한 프로필에서 점검해 보세요