2026년 Claude·Anthropic 웹과 API를 Clash로 나눠 쓰기: 도메인 분류·DNS·Fake-IP·실측

① 브랜드 한 줄이 아니라 「콘솔·웹·API」 호스트로 나누는 이유

Anthropic 제품을 쓰면 키 발급·사용량·팀 설정은 개발자 콘솔 UI로, 일상 대화는 claude.ai 같은 웹 앱으로, 애플리케이션 코드는 api.anthropic.com 같은 HTTPS API로 트래픽이 갈립니다. 정적 자산이나 분석·실험용 서브도메인은 업데이트마다 로그에 새 이름이 붙을 수 있어, 「anthropic.com만 PROXY」처럼 넓게 잡으면 의도는 달성되지만 범위가 과해지고, 반대로 API 한 줄만 넣으면 웹 로그인 리다이렉트나 콘솔의 다른 호스트에서 막히는 일이 생깁니다.

그래서 실무에서는 제품 화면 이름보다 TLS SNI에 찍히는 실제 호스트를 기준으로 규칙을 쌓고, 배포 후에는 Clash 연결 로그와 브라우저 개발자 도구 네트워크 탭으로 목록을 다듬는 방식이 안전합니다. 아래 후보는 출발점이며, 본인 환경에서 관측된 이름이 우선입니다.

② 분류 대상: 콘솔·Claude 웹·API에 자주 붙는 도메인 후보

문서·커뮤니티에서 자주 인용되는 API 베이스는 https://api.anthropic.com입니다. 웹 클라이언트는 claude.ai가 중심이 되는 경우가 많고, 기업·채용·정책 안내는 anthropic.com·www.anthropic.com 쪽으로 이어질 수 있습니다. 개발자 콘솔(키·프로젝트·사용량)은 2026년 기준 platform.claude.com이 허브가 되고 console.anthropic.com에서 리다이렉트되는 흐름이 설명되는 경우가 있으며, 문서·지원은 docs.claude.com·support.claude.com 등 *.claude.com이 로그에 붙기 쉽습니다. 실제 TLS SNI는 환경마다 다르므로 콘솔만 연 뒤 로그로 확인하는 것이 안전합니다.

• API: api.anthropic.com
• 웹 챗·제품 UI: claude.ai 및 필요 시 *.claude.ai
• 콘솔·문서·지원(claude.com): platform.claude.com, docs.claude.com, support.claude.com 등(로그 기준 보강)
• 레거시·기업: console.anthropic.com, anthropic.com 하위 호스트
• 기타: CDN·분석 호스트는 업데이트마다 달라질 수 있음

문법이 익숙하지 않다면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 익히면 실수가 줄어듭니다.

③ 최소 규칙 예시: Anthropic 계열만 PROXY

아래는 개념 YAML입니다. PROXY에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 본인 환경에 맞게 조정하세요.

rules:
  # Anthropic / Claude — verify hosts in client logs after product updates
  - DOMAIN-SUFFIX,api.anthropic.com,PROXY
  - DOMAIN-SUFFIX,claude.ai,PROXY
  - DOMAIN-SUFFIX,claude.com,PROXY
  - DOMAIN-SUFFIX,anthropic.com,PROXY
  - MATCH,DIRECT

DOMAIN-SUFFIX,claude.com는 콘솔·문서·지원까지 한꺼번에 덮고, anthropic.com은 기업 페이지·레거시 콘솔 리다이렉트까지 넓게 잡습니다. 조직 정책상 범위를 좁히려면 api.anthropic.com과 claude.ai부터 두고, 로그에 뜨는 콘솔 호스트만 덧붙이는 편이 스플릿 라우팅 의도에 잘 맞습니다. 아무 규칙에도 안 걸릴 때는 잠시 MATCH,PROXY로 바꿔 터널·노드 자체가 정상인지부터 가르는 것도 좋은 디버깅 순서입니다.

④ 웹·API·콘솔을 서로 다른 노드로 보내고 싶을 때

지연·안정성 때문에 브라우저와 배치 API에 출구를 나누고 싶다면 프록시 그룹을 쪼개 규칙에서 이름만 바꿉니다.

proxy-groups:
  - name: ANTHROPIC_API
    type: select
    proxies: [🚀 자동 선택, DIRECT]
  - name: ANTHROPIC_WEB
    type: select
    proxies: [🚀 자동 선택, DIRECT]

rules:
  - DOMAIN-SUFFIX,api.anthropic.com,ANTHROPIC_API
  - DOMAIN-SUFFIX,platform.claude.com,ANTHROPIC_WEB
  - DOMAIN-SUFFIX,claude.ai,ANTHROPIC_WEB
  - DOMAIN-SUFFIX,claude.com,ANTHROPIC_WEB
  - DOMAIN-SUFFIX,anthropic.com,ANTHROPIC_WEB
  - MATCH,DIRECT

platform.claude.com 대신 console.anthropic.com만 보이는 환경이면 그 호스트로 바꿉니다. 그룹이 늘수록 규칙 순서와 상단 GEOIP·외부 RULE-SET과의 충돌을 더 자주 점검해야 합니다. 그룹 계층은 프록시 그룹(proxy-groups) 가이드와 함께 보면 정리하기 쉽습니다.

⑤ 이미 OpenAI·Gemini 줄이 있을 때: 우선순위와 중복

Clash의 rules는 위에서 아래로 읽으며 먼저 매칭된 한 줄이 승리합니다. 그래서 구독에 들어 있는 거대한 RULE-SET이나 GEOIP,KR,DIRECT가 api.anthropic.com보다 위에 있으면, 의도와 다르게 DIRECT로 나가거나 다른 그룹에 붙을 수 있습니다. 반대로 Anthropic 전용 줄을 너무 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다.

