DeepSeek 웹과 API가 간헐적으로 불안할 때: Clash(mihomo)로 도메인 분기·DNS·Fake-IP를 맞추는 실측 (2026)

1. 왜 DeepSeek만 가끔 끊겨 보일까

웹 채팅은 chat.deepseek.com과 메인 사이트 deepseek.com·www.deepseek.com으로 나뉘고, 정적 자원이나 인증·분석용 서브도메인이 추가로 붙을 수 있습니다. API는 문서상 베이스가 https://api.deepseek.com인 OpenAI 호환 엔드포인트를 쓰는 경우가 많아, 브라우저 세션과 터미널의 출구가 다르면 「웹은 되는데 curl만 실패한다」 패턴이 생깁니다.

Clash 분할에서 일부 호스트만 직접 연결이거나 다른 정책 그룹으로 새면, UI는 반쯤 뜨고 토큰 스트림만 끊기는 식으로 보입니다. 또한 mihomo에서 Fake-IP를 쓰는 환경에서는 DNS 응답이 엔진 안에서 합성되므로, OS·브라우저 DoH가 강하면 규칙과 실제 목적지가 어긋나 「해석은 됐는데 연결만 이상하다」로 느껴질 수 있습니다.

2. 다른 AI 서비스 글과의 역할 분담

ChatGPT 글은 OpenAI 호스트와 세션·노드 고정에 초점이 있고, Claude 글은 Anthropic 지역 메시지와 DNS·fake-ip 조합을, Gemini 글은 Google AI 도메인과 QUIC을 다룹니다. Grok·X 글은 x.ai·x.com 축입니다. 본문은 그 연장이 아니라 deepseek.com 및 api.deepseek.com 등 DeepSeek 전용 호스트 집합만 다룹니다. YAML을 복사할 때 목록을 섞지 마세요.

API 접속 문제는 HTTP 상태코드보다 먼저 TLS·DNS 단계에서 막히는 경우가 많습니다. 클라이언트 라이브러리가 환경 변수나 설정 파일에 다른 베이스 URL을 넣었는지, 회사 프록시가 api.deepseek.com만 예외 처리하는지도 함께 확인하는 것이 좋습니다.

3. 규칙에 넣기 좋은 DeepSeek 도메인·API 베이스

아래는 출발점입니다. 서비스는 변경될 수 있으므로 개발자 도구·앱 로그·Clash 로그에 찍힌 호스트를 기준으로 목록을 늘리거나 줄이세요. 일반적으로 DOMAIN-SUFFIX,deepseek.com 한 줄로 하위 호스트 대부분을 포함할 수 있어 운영이 단순합니다. 다만 테스트 중 특정 서브도메인만 다른 경로로 보내야 한다면 로그로 구체 이름을 잡은 뒤 DOMAIN 규칙을 추가합니다.

DOMAIN-KEYWORD,seek처럼 과도하게 짧은 키워드는 다른 사이트까지 잡을 수 있어 비추천입니다. 반복되는 접미는 DOMAIN-SUFFIX로 쌓는 편이 안전합니다.

4. mihomo rules 스니펫

전용 정책 그룹 이름을 예시로 🔷 DeepSeek라고 하면, rules에서 넓은 MATCH·지역 규칙보다 위쪽에 두는 것이 일반적입니다. 그룹·노드 이름은 본인 구독에 맞게 바꿉니다. 규칙 우선순위는 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # DeepSeek — place above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,deepseek.com,🔷 DeepSeek
  # Optional explicit API host if you split from web:
  - DOMAIN,api.deepseek.com,🔷 DeepSeek
  # Add hosts from DevTools / SDK logs if different

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 시 커스텀 규칙이 덮어써지지 않게 하려면 구독 가져오기와 프로필 머지 순서를 확인하세요. 기업망에서는 SNI·DPI로 특정 경로만 불안정한 경우도 있어, 같은 그룹이라도 노드 지역을 바꿔 대조 실험하는 것이 좋습니다.

5. API 클라이언트·SDK와 출구 일치

Python·Node 등에서 OpenAI 클라이언트를 쓸 때 base_url을 https://api.deepseek.com로 두는 예가 흔합니다. 이때 터미널 세션에 HTTP_PROXY·HTTPS_PROXY가 잡혀 있으면 Clash의 시스템 프록시와 이중으로 겹치거나, 반대로 프록시를 타지 않아 규칙 밖으로 나가기도 합니다. 한 환경에서는 한 가지 출구 스택을 유지하는 편이 디버깅에 유리합니다.

Docker·CI에서는 호스트 Clash를 경유하도록 환경 변수를 주는 경우가 많습니다. 로컬 스크립트와 컨테이너가 서로 다른 게이트웨이를 보면 「로컬만 된다」가 됩니다. 컨테이너 쪽은 Docker·호스트 Clash 글의 흐름을 참고해 NO_PROXY까지 맞추면 실수가 줄어듭니다.

IDE·플러그인이 내장 fetch로 API를 칠 때는 TUN 모드와 시스템 프록시만 켠 상태에서 증상이 달라질 수 있습니다. Cursor 글에서 말한 것처럼, 연결 로그에서 호스트와 아웃바운드를 먼저 확정한 뒤 규칙을 보강하는 루프가 안전합니다.

6. DNS·fake-ip·nameserver-policy

mihomo에서 enhanced-mode: fake-ip를 쓰면 도메인 기반 규칙 매칭과 잘 맞지만, 브라우저·OS의 DoH가 우선하면 해석이 Clash 밖으로 새어 규칙과 실제 경로가 어긋날 수 있습니다. 특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. 아래는 예시이며 실제 업스트림은 본인 정책에 맞게 교체하세요.

# Optional — example only; use your own resolvers
dns:
  nameserver-policy:
    "+.deepseek.com":
      - https://dns.google/dns-query

전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것이 좋습니다. 서비스 약관·지역 정책은 사용자마다 다르므로 본문은 전송 경로만 다룹니다. 합법적 환경에서 연결을 안정화하는 용도로만 활용하세요.

7. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Clash 로그에서 문제 요청이 의도한 DOMAIN-SUFFIX 줄에 매칭됐는지 확인합니다. 둘째, 🔷 DeepSeek에 묶인 노드의 지연·지역이 기대와 맞는지 Proxies 화면에서 봅니다. 셋째, 웹 채팅과 API를 같은 노드로 맞췄을 때 증상이 사라지는지 비교합니다. 넷째, DoH·다른 VPN·TUN 충돌을 점검합니다.

모바일 앱이 있다면 웹과 호스트 집합이 다를 수 있으므로, 플랫폼별로 로그를 따로 모아 규칙을 보강합니다. 앱 업데이트 후 엔드포인트가 바뀌면 목록도 같이 갱신해야 합니다.