2026년 Clash로 DeepSeek 웹·API를 나눠 쓰기: 도메인 규칙·분류·DNS·실측 절차

① 왜 웹 챗과 API는 「한 덩어리 규칙」으로 끝내기 어렵나

브라우저에서 공식 사이트를 열면 로그인·정적 자원·스트리밍 응답이 여러 서브도메인으로 갈라집니다. 반면 개발자 API는 curl·SDK·IDE 플러그인이 api.deepseek.com으로 직접 붙는 경우가 많아, 규칙에서 빠지면 DIRECT로 나가다 타임아웃하거나, 반대로 불필요하게 넓은 DOMAIN-SUFFIX를 잡으면 다른 업무 트래픽까지 같은 출구로 몰릴 수 있습니다.

그래서 실무에서는 「브랜드 이름 하나」보다 실제 TLS SNI로 찍히는 호스트를 기준으로 목록을 만드는 편이 안전합니다. 서비스가 업데이트되면 CDN·인증·실험 호스트가 바뀔 수 있으므로, 아래 목록은 출발점이며 최종 확정은 Clash 로그와 브라우저 개발자 도구의 네트워크 탭으로 맞추는 것이 좋습니다.

② 분류 대상: DeepSeek 웹·API·문서에 자주 붙는 도메인 후보

공식 API 문서에서 안내하는 base URL은 api.deepseek.com이며, OpenAI 호환 클라이언트에서는 /v1 경로를 함께 쓰는 경우가 많습니다. 개발자 문서 사이트는 api-docs.deepseek.com으로 제공되는 것이 일반적입니다. 콘솔·결제·키 관리 같은 오픈 플랫폼 UI는 platform.deepseek.com 등 deepseek.com 접미사 아래 다른 호스트로 분리되는 경우가 있으므로, 첫 설정 후 로그에 뜨는 이름을 그대로 규칙에 옮기는 방식이 가장 정확합니다.

• API 트래픽: api.deepseek.com (공식 문서 기준 베이스 URL)
• 문서·가이드: api-docs.deepseek.com
• 웹·마케팅·계정 흐름: deepseek.com, www.deepseek.com, 제품에 따라 chat. 등 추가 서브도메인
• 모바일 앱: 앱이 사용하는 API 호스트는 웹과 동일할 수도, 별도일 수도 있어 기기별 로그 확인이 필요합니다.

한 번에 DOMAIN-SUFFIX,deepseek.com만 넣으면 설정은 단순해지지만, 조직 정책상 「가능한 좁게」가 필요하면 api.deepseek.com과 문서·플랫폼 호스트부터 넣고 확장하는 전략이 맞습니다. 규칙 문법이 처음이면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름 맞추기를 먼저 익히면 실수가 줄어듭니다.

③ 최소 규칙 예시: DeepSeek만 PROXY, 나머지는 DIRECT

아래는 개념 YAML입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 본인 환경(국내 트래픽은 DIRECT 등)에 맞게 조정하세요.

rules:
  # DeepSeek — verify hosts in client logs after upgrades
  - DOMAIN-SUFFIX,api.deepseek.com,PROXY
  - DOMAIN-SUFFIX,api-docs.deepseek.com,PROXY
  - DOMAIN-SUFFIX,platform.deepseek.com,PROXY
  - DOMAIN-SUFFIX,deepseek.com,PROXY
  - MATCH,DIRECT

deepseek.com 한 줄이 웹·플랫폼·일부 API를 함께 덮는 대신 범위가 넓어집니다. 반대로 API만 분리하고 싶다면 위에서 deepseek.com 줄을 빼고, 브라우저 로그에 뜨는 호스트만 추가해 스플릿을 촘촘히 가져가면 됩니다. 아무 것도 연결되지 않을 때는 잠시 MATCH,PROXY로 바꿔 「터널 자체는 정상인지」부터 가르는 것도 좋은 디버깅 순서입니다.

④ 웹과 API를 다른 노드로 보내고 싶을 때: 프록시 그룹 두 개

지연·안정성 때문에 웹 챗과 배치 API에 서로 다른 출구를 쓰고 싶다면, 그룹을 나눠 규칙에서 이름만 바꿉니다. 예시는 구조 이해용이며, 실제 노드 이름은 본인 구독에 맞게 바꿉니다.

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

rules:
  - DOMAIN-SUFFIX,api.deepseek.com,DEEPSEEK_API
  - DOMAIN-SUFFIX,api-docs.deepseek.com,DEEPSEEK_WEB
  - DOMAIN-SUFFIX,platform.deepseek.com,DEEPSEEK_WEB
  - DOMAIN-SUFFIX,deepseek.com,DEEPSEEK_WEB
  - MATCH,DIRECT

