이 글이 맞는 검색·증상

Claude Opus 4.7이나 동일 스택의 Claude API 클라이언트로 메시지·도구 호출을 보낼 때, 웹 콘솔에서는 대시보드가 열리는데 로컬 터미널·CI 러너·컨테이너 안의 앱만 context deadline exceeded·i/o timeout·TLS handshake failure처럼 끊기는 패턴이 있습니다. 개발자 컨퍼런스 시즌과 신모델 화제가 겹치면 검색량이 몰리고, 동시에 요금제·RPM·TPM 한도 조정 공지가 나온 직후라 원인을 모델 속도와 네트워크 사이에서 헷갈리기 쉽습니다.

이 문서는 Anthropic API가 실제로 어떤 호스트로 나가는지를 Clash Verge Rev(CVR)에서 보이게 만든 뒤, 프록시 분기와 HTTPS_PROXY·NO_PROXY를 한 줄로 정렬하는 데 초점을 맞춥니다. 특정 상용 노드 이름이나 구독 파일 포맷은 가정하지 않고, 2026년 현재 재현된다는 전제에서 패턴만 옮겨 쓸 수 있게 구성했습니다.

한도 메시지와 순수 타임아웃 구분하기

Opus 4.7로 올린 뒤 체감 지연이 커졌다면, 먼저 응답 본문에 429·529류와 명시적인 rate-limit 문구가 있는지 확인하세요. 이런 경우 API 키·조직 정책·동시 연결 수가 병목인 때가 많아, 프록시를 아무리 손봐도 근본적으로는 호출 빈도나 배치 크기를 낮춰야 합니다.

반대로 HTTP 상태 코드를 보기도 전에 소켓이 닫히거나, 같은 키로 브라우저에서 호출한 간단한 스크립트는 성공하는데 동일 머신의 특정 셸만 실패한다면, 출구 IP·SNI 경로·프록시 인증이 갈리는 전형적인 경로 불일치 가능성을 우선 의심하는 것이 빠릅니다. 이후 절차는 전부 이 전제에서 효과가 납니다.

규칙에 넣기 전에 확인할 Anthropic 쪽 호스트

공개 문서에 자주 등장하는 엔드포인트는 api.anthropic.com 계열입니다. 다만 엔터프라이즈 프록시, 리전별 게이트웨이, 레거시 SDK가 붙은 별칭 도메인이 있을 수 있으므로, 템플릿 YAML에 적힌 예시만 그대로 복사하기보다 실패 직후 CVR 로그의 Host 문자열을 규칙 키로 쓰는 편이 안전합니다. 규칙 편집 화면에서 DOMAIN-SUFFIX·DOMAIN-KEYWORD를 쓸 때는 과도하게 넓게 잡아 다른 SaaS 트래픽까지 덮어쓰지 않도록 주의하세요.

GEOIP·GEOSITE 묶음이 자동으로 DIRECT를 강제하면, 브라우저 확장 경로와 달리 CLI가 기본 회선으로 나가며 차단되는 경우가 있습니다. 반대로 불안정한 단일 업스트림에만 묶이면 간헐적 zero window 류 증상이 남습니다. Opus 4.7처럼 긴 컨텍스트·장시간 스트리밍을 쓰는 워크로드는 작은 패킷 손실에도 재시도 폭이 커지므로, 노드 지표만이 아니라 해당 호스트가 실제로 어떤 정책 그룹을 타는지를 로그로 고정하는 것이 중요합니다.

1단계: Clash Verge Rev 기본 상태와 mixed-port

프로필이 활성인지, 코어가 재시작 루프에 빠지지 않았는지부터 봅니다. 구독이 갱신되며 규칙 프로바이더가 바뀌면 이전에는 프록시를 타던 API 호스트가 DIRECT나 다른 그룹으로 옮겨가기도 합니다. mixed-port 숫자를 메모해 두고, 브라우저 시스템 프록시가 그 포트를 바라보는지 확인하세요. 포트가 바뀌었는데 셸의 HTTPS_PROXY만 옛 값이면, 브라우저만 정상이고 터미널만 실패하는 그림이 그대로 재현됩니다.

2단계: 프록시 분기로 Anthropic 트래픽 고정

