이 글이 맞는 증상

Windsurf에서 코드를 쓰거나 리팩터링하는 일반 편집은 되는데, Cascade로 올라간 클라우드 모델 응답만 중간에 멈추거나 ETIMEDOUT류로 다시 시도하는 패턴이 반복된다면 네트워크 경로와 프록시 분기를 의심할 만합니다. 특히 웹 검색·패널 UI는 통과하는데 추론 스트림만 끊기는 경우, 특정 호스트가 규칙에서 DIRECT나 불안정 업스트림 줄에 묶였을 가능성이 큽니다.

또 다른 전형은 AI IDE 창에서는 로딩만 길어지고, 같은 PC의 통합 터미널이나 CLI 도구에서는 즉시 실패하는 경우입니다. Chromium 계열 패널이 OS 시스템 프록시를 따라가지만, 노드나 파이썬 런타임 기본값은 HTTPS_PROXY가 비어 있으면 직접 소켓을 열 경우가 많아 동일 디스플레이라도 출구가 갈라지는 현상이 생깁니다.

이 글은 Clash Verge Rev(이하 CVR)를 기준으로 mixed-port, 규칙 기반 API 분기, 터미널 HTTPS_PROXY·NO_PROXY, 그리고 필요 시 시스템 프록시·TUN을 한 줄로 정렬하는 절차를 다룹니다. 제품 측 엔드포인트 이름은 업데이트마다 바뀔 수 있으므로, 공개 블로그 목록을 그대로 복사해 붙이기보다 실패 직후 연결 로그에 찍히는 호스트 이름을 기준으로 규칙을 보강하는 방식을 권합니다.

왜 Cascade·클라우드 API만 더 잘 끊길까

클라우드 추론 경로는 토큰 스트리밍과 긴 세션 유지 연결이 겹치면서, 짧은 REST 한 방보다 패킷 지터와 재전송 타이밍에 민감합니다. 일반 브라우저 탭이 통과한다고 해서 동일 업스트림이 스트림 체인까지 안정적인 것은 아닙니다.

또 릴리스마다 AI IDE가 붙는 인증 게이트·리전·CDN 조합이 달라지면, 과거에 잘 되던 와일드카드 규칙이 새 호스트를 놓치거나 GEOSITE 묶음 우선순위가 밀려 의도하지 않은 DIRECT로 떨어질 수 있습니다. 증상이 간헐일수록 회선 불량만 보기보다 어느 정책 그룹에 매핑되는지를 확인하는 편이 비용 대비 효과가 높습니다.

2026년 현재 Windsurf처럼 제품 이름이 명확한 AI IDE 트래픽이라도 서버 측에서 도메인을 나누어 쓰는 경우가 많아, 채팅 UI와 빌드·동기화·모델 API가 각각 다른 서픽스로 갈립니다. 그중 하나만 규칙에서 빠지면 “가끔만 Cascade가 죽는다”처럼 보입니다.

패널·터미널·백그라운드 트래픽 나누기

패널·웹뷰류는 OS 네트워크 스택을 타는 비중이 커 시스템 프록시와 동조하기 쉽습니다. 반면 LSP나 확장 프로세스가 별도 실행 파일로 분리되어 있으면 동일 규칙을 공유하지 못하고 출구만 달라질 수 있습니다.

통합 터미널은 부모 세션의 환경 변수 상속 때문에, 개발자가 최근에 .zshrc만 고쳤는데 에디터는 예전 세션을 붙잡고 있는 식으로 오래된 프록시 값이 남는 경우가 많습니다. 탭을 닫았다가 다시 열었는지, CI와 로컬 셸 설정이 같은지까지 같이 확인해야 합니다.

패키지 인덱스·사내 레지스트리는 NO_PROXY에 빼지 않으면 회사 허브가 공용 프록시를 한 번 더 거쳐 무한 대기처럼 보일 때가 있습니다. 반대로 퍼블릭 API만 프록시를 타야 한다면 허브를 DIRECT로 두고 외부 서픽스만 프록시 그룹으로 보내는 식이 안전합니다.

규칙 분기와 TUN, 무엇부터 맞출까

TUN 한 방으로 검증 속도를 낼 수는 있지만 회사 보안 에이전트·Always-On VPN과 라우팅 충돌이 잦습니다. CVR 규칙 엔진 + mixed-port는 어떤 요청이 어떤 체인으로 나갔는지 로그에 남아, 회선 문제인지 설정 문제인지 구분하기 쉽습니다.

실무에서는 (1) 코어 활성 상태와 포트 확인, (2) 실패 호스트의 정책 이름 확인, (3) 필요한 세션만 HTTPS_PROXY, (4) 남증상에만 TUN 같은 순으로 두면 재현성과 롤백이 모두 간단합니다.

