피그마 임베드 실패? figma·CDN Clash 분할 (2026)

2026년에도 이어지는 “피그마는 되는데 임베드만” 패턴

Figma는 제품·마케팅·개발 협업에서 사실상 표준에 가까운 디자인 SaaS입니다. 동시에 커뮤니티와 지원 포럼을 보면, 메인 앱에서는 파일이 열리는데 Live embed 카드·외부 사이트에 붙인 iframe 미리보기·공유 링크 뷰어만 하얀 화면·무한 로딩이 된다는 증상이 2026년에도 반복적으로 검색됩니다. 이는 단일 노드 품질만의 문제가 아니라, figma.com 아래 서로 다른 서브도메인·정적 자산·CDN·때로는 api.figma.com 같은 API 호스트로 트래픽이 갈라지면서, 기존 Clash 분할 규칙의 빈틈이 드러나는 전형적인 그림입니다.

이 글은 Mihomo·Clash Meta 계열에서 피그마 전용 전략 그룹을 두고, DOMAIN-SUFFIX로 잡을 수 있는 축을 정리한 뒤, GEOIP·넓은 MATCH·다른 SaaS 규칙보다 위쪽에 두어야 하는 이유와 DNS·fake-ip 영향을 실측 순서와 함께 설명합니다. Disney+·Netflix 같은 스트리밍, Steam 상점·CDN, 닌텐도 eShop 본문과는 도메인 축이 겹치지 않도록 체크리스트를 나눴습니다. Cursor·Hugging Face처럼 개발자·AI API 위주 글과도 장면이 다릅니다.

전제: 회사·학교 정책, 서비스 약관, 현지 법을 위반하는 우회는 다루지 않습니다. 이미 프록시 사용이 허용된 환경에서 라우팅·DNS 품질을 다룹니다.

참고: Figma는 엣지·CDN·스토리지 호스트를 수시로 조정할 수 있습니다. 본문의 DOMAIN-SUFFIX,figma.com 등은 출발점이며, 브라우저 개발자 도구 Network 탭과 Clash 로그에서 실패한 요청의 호스트를 확인해 한 줄씩 보강하는 것이 가장 정확합니다.

증상을 규칙으로 환산하기

먼저 증상을 세분화하면 작업이 빨라집니다. (1) www.figma.com에서 파일 편집은 되는데, 노션·위키·사내 포털에 넣은 임베드만 깨진다. (2) 공유 링크의 읽기 전용 뷰는 되는데 실시간 커서·코멘트 동기화만 끊긴다. (3) 썸네일·아이콘·폰트 로딩이 중간에 멈춘다. 각각은 서로 다른 호스트 묶음에 걸릴 수 있으므로, “피그마가 안 된다” 한 줄로 뭉뚱그리지 말고 어느 URL에서 재현되는지부터 적어 두세요.

협업 세션은 WebSocket·롱 폴링에 민감해, 특정 경로만 DIRECT로 떨어지거나 반대로 의도와 다른 프록시 그룹에 붙으면 체감이 크게 갈라집니다. Clash에서는 첫 일치 원칙이므로, 피그마 관련 줄이 GEOIP,KR,DIRECT나 거대한 RULE-SET 아래에 묻혀 있으면, 이미 IP로 붙은 연결은 DOMAIN-SUFFIX가 보지 못하는 경우도 있습니다. 이 점은 규칙 분할에서 강조한 우선순위와 직결됩니다.

figma.com·API·자산 축 체크리스트

핵심 접미: figma.com

대부분의 웹 클라이언트 트래픽은 figma.com 접미 아래 서브도메인으로 모입니다. Clash에서는 DOMAIN-SUFFIX,figma.com,Figma-Apps 한 줄이 넓은 출발선이 됩니다. 다만 조직 정책상 특정 서브도메인만 직결을 원한다면, DOMAIN 단위로 쪼개 더 구체적인 줄을 위에 올리는 편이 안전합니다.

REST·플러그인: api.figma.com

