Figma가 로딩만 돌거나 열리지 않을 때: Clash(mihomo)로 Figma·FigJam·정적 CDN 도메인을 분기하는 실측 (2026)

1. 왜 AI 도구 글과 다른가: 디자인 협업 스택의 네트워크

Figma와 FigJam은 브라우저 탭 하나처럼 보이지만, 내부적으로는 편집기 셸을 그리는 HTML·자바스크립트 번들, 아이콘·일러스트 같은 정적 자원, 웹폰트 로더, 실시간 멀티플레이어에 가까운 동기화 채널이 동시에 돌아갑니다. 이 중 일부는 figma.com 트리에 남고, 다른 일부는 서브도메인이나 제3자 CDN으로 빠져 나가기 때문에 「한 줄짜리 도메인만 추가하면 된다」는 접근으로는 부족합니다. Clash 분기에서는 도메인 규칙의 커버리지와 우선순위를 같이 봐야 하고, 특히 일부 요청만 다른 노드로 새거나 DIRECT로 떨어지면 UI 상태가 쉽게 깨집니다.

프록시 코어가 해 줄 수 있는 일은 관측된 호스트명을 일관된 정책 그룹으로 보내고, DNS 해석 경로가 규칙과 어긋나지 않게 맞추는 것까지입니다. 팀 플랜·SSO·기업 방화벽·지역 정책은 네트워크 분기와 별개이니, 증상을 좁힐 때 섞지 않는 편이 좋습니다. 베이스 프로필이 아직이라면 구독 가져오기로 안정적인 기본 축을 만든 뒤, 아래 스니펫을 rules 상단 쪽에 합류시키는 흐름을 권합니다.

OTT나 소셜처럼 대역폭 피크가 큰 서비스와 달리, 디자인 편집기는 지연에 민감한 상호작용과 작은 실패의 누적이 체감으로 드러나는 편입니다. 그래서 메인과 정적 자원·CDN이 서로 다른 출구를 타면 「전체가 안 된다」기보다 「한참 돌다가 겨우 열린다」 같은 모호한 패턴이 나옵니다. 이 점에서 본문은 Netflix·YouTube류 글과 검증 포인트가 조금 다릅니다.

2. 흔한 증상: 스피너·부분 로딩·FigJam 지연

파일 목록은 보이는데 캔버스가 비어 있거나, 상단 로딩 표시가 길게 남는 경우는 API·실시간 채널 쪽이 막혔을 가능성이 큽니다. 아이콘·썸네일·일부 패널만 깨지면 번들·이미지 호스트가 다른 정책으로 나가고 있을 때가 많습니다. 글꼴이 시스템 기본값으로 바뀌거나 레이아웃이 순간적으로 무너지면 웹폰트 축이 직행이거나 차단된 경우를 의심합니다. FigJam만 유독 느리면 같은 figma.com 트리 안에서도 세션 종류가 달라 일부 서브요청만 로그에 따로 찍히는지 확인할 가치가 있습니다.

「브라우저는 되는데 데스크톱 앱만 이상하다」면 OS 프록시·앱 자체의 프록시 무시·TUN 미사용 패턴을 봅니다. 반대로 앱만 되고 브라우저만 이상하면 브라우저 DoH·확장 프로그램이 Clash 밖으로 새는지 의심합니다. 디버깅 첫 단계는 항상 같습니다. 개발자 도구 Network 탭에서 pending·failed 요청의 Host를 적고, mihomo 디버그 로그에서 같은 호스트가 어떤 RULE에 걸렸는지 대조합니다.

가끔 재시도에 성공해 「저절로 나았다」처럼 보이는 경우도 있지만, 근본적으로는 규칙 순서와 DNS가 흔들리지 않게 고정해야 체감이 안정됩니다. Sniffer 글과 교차해 보면 IP로 먼저 들어온 연결이 도메인 규칙을 건너뛰는지 빠르게 확인할 수 있습니다.

3. 도메인 축: figma.com·API·정적·웹폰트

아래 분류는 커뮤니티 규칙과 필드 로그에서 자주 보이는 출발점입니다. 제품 업데이트로 호스트가 바뀔 수 있으니, 화이트리스트를 통째로 복사하기보다 관측 → 규칙 보강 루프를 전제로 두세요.

• 브랜드·앱 셸: figma.com, www.figma.com, 임베드·도움말에 쓰이는 embed.figma.com, help.figma.com 등. 편집기 진입과 라우팅에 해당합니다.
• API·백엔드: api.figma.com 및 *.figma.com 계열. 여기가 직행이면 「UI는 있는데 파일이 안 연다」 패턴이 잘 납니다.
• FigJam: 제품은 같은 계정·같은 도메인 트리 안에서 동작하는 경우가 많아, 우선 DOMAIN-SUFFIX,figma.com으로 묶고 로그에 별도 호스트가 보이면 추가합니다.
• 웹폰트(선택): 인터페이스가 Google Fonts를 쓰는 구간이 있으면 fonts.googleapis.com, fonts.gstatic.com이 Network에 뜹니다. 다른 Google 서비스와 출구를 나누고 싶다면 별도 정책 그룹을 두거나, 기존 Google 분기 규칙과 순서 충돌이 없는지 확인합니다.
• 스토리지·CDN(간헐): 첨부·내보내기·일부 자산이 *.amazonaws.com 또는 *.cloudfront.net 형태로 보일 수 있습니다. 범위가 넓어 다른 SaaS와 충돌할 수 있으니, 로그에 찍힌 FQDN부터 좁히는 편이 안전합니다.

