창은 뜨는데 “연결 중”만 길게 남는 증상

Cursor 같은 AI 코딩 IDE를 쓰다 보면, 에디터 UI는 정상인데 하단 상태나 계정 영역이 오랫동안 “연결 중(Connecting)”으로 남거나, 확장 프로그램 검색·설치만 타임아웃되는 경우가 있습니다. 브라우저 탭의 ChatGPT는 잘 되는데 클라이언트만 그럴 때 사용자는 보통 “노드가 느려서”라고 단정하기 쉽지만, 실제로는 IDE가 붙는 호스트 묶음이 웹 채팅과 다르고, 그중 일부만 DIRECT나 다른 출구로 빠지면 한 단계에서만 세션이 끊기는 패턴이 자주 나타납니다.

Clash·mihomo는 rule 모드에서 도메인·IP 기준으로 경로를 나눌 수 있어, 업무용 국내 트래픽은 직접 연결을 유지하면서 IDE·확장 마켓·업데이트 채널만 별도 전략 그룹으로 보내는 구성이 가능합니다. 이 글의 초점은 “가장 빠른 단일 노드 찾기”가 아니라, Cursor 관련 연결을 웹 AI 일반 규칙과 분리해 규칙 순서와 DNS를 한 줄로 맞추는 방법입니다. 브라우저 중심의 AI 사이트 분기는 AI 웹 전용 분기 가이드에 두고, 여기서는 데스크톱 IDE 클라이언트에 맞춘 차이를 설명합니다.

왜 “웹 AI 분기”만으로는 IDE가 안 풀릴까

ChatGPT·Grok 등 브라우저 세션을 위한 규칙은 보통 공개된 채팅 도메인·API 묶음을 기준으로 잡습니다. 반면 Cursor는 VS Code 계열 클라이언트 위에 올라가며, 편집기 본체 업데이트, 계정·라이선스·팀 기능, 확장 마켓 메타데이터·다운로드, 백그라운드 동기화가 서로 다른 호스트로 갈라질 수 있습니다. 그중 하나가 “해외 일반 사이트” 규칙에 걸려 기대와 다른 출구를 타거나, 반대로 마켓 CDN만 직접 연결을 타면 TLS·지역 캐시·속도 제한이 엇갈려 부분 실패처럼 보입니다.

또 한 가지는 규칙 순서입니다. Clash의 rules는 위에서 아래로 평가되며 처음 매칭된 한 줄이 최종입니다. “AI 사이트 RULE-SET”이 넓게 잡혀 있어도, IDE가 쓰는 호스트 이름이 그 세트에 없으면 아래쪽 MATCH로 떨어지고, 그때 선택된 노드가 마켓·업데이트와 맞지 않으면 증상이 남습니다. 반대로 IDE 전용 줄을 추가했는데 더 위에 있는 GEOIP,CN,DIRECT 같은 광범위 규칙이 먼저 잡아버리면 의도와 다르게 동작합니다.

팁

증상이 “느리다”보다 “같은 노드인데 어제는 됐는데 오늘은 확장만 안 된다”에 가깝다면, 노드 풀보다 규칙 세트 업데이트나 클라이언트가 새로 붙인 호스트가 바뀌었는지부터 의심해 보세요. 개발자 도구의 네트워크 로그·Clash 연결 로그에 나온 실제 SNI·호스트 이름을 기준으로 목록을 고치는 편이 재발을 줄입니다.

IDE 트래픽을 네 덩어리로 나누어 생각하기

