1. 증상을 두 축으로 나누어 보기: 레지스트리와 WebContainer
첫 번째 축은 순수하게 npm에 가까운 흐름입니다. 패키지 이름 조회나 버전 목록까지는 빠르게 지나가는데 tarball 받는 줄에서 진행률이 멈추거나 반복되면, 레지스트리 응답에 따라 나오는 원격 저장소 URL이 다른 출구를 타는 패턴을 의심하세요. 두 번째 축은 WebContainer와 프리뷰 번들입니다. 파일 트리와 코드 편집은 되는데 브라우저 안 가상 런타임이 올라오지 않거나 미리보기 iframe만 회색일 때는 WASM·워커 스크립트·정적 호스트 줄이 지연되거나 차단된 경우가 많습니다. 세 번째로 자주 보는 변형은 로그인·과금·프로젝트 템플릿 동기만 스피너인 경우입니다. OAuth 창과 에디터 탭이 서로 다른 테이블을 보면서 세션이 끊긴 것처럼 보입니다. 넷째, 같은 증상이라도 노드 상품만 바꾸면 잠깐 나아지면 규칙보다 중간 홉의 유휴 제한을 함께 봐야 합니다.
사용자 입장에서는 모두 「Bolt.new가 느리다」 또는 「StackBlitz가 안 된다」로 묶이지만, 네트워크 로그에서는 줄마다 목적지 접미사와 정책 이름이 찍히므로 재현 단계를 「패키지」「런타임 번들」「계정·결제」로 나누어 각 단계 직후 행을 적어 두는 습관이 중요합니다.
2. 한 도메인 키워드로 묶으면 왜 자주 실패하는가
StackBlitz 생태계는 단일 최상위 이름만 두드리는 구조가 아닙니다. 편집기 셸 UI, 템플릿 마켓, 그리고 브라우저 안에서 돌아가는 Node 호환 계층이 서로 다른 호스트와 TLS 인증서 체인을 씁니다. Bolt.new처럼 AI가 생성한 리포지토리를 바로 여는 제품은 추가로 모델 제공자·분석 엔드포인트까지 같은 탭 세션에 섞일 수 있어 더 복잡합니다. 공항 프로필에 DOMAIN-KEYWORD,stackblitz 한 줄만 추가했다면 일부 신규 엣지 접미사나 credentialless 정적 경로가 규칙 밖으로 빠져 「규칙을 넣었는데도 빌드 타임아웃」처럼 보일 수 있습니다.
반대로 과하게 넓은 키워드 규칙은 무관한 글로벌 트래픽까지 같은 노드로 보내 조직 정책과 충돌합니다. 따라서 인터넷에 떠도는 고정 목록 통째 복사보다 본인 세션에서 실제로 실패한 행 문자열을 우선하는 편이 안전합니다.
3. 권장 점검 순서: 브라우저 모드 → 로그 → 규칙 → TUN
- Clash가 시스템 프록시만인지 TUN까지 켰는지 메모합니다. Chromium 멀티 프로세스는 일부 자식만 시스템 프록시를 건너뛰는 경우가 있습니다.
- 연결 패널을 연 채로 새 프로젝트 생성, npm install 트리거, 프리뷰 새로고침을 각각 한 번씩 실행하고 새로 뜬 행만 시간 순으로 적습니다.
npmjs·npm문자열과stackblitz·webcontainer·정적 번들로 추정되는 호스트가 같은 정책 이름을 보는지 비교합니다.fake-ip사용 여부와 DNS 해석 경로를 확인합니다. 탭을 닫았다 열어도 오래된 해석이 남으면 증상이 꼬입니다.- 수동
DOMAIN-SUFFIX블록을 구독 룰보다 위로 올리고 광범위GEOIP직결과 충돌하는지 봅니다. - 여전히 번들만 멈추면 TUN 모드로 전체 테이블을 맞출지 검토하고, 브라우저 확장이 WASM 요청을 가로막지 않는지 확인합니다.
4. npm 축: 레지스트리 메타와 tarball 줄
브라우저 안 패키지 매니저도 로컬 CLI와 마찬가지로 메타데이터 GET과 tarball GET이 분리됩니다. 미러나 사내 레지스트리를 쓰면 호스트가 더 늘어납니다. 규칙이 registry.npmjs.org만 프록시로 묶고 실제 tarball 행은 DIRECT로 빠지면 다운로드 한계 대역에서 멈춘 것처럼 보입니다. 반대로 레지만 직결로 두고 tarball만 노드를 타면 회선 지연 패턴이 달라져 재시도 폭주가 납니다.
운영 관점에서는 처음에 같은 정책 그룹으로 묶어 안정화한 뒤 필요하면 CDN 계열만 실험적으로 분리하는 편이 디버깅 비용이 적습니다. 로컬에서 검증할 때는 터미널 프록시 환경 변수 글과 교차해 출구 일관성을 맞추면 재현이 빨라집니다.
5. WebContainer·프리뷰 번들이 거는 CDN 줄
WebContainer는 브라우저에서 파일 시스템 이미지와 Node ABI에 가까운 런타임을 올리기 위해 상당히 큰 바이너리 묶음을 내려받습니다. 이 과정에서 credentialless iframe이나 별도 출처 정적 경로가 등장하면 사용자 규칙이 한동안 따라가지 못합니다. 프리뷰 패널이 뜨기 직전에만 보였다 사라지는 짧은 TTL 이름은 연결 로그를 놓치기 쉬우니 필터를 넓게 두었다가 접미사 규칙으로 좁히는 방식이 안전합니다.
Bolt.new는 같은 브라우저 세션 안에서 리포지토리 생성·패키지 설치·미리보기까지 한 번에 돌리므로, 증상 시간축을 초 단위로 나누어 어떤 호스트 묶음이 겹치는지 적어 두면 이후 규칙 정리가 수월합니다.
6. Chromium 탭이 프록시를 타는 실제 경로
Windows·macOS 모두에서 브라우저는 시스템 프록시 설정을 따르는 경우가 많지만, 샌드박스된 서브프레임·서비스워커·내부 업데이터가 예외를 낼 수 있습니다. 「같은 사이트인데 탭마다 속도가 다르다」면 프로세스 유형별로 로그 행이 갈리는지 확인하세요. 회사 단말에서 HTTPS 검사를 켜 두면 WASM 다운로드만 실패하는 일도 있어 보안 제품 로그와 Clash 로그를 시간대로 맞춰 보는 것이 좋습니다.
7. DNS와 fake-ip: 이름만 바뀌어도 미리보기만 깨진다
fake-ip와 규칙 엔진 조합은 체감 지연을 줄이지만, 해석 결과와 실제 엣지 리전이 어긋나면 브라우저가 같은 호스트에 TLS 재시도를 반복합니다. 특히 글로벌 CDN은 지역별 이름이 미묘하게 달라 「패키지는 받히는데 컨테이너 부팅만 길다」는 패턴으로 드러나기도 합니다. 규칙을 고친 뒤에는 브라우저 프로세스를 완전히 종료하고 다시 열어 캐시를 비우는 편이 재현성이 높습니다.
8. 연결 로그로 호스트 묶음 쌓기
Clash Verge Rev 등에서 연결 보기를 연 상태로 문제 프로젝트를 두 번 이상 열어 보세요. 필터에 npm, jsDelivr, unpkg, stackblitz, bolt처럼 넓은 토큰부터 걸고 실패 직전 행만 따로 메모합니다. 정책 열에 DIRECT와 노드가 섞여 있으면 우선 같은 그룹으로 맞춘 다음 세분화합니다.
9. 규칙에 올리기 전 체크 표(예시·반드시 로그 검증)
아래는 사고용 틀일 뿐이며 실제 접미사는 배포 채널에 따라 바뀝니다.
| 구분 | 예시 패턴 | 메모 |
|---|---|---|
| 레지스트리 | npmjs.org 계열 | 메타와 tarball 행이 같은 정책인지 확인합니다. |
| CDN 미러 | 공개 패키지 번들 | 데모 템플릿이 외부 CDN을 함께 두드리면 줄이 늘어납니다. |
| 스택블리츠 UI | stackblitz.com 계열 | 편집기 자산과 런타임 자산을 구분합니다. |
| WebContainer | wasm·부트스트랩 호스트 | 실패 행을 우선 규칙에 올립니다. |
10. 규칙 예시(정책 이름은 본인 프로필로 교체)
# Example only — replace WEBDEV with your policy group; verify every hostname in YOUR log
rules:
- DOMAIN-SUFFIX,npmjs.org,WEBDEV
- DOMAIN-SUFFIX,stackblitz.com,WEBDEV
- DOMAIN-SUFFIX,webcontainer.io,WEBDEV
로그에만 나타나는 스토리지·엣지 접미사는 줄을 추가해 덮어씁니다. DOMAIN-KEYWORD 한 줄로 끝내기보다 확인된 접미사를 선호합니다.
11. GEOIP·국내 직결 규칙과의 충돌
공항 구독에 GEOIP,KR,DIRECT 같은 규칙이 있으면 글로벌 엣지 일부만 의도치 않게 직결로 떨어져 혼합 증상이 납니다. 로컬 파일 상단에 덮어쓰기 블록을 두고 구독 갱신 후 순서가 밀렸는지 주기적으로 확인하세요.
12. GUI에서 필터링하는 습관
Mihomo 호환 클라이언트는 문자열 필터로 빠르게 출구를 확인할 수 있습니다. 첫 설치 흐름은 Clash Verge Rev 가이드로 정리한 뒤 이 글의 분류 단계로 넘어오면 부담이 줄어듭니다.
13. 다른 글과 짝 짓기
Microsoft 개발자 행사 CDN 분류는 Microsoft Build 글, AI 코파일럿 축은 GitHub Copilot 글이 각각 다른 호스트 묶음을 다룹니다. 증상 문구가 비슷해도 제품 경계가 다르면 규칙을 그대로 옮기기 어렵습니다.
14. 자주 묻는 질문
Q. 로컬 VS Code에서는 npm이 되는데 브라우저만 안 되나요?
A. 브라우저 탭은 WASM·교차 출처 요청 제약이 더 많습니다. 같은 레지스트리라도 런타임 번들 줄이 추가로 열려 출구가 달라질 수 있습니다.
Q. 회사 프록시와 Clash를 동시에 쓰면?
A. 이중 프록시와 PAC 우선순위가 겹치면 증상이 달라집니다. 허용된 범위 안에서 어느 층이 최종 출구인지부터 정리하세요.
Q. 규칙을 많이 넣을수록 안전한가요?
A. 아닙니다. 근거 없는 장문 규칙은 오히려 디버깅을 어렵게 만듭니다. 실패 행부터 추가하는 편이 운영에 유리합니다.
15. 준수 안내
이 글은 약관 위반이나 불법 경로를 안내하지 않습니다. 소속 조직의 네트워크 정책과 클라우드 제공자 약관을 준수하고, 허용된 범위 안에서 연결 일관성을 맞추는 데 활용하세요.
16. 정리: 로그로 npm 줄과 WebContainer CDN 줄을 같은 테이블에
Bolt.new·StackBlitz 같은 브라우저 온라인 IDE는 npm 레지스트리와 WebContainer 번들이 한 세션에 겹칩니다. 빌드 타임아웃처럼 보일 때는 규칙 한 줄이 아니라 연결 로그에 찍힌 호스트·분류 규칙 순서·DNS·TUN·브라우저 예외가 겹친 결과인 경우가 많습니다. 데스크톱 에디터용 글과 혼동하지 말고 탭 프로세스 기준으로 로그를 모으면 진단이 빨라집니다.
범용 「VPN 앱」 형태의 클라이언트는 종종 규칙 편집과 연결 기록이 분리되어 있거나 노드만 바꾸라고 안내합니다. 원인 축을 나누기 어렵고 같은 증상을 반복해서 덮기 쉽습니다. 반면 Mihomo 계열 Clash 생태계는 패턴 규칙과 실시간 연결을 한 화면에서 다루기 쉬워 개발자 트래픽처럼 호스트가 많은 브라우저 세션에서도 진단 속도가 빠른 편입니다. 프로필 전환과 DNS 모드를 함께 묶어 두면 재현 실험도 수월합니다. → 즉시 무료로 Clash를 다운로드하고 npm과 WebContainer CDN 행이 같은 정책으로 보이는지 점검해 보세요