팀 라이브러리·토큰·일부 통합은 api.figma.com을 칠 수 있습니다. 웹 UI는 되는데 데스크톱 앱·플러그인·CI 스크립트만 실패한다면 이 축을 의심하세요. 필요 시 DOMAIN-SUFFIX,api.figma.com,Figma-Apps를 별도 줄로 명시해 두면 로그에서 매칭 여부를 추적하기 쉽습니다.

정적·엣지·서드파티

아이콘·폰트·이미지 스프라이트는 static.figma.com 등 정적 호스트에 실리는 경우가 많습니다. DOMAIN-SUFFIX,figma.com에 이미 포함되지만, 실제로는 공용 CDN이나 외부 스토리지에서만 실패하는 요청이 보일 수 있습니다. 그때는 Network 탭의 빨간 요청 호스트를 그대로 DOMAIN 또는 DOMAIN-SUFFIX로 추가하세요. 범위가 너무 넓은 amazonaws.com 접미는 다른 서비스까지 휩쓸 수 있으니, 관측된 FQDN부터 좁히는 것이 좋습니다.

전략 그룹·규칙 순서: 무엇보다 먼저 둘 것

흔한 실수는 다음과 같습니다. (1) 범용 AI-Apps나 PROXY 그룹에만 의존해 두었는데, 그보다 위에 있는 GEOIP가 피그마 관련 트래픽을 국내 직결로 보내 버린다. (2) 반대로 전역 프록시 아래에 두었더니 사내 SSO·프린터·캡티브와 충돌한다. 권장 그림은 ① Figma-Apps 같은 전략 그룹을 정의하고, ② DOMAIN-SUFFIX,figma.com·필요한 api.figma.com 줄을 GEOIP·MATCH·거대 RULE-SET보다 위에 둔다. ③ 이미 쓰는 ChatGPT·개발 도구 규칙과 호스트가 겹치지 않으면 순서는 비교적 자유지만, 동일 도메인을 두 그룹이 다투면 위쪽 줄이 이깁니다.

이 구성은 Adobe Creative Cloud처럼 다른 디자인 SaaS와 병렬로 두기 좋습니다. 스트리밍·게임용 분할 글을 그대로 복사해 오기보다, 본문 체크리스트처럼 figma.com 축만 따로 유지 관리하세요.

proxy-groups·rules 축약 예시

아래는 개념을 잡기 위한 예시입니다. 그룹명·노드는 본인 구독에 맞게 바꾸고, rules는 실제 관측으로 보강하세요.

YAMLproxy-groups:
  - name: "Figma-Apps"
    type: select
    proxies:
      - DIRECT
      # ... 지연·협업 품질이 맞는 노드 ...
rules:
  - DOMAIN-SUFFIX,figma.com,Figma-Apps
  - DOMAIN-SUFFIX,api.figma.com,Figma-Apps
  # Network 탭에서 확인한 정적·CDN 호스트를 여기에 한 줄씩
  # - DOMAIN,example-cdn.example.com,Figma-Apps
  # ... GEOIP, RULE-SET, MATCH ...

figma.com 접미는 범위가 넓으므로, 팀 정책상 “웹만 프록시, 데스크톱은 직결”처럼 나누고 싶다면 앱이 쓰는 호스트를 로그로 모은 뒤 더 잘게 쪼개는 편이 낫습니다.

DNS·fake-ip·TUN이 임베드에 미치는 영향

enhanced-mode: fake-ip를 쓰면 이름 해석이 Clash 쪽으로 모여야 DOMAIN-SUFFIX 단계에서 정책이 안정적으로 먹습니다. 브라우저·데스크톱 앱이 시스템 DNS를 우회하거나, 이미 IP로 연결을 열면 도메인 규칙이 건너뛰어 “메인 탭만 되고 iframe만 죽는다” 같은 갈림이 납니다. TUN 모드에서는 스플릿 DNS·nameserver 순서가 TUN 가이드와 일치하는지 먼저 확인하세요.