설정을 설계할 때는 최소한 아래 축으로 끊어서 보면 혼란이 줄어듭니다. (정확한 호스트는 버전·지역·기업 정책에 따라 달라질 수 있으므로, 항상 로그로 확인하세요.)

  • 편집기 코어·앱 채널: 설치본 업데이트, 크래시 리포트, 일부 telemetry에 해당하는 호스트
  • 계정·팀·결제·동기화: 로그인 세션, 설정 동기화, 라이선스 검증에 해당하는 API
  • 확장 마켓: 검색 인덱스, VSIX 다운로드, 아이콘·메타데이터 CDN — VS Code 호환 마켓을 쓰는 경우 Microsoft 마켓플레이스·스토리지 계열과 겹치는 경우가 많습니다
  • AI 기능 자체: 인라인 제안·채팅 백엔드 등 — 이 부분은 “웹 AI” 규칙과 겹칠 수 있지만, 호스트 이름이 브라우저용과 동일하지 않을 수 있습니다

이렇게 나누면 “한 줄짜리 AI RULE-SET”에만 의존하지 않고, 마켓·업데이트만 따로 모은 전략 그룹을 둘 이유가 분명해집니다. 레지스트리만 분리하는 개발자 시나리오는 Docker 레지스트리 분기 가이드와 비슷하게, 넓은 MATCH보다 먼저 좁은 덩어리를 두는 것이 핵심입니다.

전략 그룹 설계: PROXY_IDE를 어떻게 채울까

실무에서는 proxy-groups에 IDE 전용 그룹을 하나 두고, 이름을 PROXY_IDE처럼 고정해 두는 패턴이 많습니다. 멤버는 단순히 지연 최저가 아니라 긴 세션·대용량 다운로드·마켓 CDN에 덜 끊기는 출구를 넣습니다. select로 수동 고정해 두면 업데이트 날에 자동 전환이 덜해져 체감이 안정적이고, url-test를 쓰더라도 측정 URL을 일반 웹이 아니라 실제로 IDE 기능이 열리는지에 가깝게 두는 편이 좋습니다.

필요하면 그룹을 둘로 쪼갤 수도 있습니다. 예를 들어 PROXY_MARKET에는 마켓·CDN 출구, PROXY_CURSOR에는 앱·계정 API 출구를 넣는 식입니다. 다만 그룹이 많아질수록 규칙 유지보수가 어려워지므로, 처음에는 PROXY_IDE 하나로 시작하고 증상이 계속 쪼개질 때 단계적으로 나누는 것을 권합니다.

규칙 예시와 순서

rules에서는 검증된 RULE-SET을 쓰거나, 최소한으로 DOMAIN-SUFFIX·DOMAIN-KEYWORD로 자주 관측되는 호스트를 지정합니다. Cursor·VS Code 계열은 도메인이 바뀔 수 있으므로, 커뮤니티 세트 + 로컬 예외를 병행하는 편이 안전합니다. 중요한 것은 IDE 관련 줄이 넓은 GEOIP나 최종 MATCH보다 위에 있어야 한다는 점입니다. 아래는 개념 예시이며, 실제 프로필에서는 사용 중인 rule-provider 이름·경로에 맞게 바꿔야 합니다.

# Conceptual excerpt — adapt names to your profile
proxy-groups:
  - name: PROXY_IDE
    type: select
    proxies:
      - NODE_IDE_1
      - NODE_IDE_2
      - PROXY_DEFAULT

rules:
  - DOMAIN-SUFFIX,cursor.com,PROXY_IDE
  - DOMAIN-SUFFIX,open-vsx.org,PROXY_IDE
  - DOMAIN-SUFFIX,visualstudio.com,PROXY_IDE
  - DOMAIN-SUFFIX,microsoft.com,PROXY_IDE
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

위 목록은 교육용 스케치입니다. 특히 microsoft.com처럼 범위가 큰 접미사는 다른 업무 트래픽까지 끌고 올 수 있어, 실제로는 더 잘게 쪼개거나 RULE-SET으로 대체하는 경우가 많습니다. 핵심은 “IDE가 실제로 연결한 호스트”를 로그로 확인한 뒤, 최소한의 줄로 덮기입니다. YAML 전체 구조·Fake-IP·DNS 폴백은 YAML 심층 가이드와 함께 보면 프로필 전체와 충돌이 적습니다.

