이 글이 맞는 증상
Cursor 3로 업그레이드한 뒤부터 클라우드 에이전트 실행이 중간에 끊기거나, 패널은 떠 있는데 작업 스트림만 멈추는 경우가 늘었다면 네트워크 경로를 의심할 만합니다. 특히 로컬 모델 호출이나 단순 자동 완성은 버티는데, 원격 실행·브라우저 연계·도구 호출 계열만 불안정한 패턴은 프록시 분기와 환경 변수 불일치에서 자주 나옵니다.
또 하나의 신호는 브라우저 도구(내장 웹뷰·미리보기·외부 페이지 연동)와 터미널 안에서 도는 CLI·스크립트가 서로 다른 출구를 탈 때입니다. 화면 한쪽에서는 로딩만 길어지고, 다른 쪽에서는 ETIMEDOUT이나 재연결 루프가 반복되면, 단순히 구독 노드를 바꾸기 전에 어떤 호스트가 어떤 규칙으로 분류되는지부터 보는 편이 빠릅니다.
이 문서는 Clash Verge Rev(이하 CVR)를 기준으로 프록시 분기를 정돈하고, 필요한 세션에 HTTPS_PROXY·NO_PROXY를 맞춰 IDE·웹뷰·터미널의 출구를 한 줄로 정렬하는 순서를 다룹니다. MCP(Model Context Protocol)·원격 API 호출이 섞인 환경이라면 전송 방식에 따라 점검 순서가 달라지므로 그 구분도 함께 적습니다.
왜 Cursor 3에서 클라우드·브라우저 쪽이 더 잘 튈까
메이저 업그레이드마다 백엔드 엔드포인트·스트리밍 프로토콜·도구 브리지가 바뀌면, 예전에 잘 되던 와일드카드 규칙 한 줄이 새 호스트 이름을 놓치거나 다른 GEOSITE 묶음 아래로 밀려날 수 있습니다. 클라우드 에이전트는 긴 유지 연결과 재시도가 많아 패킷 손실·불안정 업스트림에서 브라우저의 짧은 요청보다 먼저 끊깁니다.
Electron 기반 에디터는 운영체제 시스템 프록시를 상당 부분 따르지만, 통합 터미널에서 돌아가는 도구는 환경 변수가 비어 있으면 시스템 설정을 건너뛰는 경우가 많습니다. 그 결과 같은 PC에서도 패널 A는 통과·패널 B는 실패처럼 보이는 현상이 생깁니다. 2026년 현재 제품 문서에 안내된 API 베이스 URL을 출발점으로 삼되, 실패 시 로그로 실제 TLS SNI를 확인해 규칙을 보강하는 방식이 안전합니다.
클라우드 에이전트·브라우저 도구·터미널 트래픽 나누기
클라우드 에이전트 트래픽은 인증·스트리밍 응답이 섞인 HTTPS 계열이 대부분이라, CVR 연결 로그에서 도메인만 잡혀도 DOMAIN-SUFFIX 규칙으로 정책 그룹을 지정하기 비교적 수월합니다. 다만 상위 규칙이 동일 서픽스를 DIRECT나 다른 그룹으로 덮어쓰면 증상만 남습니다.
브라우저 도구는 Chromium 계열 웹뷰를 쓰는 경우가 많아 시스템 프록시와 잘 맞지만, 특정 확장·OAuth·CDN 호출이 별도 호스트로 갈라지면 한 줄 규칙만으로는 부족합니다. 미리보기 창에서만 실패한다면 해당 창이 붙는 호스트 묶음을 로그로 따로 적어 두세요.
터미널·자동화 스크립트는 Node·Python 등 런타임 기본값이 직접 소켓을 여는 경우가 많아 HTTPS_PROXY 유무가 결과를 가릅니다. IDE 안 터미널과 OS 기본 터미널 앱이 서로 다른 셸 설정 파일을 읽으면 한쪽만 고쳐져 증상이 계속되는 경우도 흔합니다.
규칙 분기와 TUN, 무엇부터 맞출까
TUN은 한 번에 OS 트래픽을 덮어 빠르게 검증하기 좋지만, 회사 Always-On VPN·보안 에이전트와 라우팅 충돌이 잦습니다. 반면 규칙 + mixed-port + 환경 변수 축은 어떤 요청이 어느 체인으로 갔는지 로그에 남기 쉬워, 끊김이 회선 품질인지 설정 문제인지를 빠르게 가릅니다.
실무에서는 (1) 코어와 포트 확인, (2) 실패 호스트의 정책 이름 확인, (3) 터미널·CI의 HTTPS_PROXY, (4) 필요 시 TUN 순으로 두면 재현성이 높습니다.
HTTP_PROXY와 HTTPS_PROXY를 함께 보는 경우가 많습니다. 한쪽만 남아 있으면 즉시 오류 대신 묵시적 대기로 보일 수 있으니 env | grep -i proxy로 잔여 값을 함께 확인하세요.
1단계: Clash Verge Rev 기본 상태와 mixed-port
CVR을 연 뒤 활성 프로필과 코어 기동 여부를 확인합니다. 커뮤니티 규칙 세트나 구독이 갱신되면 예전에 통과하던 호스트가 다른 정책으로 옮겨가는 일이 있으니 업데이트 시각을 메모해 두면 원인 추적에 도움이 됩니다.
mixed-port 번호를 적어 둡니다. 시스템 프록시 연동이 이 포트를 가리키도록 맞춰 두었다면, 터미널 프록시 URL도 같은 로컬 입구를 써야 동일 규칙 엔진을 공유합니다. 다른 앱이 포트를 선점해 번호가 바뀌면 환경 변수만 수정해서는 증상이 남는 함정이 생깁니다.
2단계: 연결 로그로 호스트를 확정한 뒤 규칙 반영
공개 예시 목록만 복사해 붙이기보다 자신의 빌드에서 실제로 붙는 호스트를 확인하는 편이 안전합니다. 실패 직후 CVR 연결 화면에서 레코드를 열어 도메인·정책 이름·체인을 적습니다.
YAML이나 Verge 규칙 편집기에서 해당 서픽스를 지연이 낮고 허용된 프록시 그룹에 매핑합니다. 상위 GEOSITE 줄이 DIRECT로 덮어쓰지 않는지, 불안정 업스트림 한 줄에만 묶이지 않았는지 대조하세요. 팀 레포라면 규칙 옆에 짧은 근거 주석을 남기면 이후 Cursor 업데이트 때 비교하기 좋습니다.
3단계: 통합 터미널·외부 셸의 HTTPS_PROXY·NO_PROXY
많은 HTTP 스택이 아래 변수를 읽습니다.
HTTPS_PROXY/HTTP_PROXY— TLS·일반 HTTP의 프록시 URLALL_PROXY— 일부 런타임에서 통합 키로 쓰이는 경우NO_PROXY—127.0.0.1,localhost, 사내망, 로컬 MCP 허브 예외
계정 전역에 항상 export하기보다 CVR이 실제로 떠 있을 때만 적용하는 조건문을 ~/.zshrc 등에 두거나, 레포마다 정책이 다르면 direnv로 디렉터리 단 주입을 쓰면 공용 프록시를 실수로 들고 다니는 위험이 줄어듭니다.
이미 연 통합 터미널은 부모 프로세스가 바뀌기 전까지 옛 환경을 유지하므로, 변수 수정 후 탭을 닫았다가 다시 열었는지 확인해야 합니다. 원격 CI에서는 시크릿에 프록시 URL을 넣되 로그에 토큰이 노출되지 않게 주의합니다.
프록시 URL 스키마와 SOCKS
CVR mixed-port가 HTTP와 SOCKS를 함께 제공하면 우선 http://127.0.0.1:<port> 형식을 시도합니다. 레거시 클라이언트가 SOCKS만 요구하면 socks5://127.0.0.1:<port>처럼 스키마를 분명히 적습니다. 오타는 즉시 거절 대신 장시간 대기로 보이는 경우가 많습니다.
4단계: 시스템 프록시·TUN과의 정렬
macOS·Windows에서 시스템 프록시를 CVR과 연동했다면 브라우저·웹뷰가 가리키는 포트와 터미널의 127.0.0.1 경로가 일치하는지 다시 봅니다. TUN만 단독으로 쓸 때는 실제로 가상 인터페이스를 통해 나가는지 라우팅·방화벽 로그로 교차 검증합니다.
회사 VPN과 CVR TUN을 동시에 켜 두면 핸드셰이크가 이중으로 감싸이거나 루프가 나기 쉽습니다. 테스트 때는 한쪽만 켠 상태에서 같은 작업을 비교하면 원인 후보를 빠르게 줄일 수 있습니다.
HTTPS_PROXY를 넓게 켜 두면 그 세션의 패키지 레지스트리·내부 API까지 예기치 않게 우회 경로를 탈 수 있습니다. NO_PROXY 목록을 팀 표준과 맞추고, 로그에 자격 증명 문자열이 남지 않게 레벨을 조절하세요.
MCP·브라우저 도구가 함께 깨질 때
MCP 서버가 로컬 stdio라면 포트·유닛 소켓·방화벽을 먼저 보고, 원격 HTTP·SSE라면 클라우드 API와 같은 층에서 호스트 분기를 점검합니다. 팀에서 게이트웨이 역할을 하는 중간 서버를 두었다면 그 도메인까지 규칙·NO_PROXY에 포함해야 루프가 끊기지 않습니다.
브라우저 도구 패널만 문제라면 OAuth·리디렉션 URL·추가 CDN 호스트가 로그에 새로 찍히는지 확인하세요. 한 번에 많은 리소스를 물어오는 페이지일수록 단일 차단 호스트에 걸려 전체가 로딩 중으로 보일 수 있습니다.
5단계: 여전히 끊길 때 좁히기
- 같은 시각 시스템 브라우저에서 동일 호스트 HTTPS 접속이 되는지 비교합니다.
- CVR 로그에서 해당 요청이 어느 규칙·어느 체인인지 확인합니다.
- 에이전트·CLI를 띄운 셸에서 프록시 관련 환경 변수가 의도와 다른 잔여 값을 갖는지 봅니다.
- DNS가 시스템 resolver·DoH·fake-ip 정책과 엇갈려 누설이 없는지 점검합니다.
- 구독 이슈가 아니라 MTU·간헐적 패킷 로스인지 간단한 반복 측정으로 구분합니다.
이 글과 Cursor SDK 전용 글의 차이
@cursor/sdk나 CI 파이프라인 중심 글은 프로그래매틱 호출 스택과 에러 코드를 깊게 다룹니다. 반면 이 글은 Cursor 3 데스크톱 안에서 보이는 클라우드 에이전트·브라우저 도구·패널 단절을 전제로, 규칙과 환경 변수를 IDE 사용자 관점에서 정렬합니다. 두 문서를 같이 두면 스크립트까지 포함한 팀 표준을 한 번에 잡기 쉽습니다.
자주 묻는 질문
Q. 마켓플레이스 글에서 이미 Clash 규칙을 맞췄는데 클라우드 에이전트만 달라요.
A. 패널마다 쓰는 호스트 묶음이 다를 수 있습니다. 마켓 글의 도메인 목록을 복사한 뒤에도 실패 로그의 SNI가 추가로 있는지 확인하고, 통합 터미널의 HTTPS_PROXY 유무를 맞추세요.
Q. MCP 게이트웨이를 쓰는데 루프가 납니다.
A. 게이트웨이가 다시 공용 인터넷으로 나갈 때 같은 프록시를 두 번 타면 타임아웃이 날 수 있습니다. 내부 허브는 NO_PROXY에 두거나 DIRECT 규칙으로 고정하는지 검토합니다.
Q. 회사에서 터미널 프록시가 금지됐습니다.
A. 정책을 우회하지 말고 IT에 허용된 egress와 인증 프록시 형식을 요청하세요. 이 문서는 합법적인 개발 환경을 전제로 합니다.
정리: 단일 VPN보다 규칙·환경 변수를 맞추는 이유
상용 VPN 하나만 켜는 방식은 초기 설정은 단순하지만, 스플릿 터널이 바뀔 때 어떤 프로세스가 어떤 인터페이스로 나가는지 가시성이 떨어집니다. Electron 패널은 되는데 터미널 도구만 깨지는 상황처럼 층이 다른 증상을 좁히기 어렵습니다.
반면 Clash·Mihomo·CVR 계열은 호스트 단위 규칙과 연결 로그가 한 화면에 모여, 클라우드 에이전트·브라우저 도구·API 호출을 의도한 정책 그룹에 고정하고 필요한 세션에만 HTTPS_PROXY를 얹는 방식으로 제어할 수 있습니다. 로컬 채팅과 원격 에이전트가 같은 구독을 공유하더라도 출구만 어긋나면 증상이 갈라지므로, 프록시 분기와 환경 변수를 맞추는 비용이 장기적으로 더 작습니다.
여행·스트리밍 우회에는 종합 VPN이 편하지만, 패키지 레지스트리·퍼블릭 API·사내망을 한 PC에서 같이 쓰는 개발자에게는 예외 목록이 거칠면 특정 패널만 따로 끊기는 일이 잦습니다. CVR로 규칙을 유지한 채 Cursor 3 세션만 환경 변수로 정렬하면, 끊김 원인을 회선이 아닌 경로 설정으로 좁히는 데 걸리는 시간을 줄일 수 있습니다.