팁: Node·Python 클라이언트는 HTTP_PROXY만 보거나 반대로 ALL_PROXY를 우선하는 경우가 있습니다. 문제 재현 중에는 env | grep -i proxy로 빈 값과 오타 없는 스키마를 함께 확인하세요.

1단계: Clash Verge Rev 활성 상태와 mixed-port

CVR을 실행한 뒤 활성 프로필과 Mihomo 계열 코어 기동 여부를 확인합니다. 구독·룰셋이 자동 업데이트되면 과거에는 통과하던 라인이 새 RULE-SET 아래로 밀려 증상이 갑자기 나타나기도 하니 동기화 시각을 메모해 두면 회귀 분석에 도움이 됩니다.

mixed-port 숫자를 적어 두고 시스템 프록시 연동이 이 포트를 가리키는지 확인합니다. 터미널 프록시 URL도 같은 로컬 입구여야 같은 규칙 테이블을 탑니다. 다른 애플리케이션이 같은 포트를 선점했다가 번호가 바뀌면 환경 변수만 수정해서는 패널과 터미널이 어긋난 채 남습니다.

2단계: 로그에서 호스트를 확정한 뒤 API 분기

실패 시점 직후 CVR 연결 뷰를 열어 도메인 또는 SNI·정책 그룹명을 메모합니다. 공개 목록만 복사해 붙이면 빗나가거나 상위 줄에 의해 무시되는 경우가 있어, 로그 기반 패치가 훨씬 신뢰도가 높습니다.

YAML이나 규칙 편집기에서 해당 서픽스를 지연과 안정성이 검증된 프록시 그룹에 매핑합니다. 상단 GEOSITE 줄이 같은 호스트를 DIRECT로 덮거나, 특정 업스트림 한 줄에 과도하게 묶이지 않았는지 대조합니다. 빌드번호가 다른 팀원과 공유 중이라면 PR에 짧게 “어떤 실패 패턴을 막는지”를 남기면 이후 업데이트 때 비교가 쉽습니다.

3단계: HTTPS_PROXY·NO_PROXY로 툴 체인 맞추기

대부분의 HTTP 스택이 아래 변수를 읽습니다.

  • HTTPS_PROXY / HTTP_PROXY — TLS 및 일반 HTTP용 프록시 URL
  • ALL_PROXY — 일부 도구 체인이 통합 키로 쓰는 경우
  • NO_PROXY — 127.0.0.1, localhost, 사내망 CIDR·도메인, 로컬 MCP 브리지 등

항상 로그온 계정 전역으로 export하기보다, CVR 실행 중에만 켜지는 분기 블록이나 디렉터리 단 도구인 direnv로 주입하면 공용 장비에서 실수가 줄어듭니다. 이미 떠 있는 통합 터미널은 부모가 바뀌기 전까지 옛 변수를 들고 다니므로, 수정 후 새 탭으로 다시 재현 테스트를 하는 것을 잊지 마세요.

원격 런너·CI에서는 시크릿에 프록시 URL을 두되 빌드 로그에 사용자명·토큰이 섞여 출력되지 않게 파이프라인 단계 레벨을 조절합니다.

프록시 URL 형식과 SOCKS 선택

CVR mixed-port가 HTTP CONNECT와 SOCKS를 함께 제공한다면 먼저 http://127.0.0.1:<port> 형식을 시험합니다. 구형 클라이언트나 일부 라이브러리는 SOCKS만 지원하면 socks5://127.0.0.1:<port>처럼 스키마를 분명히 써야 즉시 실패 대신 무한 대기로 보이지 않습니다.

4단계: 시스템 프록시·TUN과의 교차 검증

macOS와 Windows 모두 시스템 레벨 프록시 연동 후 패널·브라우저가 가리키는 포트와 터미널이 쓰는 127.0.0.1 경로가 같은지 재확인합니다. TUN만 단독으로 켠 경우 실제 패킷이 가상 어댑터로 나가는지, 방화벽 프로필에서 허용되는지 순서대로 점검합니다.

회사 VPN과 CVR TUN을 동시에 켠 상태에서는 핸드셰이크가 이중으로 감싸이거나 순환 라우팅이 생기기 쉬워, 테스트 시에는 한쪽만 켠 채 같은 프롬프트를 재생해 시간 차 비교하는 편이 원인 분리에 빠릅니다.

주의: 넓게 연 HTTPS_PROXY는 패키지 인덱스·내부 결제 API까지 예상 밖 우회를 탈 수 있습니다. NO_PROXY를 팀 보안 정책과 맞추고 로그 레벨에 자격 증명 문자열이 남지 않게 조절하세요.

MCP·외부 에이전트와 함께 쓸 때

