1. 증상을 “마켓”과 “MCP 전송”으로 나누기

둘 다 Cursor 안에서 네트워크 오류로 보이지만 원인 축이 다릅니다. 마켓플레이스가 비거나 확장 검색만 실패한다면 편집기·OpenVSX·정적 CDN 쪽을 먼저 의심하고, MCP 서버를 추가한 직후에만 스피너가 길어지거나 터미널·개발자 도구에 TLS 관련 메시지가 찍힌다면 원격 MCP 엔드포인트·GitHub 자산·SSE 유지 연결이 서로 다른 Clash 정책 그룹으로 갈라졌을 가능성이 큽니다. 장시간 스트림은 중간 프록시의 타임아웃·HTTP/2 중간 박스·SNI 검사와도 맞물리므로, “노드만 바꾸면 된다”보다 어느 호스트가 어떤 출구를 보는지부터 적는 것이 빠릅니다.

프로필이 아직 불안정하면 구독 가져오기 튜토리얼에서 공항 규칙과 로컬 덮어쓰기 순서를 정리한 뒤 이 글의 단계로 넘어오세요.

2. MCP 전송 체인: 레지스트리·GitHub·공급사 API·SSE

원격 MCP를 쓰는 흐름은 대략 다음 층으로 나뉩니다. 첫째, Cursor가 서버 메타데이터를 읽기 위해 레지스트리나 문서 호스트(공식 예시 URL, 팀 내부 게이트웨이)에 HTTPS로 접근합니다. 둘째, 서버 바이너리나 런타임 의존성이 GitHub(github.com, objects.githubusercontent.com, 때로는 raw.githubusercontent.com)에서 내려받아지는 경우가 있습니다. 셋째, 실제 도구 호출은 공급사·자체 호스팅 API 도메인으로 나갑니다. 넷째, 스펙에 맞는 SSE 또는 스트리밍 HTTP가 열리면 짧은 요청과 달리 연결이 수 분 이상 유지되며, 이 구간만 다른 노드로 나가면 클라이언트는 “연결은 됐다가 중간에 멈춘다”로 느낍니다. 이 네 층이 DIRECT와 PROXY에 섞이면 UI는 한 화면인데 밑에서는 세션이 깨집니다.

GitHub 전반을 다룬 Copilot·모델·Microsoft 호스트 분류 글과 접미사가 비슷하지만, MCP는 npm 설치·SSE 업그레이드 경로가 추가되므로 로그에 찍힌 문자열을 그대로 기준으로 삼는 것이 안전합니다.

3. Clash 연결 로그로 호스트 묶음 만들기

Clash Verge Rev 등 GUI의 실시간 연결 보기를 연 상태에서 Cursor에서 같은 MCP 서버를 끄고 다시 켜기·도구 한 번 호출·스트림이 있는 작업을 순서대로 실행합니다. 새로 뜬 행만 시간순으로 적으면 레지스트리 조회, GitHub 다운로드, API POST, SSE 행이 어떤 정책 이름(PROXY, DIRECT, 커스텀 그룹)에 매칭되는지 표가 됩니다. fake-ip를 쓰는 경우 표시 이름과 실제 백엔드가 어긋날 수 있으니, 같은 시점에 DNS 모드도 함께 기록하세요. Electron 앱은 시스템 프록시를 일부만 따르는 경우가 있어 TUN 모드를 켠 뒤에만 로그가 깔끔해지는지도 대조합니다.

4. 터미널 검증: curl과 openssl로 출구 일치 확인

로그에 나온 호스트를 그대로 복사해 터미널에서 확인합니다. 프록시 환경 변수를 Clash의 mixed-port에 맞춘 뒤 다음과 같이 시험할 수 있습니다(주석은 설정 파일에 넣지 마세요).

export https_proxy=http://127.0.0.1:7890
curl -I https://registry.modelcontextprotocol.io
curl -I https://github.com
curl -I https://api.github.com

TLS만 따로 보고 싶다면 openssl s_client -connect 호스트:443 -servername 호스트로 핸드셰이크가 끝까지 가는지 확인합니다. 여기서 회사 중간 장비가 SNI를 깎는 경우 즉시 드러납니다. Cursor 프로세스와 터미널이 같은 시스템 프록시·TUN 경로를 쓰는지 먼저 맞추지 않으면 “curl은 되는데 IDE만 안 된다”가 생깁니다.

패키지 레지스트리와 npm 트래픽을 WSL에서 쓰는 경우 WSL2·호스트 프록시 글과 출구가 어긋나지 않는지도 점검하세요.

5. SSE·장시간 연결: 타임아웃과 노드 제약

