왜 “웹만 되고 API·앱은 이상”할까?

ChatGPT, Claude 같은 서비스는 겉으로는 하나의 브랜드처럼 보여도, 실제 트래픽은 웹 프론트, API 엔드포인트, 인증·결제·CDN, 데스크톱·모바일 앱이 서로 다른 도메인·IP·TLS 핸드셰이크 경로로 쪼개집니다. 브라우저 탭만 보면 “연결됐다”고 느껴지는데, 터미널의 curl, IDE 확장, 또는 공식 클라이언트가 다른 호스트로 붙으면 직회선(DIRECT)으로 빠지거나 반대로 의도와 다른 노드를 타면서 세션이 끊기는 패턴이 2026년에도 자주 보고됩니다.

Clash·mihomo는 이런 문제를 “노드 품질 하나”로만 설명되지 않습니다. rules에서 어떤 도메인이 먼저 매칭되느냐, 그리고 그 직후 DNS가 어떤 IP를 돌려주느냐가 합쳐져야, 웹·API·앱이 같은 논리 경로로 움직입니다. 구독 갱신이나 TUN 전체 논의는 이미 구독 관리 가이드와 TUN 가이드에서 다루었으므로, 여기서는 AI 도메인·전략 그룹·DNS에만 집중합니다.

도메인 규칙: 누락 프록시를 줄이는 순서

규칙 분류의 기본 원칙은 단순합니다. 좁고 구체적인 조건을 위에, 넓은 MATCH나 지역 기본값은 아래에 두세요. OpenAI·Anthropic 계열은 제공 정책에 따라 호스트 이름이 바뀌거나 하위 도메인이 늘어날 수 있으므로, 실무에서는 DOMAIN-SUFFIX로 상위 도메인 묶음을 잡는 패턴이 흔합니다. 예를 들어 openai.com, oaistatic.com, anthropic.com, claude.ai 등은 자주 언급되지만, 본인 환경에서 실제로 나가는 SNI를 한 번씩 확인해 목록을 보강하는 것이 안전합니다.

규칙만 넣었다고 끝이 아니라, 같은 이름의 프록시 그룹이 존재해야 합니다. AI 트래픽만 모을 PROXY-AI 같은 그룹을 만들고, 그 위에 DOMAIN-SUFFIX,... 줄을 연결하면 “일반 웹은 일반 그룹, AI는 AI 그룹”처럼 역할이 겹치지 않게 나눌 수 있습니다. 문법·우선순위·전략 그룹 타입에 대한 전체 설명은 규칙 심화 가이드와 함께 읽으면 구성이 한결 명확해집니다. 

# Conceptual fragment — order and group names must match your profile
proxy-groups:
  - name: PROXY-AI
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY-AI
  - DOMAIN-SUFFIX,anthropic.com,PROXY-AI
  - DOMAIN-SUFFIX,claude.ai,PROXY-AI
  # ... broader rules below

전략 그룹 선택: select와 url-test의 역할

AI 작업은 긴 세션·스트리밍 응답이 많아 노드 하나가 불안정하면 체감이 큽니다. select는 사용자가 고정한 노드를 그대로 쓰기에 적합하고, url-test나 fallback은 지연·실패에 반응해 후보를 바꿀 수 있습니다. 다만 url-test의 측정 URL이 AI 서비스와 무관한 글로벌 사이트라면, “지연은 낮은데 AI 호스트만 막히는” 착시가 날 수 있으므로, 가능하면 측정 대상과 실제 사용 도메인이 비슷한 지역·경로인지 점검합니다.

Claude 접속과 ChatGPT를 동일 그룹에 넣을지 나눌지는 취향과 노드 정책에 따라 다릅니다. 한 노드에서만 한쪽이 불안정하면 그룹을 쪼개고, 둘 다 같은 업스트림이면 하나의 PROXY-AI로 묶어 규칙을 단순화하는 편이 관리에 유리합니다. 중요한 것은 “이름만 AI 전용이고 실제로는 DIRECT에 가까운 우선순위”가 되지 않게 하는 것입니다.

팁: GUI에서 노드를 바꿔도 즉시 개선되지 않으면, 캐시된 DNS·기존 TCP 세션 때문일 수 있습니다. 클라이언트에서 DNS 캐시 초기화 또는 프로필 재적용 후 같은 앱을 완전히 종료했다가 다시 열어 비교해 보세요.

DNS와 fake-ip: API가 엇나가지 않게

