Claude Code CLI 타임아웃? Anthropic·npm Clash 분기

1. 웹 버전 Claude 글과 무엇이 다른가

이 사이트의 Claude·Anthropic 지역 제한 글은 브라우저에서 「현재 지역에서는 이용할 수 없음」 메시지를 볼 때, 지역 정책·세션·DNS 해석을 맞추는 데 초점이 있습니다. 반면 Claude Code는 터미널·에디터 안에서 Anthropic API로 긴 요청을 보내고, 같은 셸에서 npx·npm이 npm registry와 tarball CDN을 밟는 패턴이 섞입니다. 의도(검색 키워드)도 제품 형태도 달라서, 글을 나누어 두는 편이 독자에게 혼선이 적습니다.

또한 Cursor IDE 글은 VS Code 계열·확장 마켓·Open VSX 쪽 호스트 비중이 크고, 여기서는 Anthropic·npm 축에 더 좁혀 설명합니다. 공통점은 「개발자 도구가 만든 연결이 한 번에 여러 호스트로 갈라진다」는 점과, mihomo 로그로 실패 호스트를 먼저 확정해야 한다는 점입니다.

2. CLI에서 흔한 증상: 공유 출구와 교차 실패

증상은 대개 둘 중 하나로 시작합니다. 첫째, CLI·플러그인 쪽 Anthropic API 호출만 지연되거나 타임아웃되고, 브라우저는 정상인 것처럼 보입니다. 둘째, 반대로 npm install·npm view만 멈추고 API는 간헐적으로 살아 있습니다. 둘 다 OS·셸·Node 런타임이 공유하는 터미널 프록시 변수와 Clash의 MATCH 이전 규칙이 어긋났을 때 잘 재현됩니다.

특히 기본 브라우저는 시스템 프록시·DoH를 따로 잡는 반면, 터미널은 HTTP_PROXY가 비어 있거나 이전 세션 값이 남아 DIRECT로 나가는 경우가 있습니다. 반대로 레지스트리만 사내 미러를 타야 하는 환경에서는 범용 프록시 규칙이 tar·메타데이터 경로를 과하게 끌고 가기도 합니다. 따라서 「한 벌의 규칙으로 브라우저만 맞췄다」고 끝내지 말고, 실패한 요청의 호스트를 기준으로 조각을 추가하는 흐름이 안전합니다.

한 줄 정리

Claude Code는 API와 npm이 같은 출구를 공유하기 쉬우므로, Clash 로그에서 호스트를 확정한 뒤 전용 정책 그룹으로 묶는 것이 타임아웃 재현에 유리합니다.

3. 규칙 후보 도메인·호스트

서비스는 수시로 바뀌므로 아래는 출발점입니다. 실제로는 mihomo 로그·IDE/CLI 디버그 출력에서 등장하는 호스트를 더해야 합니다. Anthropic 측으로는 api.anthropic.com, anthropic.com, 콘솔·계정·문서 트래픽이 겹치면 console.anthropic.com 등이 추가될 수 있습니다. 앱이 붙는 호스트명은 제품 업데이트에 따라 달라질 수 있으니, 키워드 규칙을 너무 넓게DOMAIN-KEYWORD,anthropic처럼 잡으면 다른 트래픽까지 끌고 오지 않도록 주의하세요.

npm 쪽은 메타데이터·패키지 tarball이 갈라질 수 있습니다. 최소한 registry.npmjs.org는 넣고, 로그에 registry.npmjs.com·npmjs.org 계열 tarball 호스트가 보이면 DOMAIN-SUFFIX로 따라가면 됩니다. MCP·npm·GitHub 글에서 다루듯 api.github.com·객체 스토리지 URL도 같은 작업 흐름에 섞일 수 있어, 실패 시점에 맞춰 규칙을 늘리는 편이 낫습니다.

Anthropic API

스트리밍·긴 세션에서는 TCP/ TLS 단계와 HTTP 응답 지연이 갈립니다. 소켓 타임아웃이면 노드·DNS·경로 흔들림을 우선 봅니다.

npm registry

npm config get registry로 실제 엔드포인트를 확인하고, 기업 미러라면 그 호스트를 별도 규칙으로 분리합니다.

4. 터미널 프록시·npm과의 정렬

macOS·Linux·Windows(WSL 포함)에서 Node·npm이 Clash mixed-port를 타려면 HTTP_PROXY, HTTPS_PROXY, 필요 시 ALL_PROXY를 셸 프로필에 맞춰 주는 것이 일반적입니다. 로컬 루프백(127.0.0.1)과 사내 호스트는 NO_PROXY로 빼 두면 레거시 스크립트가 덜 깨집니다. Windows 네이티브 터미널과 WSL이 섞인 환경에서는 루프백 주소가 다르게 보이므로, 동일 명령을 두 셸에서 각각 시험해 보는 것이 좋습니다.

