증상부터: 왜 Claude만 웹과 API가 따로 놀까

브라우저에서 Claude 대화는 이어지는데, 같은 계정으로 Anthropic API를 호출하는 스크립트·에디터 플러그인·백엔드 작업만 timeout에 걸린다면, 혹은 정반대로 API는 통과하는데 웹 UI만 로딩이 멈춘다면 「노드가 전부 나쁘다」만은 아닙니다. Anthropic 생태는 화면에 보이는 주소 한 줄 뒤에 여러 호스트가 동시에 붙는 구조가 흔하고, 그중 일부만 직접 연결이 불안정하거나 반대로 중계가 필요한 경우가 많습니다.

전역 프록시를 켠 채로 쓰면 모든 요청이 같은 경로를 타기 때문에, 특정 구간만 TLS 협상이 까다롭거나 긴 스트리밍 연결이 중간 노드 정책과 맞지 않을 때 체감 지연·끊김이 커집니다. 반대로 거의 전부 직접 연결로 두면, API 게이트웨이나 인증·과금 콘솔 호스트만 막혀 한 기능만 실패하는 부분 장애가 납니다. 이 글은 이미 다룬 Cursor·GitHub 분류와 Perplexity·NotebookLM 분류와 서비스·도메인 집합이 겹치지 않게, 대표적인 대화형 AI SaaS + API 축인 Anthropic에 초점을 맞춥니다.

네트워크 정책과 법규는 지역·기관마다 다릅니다. 본문은 기술적 분류·연결 경로 설명에 한정하며, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. Clash 계열의 기본 개념은 Clash 사용 문서와 함께 보면 이해가 빠릅니다.

웹·API·콘솔·CDN: Anthropic 트래픽이 갈라지는 축

실무에서 자주 보이는 네 가지 축으로 나누어 생각하면 수습이 쉬워집니다. 첫째, 사용자가 직접 여는 웹 앱과 그에 딸린 서브도메인. 둘째, 키를 넣고 모델을 부르는 공식 API 엔드포인트. 셋째, 키 발급·사용량·결제를 다루는 콘솔·계정 계열 호스트. 넷째, 스크립트·아이콘·폰트를 실어 나르는 정적 자원·서드파티 분석 도메인입니다.

Clash 관점에서는 이 축들이 서로 다른 SNI·IP 풀로 풀릴 수 있어, 한 축만 잘못된 정책에 걸려도 화면은 뜨는데 응답 스트림만 멈추는 현상이 생깁니다. 특히 API는 HTTP/2·긴 keep-alive에 가까운 패턴이 많아, 다운로드용으로 잘 나오던 노드가 짧은 왕복이 잦은 API에는 맞지 않는 경우가 있습니다. 이때는 속도 테스트 점수만 보기보다, 해당 호스트를 끊김 빈도가 낮은 그룹으로 묶는 편이 낫습니다.

제품 업데이트·리전·기능 플래그에 따라 호스트 이름이 바뀔 수 있으므로, 아래 도메인 이름은 출발점으로만 두고 반드시 본인 환경의 클라이언트 로그로 교체·보강하세요. 외부 RULE-SET으로 묶고 싶다면 Rule Provider 가이드의 패턴을 참고해 별도 파일로 관리하면 diff가 명확해집니다.

로그에서 자주 등장하는 호스트 패턴(참고용)

브라우저의 Claude 세션에서는 claude.ai 계열 호스트가 중심에 서는 경우가 많고, 공식 API 클라이언트는 api.anthropic.com을 향합니다. 문서·대시보드·계정 흐름은 anthropic.com의 다른 서브도메인으로 이어지기도 합니다. 즉 「Claude 한 줄 규칙」으로 끝내기보다, 실패한 요청의 호스트 이름을 한 줄씩 규칙 상단에 추가하는 방식이 유지보수 비용을 줄입니다.

  • 웹 UI·세션: 주소창에 보이는 앱 도메인과 웹소켓·스트리밍에 쓰이는 별도 호스트.
  • API: SDK·curl·서버 사이드 코드가 붙는 API 게이트웨이 도메인.
  • 콘솔·결제·정책: 키 관리·청구·조직 설정 등 운영 화면이 분리된 호스트.
  • 정적·관측: 번들·이미지·텔레메트리가 제3자 CDN이나 분석 도메인으로 나뉘는 경우.

