Windsurf Cascade가 거부되거나 타임아웃될 때: Clash로 Codeium API·모델 게이트웨이를 분기하기 (2026)

1. 증상: 로그인은 되는데 Cascade만 무한 로딩

앱 업데이터·설정 동기 자체는 우회되지만 채널 패널이 비거나 토스트로 일반적인 네트워크 안내가 뜨면, 많은 사용자가 즉시 노드 교체부터 합니다. 그러나 같은 프록시를 쓰는 터미널에서는 패키지 다운로드가 통과하고 Cascade만 버벅거리면 실제 병목은 HTTP/3(QUIC) 경로 차이나 증명 교환용 추가 호출일 수 있습니다. 또한 회사 또는 학교 안에서 허브형 프록시에만 맞춰 둔 경우, IDE 내부 웹소켓·긴 헤더 스트림이 간헐적으로 리셋되어 안정 연결 점수가 떨어지는 패턴도 자주 재현됩니다.

본 브랜드는 VS Code 호환 레이어를 기반으로 하므로 표피적인 호스트 이름은 시간이 지날 때마다 늘어납니다. 다만 패턴 자체가 갈라지긴 할 뿐, 핵은 직접 연결 레인에만 붙던 서브도메인이 있으면 채널 패널이 반만 그려졌다가 멈추는 것처럼 보입니다. 첫 관문은 증세를 규격화하는 것 즉 규칙 매칭 한 줄이라도 다른 그룹을 타면 지연이 누적된다는 공통 인식부터 잡습니다.

2. 다른 AI IDE 글과 겹치지 않게 쓰기

본 카테고리에서 다룬 Cursor 분기 글은 패키지 마켓·확장과 npm 축 비중이 큽니다. 반면 Cascade는 브라우저 인증 교차·SSE형 도구 결과와 붙으며, 종종 표기 이름이 사용자용 문구와 다른 내부 코드명처럼 남습니다. 그래도 실무에서는 외부 레지스트리, 브라우저 창 재사용, 그리고 모델 게이트웨이 라우팅 이라는 같은 삼축이라는 점이 중요합니다. 글 간 규칙을 복붙하면 오탐이 생기므로 로그 검증 우선 전제를 깔고 작성합니다.

3. 도메인·게이트웨이 시작점 목록

아래 문자열들은 작성 시점 관행을 기준으로 한 베이스라인입니다. 기능 출시 순서에 따라 *.codeium.com, windsurf.com, 브라우저 OAuth 핸들, MCP 마켓에서 붙은 서드파티가 섞입니다. 실사용에서는 대시보드나 문서 안내처럼 server.codeium.com/api 패턴처럼 통계형 REST와 대화형 모델 엔진이 분리되어 있어도, 네 가지 카테고리로 나누어 생각합니다. 즉 업데이트 호스트 로그인·계정 상태 조회 채널 스트림·롱폴링 MCP 엔드포인트 순입니다.

GitHub 연동 글(Windows Git/GitHub 예시) 과 달리, 여기서는 IDE 본연의 패널 기능에 집중합니다. 과도하게 github.com을 같은 그룹에 넣어버리면 테스트 지연과 혼선이 커져, 실패 순간 패킷부터 추적해야 합니다. 조직 이름이 브라우저 주소표시줄에만 보였다 해서 레지스트리 전체와 동일 접미라고 단정하지 말고, 증상 재현 순간 호스트 문자열 단위로만 줄을 채워 넣는 습관이 좋습니다.

4. 프로세스명 분기와 도메인 분기 선택

macOS·Windows에서 실행 바이너리 이름만으로 패널 기능을 특정 노드로 보내면 편하지만 자식 노드 이름이 다른 경우 많습니다. Turborepo처럼 래퍼를 탄 패키지가 돌거나 터미널 속 node가 직접 외부 호출할 때 레이블이 헷갈리기 때문입니다. TUN을 쓰면 OS 전체 패킷이 코어 표면에 놓여 추적에는 유리하지만, 사내 회선에서는 직렬 프록시를 병렬로 태우지 못하게 막는 경우도 많습니다. 따라서 시작은 DOMAIN-SUFFIX와 MATCH 직전에만 올린다 라는 순서부터가 안전합니다. Windows TUN·UWP 루프백 안내 글도 같이 놓습니다.