Windsurf 같은 AI IDE에서 외부 맥락 브리지를 쓰면 stdio MCP와 원격 SSE·HTTP MCP가 같은 세션 안에 공존할 수 있습니다. stdio 타입이라면 우선 로컬 소켓·방화벽을 보고, 원격 HTTP라면 규칙상 분기된 호스트와 HTTPS_PROXY 세션이 같은 기대 경로인지 재확인합니다. 팀용 게이트웨이를 직접 세웠다면 그 도메인을 NO_PROXY와 규칙 양쪽에 일관되게 넣어 루프를 끊어야 합니다.

5단계: 여전히 끊길 때 좁히기

  1. 동일 시각에 시스템 브라우저에서 같은 호스트 이름으로 HTTPS가 한 번이라도 성공하는지 비교합니다.
  2. CVR 로그에서 해당 연결이 어떤 규칙 순번·어떤 체인 이름으로 분류됐는지 확인합니다.
  3. 통합 터미널과 외부 터미널 각각에서 curl -Iv 등으로 간단 진단을 실행해 TLS 핸드셰이크 타임아웃인지 즉각 거부인지 구분합니다.
  4. DNS가 fake-ip 체계나 DoH·시스템 리졸버와 어긋나 누설이 없는지 봅니다.
  5. MTU 불일치와 간헐적 패킷 손실처럼 구독이 아닌 경로 문제를 짧은 Ping·MTR 패턴으로 가려 냅니다.

이 글과 Cursor·Codex류 문서와의 차이

같은 CVR 규칙·HTTPS_PROXY 패턴이라도 제품별로 필요한 호스트 묶음이 모두 다릅니다. Cursor 클라우드 에이전트 글에서는 에디터 전용 패널 흐름을, Codex CLI 글에서는 터미널 전용 타임아웃을 깊게 다룬 반면 이 글은 Windsurf Cascade 세션 스트림이라는 사용자 관점의 증상을 전제로 범용 점검 루프를 제공합니다.

자주 묻는 질문

Q. 업스트림만 바꾸면 잠깐 나아져요.
A. 그 자체가 규칙상 특정 줄에 과도하게 몰린 신호입니다. 업스트림 풀이 아니라 정책 그룹에 건강 검사와 폴백을 넣거나, 간헐 끊김 줄을 분산하는 편을 검토합니다.

Q. 회사에서는 터미널 프록시 설정이 금지됐습니다.
A. 정책을 무시하지 마시고 허용된 egress와 인증 프록시 형식을 IT 보안 정책에 맞춰 요청하세요. 이 글은 합법적 개발 환경만 전제합니다.

Q. VPN 하나만 전역으로 쓰면 단순하지 않나요?
A. 패널 트래픽과 패키지 관리 트래픽까지 한 덩어리로 나가며 스플릿이 거칠면 특정 패널만 깨져 보입니다. 규칙 기반 게이트가 가시 로그까지 제공하는 이유가 거기 있습니다.

마무리: AI IDE에는 규칙·환경 변수 정렬을 먼저

Windsurf처럼 클라우드 모델이 제품 이름에 붙은 AI IDE는 출시 속도 때문에 엔드포인트 이름이 빠르게 바뀌고, 패널·도구 프로세스가 여러 레이어로 갈립니다. 상용 종합 VPN은 초기 접속 편의는 좋지만, 어떤 프로세스가 어느 인터페이스로 빠져나가는지 가시성이 떨어져 간헐 증상을 좁히기 어렵습니다.

반면 Clash·Mihomo·CVR 계열은 호스트 단위 API 분기와 연결 로그를 한 패널에 모아, 같은 구독을 쓰더라도 패널·터미널·백그라운드 업데이트의 출구를 의도적으로 정렬하고 필요한 세션에만 HTTPS_PROXY를 얹는 방식으로 제어할 수 있습니다. Cascade처럼 민감한 스트리밍은 작은 차이만으로도 시간 초과처럼 보이므로, 노드 순위만 고치기보다 경로와 환경 변수를 먼저 맞추는 편이 유지 비용도 낮습니다.

여행 중 스트리밍 우회 등에는 무설정 종합 서비스가 편하지만, 퍼블릭 API·사내망·패키지 인덱스를 한 장비에서 병렬로 다루는 개발 업무에서는 예외 처리가 무거워질수록 패널 일부만 끊긴다고 느끼기 쉽습니다. CVR로 규칙을 유지한 채 Windsurf 세션만 HTTPS_PROXY 스택까지 정렬하면, 문제를 회선 품질이 아닌 분기 설정으로 좁히는 데 들이는 시간을 줄일 수 있습니다.

Clash 호환 클라이언트를 받아 Windsurf 같은 AI IDE 규칙 스택 통일하기 →