1. 증상을 세 축으로 나누어 재현하기

첫 번째 축은 npm 타임아웃입니다. 글로벌 설치나 버전 업그레이드에서 버전 문자열 조회까지는 되는데 tarball 받는 줄에서 진행 표시만 반복되거나 아예 멈춥니다. 두 번째 축은 GitHub CLI와 릴리스 자산입니다. 워크플로 안에서 확장 기능이나 부트스트랩 스크립트가 GitHub Releases와 메타데이터 API를 동시에 두드리면, 한쪽 호스트만 다른 출구로 가서 서명 검증이나 리다이렉트가 꼬입니다. 세 번째 축은 추론 세션입니다. 설치 이후에는 문제가 없어 보였다가 긴 응답이 한 번만 걸려도 타임아웃 배너가 뜨고 다시 연결을 요구하는 패턴은 중간 장비의 유휴 세션 한계와도 맞물립니다.

질문 하나로 묶어 검색하면 해결책이 한 줄로 나오기 어렵습니다. 사용자 입장에서는 모두 “CLI가 불안정하다”로 보이지만, 네트워크 관점에서는 패키지 레지스트리·저장소 CDN·추론 API가 각각 다른 RTT 특성과 TLS 재시도 패턴을 가집니다. 따라서 재현 순서를 「설치」「저장소 도구」「모델 호출」로 나누어 각 단계 직후 연결 패널을 스크린샷처럼 메모하는 습관이 중요합니다.

2. 브라우저 Claude.ai 문제와 무엇이 다른가

탭 브라우징에서는 리소스 로더와 서비스워커가 호스트 묶음을 어느 정도 숨겨 줍니다. 반면 터미널에서는 Node와 번들러가 레지스트리와 원격 저장소를 거의 노골적으로 호출합니다. 공항 규칙에 “Anthropic 한 줄”만 넣었다면 추론 트래픽만 안정되고 패키지 저장소 줄은 여전히 느린 채로 남을 수 있습니다. 반대로 npm만 빠르게 열었는데 추론 줄이 다른 노드로 나가 조직 정책과 리전 판정이 어긋나면 세션 레벨 오류처럼 보입니다.

이 차이 때문에 브라우저 글에서 다룬 호스트 패턴을 통째로 복사하기보다, 본인 장비 로그에 실제로 찍힌 접미사를 우선해야 합니다. 인터넷에 떠도는 목록은 배포 채널과 지역 엣지 변경으로 빠르게 낡습니다.

3. 권장 점검 순서

  1. Clash 클라이언트에서 시스템 프록시 단독인지 TUN까지 켰는지 기록합니다. Electron 에디터와 통합 터미널은 출구가 달라질 수 있습니다.
  2. 연결 패널을 연 상태에서 문제 되는 명령을 한 번만 실행하고, 새로 뜬 행만 시간 순으로 적습니다.
  3. registry.npmjs.org와 tarball 호스트가 같은 정책 이름을 보는지 비교합니다.
  4. github.com·objects.githubusercontent.com·codeload.github.com 같은 패턴이 분리되어 있는지 확인합니다.
  5. Anthropic API 후보 접미사가 추론 시점에 반복되는지 확인합니다.
  6. fake-ip와 상위 DNS 해석 경로를 점검하고 TLS 재시도가 같은 호스트에서 반복되는지 봅니다.
  7. 필요하면 도메인 블록을 규칙 상단으로 올리고 광범위 GEOIP 규칙과 충돌을 줄입니다.

4. npm 축: 레지스트리 메타와 tarball 원격지

npm 타임아웃의 전형은 메타데이터 요청과 tarball 요청이 서로 다른 네트워크 경로를 타는 경우입니다. 레지스트리 응답에 따라 tarball URL은 공개 레지스트리, npm CDN, 혹은 미러 출판 소스 등 여러 형태가 됩니다. 규칙이 한 줄짜리 키워드 매칭에 의존하면 일부 접미사만 빠져 나가 지연 폭발을 만듭니다.

