어떤 증상을 Clash 분기 문제로 볼까

Cursor처럼 Electron 기반의 에디터는 OS의 네트워크 스택을 쓰지만, 내부에서 쓰는 HTTP 클라이언트·DNS 캐시·인증서 설정이 운영체제나 브라우저와 조금씩 달라서, 겉으로 비슷해 보이는 안 열림도 원인이 갈라집니다. 특히 Cursor AI 채팅이나 코드 완성이 수십 초 이상 멈춘 뒤 타임아웃으로 끝나고, 같은 망에서 웹 검색은 되는 상황은 개발자 커뮤니티에서도 자주 거론됩니다. 또 하나의 대표 패턴은 확장 프로그램 마켓이나 검색 결과가 빈 화면·무한 스피너에 가깝게 남는 경우인데, 이때는 API 호스트는 프록시를 타는데 CDN이나 메타데이터 호스트가 DIRECT로 새어 나가 차단되는 경우가 많습니다.

이 글은 의료나 법률 같은 특수 규제를 다루지 않고, 일반적인 로컬 개발 환경에서 Clash·Mihomo 계열 클라이언트를 쓰며 위 증상을 줄이기 위한 실측 순서에 초점을 맞춥니다. 먼저 전역 네트워크가 망가진 것인지, 특정 호스트만 막힌 것인지 가르는 일이 제일 중요합니다. 전자라면 노드 품질·구독 만료·회사 방화벽부터 보아야 하고, 후자라면 이 문서에서 말하는 룰 보강과 프록시 적용 방식부터 점검하는 편이 빠릅니다.

왜 룰 한 줄 차이로 AI와 마켓만 깨질까

Clash 계열은 도메인·IP·지역 조건에 따라 패킷을 프록시 그룹이나 직결로 보냅니다. 사용자가 가져온 구독 파일에 GEOIP 규칙이 공격적으로 들어 있으면, 실제 서버 위치가 예상과 다른 CDN 엣지가 DIRECT로 떨어져 SNI 검열이나 DNS 오염 구간에 걸리기도 합니다. 반대로 프록시 체인이 너무 길면 지연만 늘어 AI 스트리밍이 중간에 끊긴 것처럼 보이기도 합니다.

Cursor AI는 세션·과금·모델 라우팅을 위해 여러 하위 도메인으로 요청을 나눕니다. 확장 마켓은 Microsoft Visual Studio Marketplace, 혹은 팀 설정에 따라 Open VSX 계열 엔드포인트를 칠 수 있어, 한국·중국·기업망처럼 정책이 다른 네트워크에서는 한 브랜치만 막혀 전체 UI가 어색해지는 일이 흔합니다. 그래서 증상만 복사해 검색하기보다 Clash의 연결(Connections) 화면에서 실제로 어떤 호스트가 어떤 정책으로 나가는지를 잠깐이라도 확인하는 습관이 큰 비용 절감으로 이어집니다.

Clash 쪽에서 먼저 확인할 스위치

아래는 GUI 이름이 클라이언트마다 조금씩 달라도 공통적으로 존재하는 축입니다.

  • 시스템 프록시(System Proxy): macOS·Windows가 127.0.0.1:포트 형태의 로컬 프록시를 쓰도록 바꿉니다. 대부분의 데스크톱 앱은 이를 따르지만, 일부는 프록시 무시 옵션을 가질 수 있습니다.
  • TUN 가상 어댑터: 더 많은 프로세스를 강제로 터널에 태웁니다. Electron 앱 문제를 빠르게 가를 때 임시로 TUN만 켜고 재현해 보면 원인이 프록시 미적용인지 바로 드러나는 경우가 있습니다.
  • DNS 설정: fake-ip나 원격 DNS, 그리고 도메인별 DNS가 섞이면 브라우저 확장으로만 우회되는 것처럼 보이던 트래픽이 IDE에서는 실패할 수 있습니다. 로그에 NXDOMAIN이나 이상한 사설 대역이 찍히면 이 축을 의심합니다.
  • 규칙 모드 vs 글로벌: 문제 재현 중에만 잠깐 글로벌 프록시로 올려 보는 것도 방법입니다. 글로벌에서는 정상인데 규칙 모드에서만 깨지면 룰 테이블이 정답입니다.