규칙 모드에서 API 호스트를 지연·안정성 기준으로 묶인 프록시 그룹에 매핑합니다. 글로벌 모드로 모든 트래픽을 한 노드에 몰면 설정은 단순하지만, 국내 CDN·패키지 레지스트리까지 같은 출구를 타며 연쇄 실패를 만들기 쉽습니다. 반면 세밀한 규칙을 유지하면 왜 Opus 호출만 같은 질문에 로그 한 줄로 답할 수 있습니다.

스테이징·프로덕션 키를 나눈 팀이라면, 호스트 규칙 옆에 주석으로 어떤 비밀이 어떤 엔드포인트로 나가는지를 적어 두면 온콜 대응이 빨라집니다. 이는 코드가 아닌 개인 구독 파일 쪽 기록에 남기고 저장소에는 올리지 않는 것이 안전합니다.

팁: 짧은 핑으로는 장시간 HTTP/2 스트림이 버티는지 알기 어렵습니다. 동일 호스트에 대해 실제 SDK가 쓰는 TLS 버전·ALPN을 유지한 채 소규모 요청을 반복해 보고, 프록시 로그의 체인 이름이 매 호출마다 바뀌는지도 함께 봅니다.

3단계: 터미널·런타임의 HTTPS_PROXY 정렬

대부분의 HTTP 클라이언트는 아래 변수들을 읽습니다.

  • HTTPS_PROXY / HTTP_PROXY — REST·스트리밍 호출의 업스트림 프록시 URL
  • ALL_PROXY — 런타임에 따라 둘을 대체
  • NO_PROXY — 내부 Git, localhost, 사내 레지스트리 예외

CVR의 mixed-port가 HTTP 프록시로도 열려 있다면 http://127.0.0.1:<port> 형식이 일반적입니다. SOCKS 경로를 쓸 때는 socks5:// 스키마를 분명히 적어야 하며, 잘못된 스키마는 즉각 거절 대신 긴 타임아웃으로 보일 때가 많습니다.

변수를 어디에 둘지는 팀 정책 문제입니다. 개인 머신 전체에 영구 export하기보다 개발 전용 셸 프로파일 분기, direnv, IDE가 띄운 터미널 세션에만 주입하는 방식이 흔합니다. 중요한 점은 IDE를 환경 변경 이후 재실행했는지입니다. 이미 떠 있는 통합 터미널은 부모 프로세스가 갱신되기 전까지 옛 프록시 값을 물고 갑니다.

NO_PROXY에서 자주 터지는 오타·범위

NO_PROXY에 *.internal.example.com 같은 패턴을 넣었는데 일부 스택은 와일드카드를 지원하지 않습니다. 이 경우 실제 FQDN을 쉼표로 나열하거나, CIDR이 지원되는 런타임이면 내부 대역을 명시해야 합니다. 컨테이너 안에서 호스트 루프백이 도커 브리지 IP로 바뀌는 시나리오도 있어, localhost만 빼 두었다가 레지스트리 pull만 실패하는 경우가 생깁니다.

팀 단위로는 레포의 .env.example에 키 이름만 적고, 값은 각자 로컬에 두는 패턴이 안전합니다. CI에서는 별도 시크릿과 프록시 설정을 쓰므로 변수명 충돌을 피하기 위해 접두사를 나누는 것도 좋습니다.

TLS·핸드셰이크 실패와 프록시 체인

중간 프록시가 TLS 인터셉트를 하는 회사망이라면, 클러스터 내부의 신뢰 저장소에 루트가 없을 때만 실패하는 패턴이 나옵니다. 반대로 투명 프록시 없이 순수하게 Split DNS만 틀어진 경우에는 SNI는 맞는데 해석된 IP가 차단 대역인 상황도 있습니다. CVR 로그의 체인 이름과, 동일 시각에 브라우저·curl이 어떤 경로를 타는지 나란히 비교하면 원인 후보를 빠르게 줄일 수 있습니다.

Opus 4.7 호출이 길게 이어질수록 일부 상용 회선은 유휴 세션을 잘라 새 연결이 필요해지는데, 이때마다 프록시 인증이나 지역 회전 정책이 개입하면 간헐 성공처럼 보입니다. 이런 경우 규칙뿐 아니라 업스트림의 세션 유지 옵션도 함께 보는 것이 좋습니다.

시스템 프록시·TUN과의 동시 사용