주의

서비스 이용약관·지역 정책·고용 계약·보안 정책을 위반하는 경로 조작을 돕는 내용은 다루지 않습니다. 이 글은 합법적으로 사용 권한이 있는 환경에서 기술적 경로 불일치로 인한 끊김을 줄이는 설정에 한합니다.

시스템 프록시, TUN, DNS를 한 축으로 맞추기

IDE는 때로 시스템 프록시 설정을 따르지 않고 자체 스택으로 나가는 동작을 섞어 쓰기도 합니다. 그래서 브라우저만 Clash에 맞춰 두고 IDE는 예외인 경우, “웹만 되고 IDE만 안 됨”이 쉽게 납니다. 가능하면 TUN 모드로 시스템 트래픽을 코어에 모으거나, 반대로 IDE를 포함해 모든 앱이 같은 시스템 프록시를 보도록 통일하는 편이 증상 재현을 줄입니다.

DNS는 enhanced-mode: fake-ip를 쓰면 로컬 앱이 받는 응답과 터널 내부 질의가 달라지는 문제를 완화하기 쉬운데, 특정 SaaS·마켓 CDN은 fake-ip-filter 예외가 필요할 수 있습니다. IPv6가 켜져 있으면 AAAA 응답을 따라 트래픽이 IPv6로만 나가며 규칙이 기대와 다르게 보이는 사례도 있으니, 재현 시에는 한 번에 한 변수만 바꿔 좁히는 것이 안전합니다. Windows에서 TUN 이슈가 겹칠 때는 TUN 점검 가이드의 순서를 참고할 수 있습니다.

점검 순서 체크리스트

설정을 크게 뒤집기 전에 아래 순서를 권합니다.

  1. 모드가 rule인지, 지금 보고 있는 프로필이 실제로 로드됐는지 확인한다.
  2. Cursor 관련 호스트가 로그에 찍히는지 확인하고, rules에서 그 줄이 DIRECT·넓은 MATCH보다 위에 있는지 본다.
  3. PROXY_IDE가 가리키는 노드가 의도한 출구인지, 자동 전환 그룹이 과도하게 바뀌지 않는지 본다.
  4. DNS가 Fake-IP인지, 필요한 도메인이 fake-ip-filter 예외를 빠뜨리지 않았는지 본다.
  5. TUN/시스템 프록시/다른 VPN의 중복을 제거하고, IPv6 변수를 분리한다.
  6. 문제가 확장 마켓만인지, 계정 동기화만인지 범위를 나누어 재현한다.

이 순서는 새 버전 출시일에 급하게 노드를 바꾸기보다, 규칙과 경로를 먼저 고정해 두면 이후에도 같은 유형의 문제를 빨리 닫을 수 있습니다.

정리

Cursor가 “연결 중”에서 오래 멈추거나 확장·업데이트만 실패하는 증상은, 단일 스위치가 아니라 IDE가 사용하는 호스트 묶음이 브라우저형 AI와 다르고, 그 묶음이 규칙 순서·전략 그룹·DNS·실제 출구가 한 줄로 이어졌을 때 가장 잘 풀립니다. 웹 AI 전용 규칙만으로는 부족할 수 있으니, 편집기·마켓·업데이트를 별도 그룹으로 묶어 유지보수하는 접근이 장기적으로 안정적입니다.

Clash·mihomo는 YAML 한 장으로 이런 분기를 명시적으로 유지할 수 있어, 문제가 생겼을 때도 원인 후보를 빠르게 좁힐 수 있습니다. 최신 클라이언트 빌드와 호환되는 코어 조합은 다운로드 페이지에서 확인할 수 있습니다. → Clash를 무료로 내려받아 프로필과 규칙을 정리한 뒤, IDE 전용 전략 그룹부터 차근차근 맞춰 보시기 바랍니다.