이렇게 나누면 운영 중에 「API만 느리다」일 때 DEEPSEEK_API만 노드를 바꿔 테스트하기 쉽습니다. 다만 그룹이 늘수록 규칙 순서와 GEOIP 같은 상위 규칙과의 충돌을 더 자주 점검해야 합니다.

⑤ RULE-SET(rule-providers)로 묶어 두기

여러 기기에 같은 정책을 복제하거나, 커뮤니티 규칙 세트를 주기적으로 갱신하려면 rule-providers가 편합니다. 원격 규칙 파일의 신뢰도는 사용자가 판단해야 하며, 중요한 환경에서는 자체 호스트 목록을 유지하는 편이 안전합니다. 수동 DOMAIN-SUFFIX와의 차이는 「배포·갱신 단위」이지, DNS나 TUN 문제를 대신 해결해 주지는 않는다는 점은 동일합니다.

⑥ DNS가 원인일 때: fake-ip, DoH, 잘못된 경로로 인한 오탈락

증상이 「연결은 되는데 가끔 끊긴다」가 아니라 이름 해석이 이상하다·간헐적 실패라면 DNS를 의심합니다. fake-ip를 쓰는 프로필에서는 애플리케이션이 보는 주소와 실제 라우팅이 어긋나 보일 수 있고, OS·브라우저 DoH와 Clash dns 블록이 동시에 켜이면 조회 경로가 엇갈리기도 합니다. API 클라이언트는 특히 프록시 우회 여부와 해석 결과 캐시가 겹치면 원인 파악이 어려워지므로, 한 번에 한 가지 변수만 바꾸는 식으로 좁히는 것이 좋습니다.

IPv6 우선으로 나갔다가 특정 구간에서 막히는 환경에서는 OS와 코어 설정의 IPv4/IPv6 일관성을 맞추는 것도 중요합니다. TUN·DNS를 함께 쓸 때의 체크리스트는 TUN 모드·DNS 심화 글의 순서를 참고하면 빠르게 후보를 줄일 수 있습니다.

⑦ 모드 선택: Rule, Global, Direct와 시스템 프록시·TUN

Rule 모드는 위 rules 순서대로 매칭합니다. 문제 재현 단계에서는 Global을 잠깐 켜서 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC 경로로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 반대로 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 정책을 먼저 확인해야 합니다.

터미널에서 curl로 API를 호출할 때 프록시 환경 변수(HTTPS_PROXY 등)를 쓰는지, Clash 포트를 직접 지정하는지에 따라 규칙 적용 여부가 달라질 수 있습니다. IDE·CLI 중심의 일반적인 분류 흐름은 Cursor·GitHub 분류 글과 결이 비슷하지만, 이 글의 초점은 DeepSeek 호스트 이름에 맞춘 것입니다.

⑧ 실측 절차: 브라우저와 API를 각각 검증

1. 프로필 백업: YAML보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
2. Rule 모드: 의도한 프록시 그룹이 선택돼 있는지, 상위에 GEOIP 등이 먼저 먹히지 않는지 확인합니다.
3. 웹 단일 탭: 공식 웹만 연 뒤 Clash 로그에서 매칭된 DOMAIN·정책을 확인하고, 빠진 서픽스를 추가합니다.
4. API 최소 호출: 문서에 나온 예시처럼 api.deepseek.com로 작은 요청을 보내, 같은 시점에 로그가 PROXY로 찍히는지 봅니다.
5. DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.
6. 모바일: VPN 권한·배터리 제한·앱별 설정이 데스크톱과 달라 동일 YAML이라도 체감이 다를 수 있습니다.

처음 Clash를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 설정이 훨씬 덜 어지럽습니다. 다른 생성형 AI 제품의 도메인 패턴과 비교해 보고 싶다면 Google Gemini 분류 글과 대조해 보면, 어떤 호스트가 제품마다 다른지 감이 잡힙니다.

⑨ 보안·정책·서비스 약관을 함께 기억하기

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

⑩ 정리: DeepSeek는 「API 호스트」와 「웹 호스트」를 한 세트로 보라

2026년에도 DeepSeek에 대한 웹·앱·API 수요는 겹치지만, 실제 패킷 레벨에서는 서로 다른 호스트로 갈라지는 경우가 많습니다. 안정적인 체감은 노드 품질만이 아니라 도메인 규칙이 빠짐없이 매칭되는지, DNS가 같은 경로를 보는지, Rule 대 Global 선택이 목표와 맞는지에 따라 갈립니다. 반복 시나리오에는 규칙 기반 프록시가 같은 정책을 다시 쓰기 쉬워, 일회성 전역 VPN보다 업무·개발 패턴에 맞출 때 유리한 경우가 많습니다.

클라이언트 설치와 버전 안내는 릴리스만 쫓기보다 사이트 안내를 따르는 편이 혼선이 적습니다. → Clash를 무료로 내려받고, DeepSeek 웹·API용 분류 규칙과 DNS를 맞춰 보세요.