1. 증상부터 나누기: “느림”과 “끊김”은 다릅니다
사용자 입장에서는 모두 “Claude 가 안 된다”로 느껴지지만, 관찰 포인트는 세 가지로 나누는 편이 빠릅니다. 첫째, 웹 UI 가 무한 로딩인데 개발자 도구 네트워크 탭에서 특정 스크립트나 API 호출만 빨간색인지. 둘째, 공식 API(api.anthropic.com 등) 호출이 애플리케이션·스크립트에서만 실패하는지. 셋째, 브라우저는 되는데 터미널·CI 는 실패하는지입니다. 이 패턴이 갈리면 원인은 “노드 품질 하나”보다 트래픽이 Clash 를 안 타는 구간이나 규칙 순서 쪽으로 좁혀집니다.
구독 YAML 을 아직 익숙하게 못 가져왔다면 구독 가져오기 튜토리얼을 먼저 밟고 오는 것이 좋습니다. 그다음 이 글의 순서를 적용하면 재현이 쉬워집니다.
2. 권장 점검 순서 (실측 기준)
- Clash 가 켜져 있고 시스템 프록시 또는 TUN 중 무엇으로 잡히는지 메모합니다.
- 실시간 연결 패널에서
anthropic·claude문자열을 필터링해 기대한 정책 그룹으로 나가는지,DIRECT로 새는지 봅니다. fake-ip사용 여부와 DNS 상위 서버 도달 여부를 확인합니다. 필요 시 특정 접미사에nameserver-policy를 둡니다.- 웹·콘솔·API 를 도메인 접미사 단위로 규칙에 올리고, 공급자 규칙·GEOIP 보다 앞쪽에 둘지 뒤에 둘지 순서를 정리합니다.
- 규칙이 맞다면 지터가 적은 노드를 고정하고, 짧은 주기의 자동 페일오버가 API 세션을 자주 끊지 않는지 봅니다.
범용 오류 코드와 복구 흐름은 Clash 일반 트러블슈팅 가이드를 함께 두면 좋습니다.
3. 시스템 프록시와 TUN: 앱마다 다른 출구
macOS·Windows 의 시스템 프록시는 편하지만, 일부 CLI·컨테이너·샌드박스 앱은 이를 무시합니다. 그 결과 브라우저의 claude.ai 는 정상인데, 같은 머신에서 curl 로 Anthropic API 를 호출하면 실패하는 상황이 생깁니다. 반대로 TUN 을 켜면 라우팅 계층에서 잡혀 일관성은 좋아지지만, 다른 VPN 과의 충돌·권한 문제가 늘 수 있습니다.
TUN 모드 안내에 따라 켠 뒤, 다시 연결 로그에서 Anthropic 관련 호스트가 모두 Clash 를 통과하는지 확인하세요. “한 번에 하나의 출구”만 남기는 것이 디버깅의 기본입니다.
4. DNS·fake-ip: 작은 불일치가 타임아웃처럼 보일 때
fake-ip 는 체감 속도에 도움이 될 수 있으나, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 재시도가 늘고, 사용자에게는 “응답 없음”이나 긴 스피너로 보입니다. CDN 과 서브도메인이 많은 서비스일수록 이런 증상이 드러납니다.
상위 DNS 가 안정적으로 도달하는지 확인한 다음, anthropic.com·claude.ai 등 핵심 접미사에 별도 정책을 두어 흔들림을 줄이세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 사용 중인 코어 문서를 함께 보는 것이 안전합니다.
5. Anthropic·Claude 호스트를 의도적으로 나누기
서비스는 단일 도메인이 아니라 웹 프런트·API 엔드포인트·콘솔·과금·분석·CDN 등으로 퍼집니다. 아래 표는 점검용 체크리스트이며, 실제 이름은 브라우저 개발자 도구와 연결 로그로 최신 상태를 확인해야 합니다.
| 구분 | 예시 방향 | 팁 |
|---|---|---|
| 채팅 웹 | claude.ai | 정적 자산·XHR 이 다른 호스트로 갈 수 있어 규칙 순서가 중요합니다. |
| API | api.anthropic.com | 자동화·SDK 호출은 웹과 다른 정책 그룹으로 빼 두면 로그 해석이 쉽습니다. |
| 회사·제품 공통 | anthropic.com | 문서·랜딩·리다이렉트가 함께 묶일 수 있습니다. |
| 기타 | 로그에 보이는 서브도메인 | 공급자의 광범위한 직결 규칙에 덮이지 않게 위쪽에 명시합니다. |
6. 규칙 예시 (그룹 이름은 본인 설정으로 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,claude.ai,PROXY
- DOMAIN,api.anthropic.com,PROXY
- DOMAIN-KEYWORD,anthropic,PROXYAPI 전용 그룹을 쓰려면 DOMAIN,api.anthropic.com,PROXY_API 처럼 분리하고, 웹은 PROXY_WEB 에 두면 지연 원인을 나누어 보기 좋습니다. 공급자가 넣은 DIRECT 규칙이 위에서 먼저 매칭되면 의도와 다르게 동작하므로, 규칙 파일 순서와 include 순서를 함께 봐야 합니다.
7. 정책 그룹과 노드: API 타임아웃을 줄이는 쪽
순간 속도 벤치마크가 높아도 짧은 구간에서 패킷 손실·지터가 크면 HTTP/2 스트림이 자주 재협상되며 API 타임아웃으로 이어질 수 있습니다. Anthropic 규칙에는 손실이 적은 회선을 고정하거나, 지나치게 공격적인 자동 페일오버를 완화하는 편이 낫습니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
8. 연결 로그로 교차 검증하기
추측으로 노드를 바꾸기 전에, 어떤 호스트가 어떤 정책에 걸렸는지를 한 번에 적어 두세요. GUI 클라이언트의 실시간 연결 목록에서 도메인 문자열을 복사해 팀 위키에 붙여 두면, 이후 동일 증상이 재현될 때 비교 기준이 됩니다. DIRECT 인데 지역 제한이 있는 경로로 나가면 웹은 되고 API 만 실패하는 패턴도 설명됩니다.
9. GUI 워크플로: Clash Verge Rev
필터로 claude·anthropic 을 걸면 잘못된 정책 적중을 빠르게 찾을 수 있습니다. 설치와 구독 흐름은 초보자 가이드를 따르세요.
10. OpenAI 글과의 관계
같은 “생성형 AI 프록시”라도 호스트 집합이 다릅니다. ChatGPT·OpenAI 분류 가이드는 openai.com·chatgpt.com 축이고, 이 글은 Anthropic·claude.ai 축입니다. 두 문서를 나란히 두면 팀 내 네트워크 체크리스트로 쓰기 좋습니다.
11. 추가 함정: 확장·이중 VPN·기업 프록시
브라우저 확장이 자체 프록시를 켜 두면 OS 설정과 겹쳐 혼란이 커집니다. 점검 시에는 잠시 끄세요. Clash 외 다른 상시 VPN 과 동시에 켜면 루프나 이중 터널처럼 보이는 증상이 납니다. 기업망에서 SSL 검사를 하는 경우, 클라이언트 인증서 경고나 핸드셰이크 실패가 별도로 나올 수 있어, 그때는 프록시 분류 이전에 보안 정책을 확인해야 합니다.
12. 정리: 로그 한 줄이 곧 증거입니다
Claude 프록시 문제는 단일 스위치가 아니라 모드·DNS·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. Anthropic 과 claude.ai 를 도메인 단위로 올리고, Clash 분류 로그에 찍힌 정책 이름을 기록하면 불필요한 노드 순환을 줄일 수 있습니다. API 타임아웃 을 줄이려면 “더 빠른 노드”보다 “같은 세션을 안정적으로 유지하는 출구”를 우선하세요.
설정 파일을 매번 손으로 다듬기보다 Mihomo 를 내장한 공식 클라이언트에서 로그와 업데이트를 한곳에 모으는 편이 실무에 편할 때도 많습니다. → Clash 를 무료로 내려받고 차이를 직접 확인해 보세요