팁: Cursor를 켠 채로 AI 질문을 한 번 보내고, 같은 시각 Clash 로그에 뜬 호스트 이름을 스크린샷 또는 메모해 두면 이후 YAML 수정이 훨씬 정확해집니다.

자주 필요한 호스트 이름(참고용 예시)

아래 표는 반드시 전부 필요하다는 뜻이 아니라, 연결 로그에 실제로 보일 때 우선 검토할 후보를 모아 둔 것입니다. Clash for Windows·Clash Verge·자체 빌드 등 편한 편집기로 구독 파일이나 Override 블록을 열어 보세요.

용도 도메인·접미사 예시 메모
Cursor 웹·API cursor.com, api.cursor.com, cursor.sh 빌드·리전에 따라 추가 하위 도메인이 생길 수 있음
Visual Studio Marketplace marketplace.visualstudio.com, *.vsassets.io 확장 메타데이터·아이콘 CDN이 갈라짐
VS Code CDN *.vscode-cdn.net 다운로드 경로가 CDN으로 붙는 경우
Open VSX open-vsx.org, *.open-vsx.org 팀에서 마켓 미러를 Open VSX로 돌린 경우
GitHub(연동) github.com, api.github.com 확장·Copilot 연계나 로그인 연동 시

실제 환경에서는 워크스페이스 신뢰·사내 아티팩트 저장소 때문에 표에 없는 내부 도메인이 더 붙을 수 있습니다. 이럴 때 표를 맹신하기보다 로그에 찍힌 문자열을 그대로 DOMAIN-SUFFIX나 DOMAIN-KEYWORD로 옮기되, 키워드 규칙은 과하게 넓게 쓰지 않는 것이 안전합니다. 너무 넓은 키워드는 광고 차단 목록과 겹쳐 의도치 않은 직결을 만들기도 합니다.

Mihomo/Clash 규칙에 넣기 쉬운 YAML 조각

운영 중인 정책 그룹 이름이 PROXY가 아니라면 아래 예시에서 해당 이름으로 바꿔 넣으세요. 순서는 더 구체적인 규칙이 위, MATCH가 맨 아래라는 전제를 깨지 않도록 주의합니다.

# Cursor + marketplace-oriented split (adjust policy group name)
DOMAIN-SUFFIX,cursor.com,PROXY
DOMAIN-SUFFIX,cursor.sh,PROXY
DOMAIN-SUFFIX,api.cursor.com,PROXY
DOMAIN-SUFFIX,marketplace.visualstudio.com,PROXY
DOMAIN-SUFFIX,vsassets.io,PROXY
DOMAIN-SUFFIX,vscode-cdn.net,PROXY
DOMAIN-SUFFIX,open-vsx.org,PROXY
# Log-driven: append any extra hosts you see in Connections

구독 업데이트 때마다 덮어씌워지는 파일을 직접 손대기 불안하면 Clash Verge 계열의 Merge/Override 기능에 같은 블록을 넣어 두는 편이 운영에 유리합니다. 팀 단위로 공유한다면 주석에 날짜와 이유를 짧게 남겨, 몇 달 뒤에도 왜 그 줄이 들어왔는지 알 수 있게 해 두세요.

DNS·TLS·인증서 이슈를 한 번에 훑기

룰을 아무리 넣어도 첫 TLS 핸드셰이크에서 끊기면 DNS가 가짜 응답을 돌려 주거나, 중간 장비가 SNI를 보고 드롭하는 케이스를 의심합니다. 이때는 같은 호스트에 대해 로컬 터미널에서 curl -v를 직접 찍어 보거나, Clash의 DNS Query 로그와 비교해 보는 것이 빠릅니다.

일부 기업망은 자체 루트 인증서를 박아 넣기 때문에 IDE 쪽만 인증서 검증에 실패할 수도 있습니다. 이 경우는 프록시 문제가 아니라 신뢰 저장소 문제에 가깝습니다. 반대로 Clash의 MITM/스니핑 실험을 켜 둔 상태에서 깨지면, 실험용 설정을 끄고 다시 테스트해야 합니다.