운영 관점에서는 “모든 npm 트래픽을 같은 정책 그룹으로 묶었다가 안정화한 다음 필요하면 CDN만 분리 실험”이 더 안전합니다. 증상이 재발하면 로그 문자열을 그대로 복사해 접미사 규칙을 추가하는 편이 빠릅니다. 사내 레지스트리를 쓸 때는 NO_PROXY와 규칙이 동시에 걸려 역설적으로 막히는 경우도 있으니 예외 목록을 명시적으로 관리하세요.

5. GitHub 축: gh와 저장소 세션

GitHub CLI는 인증과 REST, 때로는 대용량 객체 저장소 줄까지 한 번에 묶습니다. 일부 Claude Code 워크플로에서는 저장소 템플릿 가져오기나 릴리스 바이너리 확인이 같은 스크립트에 들어 있습니다. 이때 api.github.com만 프록시로 묶고 objects.githubusercontent.com 줄을 다른 출구로 보내면 표면적으로는 진행 중처럼 보이다가 마지막에 실패합니다.

반대로 조직 SSO와 디바이스 인증을 쓰는 경우에는 브라우저 창과 토큰 교환 호스트까지 포함해야 하므로, “코드만 받으면 된다”는 가정으로 규칙을 과하게 줄이면 안 됩니다. 실패 행부터 규칙에 올리는 접근을 유지하세요.

6. Anthropic 축: 추론 API와 세션 특성

Anthropic API는 짧은 요청 한 번으로 끝나지 않고 길게 유지되는 HTTPS 세션 특성이 있습니다. 노드 상품군이 유휴 TCP를 빠르게 자르면 사용자에게는 간헐적 끊김으로 보입니다. 규칙상 출구가 같아 보여도 프로토콜 스택과 중간 계층 제약으로 체감이 달라질 수 있으므로, 규칙 조정과 노드 교체 실험을 분리해서 생각하는 것이 좋습니다.

조직 정책상 허용 범위와 데이터 처리 요건은 각사 규정을 따르세요. 이 글은 허용된 네트워크 안에서 경로 일관성을 맞추는 데 초점을 둡니다.

7. 터미널 프록시와 mixed-port 교차 검증

시스템 프록시를 켜도 통합 터미널 프로세스가 환경 변수를 물려받지 않으면 CLI 스택만 직결로 나갑니다. 이 경우 규칙을 아무리 고쳐도 로그에 행 자체가 안 뜹니다. 먼저 HTTPS_PROXY와 ALL_PROXY를 현재 세션에 명시하고 curl -I로 mixed-port 경유를 증명하는 방법이 재현성이 높습니다. 구체적인 export 순서와 함정은 터미널 프록시 글을 참고하세요.

Windows에서 스토어 앱 경계와 겹치면 UWP 예외 설정이 필요할 수 있습니다. 해당 축은 별도 글이 더 빠릅니다.

8. DNS와 fake-ip 함정

fake-ip는 체감 지연을 줄일 수 있지만 규칙 엔진에 넘어가는 이름과 실제 백엔드가 어긋나면 TLS 재시도가 반복됩니다. 패키지 도구는 해석 결과를 길게 캐시하기도 해서 규칙을 고친 뒤에도 옛 주소가 남아 보입니다. 변경 후에는 관련 프로세스를 완전히 종료했다가 다시 여는 편이 안전합니다.

9. 규칙 예시: 이름은 반드시 교체

아래는 사고용 예시입니다. 정책 그룹 이름과 순서는 본인 프로필에 맞게 고치고, 반드시 로그로 검증하세요.

# Example only — replace DEV_AI with your policy group; verify hosts in logs
rules:
  - DOMAIN-SUFFIX,npmjs.org,DEV_AI
  - DOMAIN-SUFFIX,npm.community,DEV_AI
  - DOMAIN-SUFFIX,github.com,DEV_AI
  - DOMAIN-SUFFIX,githubusercontent.com,DEV_AI
  - DOMAIN-SUFFIX,anthropic.com,DEV_AI