SSE는 HTTP를 유지한 채 이벤트를 밀어 넣는 방식이라, 중간 프록시나 노드가 idle 타임아웃이 짧으면 스트림이 끊깁니다. 규칙으로 올바른 그룹에 넣었는데도 중간에 끊기면 노드 측 제한을 의심하고, 동일 호스트를 다른 정책 그룹으로 옮겨 A/B 테스트하세요. HTTP/2 업그레이드·WebSocket과 섞인 구현도 있어 로그에 101 전환 행이 보이면 별도 경로로 취급하는 편이 낫습니다. 이 단계는 Figma·WebSocket 분류 글의 “장시간 채널” 절차와 읽는 습관을 같이 두면 이해가 빨라집니다.

6. 규칙 예시: DOMAIN-SUFFIX를 로그 순서에 맞추기

아래는 틀일 뿐이며 정책 그룹 이름과 도메인은 반드시 본인 로그로 교체하세요.

# Example only — replace MCP_GROUP with your policy; verify hostnames in logs
rules:
  - DOMAIN-SUFFIX,modelcontextprotocol.io,MCP_GROUP
  - DOMAIN-SUFFIX,github.com,MCP_GROUP
  - DOMAIN-SUFFIX,githubusercontent.com,MCP_GROUP
  - DOMAIN-SUFFIX,npmjs.org,MCP_GROUP
  - DOMAIN-SUFFIX,registry.npmjs.org,MCP_GROUP

DOMAIN-KEYWORD,git처럼 과하게 넓히면 무관한 트래픽까지 끌어와 역효과가 납니다. 먼저 한 그룹으로 묶여 안정화한 뒤, 필요하면 GitHub 다운로드만 별도 그룹으로 나누는 식으로 단계적으로 조정하세요. 공항 구독의 GEOIP·DIRECT 규칙이 위에 있으면 로컬 블록이 무시되므로 순서를 다시 확인합니다.

7. DNS·fake-ip·DoH: 이름이 틀어지면 TLS만 반복됩니다

같은 호스트라도 Clash DNS와 OS DNS가 다르면 한쪽은 성공·한쪽은 실패하는 패턴이 납니다. fake-ip를 쓰는 프로필에서는 규칙 매칭에 쓰인 이름과 실제 업스트림이 어긋나지 않는지 Mihomo 문서의 권장 조합을 따르세요. 레지스트리가 CDN 뒤에 있으면 짧은 TTL로 IP가 바뀌어 세션 중 재연결이 잦아질 수 있으니, 문제 재현 직후에만 DNS 캐시를 비우고 측정합니다.

8. 마켓플레이스 글과의 관계

마켓플레이스 분류 글은 편집기·OpenVSX·AI API(api2.cursor.sh 등) 축에 초점을 둡니다. 본 글은 MCP 서버 설치·실행·스트림이 만들어내는 GitHub·npm·SSE 호스트 축입니다. 증상이 겹칠 때는 두 글의 체크리스트를 순서대로 밟되, 로그에 mcp·registry·sse·GitHub 객체 스토리지가 보이면 우선 본 글의 규칙을 적용하세요.

9. 준수·보안 안내

조직망에서 우회 연결을 허용하지 않는다면 IT 정책을 따르세요. 이 글은 허용된 범위에서 출구 일관성을 맞추는 기술 설명이며, 타인의 MCP 엔드포인트나 토큰을 무단으로 노출하는 행위를 권장하지 않습니다. 공급사 API 키는 레포·로그에 남기지 마세요.

10. 정리: MCP는 “한 도메인 한 스위치”가 아닙니다

Cursor MCP 원격 사용은 레지스트리·GitHub 자산·공급사 API·SSE가 한 흐름으로 엮입니다. Clash 분류에서 이들이 서로 다른 출구를 보면 스피너와 TLS 오류로 표면화됩니다. 연결 로그로 묶은 뒤 curl·openssl로 동일 출구를 검증하고, GitHub 프록시와 스트림 구간을 규칙 상단에서 좁혀 가면 AI 개발도구 체인을 안정적으로 유지하기 쉽습니다.

설정 파일을 매번 손으로 고치기보다 Mihomo 호환 클라이언트에서 프로필 전환과 연결 기록을 한 화면에서 다루는 편이 운영 부담이 적습니다. 다른 범용 프록시 도구와 비교해도, 규칙·DNS·TUN을 같은 앱에서 묶어 두면 “SSE만 끊긴다” 같은 증상을 빠르게 좁힐 수 있습니다. → Clash를 무료로 내려받아 MCP 세션의 출구를 한 그룹으로 맞춰 보세요