글로벌 TUN은 OS 전체를 한 번에 덮어 출구를 통일하기 좋지만, 다른 Always-On VPN·보안 에이전트와 충돌하기 쉽습니다. 회사 정책으로 TUN을 못 쓰는 환경이라면 시스템 프록시 연동 + 명시적 HTTPS_PROXY 조합이 현실적인 타협입니다. TUN만 켜 둔 상태에서도 특정 런타임은 로컬 라우팅을 무시한다는 보고가 있으므로, CLI에는 여전히 프록시 URL을 선언하는 편이 안전합니다.

이중 VPN 구조에서는 어느 쪽이 DNS를 잡는지에 따라 동일 호스트라도 완전히 다른 경로로 나갑니다. 한쪽만 끈 채로 짧은 동일 요청을 비교해 보세요.

주의: HTTPS_PROXY를 export하면 그 셸에서 돌아가는 모든 HTTP 클라이언트가 영향을 받습니다. 패키지 매니저·클라우드 메타데이터 엔드포인트까지 우회하지 않도록 NO_PROXY를 주기적으로 검토하세요.

여전히 타임아웃일 때 좁히기 순서

  1. 동일 시각·동일 머신에서 브라우저·curl로 호스트에 HTTPS가 열리는지 비교합니다.
  2. CVR 로그에서 해당 호스트가 어느 규칙·어느 그룹으로 분류됐는지 확인합니다.
  3. 터미널에서 env | grep -i proxy로 의도와 다른 잔여 변수가 없는지 봅니다.
  4. 응답 코드가 없이 끊기면 MTU·패킷 로스·지역 회전을 의심합니다.
  5. 한도 메시지가 섞여 있으면 RPM/TPM·동시 스트림 설정을 점검합니다.

WSL2·원격 SSH 개발자에게

Windows에서 CVR을 쓰고 WSL2 안에서 빌드를 돌리면 127.0.0.1이 가리키는 대상이 달라 mixed-port에 연결되지 않는 경우가 있습니다. mirrored networking 정책이나 호스트 IP를 향하게 바꿔야 할 수 있습니다. VS Code Remote·JetBrains Gateway처럼 원격 셸에서 돌아가는 에이전트는 서버 측 환경 변수를 물고 오므로, 로컬 macOS에만 HTTPS_PROXY를 넣었다면 증상이 그대로 남습니다.

자주 묻는 질문

Q. API 키가 프록시 로그에 남지 않게 하려면?
A. 고해상도 트레이스를 끄고, 공용 머신에서는 셸 히스토리에 export 줄이 쌓이지 않게 합니다. 가능하면 공식 문서가 권장하는 자격 증명 저장 방식을 따르세요.

Q. 같은 규칙인데 Opus 4.7만 느립니다.
A. 출력 토큰·컨텍스트 길이가 길어져 RTT가 체감될 수 있습니다. 동시에 동일 호스트에 대해 작은 프롬프트를 보내 지연을 비교해 보세요. 네트워크 문제라면 작은 요청에서도 이른 단계에서 끊깁니다.

Q. 회사에서 터미널 프록시가 금지라면?
A. 정책을 우회하지 말고 IT에 허용 egress·공식 프록시를 요청하는 것이 안전합니다. 이 글은 합법적 개발 환경을 전제로 합니다.

정리: 범용 VPN 대신 Clash Verge Rev로 경로를 보이게 할 이유

단일 상용 VPN 앱만 켜 두는 방식은 처음에는 간단하지만, 스플릿 터널·지역 정책이 바뀔 때 어떤 프로세스가 어떤 인터페이스로 나가는지 가시성이 떨어집니다. 반면 Clash·Mihomo·Clash Verge Rev 계열은 호스트 단위 규칙과 로그가 한 화면에 모여 api.anthropic.com 같은 API 엔드포인트를 놓치지 않게 만듭니다. 브라우저는 시스템 프록시로, CLI는 HTTPS_PROXY로 같은 mixed-port를 바라보게만 해도 경로 불일치로 인한 간헐적 Opus 4.7 타임아웃 상당 부분을 걸러낼 수 있습니다.

종합 VPN은 여행·스트리밍에는 편하지만, 퍼블릭 API·사내 Git·컨테이너 레지스트리를 한꺼번에 쓰는 개발자 프록시 시나리오에서는 예외 목록이 거칠거나 CLI를 놓치기 쉽습니다. CVR로 프록시 분기를 유지한 채 필요한 세션에만 환경 변수를 얹으면, 문제가 회선이 아니라 경로인지 빠르게 판별할 수 있습니다.

Clash 호환 클라이언트를 받아 Anthropic API와 터미널 경로를 같은 규칙으로 맞추기 →