Claude Code·API 불안정? Clash 분류 규칙으로 라우팅 고정(2026)

2026년, 왜 터미널·API 쪽 Claude가 더 예민해졌나

2026년에도 AI 코딩 어시스턴트와 클라우드 모델 API는 개발 일정의 중심에 있습니다. 특히 Claude Code처럼 터미널과 에디터에 붙는 도구는, 화면에 보이는 UI보다 백그라운드에서 동시에 열리는 수십 개의 TLS 세션을 전제로 합니다. 콘솔 로그인, 사용량·결제 페이지, 실제 Anthropic API 게이트웨이, CDN·리다이렉트 체인까지 호스트가 한 덩어리가 아니기 때문에, 일반적인 「해외만 프록시」 프리셋만으로는 일부 요청만 직행(DIRECT)으로 새거나, 반대로 불필요하게 넓은 키워드 규칙에 걸리는 상황이 생깁니다.

그 결과 체감 증상은 비슷해 보입니다. IDE 안에서는 괜찮은데 CLI만 타임아웃, 또는 반대로 API 키 검증은 되는데 스트리밍 응답 중간에 끊김. 원인을 노드 품질만 탓하기 전에, Clash 분류 규칙이 의도한 프록시 그룹으로 트래픽을 보내고 있는지를 먼저 확인하는 편이 낫습니다. 이 글은 이미 정리해 둔 Cursor 전용 분기 가이드와 짝을 이루도록, 도메인 차원과 프로세스 차원을 나눠 설명합니다. 두 글의 호스트 목록을 그대로 섞어 쓰지 말고, 본인 환경의 연결 로그를 기준으로 유지보수하세요.

⚠️

준수 안내: 프록시 사용과 AI 서비스 이용은 거주 지역 법령과 Anthropic 이용약관을 따라야 합니다. 본문은 네트워크 경로와 Clash 설정 기술만 다루며, 규제 회피나 약관 위반을 조장하지 않습니다.

Cursor 편과 다른 점: 터미널·런타임이 만드는 트래픽 지도

Cursor류 IDE는 확장 마켓·에디터 업데이트 채널 비중이 크지만, Claude Code와 각종 SDK·CLI는 종종 node, deno, bun, 패키지 매니저가 띄운 자식 프로세스를 통해 나갑니다. 즉 규칙을 「앱 이름」만으로 상상하면 빗나가기 쉽습니다. Windows에서는 실행 파일 이름이 node.exe로 통일되는 경우가 많고, macOS·Linux에서는 경로에 따라 프로세스 이름이 달라 보일 수 있습니다.

따라서 실무에서는 (1) 목적지 호스트를 DOMAIN-SUFFIX 등으로 Anthropic 관련 그룹에 붙이고, (2) 동시에 로그에서 반복되는 프로세스 이름이 있다면 PROCESS-NAME 규칙을 보조적으로 쓰는 이중 접근이 안전합니다. 후자는 모든 트래픽을 덮어쓰기 쉬우므로, 반드시 도메인 규칙과 순서를 함께 설계해야 합니다.

차원 1 — 도메인 기반 분류: 접미사, 룰셋, 순서

가장 재현성이 높은 축은 여전히 도메인입니다. Anthropic 계열은 제품 업데이트마다 서브도메인이 늘 수 있으므로, 커뮤니티에 떠도는 고정 목록을 그대로 복사하기보다 클라이언트의 최근 연결 목록에서 접미사를 모으는 방식이 낫습니다. 규칙을 쓸 때는 넓은 DOMAIN-KEYWORD보다 DOMAIN-SUFFIX를 우선하고, 팀 단위로라면 작은 YAML을 rule-providers로 분리해 버전 관리하는 편이 유지보수에 유리합니다.

중요한 것은 배치 순서입니다. GEOIP나 거대 RULE-SET이 Anthropic 호스트를 먼저 직결이나 다른 그룹으로 보내버리면, 아래쪽에 정교한 규칙을 아무리 추가해도 도달하지 못합니다. 중국 본토 직결 + 해외 프록시를 같이 쓰는 패턴은 규칙 분류 실무 글과 함께 읽으면 전체 그림이 잡힙니다. 구독을 막 넣었다면 구독 가져오기에서 노드·그룹 이름이 실제로 로드됐는지도 먼저 확인하세요.

차원 2 — 프로세스 기반 분류: PROCESS-NAME과 함정

Mihomo(Clash Meta) 계열에서는 플랫폼 지원 범위 안에서 PROCESS-NAME 규칙을 쓸 수 있습니다. 예를 들어 특정 CLI 바이너리 이름이 로그에 일관되게 찍힌다면, 해당 프로세스만 잠시 전용 그룹으로 보내 나머지 node 트래픽과 분리하는 식입니다. 다만 node 하나에 여러 프로젝트가 몰리면 과매칭이 나므로, 프로세스 규칙은 도메인 규칙 뒤가 아니라 앞에 둘지·뒤에 둘지를 신중히 정해야 하며, 대개는 도메인이 1차 필터이고 프로세스는 보조 역할에 그치는 구성이 안전합니다.

또한 TUN 모드를 켠 상태에서만 프로세스 정보가 의미 있게 보이는 경우가 많습니다. 시스템 프록시만 쓰는 환경에서는 앱이 프록시 체인을 타지 않아 규칙이 아예 실행되지 않을 수 있으니, TUN 모드 가이드의 전제와 DNS 절을 함께 검토하는 것이 좋습니다.

