1. 증상을 먼저 나누기: 자산·API·실시간은 다른 표정으로 깨집니다
사용자 입장에서는 모두 “Figma 가 느리다”로 느껴지지만 관찰 포인트는 갈립니다. 첫째, 파일 썸네일·팀 라이브러리는 보이는데 특정 파일을 열면 캔버스 영역만 하얗게 길게 머무는 경우입니다. 둘째, 편집은 되는데 동료 커서·선택 하이라이트가 멈추거나 몇 초 뒤에야 따라오는 경우입니다. 셋째, 댓글 스레드가 한쪽 클라이언트에서만 갱신되거나 새 메시지가 역순으로 섞여 보이는 경우입니다. 넷째, 브라우저 탭은 정상인데 데스크톱 앱 만 같은 증상을 보이는 경우입니다. 다섯째, 특정 노드로 바꾸면 즉시 나아지고 다른 노드에서는 항상 같은 패턴이 반복되는 경우입니다. 각각은 TLS 종단·지연·세션 유지 특성이 조금씩 달라서, 한 번에 “Figma 전부 PROXY” 로 덮기보다 연결 로그에 찍힌 호스트 를 근거로 묶는 편이 안전합니다.
구독 YAML 을 아직 익숙하게 다루지 않는다면 구독 가져오기 튜토리얼에서 프로필을 먼저 안정화한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.
2. 왜 CDN·HTTPS·WebSocket을 같은 ‘Figma 세션’으로 묶어야 하나요?
에디터가 뜨기까지는 HTML·JS 번들·폰트·이미지 프리뷰가 여러 호스트에서 내려옵니다. 세션이 열린 뒤에는 문서 변경·프레즌스·협업 이벤트가 실시간 채널로 이어지는데, 이 경로가 끊기면 화면은 “반쯤” 살아 있는 것처럼 보입니다. 공항 규칙이 *.figma.com 일부만 프록시로 보내고 나머지 접미사를 DIRECT 로 보내면, 브라우저 입장에서는 TLS 세션이나 캐시 키가 어긋나 협업 로딩 실패 가 난 것처럼 보이기도 합니다. 반대로 모든 트래픽을 지연 큰 먼 노드로만 몰면 실시간 채널이 버벅여 커서가 끊깁니다. 그래서 “같은 제품이라도 목적별 호스트를 한 출구에 묶고, 로그로 검증한다”는 접근이 중요합니다.
Figma 측 네트워크 가이드는 조직·제품 에디션에 따라 허용 도메인 목록을 안내합니다. 기업 방화벽 문서에 나오는 *.figma.site · *.awswaf.com · esm.sh · jsdelivr.net 같은 보조 호스트는 플러그인·임베드·보안 검증 흐름에서 함께 붙을 수 있으니, 증상이 “플러그인 패널만 비었다”처럼 좁을 때는 연결 로그에 이 접미사가 섞였는지도 확인하세요.
Clash 계열은 버전과 코어에 따라 UDP·TUN·스니핑 옵션 세부가 다릅니다. 이 글은 특정 필드 이름을 강제하지 않고, Mihomo 최신 문서와 GUI 설명을 함께 보는 전제에서 공통 원리만 짚습니다.
3. 권장 점검 순서
- Clash 가 켜져 있는지, 시스템 프록시 인지 TUN 인지 기록합니다.
- 실시간 연결 목록에서 figma·static·cdn·wss 관련 호스트가 기대한 정책 그룹으로 나가는지,
DIRECT로 새는지 확인합니다. - 파일을 열 때와 동시 편집을 시작할 때 로그가 어떻게 달라지는지 비교합니다.
fake-ip사용 여부와 DNS 해석 정책을 확인하고, 필요하면 핵심 접미사에nameserver-policy를 둡니다.- 로그에서 본 호스트를
DOMAIN-SUFFIX규칙으로 올리고, 공급자 규칙·로컬 규칙의 순서 충돌을 정리합니다. - 브라우저와 데스크톱 앱을 각각 시험해 경로 차이가 있는지 확인합니다.
4. 브라우저 탭과 데스크톱 앱: 프록시를 따르는 경로가 다를 수 있습니다
Chromium 계열 브라우저는 시스템 프록시를 잘 따르는 편이지만, Electron 기반 데스크톱 앱 은 내부 네트워크 스택이나 인증서 저장소 차이로 일부 요청이 DIRECT 로 나가기도 합니다. “웹만 되고 앱만 스피너” 패턴이면 이런 경로 차이를 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. 다만 다른 상시 VPN 과 동시에 켜면 어댑터 충돌이 생길 수 있으니, 한 번에 하나의 터널만 남기고 다시 테스트하세요.
회사 단말에서 SSL 검사·PAC·WPAD 가 섞이면 브라우저와 OS 가 서로 다른 “출구”를 보기도 합니다. Clash 쪽 규칙을 고치기 전에 IT 정책과 충돌하지 않는지 확인하는 것이 안전합니다.
5. DNS·fake-ip: 규칙과 어긋나면 협업만 유령처럼 끊깁니다
fake-ip 는 체감 지연을 줄이는 데 도움이 될 수 있지만, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 핸드셰이크가 반복되고 실시간 채널은 짧게 붙었다가 끊기는 패턴이 나옵니다. 특히 Figma CDN 처럼 서브도메인마다 다른 엣지로 붙는 서비스에서 두드러집니다.
상위 DNS 가 신뢰 가능하고 Clash 에서 도달 가능한지 먼저 확인한 뒤, figma.com 등 핵심 접미사에 별도 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 최신 문서와 예제를 함께 보는 것이 안전합니다. 규칙을 고친 뒤에는 OS DNS 캐시를 비우거나 Figma 를 완전히 종료했다가 다시 열어 이전 세션이 남지 않게 하는 것도 도움이 됩니다.
6. 도메인 수집: 연결 패널이 최우선 증거입니다
인터넷에 떠도는 “완성된 Figma 도메인 목록”은 배포 시점과 지역·ISP 에 따라 빠르게 달라질 수 있습니다. 그래서 이 글은 고정 목록을 외우게 하기보다, 본인 PC 세션에서 실제로 붙는 호스트 를 모으는 절차를 권장합니다.
Clash Verge Rev 등 GUI 에서 실시간 연결을 연 뒤 Figma 에서 파일을 열고, 동료를 초대해 동시 선택·댓글을 남겨 보세요. www.figma.com·figma.com 외에 static.figma.com 같은 자산 호스트, API 성격의 서브도메인, WebSocket 업그레이드가 보이는 호스트를 메모합니다. 실패한 연결(타임아웃·리셋)의 접미사를 우선적으로 규칙에 올리면 체감이 가장 큽니다.
Figma 프록시 문제를 줄이려면 “추측으로 노드만 바꾸기”보다, 로그에 찍힌 문자열을 그대로 복사해 두었다가 규칙에 반영하는 습관이 더 빠릅니다.
7. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름과 개수는 반드시 연결 로그로 검증해야 합니다.
| 구분 | 예시 방향 | 메모 |
|---|---|---|
| 핵심 앱·API | figma.com 및 하위 호스트 | 로그인·파일 메타·에디터 셸과 함께 묶였는지 봅니다. |
| 게시·임베드 | figma.site 계열 | 프로토타입 공유·사이트 기능에서 별도로 보일 수 있습니다. |
| 정적 자산·CDN | static.figma.com 등 | Figma CDN 성격 호스트가 API 와 같은 출구인지 확인합니다. |
| 실시간 협업 | 로그에 보이는 WebSocket 호스트 | 커서·프레즌스 이벤트가 붙는 순간 로그가 바뀌는지 봅니다. |
| 보조·플러그인 | jsdelivr.net·esm.sh·awswaf.com | 조직 가이드와 증상 범위에 맞춰 선택적으로 추가합니다. |
8. 규칙 예시 (정책 그룹 이름은 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,figma.com,PROXY
- DOMAIN-SUFFIX,figma.site,PROXY
- DOMAIN-SUFFIX,figma-gov.com,PROXY
- DOMAIN-SUFFIX,figma-gov.site,PROXYDOMAIN-KEYWORD,figma 는 편하지만 다른 서비스와 충돌할 수 있으니 과도하게 쓰지 말고, 로그에 근거해 접미사를 좁히세요. 먼저 같은 출구로 묶인 상태에서 안정화 한 뒤, 자산만 저지연 노드·실시간만 다른 그룹으로 나누는 식의 세분화를 검토할 수 있습니다. 다만 한 세션 안에서 호스트가 서로 다른 출구를 보면 인증·지역 판정이 꼬일 수 있으니 단계적으로 접근하세요.
Figma 측 호스트 명은 시기에 따라 바뀔 수 있으므로, 위 예시는 출발점으로만 두고 본인 세션 기준으로 덮어쓰는 것이 좋습니다.
9. WebSocket·Upgrade: 차단·중간 프록시를 함께 봅니다
실시간 협업은 HTTP 업그레이드나 장시간 유지 연결에 민감합니다. 회사 게이트웨이가 WebSocket 을 끊거나, 중간 캐시가 업그레이드 헤더를 깨면 증상은 Clash 규칙과 무관하게 남을 수 있습니다. Clash 쪽에서는 해당 호스트가 기대한 노드로 나가는지, TLS 스니핑·규칙 순서 때문에 엉뚱한 정책에 걸리지 않는지부터 확인하세요.
지터가 큰 노드는 대화형 세션에 불리합니다. 규칙이 맞는지 확인한 뒤에는 손실이 적은 회선을 고정하거나 자동 전환 임계값을 완화하는 편이 낫습니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
10. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,CN,DIRECT 같은 광범위 규칙이 있으면, 일부 CDN 엣지가 의도치 않게 직결로 보내져 “한국 노드를 썼는데도 썸네일만 안 받아진다”는 패턴이 납니다. 이럴 때는 Figma 관련 블록을 규칙 상단에 두거나, 충돌하는 공급자 규칙 뒤에 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요.
구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리는 경우도 흔합니다. “Figma 전용 블록”을 파일 상단에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.
11. GUI 워크플로: Clash Verge Rev
연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. 대용량 CDN 분류 패턴을 이미 다뤄본 적이 있다면 Steam 상점·CDN 분류 가이드와 로그 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.
12. 그래도 안 될 때: 일반 트러블슈팅과의 교차
포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 7890 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Figma 전용 단계로 돌아오세요.
13. 정리: 로그 근거를 한 층씩 쌓기
Figma Clash 조합에서 캔버스 가 길게 스피너 에 머물거나 실시간 협업 · 댓글 이 어긋나는 현상은 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·WebSocket 경로·노드 품질 이 겹친 결과인 경우가 많습니다. 이 글의 순서대로 연결 로그 증거를 남기면 불필요한 노드 순환과 잘못된 DIRECT 를 빠르게 줄일 수 있습니다.
설정 파일을 매번 직접 고치기보다 Mihomo 를 내장한 공식 클라이언트에서 로그·업데이트·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash 를 무료로 내려받고 Figma 세션을 같은 출구로 묶어 보세요