MCP 도구 총 타임아웃? npm·GitHub를 Clash로 분기해 Model Context Protocol 스택을 안정화하세요 (2026)

1. 왜 MCP에 npm·GitHub가 동시에 붙는가

Model Context Protocol은 IDE·에이전트가 외부 도구와 말을 섞는 프로토콜이고, 실제 서버는 보통 Node로 배포하거나, 배포 가이드가 npx -y <패키지> 형태로 안내하는 경우가 많습니다. 이 순간 npm registry를 거쳐 tarball을 받고, 런타임이 내부에서 https://로 나가는 도메인은 예제·템플릿마다 갈리지만, 공개 패키지를 끌어오는 경우 github.com나 codeload.github.com이 함께 올라옵니다. 팀이 사내 GitHub Enterprise·ghcr.io·릴리스 아티팩트를 쓰면, 단일 개발자 도구 세션이 npm·GitHub·기타 CDN을 섞어 부르게 됩니다. 네트워크 정책이 모호하면, 한 호스트의 지연이 누적되어도 상위 로그엔 MCP 타임아웃으로만 읽힐 수 있어, 먼저 Clash 분기로 트랜잭션 단위를 나누는 것이 효율적입니다.

이미 Windows·npm·pnpm 글에서 HTTP_PROXY·NO_PROXY를 다루었다면, 여기에 더해 ghcr.io·api.github.com·객체 URL을 YAML의 rules에 이름으로 박아 두면, IDE가 자식 셸을 띄울 때도 동일한 출국 경로를 타기 쉽습니다. Cursor용 도메인 전용으로만 고정한 프로필이 있다면, MCP 워크플로용으로 npm·GitHub 섹션을 꼭 한 블록 추가하는 편이 안전합니다.

2. "총 타임아웃"으로 읽히는 전형적 패턴

로그에 ETIMEDOUT·socket hang up·Request timeout이 연속이면, 실제론 (가) registry에서 메타는 받고 tarball 쪽 S3·CDN이 막힌 경우, (나) api.github.com rate limit·SSRF 방화벽·지역 라우팅, (다) github.com 웹·raw.githubusercontent.com·objects.githubusercontent.com이 서로 다른 AS로 갈리는 경우가 흔합니다. npx는 캐시·버전 탐지 단계에서 여러 npm 엔드포인트를 두드리고, git LFS나 릴리스 zip를 받으면 codeload.github.com까지 붙습니다. Clash에서 이들을 한 정책 그룹에 넣지 않고 광역 MATCH에 맡기면, 일부는 직접·일부는 느린 노드·일부는 끊긴 노드로 흩어질 수 있어, 체감은 "전부 MCP가 죽었다"로 보입니다. 사전에 curl -I로 호스트를 나누어 측정한 뒤, 규칙으로 묶는 것이 첫걸음입니다.

3. npm·패키지 매니저 쪽에 묶을 호스트

공용으로 자주 쓰는 것은 registry.npmjs.org, 예전 registry.npm.taobao.org 계열(현 팀이 바꾼 미러), registry.yarnpkg.com입니다. corepack·pnpm·bun은 설정에 따라 registry.npmjs.org에 덧붙이거나 별도 미러에 붙습니다. Clash 규칙에선 DOMAIN-SUFFIX로 npmjs.org를 넓게 잡고, 팀이 쓰는 npm registry FQDN을 그대로 한 줄씩 박는 방식이 유지보수에 유리합니다. 사내 verdaccio·npmmirror는 DIRECT로 빼는 경우가 많으니, NO_PROXY와 rules를 맞춰 해외·국내 이중이 없게 맞춥니다. 이렇게 해도 metadata에 남는 tarball URL이 여전히 registry.npmjs.org이면, 그 suffix는 분기 대상에 남겨야 합니다.

4. GitHub: API·콘텐츠·릴리스·컨테이너

최소로 잡을 목록에 github.com, api.github.com, codeload.github.com, raw.githubusercontent.com, github-releases.githubusercontent.com·objects.githubusercontent.com 류를 넣는 경우가 많습니다. ghcr.io·pkg.github.com이 서버·액션이 Container·패키지를 끌어오는 구조면 별도 줄로 추가합니다. GitHub 쪽이 전부 타임아웃이면 api.github.com 토큰·조직 IP 허용 목록을 의심하기 전에, Clash 로그에서 DIRECT로 떨어지는지·노드가 죽었는지부터 확인하세요. mihomo 대시보드나 /proxies로 지연·선택을 보며, url-test·fallback이 붙은 그룹이면 라우팅 가이드와 지연·페일오버 글을 맞춰 둡니다. 조직이 .github Pages를 쓰면 *.github.io를 한 블록으로 병기할 수도 있습니다. 다만 범위가 너무 넓으면 광고·서드파티로 새는 경우가 있으니, MCP·CI와 동일한 프로필을 쓰는 팀이면 DOMAIN 단위로 조여 가는 전략이 낫습니다.