한 호스트만 빠져도 증상은 「전체가 안 된다」처럼 보이므로, 증상이 난 시점에 로그를 한 번 캡처해 두는 습관이 중요합니다. 기업·교육 기관 계정에서는 추가적인 디바이스 인증·정책 체크 URL이 붙을 수 있습니다.

전용 proxy-groups 설계: AI_ANTHROPIC을 다른 AI 그룹과 분리하기

이미 AI_DEV(IDE·GitHub)·AI_SEARCH(Perplexity 등) 같은 그룹을 쓰고 있다면, Anthropic 스택용으로 AI_ANTHROPIC(이름은 임의)를 또 하나 두는 것을 권합니다. 이유는 단순합니다. Cursor 쪽은 대용량 패키지·Git 객체처럼 대역폭·지속 연결 성격이 강하고, Claude 웹·API는 짧은 왕복이 잦은 질의와 스트리밍이 중심입니다. 같은 그룹에 넣으면 url-test 기준이 한쪽에만 맞춰져 다른 쪽이 불안정해질 수 있습니다.

AI_ANTHROPIC에는 보통 완만한 임계값의 url-test, 혹은 수동 선택형 select를 올려 두고, 지연 숫자만 보지 말고 끊김 빈도·스트리밍 완주율을 기준으로 노드를 고릅니다. 스트리밍 응답이 중간에 끊기면 사용자는 「느리다」보다 「망가졌다」로 인식하기 때문입니다. API 키를 서버에 두고 호출하는 경우에는 클라이언트 PC가 아니라 서버 출구에서도 동일한 원칙이 적용됩니다.

YAML 스케치: DOMAIN 규칙을 좁은 예외로 위에 쌓기

아래는 이해를 돕기 위한 축약 예시입니다. 실제 도메인은 본인 환경의 로그로 교체하고, AI_ANTHROPIC은 프로필 안의 proxy-groups 이름과 맞추세요. 코어·GUI에 따라 지원 키워드가 다를 수 있습니다.

# Anthropic / Claude — keep narrow rules above broad GEOIP / RULE-SET (comments in English per project convention)
proxy-groups:
  - name: AI_ANTHROPIC
    type: select
    proxies:
      - PROXY_NODE_A
      - PROXY_NODE_B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,claude.ai,AI_ANTHROPIC
  - DOMAIN-SUFFIX,anthropic.com,AI_ANTHROPIC
  - DOMAIN-SUFFIX,api.anthropic.com,AI_ANTHROPIC
  # Add console.* / docs.* / static hosts from your session logs; trim third-party CDNs carefully
  - MATCH,PROXY_OR_FALLBACK

위 예시에서 anthropic.com을 넓게 잡으면 의도하지 않은 서브도메인까지 같은 그룹으로 몰릴 수 있으므로, 실사용에서는 실제로 맞닿는 호스트만 남기고 나머지는 제거하는 편이 안전합니다. MATCH 한 줄은 기존 프로필의 마지막 규칙 자리를 가정한 것이며, 실제 파일에서는 이미 쓰는 GEOIP·RULE-SET 순서를 유지한 채 Anthropic 블록만 위쪽에 끼워 넣으세요.

규칙 순서와 충돌: 첫 매칭이 이기고, 넓은 RULE-SET이 삼킨다

Clash 계열은 rules를 위에서 아래로 읽다가 처음 맞는 한 줄에서 결정합니다. Anthropic용 예외를 추가했는데도 효과가 없다면, 그보다 위에 있는 더 넓은 DOMAIN-KEYWORD나 대형 RULE-SET이 먼저 매칭되는지 확인해야 합니다.

또 한 가지, GEOIP,CN,DIRECT 같은 규칙이 API가 붙는 IP 대역을 국내로 오인하면, 의도와 반대로 직접 연결로 떨어질 수 있습니다. 이때는 로그의 실제 목적지와 GeoIP 결과를 대조해, 필요하면 DOMAIN 기반 예외를 GEOIP보다 위에 두세요. 다만 사내망·결제·은행 앱 직통처럼 더 좁고 민감한 예외는 그보다 또 위에 두는 것이 안전합니다.

DNS·fake-ip: 멀티 도메인일수록 같이 봐야 할 이유