ChatGPT·Gemini용 DOMAIN-SUFFIX와 Anthropic용 줄은 호스트가 겹치지 않으므로 내용 충돌은 적지만, 줄의 세로 순서는 공통입니다. 즉 「AI 한 덩어리 RULE-SET」을 쓰더라도, 그 세트가 GEOIP DIRECT보다 위인지·구독 기본 규칙보다 아래인지만 틀려도 결과가 달라집니다. 재현이 어려울 때는 로그에 찍힌 규칙 이름·행 번호를 기준으로 한 줄씩만 옮겨 보세요.

같은 생성형 AI 주제라도 제품별 호스트가 다르므로, ChatGPT·OpenAI 분류·Google Gemini 분류 글과 목록을 나란히 두고 빠진 접두사가 없는지 대조하면 좋습니다.

⑥ RULE-SET(rule-providers)로 팀에 배포할 때

여러 PC에 같은 Anthropic 목록을 깔아 두려면 rule-providers로 묶는 방법이 편합니다. 원격 규칙 파일의 출처와 갱신 주기는 조직 정책에 맞게 판단해야 하며, 보안이 중요하면 자체 호스트 목록을 Git 등으로 관리하는 편이 낫습니다. RULE-SET은 배포 단위를 바꿀 뿐, DNS 불일치나 TUN 미포착을 자동으로 고쳐 주지는 않습니다.

⑦ DNS와 Fake-IP: 「규칙은 맞는데 앱만 이상할 때」

증상이 간헐적 이름 실패·한 앱만 이상한 IP로 붙는 형태라면 DNS를 의심합니다. fake-ip 모드에서는 애플리케이션이 보는 주소와 실제 outbound 경로가 어긋나 보일 수 있고, OS나 브라우저 DoH가 켜진 채 Clash dns 블록도 동작하면 어느 경로가 먼저 응답했는지에 따라 결과가 달라집니다. API 클라이언트는 프록시 경유 DNS와 직접 조회가 섞이면 원인 추적이 특히 어려우므로, 한 번에 한 계층만 바꿔 가며 좁히는 것이 좋습니다.

IPv6 우선 해석 뒤 특정 구간에서만 막히는 경우에는 OS·코어 설정의 IPv4/IPv6 일관성도 함께 봅니다. TUN과 DNS를 같이 쓸 때의 절차는 TUN 모드·DNS 심화 글의 순서를 참고하면 후보를 빠르게 줄일 수 있습니다.

⑧ Rule, Global, Direct와 시스템 프록시·TUN

Rule 모드는 정한 rules 순서대로 매칭합니다. 처음 증상을 볼 때는 Global을 잠깐 켜 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 터미널에서 curl로 api.anthropic.com을 호출할 때 HTTPS_PROXY를 쓰는지 로컬 포트를 직접 지정하는지에 따라 규칙 적용 여부가 달라집니다. IDE·CLI 중심 흐름은 Cursor·GitHub 분류 글과 결이 비슷하지만, 이 글은 호스트를 Anthropic 제품군에 맞춘 것입니다.

⑨ 실측 절차: 콘솔·웹·API를 각각 검증

1. 프로필 백업: YAML보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
2. Rule 모드: 선택된 프록시 그룹이 의도와 같은지, 상위 GEOIP·RULE-SET이 Anthropic 호스트보다 먼저 먹지 않는지 확인합니다.
3. 콘솔 단독: 키·프로젝트 화면만 연 뒤 로그에서 매칭된 DOMAIN·정책을 확인하고 빈 서픽스를 추가합니다.
4. 웹 단일 탭: claude.ai만 연 상태에서 동일하게 로그를 맞춥니다.
5. API 최소 호출: 문서 수준의 작은 요청을 api.anthropic.com로 보내 같은 시점에 기대 그룹으로 찍히는지 봅니다.
6. DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.

처음 클라이언트를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 덜 헷갈립니다. 다른 API 전용 글은 DeepSeek 웹·API 분류와 비교해 보세요.

⑩ 보안·정책·서비스 약관

네트워크 경로를 다루는 방법과 별개로, Anthropic 이용 가능 지역·약관·조직 보안 정책은 사용자가 스스로 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 특정 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다. 기업 환경에서는 IT 부서의 프록시·DLP 정책을 우선합니다.

⑪ 정리: Anthropic은 콘솔·웹·API 호스트를 한 세트로 관측하라

2026년에도 Claude와 Anthropic API 수요는 겹치지만, 패킷 레벨에서는 claude.ai·api.anthropic.com·콘솔 호스트로 갈라지는 경우가 많습니다. 안정적인 체감은 노드 품질만이 아니라 도메인 규칙이 빠짐없이 매칭되는지, DNS·Fake-IP가 같은 경로를 보는지, 기존 OpenAI·Gemini 줄과 섞인 규칙 표 순서가 의도와 맞는지에 따라 갈립니다. 반복 시나리오에는 규칙 기반 프록시가 같은 정책을 다시 쓰기 쉬워, 매번 전역 VPN만 켜고 끄는 방식보다 업무·개발 패턴에 맞출 때 유리한 경우가 많습니다.

설치와 버전 안내는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 혼선이 적습니다. 전역 터널보다 관측 가능한 분류에서 Clash가 장기적으로 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Claude·Anthropic 웹·API용 분류 규칙과 DNS를 맞춰 보세요.