5. DNS·Fake-IP와 로그로 출구 맞추기

fake-ip를 켠 상태에서 github.com이 198.18.x.x로만 보이고, sniffer·rule이 기대한 호스트로 매칭되지 않으면, 실제 분기는 틀어질 수 있습니다. mihomo에서 DoH를 강제하는지, OS가 8.8.8.8로 빠져 Clash를 우회하는지, WSL2면 호스트 resolv가 누가 잡는지는 WSL2·DNS 글과 겹쳐 확인합니다. 개발자 도구는 동시에 수백 DNS 질의를 띄울 수 있으니, /logs에 찍힌 A·AAAA·스니퍼 SNI를 github·npm 호스트에 대해 꼼꼼히 겹쳐 보는 편이 좋습니다. 타임아웃이 DNS 단계에만 붙는지, TLS 이후에 붙는지에 따라 해결책이 갈립니다.

6. Clash rules 예시: npm·GitHub를 한 정책으로

아래는 개념 스니펫입니다. 정책 그룹명은 본인 YAML에 맞게 바꾸고, PROXY 자리는 팀이 쓰는 url-test·select로 치환하세요. 사내 DIRECT가 먼저여야 할 호스트는 위에 두는 습관이 안전합니다.

# Example — replace PROXY and ordering with your config
rules:
  - DOMAIN-SUFFIX,npmjs.org,PROXY
  - DOMAIN-SUFFIX,yarnpkg.com,PROXY
  - DOMAIN,registry.npmjs.org,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN,api.github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN,codeload.github.com,PROXY
  - DOMAIN-SUFFIX,ghcr.io,PROXY

rule-providers·GEOIP와 섞을 때 GEOSITE,github,PROXY 류의 편의키가 있으면 쓸 수 있지만, 환경마다 내용이 달라 MCP 세션에선 명시 DOMAIN이 더 예측 가능한 경우가 있습니다. 구독이 불안정하면 먼저 Windows 구독·TLS 글을 점검하세요. 중복 규칙이 많을수록, Clash 분기는 상단이 승리한다는 점을 잊지 말고 한 번씩 전체 rules를 출력해 확인하는 것이 좋습니다. 이렇게 npm과 GitHub를 묶어 두면, Model Context Protocol 쪽 로그는 같아도 실제 흐름은 끊기지 않기 쉬워집니다.

7. TUN·시스템 프록시·MCP 자식 프로세스

일부 MCP 구현은 IDE가 띄운 node·npx 자식이 시스템 프록시를 전혀 보지 않고 직접 돌기도 합니다. 이 경우 TUN이나, 터미널 셸에 HTTP_PROXY를 강제하는 팀 루틴이 유효해집니다. Verge·Windows 글의 전역 프록시·TUN 절차와 병행해, "어느 프로세스가 누구의 환경 변수를 상속받는지"를 정리하세요. macOS·Linux도 동일하며, UWP/샌드박스 루프백 이슈는 UWP 글과 교차 점검할 수 있습니다. 개발자 도구 생태는 작은 예외가 곧 타임아웃으로 터지므로, Clash 분기+환경 둘 다 맞추는 "이중선"이 MCP 스택에 잘 맞습니다.

8. 실측 점검 순서

첫째, 동일 셸에서 npm ping과 curl -I https://api.github.com로 지연·HTTP 코드를 봅니다. 둘째, npx로 MCP 패키지를 띄울 때, Clash 로그에 github·npm FQDN이 기대한 정책 그룹에 찍히는지 확인합니다. 셋째, corepack·pnpm 캐시를 바꾸기 전에, 동일 registry·PROXY 상태로 재현되는지 봅니다. 넷째, GitHub 토큰·SSO·IP 허용이 겹쳤는지, 401·403이 아닌지를 HTTP 레벨에서 구분합니다. 다섯째, 여전히 타임아웃이면 DNS 모드를 전환·스니퍼·IPv6 AAAA를 IPv6 글과 맞춰 봅니다. 이 순서는 Model Context Protocol뿐 아니라, 일반 CI·로컬 개발에도 그대로 이어집니다.