5. mihomo 규칙 스니펫

다음은 전용 그룹을 Windsurf-Core라고 이름 붙였을 때의 예시 묶음입니다. 이름은 사용자 구독과 맞게 바꾸세요. 규칙 우선순위 개념은 고급 라우팅, 패치 덮임 방지에는 구독 가져오기 페이지를 활용하면 됩니다. 주석 블록은 영어 표기 규격을 따랐습니다.

rules:
  # Windsurf / Cascade / Codeium — keep above broad GEOIP MATCH
  - DOMAIN-SUFFIX,codeium.com,Windsurf-Core
  - DOMAIN-SUFFIX,windsurf.com,Windsurf-Core
  - DOMAIN-SUFFIX,server.codeium.com,Windsurf-Core

  - DOMAIN-SUFFIX,marketplace.visualstudio.com,Windsurf-Core
  - DOMAIN-SUFFIX,open-vsx.org,Windsurf-Core
  - DOMAIN-SUFFIX,registry.npmjs.org,Windsurf-Core
  # Append hosts from Cascade failure logs (SSE / OAuth / MCP)

  # Example process pin (rename binary per OS/build)
  # - PROCESS-NAME,Windsurf,Windsurf-Core

  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

DOMAIN-KEYWORD처럼 지나치게 넓은 키워드는 다른 트래픽까지 끌고 오오탐 가능성을 키웁니다. MCP 전용 줄을 따로 쓸 생각이라면 해당 호스트 줄을 별 블록으로 분리했는지 명시해야 합니다.

6. 정책 그룹·모델 경로 안정화

자동 테스트 그룹에만 넣으면 체크 주기 때마다 눈 깜박 할 사이 회선 교체가 발생해 응답 편차가 극적으로 커질 수 있습니다. Cascade 기반 작업에서는 토스트가 다시 안 뜨는 것만으로 사용자 만족이 크게 달라지므로 전용 줄에서 직접 고정, 또는 fallback으로 순서가 예측 가능한 줄을 선택하는 방법이 많이 씁니다. 자동 지연·페일오버 혼합은 url 테스트 대비 글을 통해 설계 패턴 예시만 가져오고, 회선 국경과 서비스 약관이 맞물리면 그다음 순위로 ASN을 교정합니다.

7. DNS·Fake-IP와 QUIC 교차 검증

mihomo의 Fake-IP 기능은 패킷을 도메인 기준 라우팅하는 데 익숙하게 해 주지만 브라우저 DoH 또는 OS 수준 보안 DNS가 활성이라면 패널 패킷 한쪽만 교차 경로에서 벗어납니다. 개요와 축 이름은 DNS·Fake IP 비교 블록을 함께 읽도록 권합니다. 여기서는 보조 예시입니다.

# Example only — align resolver policy with outbound choice
dns:
  nameserver-policy:
    "+.codeium.com":
      - https://dns.google/dns-query
    "+.windsurf.com":
      - https://dns.alidns.com/dns-query

8. MCP·플러그인이 숨긴 간접 장애

Cascade가 도구 패널까지 열린 뒤에야 멈춘다면, 실제 시간은 MCP 서버 쪽 헬스 또는 OAuth 리다이렉트 때문에 소모됐을 수 있습니다. 패널 문자열보다 툴링 패널 패킷 줄을 따라가세요. 패키지나 npm 교차 이슈는 MCP 라우팅 글에서 이미 많이 다루었으므로, 여기서는 Windsurf 문자열 패키지가 아닌 MCP 스트림이 중첩된다는 차이점만 명시했습니다.

9. 로그 순서 체크리스트

절차는 단순합니다. 가장 최근 패널 패킷 줄을 따라가 해당 규칙명이 사용자가 지정했던 줄인지 검사합니다. 같은 요청이라도 패널이 세션을 나눌 때마다 다시 붙었는지 헤더 순서를 따라가 두 번째 줄이 새 그룹을 타진 않았는지 봅니다. QUIC 실험이 끝나면 패널 상태 복귀 속도 차이만 기록해 두세요. 종합 구조 파악은 Clash란 무엇인가 페이지에서 그림처럼 잡아도 됩니다.

10. 자주 묻는 질문