같은 서비스라도 DNS 응답이 캐시·모드에 따라 다른 IP로 풀리면, 규칙은 맞는데 체감만 나쁜 상황이 연출됩니다. 특히 fake-ip를 쓰는 프로필에서는 도메인 규칙과 DNS 처리 순서가 맞물리므로, Claude만 느릴 때는 DNS 섹션과 Clash 로그를 함께 보는 것이 좋습니다. 누수·모드 선택은 DNS 누수 방지 가이드에 단계별로 정리되어 있습니다.

브라우저 확장 프로그램이 자체 DNS를 쓰거나, DoH를 우회로 붙이면 Clash가 보는 트래픽과 앱이 해석한 IP가 어긋날 수 있습니다. 증상이 브라우저에만 국한되면 확장·실험 플래그부터 끄고 재현해 보세요. 터미널 SDK만 문제라면 해당 셸·컨테이너의 HTTP(S)_PROXY 환경 변수와 Clash 시스템 프록시/TUN 설정이 동시에 걸려 루프를 만드는지도 점검합니다.

검증 루틴: 로그로 호스트를 모으고 한 변수씩 줄이기

규칙을 바꾼 뒤에는 다음 순서를 추천합니다. 첫째, 동일한 질문·동일한 API 호출을 반복하며 로그에 남는 호스트 이름을 목록으로 모읍니다. 둘째, 문제 호스트만 임시로 다른 그룹이나 DIRECT로 옮겨 한 번에 한 변수만 바꿉니다. 셋째, 스트리밍 응답이 중간에 끊기면 노드 교체뿐 아니라 해당 API 도메인을 keep-alive에 유리한 프로필과 짝지었는지도 봅니다.

체감 지연을 줄이는 일반 튜닝은 속도 최적화 팁과 병행하면 좋습니다. 다만 대화형 AI는 대역폭보다 왕복 지연·끊김이 체감에 더 크게 작용하는 경우가 많습니다. 로컬 방화벽·회사 SSL 검사가 중간에 끼면 증상이 노드와 무관하게 나타나기도 하므로, 동일 네트워크에서 다른 기기로 한 번만 대조해 보는 것도 비용 대비 효과가 큽니다.

보안·컴플라이언스 메모

회사망·학교망에서는 분할 터널·사용자 정의 규칙이 정책 위반일 수 있습니다. RULE-SET·원격 구독 URL은 외부 정책을 끌어오는 통로이므로 출처를 검증하지 않으면 민감한 트래픽이 예기치 않은 경로로 나갈 위험이 있습니다. 팀 단위로 쓸 때는 허용 도메인을 문서화하고 변경 시 리뷰를 거치는 편이 안전합니다.

API 키는 로그·스크린샷·공유 설정 파일에 남기 쉬우므로, 규칙 파일을 git에 올릴 때는 샘플과 실키를 분리하세요. 오픈 소스 코어의 이슈와 릴리스는 Mihomo GitHub 저장소에서 확인할 수 있습니다. 클라이언트 설치 패키지는 배포 신뢰를 위해 공식 다운로드 페이지를 우선하는 편이 좋습니다.

정리

Claude와 Anthropic API는 단일 탭 앱처럼 보여도 실제로는 웹·API·콘솔·정적 자원이 얽힌 묶음입니다. Clash의 강점은 이 묶음을 도메인·IP 단위로 나누어 각각에 맞는 정책 그룹을 주는 데 있으므로, 전역 스위치에만 의존하기보다 AI_ANTHROPIC 전용 규칙 블록을 설계하고 IDE용·AI 검색용 그룹과 분리하는 편이 안정적입니다.

기억할 점: 호스트 목록은 제품 업데이트와 함께 바뀝니다. 로그로 실제 접속 대상을 확인하고, 좁은 예외를 규칙 상단에 쌓으며 불필요하게 넓은 DOMAIN-SUFFIX는 피하세요.

규칙형 클라이언트는 한번 구조를 잡아 두면 브라우저 기반 AI와 터미널 API가 섞인 환경에서도 정책을 한눈에 유지하기 쉽습니다. 다른 범용 도구에 비해 Clash는 규칙 순서와 그룹 설계만 정리돼 있어도 체감이 확 달라지는 편입니다.

→ Clash를 무료로 내려받아 Anthropic·Claude용 분류 규칙을 프로필에 반영해 보세요