과하게 넓은 DOMAIN-KEYWORD 한 줄은 다른 트래픽까지 잡아 동료에게 피해를 줄 수 있습니다. 먼저 로그에서 확인된 접미사를 올리고, 필요하면 단계적으로 확장합니다.

10. GEOIP·국내 직결 규칙과의 충돌

공항 구독에 GEOIP,KR,DIRECT 같은 광범위 규칙이 있으면 글로벌 CDN 일부만 의도치 않게 직결로 빠져 혼합 증상이 납니다. 로컬 덮어쓰기 블록을 파일 상단 근처에 두고 구독 갱신 후 순서가 밀렸는지 주기적으로 확인하세요.

11. GUI 워크플로: 로그 필터링 습관

Mihomo 호환 클라이언트는 연결 패널에서 문자열 필터가 가능합니다. npm·github·anthropic처럼 넓은 토큰으로 시작했다가 실패 행이 포착되면 접미사 규칙으로 좁히면 됩니다. 첫 설치 흐름은 Clash Verge Rev 입문 가이드를 참고해 프로필 적용 순서를 정리한 뒤 이 글의 분류 단계로 넘어오면 부담이 줄어듭니다.

12. 다른 도구 글과 짝 짓기

Microsoft·모델 호스트 분리 축은 Copilot·GitHub 글, 원격 MCP·SSE는 Cursor MCP 글이 각각 다른 제품 경계를 다룹니다. 증상 문구가 비슷해도 스택이 다르면 규칙 복사만으로는 안 맞습니다.

13. 자주 묻는 질문

Q. 브라우저에서는 Claude가 되는데 CLI만 안 된다면?
A. 터미널 출구와 브라우저 출구가 다른 전형입니다. 환경 변수·TUN·통합 터미널 종류부터 맞춘 뒤 로그를 다시 보세요.

Q. 회사 프록시 안에서도 같은가요?
A. 이중 프록시와 인증 헤더가 겹치면 증상이 달라집니다. 허용된 범위 안에서 PAC와 Clash 우선순위를 조직 보안 정책과 함께 조정해야 합니다.

Q. 규칙을 많이 넣을수록 좋나요?
A. 아닙니다. 로그에 근거하지 않은 장문 규칙은 디버깅을 어렵게 만듭니다. 실패 행부터 추가하는 편이 운영 비용이 적습니다.

14. 준수 안내

이 글은 불법 우회나 약관 위반을 돕지 않습니다. 소속 조직의 네트워크 정책과 클라우드 제공자 약관을 준수하고, 허용된 경로 안에서 안정성을 개선하는 데 활용하세요.

15. 정리

Claude Code CLI 주변에서는 npm 타임아웃·저장소 줄·Anthropic API 세 축이 동시에 움직입니다. 규칙을 한 줄로 뭉개면 반쪽 증상이 반복되므로 먼저 연결 로그로 출구를 증명하고 접미사 블록을 정렬하세요. 터미널 프로세스만 직결인 경우에는 규칙 이전에 환경 변수와 mixed-port 검증이 우선입니다.

범용 프록시 앱 중에는 규칙 편집과 로그 확인이 분리되어 있거나 구독만 바꾸라고 안내하는 경우가 많습니다. 운영자 입장에서는 원인 분리가 어렵고 같은 증상을 노드 교체로만 덮기 쉽습니다. 반면 Mihomo 계열 클라이언트는 패턴 규칙과 연결 기록을 한 화면에서 다루기 쉬워 명령줄 개발 스택처럼 호스트가 많은 경우 진단 속도가 빠른 편입니다. 게다가 프로필 전환과 DNS 모드를 함께 묶어 두면 재현 실험을 반복하기도 수월합니다. → 즉시 무료로 Clash를 다운로드하고 npm·GitHub·Anthropic 줄을 같은 정책으로 묶어 명령줄 AI 워크플로를 매끈하게 다듬어 보세요