특정 호스트에 fake-ip-filter를 넣어 실제 레코드를 보이게 하면 증상이 뒤집히는 사례도 있으니, 범용 복붙보다 한 호스트씩 최소 변경이 안전합니다. DNS 전파 지연이나 공용 DoH 차단은 피그마뿐 아니라 모든 SaaS에 공통이므로, 동일 네트워크에서 다른 사이트는 정상인지도 함께 보세요.

실측 절차: Network·로그·규칙 매칭

문제가 나는 페이지에서 개발자 도구 Network를 연 뒤 새로고침하고, 실패한 요청의 호스트·스킴·상태 코드를 기록합니다.
Clash 로그에서 같은 시각의 [Rule]·정책 이름을 찾아, 기대한 Figma-Apps인지 DIRECT·다른 그룹인지 확인합니다.
불일치면 해당 DOMAIN·DOMAIN-SUFFIX 줄을 위로 올리거나 한 줄 추가합니다.
임베드가 들어 있는 부모 페이지 출처(노션·컨플루언스 등)에서만 실패한다면, 부모 도메인 CSP·X-Frame-Options와 네트워크 경로를 구분해 봅니다. 네트워크 레벨에서 막힌 경우에만 Clash 규칙이 효과가 있습니다.
같은 노드에서 메인 앱만·임베드만을 번갈아 재현해, 노드 품질 문제인지 정책 문제인지 나눕니다.

스트리밍·Steam·닌텐도 규칙과 겹치지 않게

이미 Disney+·Netflix·Steam·닌텐도용 DOMAIN-SUFFIX 묶음을 쓰고 있다면, 피그마 줄을 그 옆에 단순 나열하기보다 목적별 주석으로 섹션을 나누어 두면 유지보수가 쉽습니다. 호스트가 겹치지 않으므로 우선순위 충돌은 드물지만, 거대한 RULE-SET이 figma 문자열을 포함해 버리면 의도와 다른 매칭이 나올 수 있습니다. 그럴 때는 예외 줄을 rule-set 앞에 두는 패턴을 재사용하세요.

Rule-set·Provider와의 공존

원격 RULE-SET이 광범위한 DOMAIN-SUFFIX를 한꺼번에 가져오면, 수동으로 넣은 피그마 예외가 뒤로 밀릴 수 있습니다. Provider 순서와 include 위치를 확인하고, Figma-Apps 예외는 세트 앞에 두는 습관이 안전합니다. 출처를 알 수 없는 규칙 묶음은 보안·안정성 측면에서도 지양하세요.

주의: Figma는 계정·팀·지역 정책에 따라 기능이 제한될 수 있습니다. Clash는 경로를 나누는 도구일 뿐, 서비스 이용 권한이나 라이선스를 보장하지 않습니다.

정리

Figma 협업·Live embed·외부 미리보기 문제를 네트워크 관점에서 보면, figma.com·api.figma.com·정적·CDN 호스트로 갈라진 트래픽이 분할 규칙·DNS 설정과 맞지 않아 생기는 경우가 많습니다. DOMAIN-SUFFIX로 전략 그룹을 정하고 GEOIP·MATCH보다 위에 두며, 브라우저와 Clash 로그로 실패 호스트를 보강하면 “캔버스는 되는데 임베드만” 증상을 재현 가능한 설정 문제로 좁힐 수 있습니다. 스트리밍·게임·AI API 글과는 다른 디자인 SaaS 축으로 프로필을 정리해 두면 이후 트러블슈팅도 빨라집니다.

설치·기본 프로필은 문서를 참고하시고, 규칙을 적용해 보시려면 Clash를 무료로 다운로드한 뒤 위 우선순위에 맞춰 rules만 조정해 보시길 바랍니다. 다른 범용 프록시 대비 UI·프로필 관리가 단순한 편이라, 디자이너·PM이 직접 프로필을 손보며 DNS·노드를 맞추기에도 부담이 적은 편입니다.