증상: 웹은 되는데 API·CLI만 들쭉날쭉할 때

Claude 프록시나 claude.ai 접속을 이야기할 때 흔한 패턴은 한 가지가 아닙니다. 브라우저 탭에서는 대화가 이어지는데, 터미널의 공식 CLI·서드파티 클라이언트·애플리케이션에서 붙는 Anthropic API만 타임아웃되거나 스트리밍이 중간에 끊기는 경우입니다. 반대로 웹 로그인·결제·정적 자산은 국내 CDN에 가깝게 잡히고, 추론 요청만 해외 노드로 나가야 하는 구조라면, Clash 분류 한 줄 차이로 목적지와 정책 그룹이 갈라질 수 있습니다.

또 하나는 「자동 선택」이나 지연 기반 선택을 쓰는 정책 그룹에서, 대화가 길어질수록 중간에 다른 노드로 바뀌어 세션이 흔들리는 유형입니다. 이때 문제는 Anthropic 서비스 자체만이 아니라, 클라이언트가 열고 닫는 TCP·TLS 세션과 HTTP/2·스트리밍의 특성까지 함께 봐야 합니다. 본문은 IDE 확장 중심으로 정리한 Cursor·GitHub Copilot 가이드와 달리, 브라우저와 API·CLI를 나누어 보고 SNI와 규칙 적중을 기준으로 원인을 좁히는 데 초점을 둡니다.

claude.ai와 API가 나누는 호스트

실제 화면에서 쓰는 호스트 이름은 시기·제품·리전 설정에 따라 달라질 수 있으므로, 여기서는 원리 설명에 그칩니다. 다만 공통적으로는 (1) 사용자가 주소창에 치는 웹 앱 도메인, (2) 인증·세션·정적 리소스를 나누는 하위 도메인, (3) api.anthropic.com 등 API 안정성을 좌우하는 별도 호스트가 동시에 등장한다는 점을 전제로 하면 됩니다. Clash 분류에서 이 중 일부만 프록시 그룹에 넣고 나머지는 DIRECT나 다른 그룹으로 보내면, 웹은 정상인데 API만 TLS 핸드셰이크에서 실패하거나 중간 장비에 걸리는 형태가 납니다.

따라서 첫 단계는 추측이 아니라 연결 로그로 실패한 요청의 목적지 호스트명을 확인하는 것입니다. 어떤 줄이 어떤 정책 그룹에 매칭되었는지 보면, GEOIP나 넓은 DIRECT 규칙에 먼저 걸린 것인지, 의도한 AI 전용 그룹에 들어간 것인지 바로 갈립니다. 절차는 로그로 규칙 적중·DNS·노드 분리하기와 같은 흐름을 따르면 됩니다.

Clash 분류와 규칙 순서

Clash 계열은 위에서 아래로 첫 매칭에서 결정됩니다. claude.ai와 Anthropic 관련 도메인을 한데 묶은 규칙 블록이 GEOIP·MATCH보다 위에 있어야 하고, Rule Provider가 오래되었으면 새 호스트가 빠질 수 있습니다. 스플릿 라우팅의 뼈대는 분류 규칙 최적화 튜토리얼에서 다룬 것과 같으며, 여기서는 그 위에 「AI 서비스 전용」 정책 그룹을 얹는다고 이해하면 됩니다.

YAML 예시는 배포판·코어 버전마다 키 이름이 조금씩 다르므로, 아래는 구조 이해용이며 주석은 영문으로 두었습니다.

# Place Anthropic / Claude domains above broad GEOIP or DIRECT rules.
rules:
  - DOMAIN-SUFFIX,anthropic.com,PROXY_AI
  - DOMAIN-SUFFIX,claude.ai,PROXY_AI
  - DOMAIN-KEYWORD,anthropic,PROXY_AI
  # ... then GEOIP, MATCH, etc.

실제로는 DOMAIN-SUFFIX만으로 부족한 하위 호스트가 생기면 로그에 나온 이름을 규칙에 추가하는 방식이 가장 안전합니다. 키워드 규칙은 오탐이 생기기 쉬우니, 범위를 너무 넓히지 않는 편이 좋습니다.

고정 노드(스티키)와 API 안정성

API 안정성 이슈 중 상당수는 응답 지연이 아니라 출구 IP가 바뀌는 것과 연관됩니다. 자동 선택·부하 분산형 정책 그룹은 요청마다 다른 노드를 고를 수 있고, 일부 API는 연속 요청에 대해 세션·속도 제한·리스크 관리를 출구 IP 기준으로 보는 경우가 있습니다. 사용자 입장에서는 「노드 품질」 문제로 착각하기 쉽지만, 로그상으로는 매 요청마다 다른 프록시 이름이 찍히기도 합니다.

대응으로 자주 쓰는 방법은 (1) 해당 트래픽만 보내는 정책 그룹에서 특정 노드를 수동 선택하거나, (2) 클라이언트가 지원한다면 동일 그룹 안에서도 우선순위를 고정하는 방식입니다. GUI에서는 그룹 이름이 「자동」「Fallback」「Load-balance」 등으로 다르게 보이므로, 자신이 쓰는 클라이언트에서 어떤 모드가 노드를 바꿀 수 있는지 설명을 확인하는 것이 먼저입니다. 목표는 한 세션·한 작업 단위 안에서 동일 출구를 유지하는 것이지, 반드시 특정 프로토콜 이름을 쓰라는 뜻은 아닙니다.