실측 복구 순서(요약 체크리스트)

  1. Clash에서 글로벌 모드로 잠깐 전환해 Cursor AI·마켓이 동시에 살아나는지 본다. 살아난다면 규칙 문제 쪽으로 좁힌다.
  2. 규칙 모드로 돌아와 연결 로그를 연 채로 Cursor에서 동일 동작을 반복한다.
  3. 로그에 나온 호스트를 표와 예시 YAML에 없으면 그대로 추가한다.
  4. 시스템 프록시만 켜 둔 상태에서 재현되면 TUN을 잠시 켜 본다. TUN에서만 정상이면 앱이 시스템 프록시를 건너뛰는 패턴이다.
  5. DNS 모드를 바꿔 보거나, 문제 호스트에 대해 지정 DNS를 분리해 본다.
  6. 수정 후에는 Cursor를 완전히 종료했다가 다시 연다(메뉴의 Quit). 단순 창 닫기만으로는 캐시가 남을 수 있다.
주의: 글로벌 모드나 TUN은 모든 트래픽 경로를 바꿉니다. 은행·업무 VPN과 겹치지 않는지, 회사 정책을 위반하지 않는지 먼저 확인하세요.

Windows와 macOS에서 흔한 차이

Windows는 보안 제품이 로컬 루프백 프록시를 간섭하는 일이 있어, Clash 로그에는 정상으로 보이는데 앱만 실패하는 격리(샌드박스)형 백신 이슈가 종종 보고됩니다. 이때는 예외 경로를 주거나 잠시 실시간 검사를 낮춰 재현 여부만 분리해 보는 것이 현실적입니다.

macOS는 시스템 설정의 네트워크 서비스 순서나 iCloud 프라이빗 릴레이가 DNS를 바꿔 놓아 IDE만 이상하게 동작하는 경우가 있습니다. 또한 회사 프로필이 프록시 PAC을 강제하면 Clash의 로컬 프록시와 충돌할 수 있으니, 프로필별로 어떤 스크립트가 잡혀 있는지 함께 봐야 합니다.

짧게 다시 읽는 요점

Cursor AI 타임아웃과 확장 마켓 로딩은 증상 문구는 비슷해도 실패 지점이 다를 수 있습니다. 한 번에 모든 호스트를 외워 넣기보다 연결 로그 기반으로 추가하고, 글로벌 모드 대비로 원인을 좁히면 같은 증상이 반복될 때 수정 시간이 크게 줄어듭니다. DNS·TLS까지 의심되면 터미널과 IDE를 나란히 두고 같은 URL에 대한 테스트를 찍어 보세요.

규칙형 프록시를 쓸 때 Clash가 유리한 점

단일 상용 VPN 앱은 전체 터널에 가깝게 동작하는 경우가 많아, 개발용 트래픽과 사내 포털을 동시에 쓰면 지연·분기 충돌을 피하기 어렵습니다. 반면 Clash·Mihomo 계열은 도메인 단위로 정책을 쌓을 수 있어 IDE·마켓·패키지 레지스트리만 골라 프록시에 태우고 나머지는 직결에 둘 수 있습니다. GUI 없이 YAML만 던지는 방식보다도, Verge류 클라이언트처럼 로그와 정책 그룹을 한 화면에서 보는 도구와 맞물릴 때 운영 부담이 줄어듭니다.

상용 터널이 제공하는 간편 모드가 한때는 편했어도, 팀마다 다른 마켓 미러와 사내 레지스트리를 섞어 쓰는 지금처럼 환경 차이가 큰 상황에서는 규칙을 직접 설계할 수 있는 쪽이 재현성이 높습니다. 특히 Cursor 같이 여러 클라우드 엔드포인트를 오가는 앱은 작은 누락이 곧바로 무한 로딩으로 드러나기 때문에, 로그 기반으로 조각내어 고치는 방식과 잘 맞습니다.

Clash 클라이언트를 내려받아 동일한 분기 패턴을 PC 전체에 적용해 보기 →