Windows에서 npm·pnpm을 Clash와 함께 쓸 때의 환경 변수·NO_PROXY 패턴도 참고하세요. Clash 쪽 규칙이 아무리 정교해도, 터미널이 프록시를 안 타면 로그에 잡히지 않거나 반대편 경로로 새어 나갑니다. TUN 모드를 쓰면 앱별 변수 의존도가 줄어드는 경우가 많지만, UWP·루프백 예외는 여전히 점검 대상입니다.

5. mihomo rules 스니펫과 순서

전용 정책 그룹 이름을 예시로 🔷 Dev-Anthropic-Npm이라고 하면, 넓은 GEOIP·MATCH보다 위쪽에 도메인 규칙을 둡니다. 그룹명·프록시 이름은 구독에 맞게 바꿉니다. 규칙 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # Anthropic API + npm — tighten host list from live logs
  - DOMAIN-SUFFIX,api.anthropic.com,🔷 Dev-Anthropic-Npm
  - DOMAIN-SUFFIX,anthropic.com,🔷 Dev-Anthropic-Npm
  - DOMAIN-SUFFIX,registry.npmjs.org,🔷 Dev-Anthropic-Npm
  - DOMAIN-SUFFIX,npmjs.org,🔷 Dev-Anthropic-Npm
  # Optional when console/docs break: console.anthropic.com, etc.

  # ... LAN / CN direct, then broad MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 YAML이 덮어쓰지 않게 하려면 머지 순서를 확인하세요. 패턴만 복사해 다른 AI 서비스 글과 섞이면 오탐이 늘어납니다.

6. DNS·Fake-IP와 규칙의 협업

Clash Meta에서 fake-ip를 쓰면 도메인 기준 Clash 분할이 단순해지지만, 시스템·터미널·별도 DoH가 코어 밖에서 먼저 해석하면 규칙과 실제 연결 목적지가 어긋날 수 있습니다. 증상은 「페이지는 열리는데 특정 도메인 규칙만 안 먹는다」에 가깝고, 이때는 fake-ip와 redir-host 대조 글의 절차로 DNS 모드·nameserver-policy·누수를 한 번에 점검하는 편이 빠릅니다.

# Optional — align resolvers; match upstreams to your policy
dns:
  nameserver-policy:
    "+.anthropic.com":
      - https://dns.google/dns-query
    "+.npmjs.org":
      - https://dns.google/dns-query

참고: 상용 DNS·필터 목록은 정책과 감사 요건에 맞게 선택하세요. 예시는 형식 설명용이며, 반드시 그대로 복사할 필요는 없습니다.

7. 정책 그룹: 노드 흔들림 줄이기

url-test만으로 API 트래픽을 보내면 지연이 좋은 노드로 자주 바뀌고, 스트리밍·긴 세션에서는 재연결 비용이 체감될 수 있습니다. 가능하면 전용 그룹 안에서 고정 선택이나 fallback 순서를 명확히 두고, 지역·ASN이 서비스 정책과 맞는지 함께 봅니다. 자동 지연 측정과 페일오버 조합은 url-test·fallback 글을 참고하세요.

8. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Claude Code를 재현 시나리오로 실행한 뒤 mihomo 로그에서 실패 요청이 의도한 규칙 줄에 매칭됐는지 확인합니다. 둘째, Proxies 화면에서 🔷 Dev-Anthropic-Npm 등 전용 그룹이 기대한 노드를 가리키는지 봅니다. 셋째, 동일 재현에서 터미널 env의 프록시 변수만 바꿔 대조합니다. 넷째, DNS 모드·DoH·VPN 동시 사용 여부를 바꿔 fake-ip와의 충돌을 줄입니다. 전체 그림은 Clash 개요와 함께 보면 정리하기 쉽습니다.

로그에서 볼 것

도메인·아웃바운드 이름·지연이 연속으로 일치하는지 확인합니다. 메타데이터 요청과 tarball이 서로 다른 그룹으로 새면 설치가 중간에 멈춘 것처럼 보일 수 있습니다.

API 타임아웃일 때

HTTP 오류 코드와 소켓 단계 타임아웃을 구분합니다. 후자는 노드 품질·DNS·프록시 변수·TUN 경로를 우선 의심합니다.

정리하면, Claude Code류 워크플로는 Anthropic API와 npm registry가 한 작업 흐름에 겹치기 쉬워, 증상만 보면 앱 버그처럼 보이기도 합니다. mihomo에서 호스트를 로그로 확정하고 Clash 분할 규칙을 MATCH 앞에 두며, 터미널 프록시·DNS·Fake-IP를 같은 실험 루틴에 넣으면 타임아웃 원인을 빠르게 가늠할 수 있습니다. 같은 카테고리의 다른 AI 개발 도구 글과 역할을 나누면서도, 규칙을 조각내 재사용하기 좋다는 점은 Clash 계열 클라이언트의 장점입니다.

→ Clash를 무료로 내려받아 최신 클라이언트에서 규칙·DNS·로그를 한 흐름으로 점검하고, Anthropic·npm 전용 정책 그룹을 차근차근 적용해 보세요.