v0.dev가 안 열리거나 하얀 화면만 보일 때: Vercel·v0 AI 도메인을 Clash(mihomo)로 분기하는 실측 (2026)

1. 하얀 화면·403·타임아웃이 나오는 이유

최신 웹앱은 HTML 한 방으로 끝나지 않고, 클라이언트 번들·API·인증·분석까지 여러 출발지로 요청이 흩어집니다. v0.dev처럼 Vercel에 올라간 제품은 배포 미리보기 URL이 *.vercel.app 형태로 열리기도 하고, 프로덕션은 브랜드 도메인과 엣지 캐시·설정 API가 나뉘어 있습니다. 이 상태에서 크로스보더 노드 품질이 들쭉날쭉하면, 한 호스트만 다른 경로로 새어 「UI 반쪽만 그린다」는 증상이 납니다. 403은 항상 프록시 탓만은 아니며, 엣지 규칙·쿠키·리전 정책과 겹칠 수 있지만, 먼저 Clash 로그에서 어떤 호스트가 어떤 아웃바운드로 나갔는지를 맞추는 것이 디버깅 비용을 줄입니다.

또 한 가지는 전송 경로입니다. Chromium 계열 브라우저는 HTTP/3(QUIC)을 시도하는데, UDP 443이 TCP와 다르게 취급되면 간헐적으로만 실패하는 패턴이 섞입니다. TCP 기반 노드는 통과하는데 QUIC만 끊기는 경우, 증상이 「가끔만 새로고침하면 된다」처럼 보여 원인 파악이 더 어렵습니다. 이 글 뒤쪽에서 QUIC을 실험적으로 끄는 단계를 같은 루틴에 넣었습니다.

2. Cursor·MCP 글과 역할 나누기

같은 블로그의 Cursor 글은 Electron IDE·로컬 터미널·npm 레지스트리처럼 데스크톱 앱 축에 맞춰 있습니다. MCP·npm·GitHub 글은 Model Context Protocol 런타임이 패키지·저장소를 동시에 두드릴 때의 타임아웃에 초점을 둡니다. 반면 본문은 브라우저 탭에서 도는 AI 웹 빌더와 Vercel 배포·엣지 호스트를 묶는 쪽입니다. 규칙 세트를 복사할 때 호스트 목록을 섞지 말고, DevTools 네트워크 탭에 실제로 뜨는 이름을 기준으로 목록을 키우는 것이 안전합니다.

3. 규칙에 넣을 호스트 출발점(v0·Vercel)

서비스는 수시로 바뀌므로 아래는 출발점입니다. v0 세션을 연 뒤 개발자 도구의 네트워크 목록과 Clash 로그를 대조해 접미를 추가하세요. 흔히 쓰는 묶음에는 v0.dev, vercel.com, vercel.app 계열이 포함됩니다. 미리보기·내부 배포가 *.vercel.app로 열리면 해당 접미 전체를 같은 정책 그룹에 넣는 편이 증상 재현을 줄입니다. API·인증 서브도메인은 제품 업데이트로 바뀔 수 있으니, 실패한 요청의 정확한 호스트 문자열을 먼저 확정하는 방식이 좋습니다.

4. mihomo rules 스니펫

전용 정책 그룹 이름을 예시로 🔷 Vercel-v0라고 하면, rules 상단(넓은 MATCH·GEOIP보다 앞)에 두는 편이 안전합니다. 실제 그룹·프록시 이름은 구독에 맞게 바꿉니다. 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # v0 / Vercel — keep above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,v0.dev,🔷 Vercel-v0
  - DOMAIN-SUFFIX,vercel.com,🔷 Vercel-v0
  - DOMAIN-SUFFIX,vercel.app,🔷 Vercel-v0
  # Add api.* / edge hosts from DevTools + Clash log

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 프로필이 덮어쓰지 않게 하려면 구독 가져오기 문서의 머지·오버라이드 순서를 함께 확인하세요.

5. 정책 그룹·HTTPS 스니퍼

url-test만 쓰면 노드가 바뀔 때마다 지연이 출렁일 수 있습니다. AI 웹 빌더처럼 긴 세션이 이어지는 서비스는 전용 그룹 안에서 고정 선택이나 fallback 순서를 명확히 두는 편이 낫습니다. 자동 지연 테스트와 페일오버 조합은 url-test·fallback 글을 참고하세요. TLS SNI가 규칙 매칭에 필요하면 mihomo의 스니퍼 설정을 켜고 로그에서 실제 SNI가 기대 호스트와 맞는지 확인합니다. 스니퍼 일반론은 HTTPS 스니퍼·로그 글과 짝을 이룹니다.

6. DNS·Fake-IP·브라우저 DoH

Clash Meta(mihomo)에서 fake-ip를 쓰면 도메인 기준 분기가 쉬워지지만, OS나 브라우저가 DoH로 우회하면 해석 경로가 어긋날 수 있습니다. Windows에서 Chrome·Edge만 이상하게 보일 때는 보안 DNS 끄기·시스템 프록시 글과 같은 루틴을 먼저 맞추는 것이 좋습니다. 특정 접미만 지정 리졸버로 보내려면 nameserver-policy를 검토합니다.

# Optional — example only; align resolvers with your policy
dns:
  nameserver-policy:
    "+.v0.dev":
      - https://dns.google/dns-query
    "+.vercel.app":
      - https://dns.google/dns-query

Fake-IP와 실제 IP가 섞이면 일부 요청만 다른 규칙 줄로 떨어질 수 있으니, 문제 재현 중에는 로그의 매칭된 규칙 타입·도메인을 연속으로 확인합니다.

7. QUIC(HTTP/3) 선택적 끄기

브라우저가 HTTP/3을 켠 상태에서 UDP 경로만 불안정하면, 동일 사이트라도 TCP 폴백 전에 스피너가 길어질 수 있습니다. 실험으로 QUIC을 끄거나, TUN·방화벽에서 UDP 443 처리를 TCP와 분리해 점검해 보세요. 지연 특성이 바뀔 수 있으니 재현이 끝난 뒤 노드나 네트워크를 바꿔 다시 켜며 최적점을 찾는 편이 좋습니다.

8. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Clash 로그에서 실패 요청이 의도한 규칙 줄에 매칭되었는지 확인합니다. 둘째, Proxies 화면에서 Vercel-v0 그룹이 가리키는 노드가 기대 리전·품질과 맞는지 봅니다. 셋째, 동일 시나리오에서 DNS·QUIC 설정만 바꿔 재현 여부를 비교합니다. 넷째, VPN·다른 필터와 TUN이 충돌하지 않는지 점검합니다. 전체 그림은 Clash 개요와 함께 보면 정리하기 쉽습니다.