전략 그룹 선택: API 안정성을 위한 조합

분류 규칙이 가리키는 끝점은 언제나 proxy-groups 안의 이름입니다. API·스트리밍 응답에는 다음 조합이 자주 쓰입니다. (1) 수동 선택 select로 「지금 쓸 회선」을 고정해 재현성을 확보한다. (2) 지연이 중요하면 url-test로 풀 안에서 자동 교체하되, 너무 공격적인 간격은 오히려 세션을 흔들 수 있으니 값을 보수적으로 잡는다. (3) 장애 대비가 필요하면 fallback을 병행하되, Anthropic 측 rate limit·세션 특성을 고려해 불필요한 빠른 페일오버는 피한다.

그룹 안에 DIRECT를 남겨 두면 A/B 테스트에 도움이 되지만, 「API가 불안정하다」는 신고만 있고 실제로는 직행이 섞인 경우를 가리기 어렵습니다. 운영 중에는 한동안 DIRECT를 빼고 재현해 보는 것도 진단 방법입니다.

YAML 스케치(이름·도메인은 실측으로 교체)

아래는 구조를 보여 주는 예시입니다. AI-ANTHROPIC, 멤버 프록시 이름, 접미사 목록은 반드시 본인 프로필과 로그에 맞게 바꿔야 합니다.

# Example only — replace names and suffixes with your profile and logs
proxy-groups:
  - name: AI-ANTHROPIC
    type: select
    proxies:
      - Proxy
      - AUTO
      - DIRECT

rules:
  - PROCESS-NAME,claude,AI-ANTHROPIC
  - PROCESS-NAME,node,AI-ANTHROPIC
  - DOMAIN-SUFFIX,anthropic.com,AI-ANTHROPIC
  - DOMAIN-SUFFIX,claude.ai,AI-ANTHROPIC
  # Add API/CDN/auth suffixes observed in your client logs
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

PROCESS-NAME,node는 범위가 매우 넓습니다. 실제 운영에서는 로그에 찍힌 정확한 프로세스 이름만 남기고 나머지는 제거하거나, 도메인 규칙만으로 충분한지 먼저 검증하세요. 존재하지 않는 그룹 이름을 적으면 프로필 전체가 로드되지 않습니다.

DNS·fake-ip: 간헐 실패의 숨은 원인

fake-ip 모드에서는 규칙 매칭은 빠르지만, 특정 호스트에서 해석·캐시가 어긋나면 API 클라이언트가 보기에도 「가끔만」 실패합니다. 반복되는 호스트는 fake-ip-filter에 넣거나, nameserver와 fallback 체인을 점검해야 합니다. DNS만 고치면 규칙이 갑자기 맞아떨어지는 사례가 많으니, 연결 패널과 DNS 로그를 같이 보는 습관이 안정적 접속을 만듭니다.

검증 절차

콘솔 로그인, 단일 채팅 완료, API 한 번 호출을 각각 실행하며 최근 연결에 뜬 호스트를 스크린샷·메모로 남깁니다.
동일 동작을 반복할 때마다 규칙 열에 기대한 그룹 이름(예: AI-ANTHROPIC)이 찍히는지 확인합니다.
지연 차이가 큰 노드로 바꿔 보고 오류 패턴이 따라오는지 봅니다. 변하지 않으면 규칙·DNS 쪽을 의심합니다.
다른 VPN·기업 보안 에이전트와 경로가 겹치지 않는지 확인합니다.

보안·운영 메모

프록시 노드는 트래픽을 중계할 수 있으므로 신뢰할 수 있는 구독을 전제로 합니다. 회사 장비에서는 정책 위반이 될 수 있으니 사내 가이드를 우선합니다. 팀과 룰셋을 공유할 때는 최소 권한·변경 이력을 남기세요.

체크리스트

Anthropic 관련 도메인 규칙이 넓은 GEOIP·MATCH보다 앞에 있는가.
PROCESS-NAME 과매칭으로 다른 개발 도구 트래픽이 흔들리지 않는가.
프록시 그룹 이름이 YAML 전체에서 일관되는가.
DNS 모드·필터가 최근 로그와 모순되지 않는가.
TUN·시스템 프록시 중 무엇을 쓰는지와 터미널 런타임 설정이 맞는가.

정리

Claude Code와 Anthropic API는 IDE 한 개의 트래픽 패턴으로 끝나지 않습니다. 도메인 분류로 해야 할 일의 뼈대를 잡고, 필요할 때만 프로세스 분류를 얹으면 Cursor 편과 다른 실무 요구를 덜 밀어넣고도 같은 Clash 인프라를 공유할 수 있습니다. 목록은 한 번에 완벽할 필요가 없고, 로그가 알려 주는 새 접미사를 주기적으로 룰셋에 반영하는 방식이 장기적으로 가장 덜 깨집니다.

클라이언트를 최신 Mihomo 계열로 맞추는 일도 체감에 영향을 줍니다. 플랫폼별 패키지는 공식 다운로드 페이지에서 고를 수 있습니다. 기본 개념은 문서 섹션과 함께 보시면 설정 속도가 빨라집니다. → Clash를 무료로 내려받아 규칙을 적용한 뒤, 터미널에서 API 호출을 다시 시험해 보세요.