4. mihomo rules·proxy-groups 예시

mihomo에서는 넓은 GEOIP·MATCH보다 위쪽에 Figma 묶음을 두는 것이 안전합니다. 정책 그룹 이름 ▶️ Figma는 예시이며, 본인 구독의 셀렉터·노드 이름으로 바꿉니다. 병합 순서 개념은 고급 라우팅 가이드와 함께 읽으면 이해가 빨라집니다.

proxy-groups:
  - name: ▶️ Figma
    type: select
    proxies:
      - Stable-A
      - Stable-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,figma.com,▶️ Figma
  - DOMAIN,api.figma.com,▶️ Figma
  - DOMAIN,embed.figma.com,▶️ Figma
  # Optional: only if Network tab shows pending font hosts
  - DOMAIN-SUFFIX,googleapis.com,▶️ Figma
  - DOMAIN-SUFFIX,gstatic.com,▶️ Figma
  # Optional catch — verify in logs; may overlap other Google traffic
  - DOMAIN-KEYWORD,figma,▶️ Figma
  # ... GEOIP PRIVATE, MATCH, etc.

5. DNS·Fake-IP·nameserver-policy

Fake-IP 모드는 도메인 기반 규칙과 궁합이 좋지만, 브라우저·OS의 DNS over HTTPS가 우선하면 해석이 코어 밖으로 새어 규칙과 실제 연결이 어긋날 수 있습니다. www.figma.com과 api.figma.com이 서로 다른 리졸버를 타면, TLS는 잡혀도 애플리케이션 계층에서 끊임없이 재시도하는 모호한 증상이 나옵니다. Claude 편의 Fake-IP 점검표를 확장해, 「해석 결과의 출구」와 「로그에 찍힌 아웃바운드」가 같은 노드 풀을 가리키는지 먼저 확인하세요.

특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. 예시는 참고용이며, 실제 업스트림은 본인 정책에 맞게 교체합니다.

# Optional snippet — adjust resolvers to your policy
dns:
  nameserver-policy:
    "+.figma.com":
      - https://dns.google/dns-query

설정을 바꾼 뒤에는 OS·브라우저 세션 캐시가 남아 가짜 음성(false negative)을 만들 수 있습니다. 테스트 구간에서는 클라이언트를 한 번 재시작하거나 시크릿 창을 쓰는 것이 재현성을 높입니다. 전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것도 좋습니다.

6. Sniffer·SNI와 로그 대조

연결이 먼저 IP 형태로 코어에 들어오면 DOMAIN 규칙을 건너뛰고 GEOIP나 MATCH로 떨어져, Figma의 일부 서브요청만 직행하는 상황이 생깁니다. 이때 Sniffer가 TLS ClientHello의 SNI에서 호스트명을 복원해 주면 다시 도메인 규칙으로 되돌릴 수 있습니다. 절차는 Sniffer 전용 글의 순서를 그대로 밟되, 편집기 세션처럼 병렬 요청이 많을 때는 규칙 우선순위와 스니퍼 옵션이 서로 부딪치지 않는지 확인하세요.

Sniffer는 편리하지만 호환성·프라이버시 트레이드오프가 있습니다. 회사 보안 에이전트·다른 VPN·로컬 필터가 동시에 있으면 로그가 서로 모순될 수 있으니, 재현 실험 때는 경로를 최대한 단순화하는 것이 좋습니다.

7. 검증 체크리스트와 함정

설정 후에는 다음을 순서대로 확인합니다. 첫째, 중간 크기 파일을 열고 줌·스크롤·코멘트 패널을 열 때 로그의 Host가 대부분 ▶️ Figma로 모이는지. 둘째, 서드파티 규칙에 광역 DIRECT나 지역 리스트가 앞쪽에서 figma.com 계열을 빼돌리지 않는지. 셋째, Fake-IP·nameserver-policy가 선택한 노드와 같은 출구를 가리키는지. 넷째, Wi-Fi와 LTE를 바꿔 증상이 재현되는지. 다섯째, 로그에 S3·CloudFront류가 따로 보이면 FQDN 단위로 한 줄씩 보강합니다.

흔한 함정은 figma.com 한 줄만 넣고 api.figma.com·임베드 호스트를 빼먹는 경우, 순수 DNS 문제로 오해하는 경우(실제로는 WebSocket·UDP 정책), 그리고 DOMAIN-KEYWORD를 과도하게 늘려 다른 트래픽까지 끌어오는 경우입니다. 데스크톱과 웹을 같은 출구로 맞추려면 시스템 프록시만으로 부족할 때가 많으니, 필요하면 TUN으로 트래픽을 한 코어에 모으는 방안을 검토하세요.