DNS는 규칙보다 앞서 “어디로 붙을지”의 전제를 만듭니다. fake-ip 모드를 쓰면 도메인 질의가 Clash 내부에서 처리되고, 규칙 엔진이 도메인 기준으로 매칭하기 쉬워집니다. 반대로 실제 IP가 먼저 로컬 스텁 리졸버에 노출되면, 일부 규칙은 IP 기준으로만 판단하게 되어 도메인 규칙이 빗나가는 경우가 있습니다. 그래서 AI용 도메인을 fake-ip-filter에 넣거나, 반대로 특정 API만 redir-host 쪽에 맞추는 식으로 DNS 모드와 규칙 세트를 한 세트로 맞추는 것이 중요합니다.

nameserver와 fallback 체인도 살펴보세요. 업스트림 DNS가 지역별로 다른 응답을 주면, 같은 api.openai.com이라도 세션마다 다른 엣지로 붙어 403·429·TLS 오류가 번갈아 나올 수 있습니다. “항상 같은 해석”에 가깝게 가져가되, 프라이버시 정책과 회사망 제약 안에서 선택합니다. 기능 개요는 문서 허브와 프로필 예시를 함께 참고하면 좋습니다.

분할 터널 관점: 국소 프록시로 끊김 줄이기

모든 트래픽을 한꺼번에 글로벌 프록시에 태우면 배터리·지연·정책 충돌이 커질 수 있습니다. 분할 터널(split tunnel)을 Clash로 구현한다는 것은, 곧 규칙으로 “이 도메인만 프록시”를 명시하는 것과 맞닿아 있습니다. AI 도메인만 PROXY-AI로 보내고 나머지는 DIRECT 또는 국내 전용 그룹으로 두면, 불필요한 홉이 줄어들어 체감 안정성이 좋아지는 경우가 많습니다.

데스크톱 앱이 시스템 프록시를 무시한다면, 브라우저만으로는 재현되지 않는 증상이 나옵니다. 이때는 system-proxy만으로는 부족할 수 있고, TUN이 필요한지 여부는 사용 앱·OS에 따라 갈립니다. TUN의 전체 개념·권한은 TUN 가이드에 맡기고, 여기서는 “AI 관련 호스트가 규칙에 잡혔는지”를 먼저 의심하는 것이 순서입니다.

자가 점검 체크리스트

  • AI 사이트/API에 대응하는 DOMAIN·DOMAIN-SUFFIX 규칙이 MATCH보다 위에 있는가.
  • 전략 그룹 이름이 규칙과 정확히 일치하고, 의도한 노드·백업이 들어 있는가.
  • DNS 모드(fake-ip / redir-host)와 fake-ip-filter가 API·스트리밍 경로와 충돌하지 않는가.
  • 브라우저와 달리 실패하는 앱·CLI가 시스템 프록시를 쓰는지, 별도 해석 경로를 쓰는지.
Clash는 로컬 프록시 엔진일 뿐이며, 타인의 서비스 약관·저작권·수출 규정을 우회하도록 안내하지 않습니다. 항상 법령과 계약 관계를 준수하고, 회사·학교 기기에서는 정책을 확인하세요.

정리: 규칙·그룹·DNS를 한 줄로 맞추기

Clash ChatGPT·Claude 접속을 안정적으로 쓰려면, 노드만 바꿔치기하기 전에 규칙 분류가 AI 호스트를 빠짐없이 덮는지, 전략 그룹이 실제로 그 경로를 태우는지, DNS가 같은 도메인을 일관되게 해석하는지를 세트로 점검하는 것이 효과적입니다. AI 도구 프록시는 장비마다 다른 앱·API 조합을 동시에 쓰기 때문에, “한 번 맞춰 두면 오래 간다”기보다 로그로 SNI·호스트를 확인하는 습관이 더 큰 자산입니다. 같은 조건에서도 규칙 편집과 프로필 전환이 수월한 클라이언트면 시행착오 시간이 줄어듭니다.

다른 도구들과 비교했을 때 Clash·mihomo 계열은 표현력 있는 규칙과 공개된 설정 예시 덕분에, 생성형 AI처럼 트래픽이 잘게 쪼개진 서비스를 다루기에도 균형이 잘 잡힌 편입니다.

→ Clash 공식 클라이언트 무료 다운로드 — 규칙·DNS·프로필을 한 화면에서 다루며 AI 웹과 API를 동시에 맞춰 보고 싶다면, 최신 빌드를 받아 직접 구성해 보는 것이 가장 빠릅니다.