이 글이 맞는 상황인지 먼저 가늠하기
검색어에 Claude Code, Anthropic API, Clash Verge Rev, 분류 규칙을 함께 넣었다면, 이미 대략적인 그림은 갖고 계신 겁니다. 즉 「웹사이트가 안 열린다」 수준이 아니라, curl·IDE 통합 터미널·빌드 스크립트처럼 자동화된 경로에서만 실패한다는 뜻에 가깝습니다. 이때 필요한 것은 새 노드를 무작정 추가하는 일이 아니라, 어떤 소켓이 어떤 이름으로, 어떤 출구 정책을 타는지를 고정하는 작업입니다.
Clash Verge Rev는 Mihomo 코어를 감싼 그래픽 셸이므로, 최종적으로는 YAML의 rules·proxy-groups·이름 해석 모드가 말단 동작을 결정합니다. UI에서 버튼 이름이 조금 달라도, 사고의 축은 항상 동일합니다. ①트래픽이 어떤 규칙 줄에 매칭되는가, ②그 줄이 가리키는 그룹이 실제로 어떤 노드로 해석되는가, ③프로세스가 시스템 프록시를 보는가 아니면 OS 아래 레벨에서 터널을 탄다, 이 세 가지입니다.
Anthropic 쪽에서 자주 보이는 병목 유형
증상만 놓고 보면 모두 비슷합니다. 연결 시간 초과, TLS 핸셰이크 중단, 간헐적인 503 폭주처럼 보이는 재시도 루프. 그러나 원인 묶음은 몇 갈래로 나뉩니다. 첫째, DNS 응답 경로입니다. fake-ip를 켠 프로필에서 로컬 스텁 리졸버와 코어의 이름 해석 순서가 어긋나면, 브라우저 캐시에는 살아 있는 이름이 CLI에서는 매번 다른 중간 결과를 밟기도 합니다. 둘째, 출구 지역·운영자 정책입니다. 동일 API라도 계정·결제 단계에서 지역 제한 메시지가 섞여 나오면, 순수 회선 품질 문제와 구분해야 합니다. 셋째, 프록시 미주입입니다. Claude Code가 내부적으로 부르는 하위 프로세스가 부모 셸의 환경 변수를 물려받지 않는 경우가 있어, 사람 눈에는 분명히 프록시를 넣었다고 생각해도 실제 호출은 직접 나가고 있을 수 있습니다.
이런 때에 필요한 건 “한 번에 전부 우회”가 아니라, API 호스트 묶음만 전략 그룹에 묶고 나머지 트래픽은 평소와 같은 직통·다른 그룹을 유지하는 쪽이 재현성과 디버깅 비용 면에서 유리합니다. 글로벌 모드로 모두를 같은 릴레이에 태우면 증상은 잠시 사라져 보여도, 패키지 매니저나 사내 Git 호스트까지 함께 느려지는 부작용이 생깁니다.
도메인 분류: 최소 예시와 확장 순서
실제 운영 환경마다 추가로 등장하는 호스트 이름은 다릅니다. 그래서 여기서는 「항상 이대로 복붙」이 아니라, 최소 세트를 놓고 로그로 덧붙이는 사고법을 권합니다. 우선 API 문서와 통신 실패 로그에 반복 등장하는 호스트를 메모합니다. 그다음 Mihomo 규칙에서 DOMAIN-SUFFIX·DOMAIN-KEYWORD·외부 RULE-SET 중 무엇이 팀 컨벤션에 맞는지 고릅니다.
규칙 예시는 개념용입니다. 실제 키 이름·그룹명·인덴트는 사용 중인 프로필 템플릿에 맞춰야 합니다.
# Example only — adjust proxy group & indent to your profile
rules:
- DOMAIN-SUFFIX,api.anthropic.com,AI-OUT
- DOMAIN-SUFFIX,anthropic.com,DIRECT
- MATCH,GLOBALAI-OUT 자리에는 지연 테스트가 있는 셀렉터 그룹 이름을 두는 경우가 많습니다. 반대로 조직망에서 특정 서브도메인만 직통을 요구한다면, 더 구체적인 줄을 위에 올려 위에서 아래로 내려가며 첫 매칭에서 멈추는 규칙 엔진 특성을 이용합니다. 키워드 규칙은 편하지만 오탐이 커질 수 있으니, 가능하면 DOMAIN·DOMAIN-SUFFIX로 좁힌 뒤에 키워드를 보조로 씁니다.
구독에서 내려오는 대형 규칙 세트와 충돌이 나면, Verge Rev의 프로필 편집기에서 자신이 추가한 줄이 실제 활성 스냅샷에 포함됐는지를 반드시 확인합니다. 편집 창에만 있고 활성 프로필이 다른 파일을 가리키는 경우가 흔한 실수입니다.
시스템 프록시와 TUN: CLI를 생각하면 선택이 달라진다
브라우저 중심 사용자라면 시스템 프록시만으로도 체감 문제가 거의 사라집니다. 그러나 Claude Code처럼 자식 프로세스가 많은 CLI 도구는 상황이 다릅니다. 일부는 WinHTTP·macOS 프록시 테이블을 보지 않고 곧장 인터페이스에 붙습니다. 이럴 때 대안이 TUN 모드입니다. OS 아래에서 가상 인터페이스를 통해 라우팅 테이블을 재작성하므로, “프록시를 모르는” 바이너리도 같은 터널을 타게 만들기 쉽습니다.
반대로 TUN은 다른 VPN 클라이언트, 제로 트러스트 에이전트, 사내 DLP와 충돌할 수 있습니다. 증상이 시스템 전체 네트워크 먹통, 혹은 특정 서브넷만 블랙홀로 사라질 때는 TUN부터 의심합니다. 이 경우 단계는 (1) TUN을 끄고 혼합 포트의 HTTP/SOCKS를 확인한 뒤 (2) 셸 프로필에 프록시 변수를 선언하고 (3) Claude Code 재실행 — 순으로 줄여 가며 단일 변수만 움직이는 편이 빠릅니다. Verge Rev 화면에서도 초보자에게는 규칙 모드 + 시스템 프록시를 먼저 안정시키고, 여전히 CLI만 남으면 TUN을 검토하는 순서가 안전합니다.
검증 시나리오: 동일 호스트를 브라우저·셸에서 교차 확인
가장 값싼 검증은 같은 시각에 두 채널을 동시에 찍는 것입니다. 브라우저 개발자 도구의 네트워크 탭과, PowerShell의 Invoke-WebRequest 또는 curl -v 출력을 나란히 둡니다. TLS 핑거프린트까지 비교할 필요는 없고, 어느 단계에서 멈추는지만 대조해도 분기가 갈립니다. DNS에서 멈추면 이름 해석 순서와 fake-ip 설정을, TCP 연결 직후 멈추면 회선·SNI 차단 가능성을, 응답은 오는데 애플리케이션만 실패하면 상위 레이어의 인증·조직 정책을 봅니다.
Verge Rev의 코어 로그는 여기서 중요합니다. 사람이 추측으로 노드를 바꾸기 전에, 해당 요청이 어떤 규칙 줄에서 어떤 그룹으로 떨어졌는지 한 줄이라도 확보하세요. UI 버전마다 로그 패널 위치는 조금씩 다르지만, “매칭된 규칙 이름”과 “최종 아웃바운드”라는 텍스트는 공통적으로 있습니다.
장애 대응 체크리스트(현장용 메모)
- 시스템 시간·타임존이 TLS 검증과 무관해 보여도 자주 원인이 됩니다.
- 구독 만료·토큰 교체는 애플리케이션 메시지가 아니라 중간 프록시에서 문자열로만 보일 때가 있습니다.
- 사내 DNS 필터와 Clash 측 nameserver 설정이 이중으로 걸리면, 가짜 응답이 조용히 섞입니다.
- IPv6 우선 경로가 예상 밖으로 직통을 탈 때, 일시적으로 IPv4 고정 또는 인터페이스 제한으로 실험해 볼 가치가 있습니다.
- 문제 재현 중에는 글로벌/규칙 전환, TUN 온오프, 노드 교체를 한 번에 바꾸지 말고 한 단계씩 되돌리며 로그를 남깁니다.
법적·조직 정책 주의
프록시와 API 사용 허가는 국가·고용 계약·클라우드 이용약관에 따라 다릅니다. 본문은 기술적인 라우팅 정렬을 설명할 뿐, 특정 회선으로 의무적으로 우회하라는 뜻이 아닙니다. 회사 장비라면 보안팀이 요구하는 분류·로깅·키 관리 절차를 먼저 확인하세요.
빠른 FAQ(본문 요약)
브라우저만 되고 CLI만 실패? 프록시 미주입·fake-ip·DNS 이슈를 동시에 의심하고, 시스템 프록시 동기화와 셸 변수부터 맞춥니다.
global이 편하지 않나? 단기 디버깅에는 도움이 될 수 있으나, 장기 운영 가시성은 rule이 낫습니다.
TUN 충돌? 다른 터널 스택을 끄거나, 프록시 변수 기반으로 우회합니다.
도메인은 어디까지? 로그로 관측된 호스트부터 차근차근 추가합니다.
일부 상용 “올인원” 우회 앱은 보기에는 간단하지만 내부 분기를 블랙박스로 숨겨, API·CLI·CI가 섞인 실무 환경에서 문제를 좁히기 어렵게 만듭니다. 반면 Mihomo 계열은 규칙과 전략 그룹이라는 같은 언어로 출구를 설명하므로, Verge Rev 같은 셸을 얹었을 때 로그와 UI가 서로를 뒷받침합니다. 안정적인 Anthropic API 경로를 직접 설계하고 싶다면, 검증 가능한 클라이언트 패키지를 고르는 것부터가 첫걸음입니다.