TLS·SNI 쪽에서 볼 것

HTTPS에서는 클라이언트가 ClientHello에 실어보내는 SNI(Server Name Indication)로 가상 호스트가 구분됩니다. 규칙 엔진이 도메인 기준으로 잘 매칭되더라도, 중간 캐시·보안 장비·잘못된 MITM 설정이 SNI나 인증서 체인에 간섭하면 브라우저 한 종류만 살아 있고 다른 클라이언트만 실패하는 차이가 납니다. SNI 자체를 「고쳐 넣는」 설정은 일반 사용자 환경에서는 드물고, 실무에서는 다음을 확인합니다.

  • 실패한 연결의 로그에 TLS 관련 오류 문자열이 있는지, 규칙 문제인지 품질 문제인지 구분합니다.
  • 동일 PC에서 브라우저와 CLI를 번갈아 쓸 때, 한쪽만 회사 SSL 검사나 다른 VPN에 걸리지 않는지 봅니다.
  • 프록시 프로토콜을 바꿨을 때(예: 다른 전송 프리셋) 증상이 사라지면, 노드 경로나 중간 호환성 이슈를 의심합니다.

여기까지가 Claude 프록시 맥락에서 말하는 「네트워크 측에서 재현 가능한 점검」에 해당합니다. 애플리케이션 버그와 구분하려면, 같은 시점에 같은 목적지로 curl 등으로 TLS만 좁혀 보는 방법도 도움이 됩니다.

DNS·fake-ip 정합

브라우저는 Secure DNS·캐시 정책이 복잡하고, CLI는 시스템 resolver나 별도 라이브러리를 탈 수 있습니다. Clash에서 fake-ip를 쓰는데 OS나 다른 앱이 먼저 다른 DNS로 응답을 받으면, 규칙이 기대한 경로와 실제 소켓이 어긋날 수 있습니다. fake-ip와 redir-host 글에서 설명한 것처럼, 증상이 DNS 쪽이면 모드 전환·필터 목록·캐시 초기화가 변수 분리에 유리합니다.

정리하면, 웹과 API를 같은 정책 그룹으로 보내더라도 DNS 질의 경로가 다르면 결과가 갈립니다. 가능하면 한 프로필 안에서 시스템 DNS·TUN·시스템 프록시 관계를 단순화하고, 문제가 생기면 한 번에 한 가지 설정만 바꿉니다.

TUN·환경 변수: API와 CLI를 한 규칙에 맞추기

시스템 프록시만 켜 두면 브라우저는 편하지만, 일부 CLI·런타임은 프록시 환경 변수를 읽지 않고 직접 연결합니다. TUN 모드는 IP 레이어에서 트래픽을 Clash로 모아 같은 Clash 분류를 터미널에도 적용하기 쉽게 합니다. TUN을 당장 쓰기 어렵다면, 해당 셸에서만 HTTPS_PROXY·ALL_PROXY를 로컬 Clash 포트로 맞추는 방법도 있습니다. 다만 회사 VPN·다른 프록시와 겹치면 오히려 불안정해질 수 있으니, 한 세션에서는 출구를 하나로 통일하는 편이 안전합니다.

점검 체크리스트(순서대로)

  1. 실패한 요청의 목적지 도메인과 매칭된 정책 그룹을 Clash 로그에서 확인합니다.
  2. claude.ai·Anthropic API 호스트가 의도한 그룹(예: PROXY_AI)으로 가는지, 규칙 순서를 YAML과 대조합니다.
  3. 자동 전환 그룹을 쓰는 경우, 세션 중 노드 이름이 바뀌지 않는지 로그로 확인하고 필요 시 수동 고정을 검토합니다.
  4. TLS·SNI 관련 오류가 있으면 동일 기기의 다른 VPN·SSL 검사와 충돌하지 않는지 봅니다.
  5. DNS 모드·캐시·TUN·시스템 프록시를 점검하고, 브라우저와 CLI의 resolver 차이를 줄입니다.
  6. 그래도 불안정하면 다른 노드·프리셋을 시험하되, 한 번에 한 변수만 바꿉니다.

보안·정책에 대한 짧은 메모

회사 기기·교육망·국가별 규정 환경에서는 클라이언트 설치·TUN·프록시 자체가 정책 위반이 될 수 있습니다. 본문은 기술적 연결 안정성을 설명하기 위한 것이며, 특정 서비스 이용을 조장하거나 계약·법률 검토를 대신하지 않습니다. 각 서비스 약관과 로컬 법규를 우선하세요.

정리

Claude 프록시와 claude.ai·Anthropic API를 안정적으로 쓰려면, 범용 브라우징 규칙만으로는 부족하고 웹·API·CLI가 실제로 쓰는 호스트를 로그로 확인한 뒤 Clash 분류에 반영하는 것이 중심입니다. 여기에 출구 고정·SNI·TLS 오류 구분·DNS 정합까지 더하면, 「감으로 노드만 바꾸는」 반복을 줄일 수 있습니다.

클라이언트 설치 파일 출처가 여러 갈래로 흩어져 있어 혼동하기 쉬운데, ClashFast 다운로드 페이지에서 플랫폼별 빌드를 모아 두었습니다. 환경을 맞춘 뒤에는 → Clash를 무료로 내려받아 분류 규칙과 TUN을 직접 조합해 보세요.