1 DeepSeek만 따로 규칙을 두는 이유
2026년에도 국산·해외 LLM을 업무와 개발에 병행하는 경우가 많습니다. 제조사마다 도메인 설계가 달라, OpenAI 계열은 ChatGPT 글의 openai.com·chatgpt.com 묶음이 중심이고, Anthropic은 Claude 글처럼 anthropic.com에 가깝게 모입니다. Google 계열은 Gemini 글의 googleapis.com 등이 넓게 퍼집니다. DeepSeek는 브랜드 사이트·채팅 UI·공식 API·문서·플랫폼이 각각 deepseek.com 계열 아래에서도 서로 다른 서브도메인으로 갈라집니다. «해외 AI 한 줄»이나 거대 GEOSITE 한 덩어리에만 기대면 api.deepseek.com만 프록시하고 웹 자원은 직행하는 식으로 출구가 엇갈리기 쉽고, 스트리밍 응답이 중간에 끊기거나 로그인만 실패하는 패턴이 납니다.
Clash에서는 DOMAIN-SUFFIX와 Rule Provider로 호스트 묶음을 명시하고, 지연·안정성에 맞춰 둔 프록시 그룹 이름을 규칙에서 참조합니다. 목표는 속도 자랑이 아니라 연결 로그에 찍힌 호스트마다 기대한 정책이 걸리게 해서, 채팅 UI와 API 스크립트가 같은 노드 정책을 쓰게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 Mihomo를 지원하는 GUI를 고른 뒤, 아래 YAML 조각을 기존 프로파일에 합치면 됩니다.
2 웹 브라우저와 API 요청: 두 갈래를 동시에 맞추기
웹: 사용자는 주로 deepseek.com과 채팅 UI(예: chat.deepseek.com 등, 실제 호스트는 서비스 업데이트에 따라 달라질 수 있음)로 들어갑니다. 정적 자원·분석·고객 지원 스크립트는 추가 서브도메인이나 CDN으로 갈 수 있어, API만 프록시에 넣고 프런트 자원을 빼면 «응답은 되는데 화면만 반쯤» 같은 증상이 납니다.
API: 개발자·자동화 스크립트는 보통 https://api.deepseek.com 베이스(예: OpenAI 호환 /v1 경로)를 향하고, 키 발급·사용량·과금은 platform.deepseek.com 등 플랫폼 호스트를 씁니다. 공식 문서는 api-docs.deepseek.com 등 별도 호스트로 제공되는 경우가 있습니다. Python·Node SDK와 curl은 시스템 프록시를 무시하는 경우가 많아, 브라우저만 정상이고 터미널만 타임아웃하는 패턴이 자주 나옵니다. 이때는 TUN 모드로 커널 라우팅을 통일하거나, 셸에 HTTPS_PROXY를 Clash 리스닝 주소에 맞추는 편이 낫습니다.
deepseek.com 접미사로 한 축을 잡되, 로그에 새 서브도메인이 뜨면 Rule Provider나 DOMAIN-SUFFIX 줄을 보강하는 식으로 유지보수하세요.
3 도메인 묶음·DOMAIN-SUFFIX·규칙 순서
최소한 DOMAIN-SUFFIX,deepseek.com으로 브랜드 축을 잡는 것을 권장합니다. 이렇게 하면 api.deepseek.com·platform.deepseek.com·www.deepseek.com 등이 같은 규칙 줄에 포함되는 경우가 많습니다. 로그에 문서 전용·CDN 전용 호스트가 따로 보이면 한 줄씩 추가하거나, 신뢰할 수 있는 원격 Rule Provider 목록에 합치고 interval로 갱신하세요.
규칙 순서는 실수하기 쉽습니다. 너무 넓은 MATCH나 «해외 전체» 규칙이 위에 있으면 DeepSeek 전용 줄이 도달하기 전에 흡수되거나, 반대로 직접 연결이 먼저면 TLS 단계에서 끊길 수 있습니다. DeepSeek 묶음은 구독이 준 «큰 덩어리»보다 앞쪽에 두고, 디버깅 시 Connections 로그에서 deepseek로 필터해 기대한 PROXY_DEEPSEEK 같은 그룹 이름이 찍히는지 확인하세요.
DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추는 것이 안전합니다. SNI와 정책이 어긋나면 «가끔만 인증서 오류»처럼 보이기도 합니다.
4 Rule Provider와 rules: 예시
아래는 개념 예시입니다. proxy-groups 이름·노드 목록은 본인 프로파일과 맞추고, rule-providers의 url은 실제로 신뢰하는 목록으로 바꾸세요. 원격 목록이 없으면 RULE-SET 줄을 빼고 DOMAIN-SUFFIX,deepseek.com만 써도 됩니다.
# Example only — merge with your full profile
proxy-groups:
- name: PROXY_DEEPSEEK
type: select
proxies:
- AUTO-BEST
- DIRECT
rule-providers:
deepseek:
type: http
behavior: classical
url: "https://example.com/rules/deepseek.txt"
path: ./ruleset/deepseek.yaml
interval: 86400
rules:
- RULE-SET,deepseek,PROXY_DEEPSEEK
- DOMAIN-SUFFIX,deepseek.com,PROXY_DEEPSEEKDOMAIN-KEYWORD,deepseek는 다른 사이트·로그 문자열과 겹칠 수 있습니다. 접미사·규칙 집합을 우선하고 KEYWORD는 임시 진단용으로만 쓰세요.
5 GEOSITE 한 덩어리에만 기대지 않기
구독에 들어 있는 GEOSITE·거대 «비중국» 묶음은 편하지만 해상도가 거칠고 갱신도 커뮤니티 속도에 묶입니다. LLM 트래픽만 낮은 지연 노드로 보내고 싶은데 무관한 사이트까지 같은 출구를 타게 되거나, 새 CDN 호스트가 목록에 없으면 직접 연결로 새었다가 끊기는 일이 생깁니다. 범용 규칙 위에 DeepSeek 전용 RULE-SET 또는 DOMAIN-SUFFIX,deepseek.com 줄을 덧씌우는 편이 팀에서도 설명하기 쉽습니다.
6 TUN·시스템 프록시·터미널 환경 변수
시스템 프록시만 켜면 브라우저는 따라오지만 CLI·일부 IDE 런타임은 그대로 직접 연결합니다. 웹 채팅과 API 스크립트를 동시에 쓰는 환경이라면 TUN으로 한 번에 규칙 엔진에 넣거나, 셸마다 HTTPS_PROXY를 맞추고 NO_PROXY에 deepseek.com이 빠져 있지 않은지 확인하세요. 이중·삼중 프록시 체인은 지연과 인증서 이슈만 키우는 경우가 많습니다.
Cursor·Clash 글은 IDE·확장 마켓 쪽 호스트에 초점이 있고, 본문은 OS 레벨에서 DeepSeek 호스트가 한 그룹으로 가게 만드는 데 초점을 둡니다. 둘 다 필요하면 규칙만 합치지 말고 로그로 각각 검증하세요.
7 platform·api-docs·OpenAI 호환 베이스 URL
공식 SDK나 OpenAI 호환 클라이언트가 최종적으로 api.deepseek.com을 부르면 네트워크 레이어에서는 브라우저와 같은 프록시 그룹을 타야 합니다. 앱이 시스템 프록시를 지원하면 Clash와 동기화하고, 아니면 TUN이 더 단순합니다. 키 관리·쿼터 확인을 위해 platform.deepseek.com에 브라우저로 접속할 때도 동일 정책이 걸리게 두는 것이 로그 분석에 유리합니다. 문서 사이트(api-docs.deepseek.com 등)는 읽기 전용이어도 차단되면 삽입된 예제·리다이렉트가 깨질 수 있으니, 필요하면 같은 그룹에 포함하세요.
출처 불명의 공용 프록시에 API 키를 태우지 마세요. 회사망에서는 보안 정책에 따라 프록시 사용 자체가 제한될 수 있습니다.
8 API 키·쿼터·준수
연결이 되어도 401·403·429·쿼터 초과·결제 오류는 계정·프로젝트 설정 문제일 수 있습니다. 키는 저장소에 올리지 말고 비밀 저장소·최소 권한으로 관리하세요. 본문은 클라이언트 측 경로 가용성만 다루며 지역 법규·고용 계약·서비스 약관 해석을 대신하지 않습니다.
9 DNS·로그·자주 보는 오류
«해석은 되는데 연결이 안 된다»면 DNS 단계와 TCP·TLS 단계를 나누어 보세요. FakeIP·DoH·fallback이 꼬이면 규칙은 맞는데 세션이 다른 출구로 나가기도 합니다. 노드를 바꿀 때마다 같은 호스트가 들쭉날쭉하면 선로 품질을 의심하고, 노드를 고정한 채 로그의 호스트 목록을 한 번에 모아 보는 편이 빠릅니다.
스트리밍 응답이 중간에 끊기면 HTTP/2와 불안정한 회선 조합도 흔한 원인입니다. 브라우저에서 채팅까지 확인 → 최소 스크립트로 API 헬스 체크 → 실제 업무 트래픽 순서를 권장합니다.
- 브라우저만 되고 터미널만 실패: 프록시 미적용·
NO_PROXY·TUN 미포함 프로세스를 의심합니다. - 웹은 되는데 API만 403/401: 규칙보다 키·지역·계정 상태를 먼저 확인합니다.
- 간헐적 TLS 오류: DNS·SNI·중간 프록시 충돌 가능성을 점검합니다.
10 자주 묻는 질문
- ChatGPT 규칙만 있으면 되나요? OpenAI 도메인과 DeepSeek 도메인은 다릅니다. 본문의
deepseek.com묶음을 추가하세요. - API만 좁히고 싶다: 가능은 하지만 웹·플랫폼 호스트를 빼면 다시 로그로 검증해야 합니다.
- Gemini·Claude 규칙과 충돌? 순서와 프록시 그룹만 분리하면 병행 가능합니다. 대상 도메인이 다릅니다.
- UWP 앱에서만 이상하다: Windows UWP·Loopback 글을 참고해 스토어 앱 예외를 점검하세요.
11 정리
2026년에도 DeepSeek 웹과 API를 안정적으로 쓰려면 «전역 스위치 하나»보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash에서 DOMAIN-SUFFIX·Rule Provider로 deepseek.com 축을 전용 프록시 그룹에 묶고, 웹과 API 두 갈래를 TUN 또는 환경 변수로 맞추면 로그 기반 디버깅이 쉬워집니다. 규칙 가독성과 클라이언트 선택 폭에서 다른 도구들보다 실무에 잘 맞는 경우가 많습니다.
설치 패키지는 공식 다운로드 페이지를 우선하세요. 소스·이슈는 GitHub 등을 참고하되, 배포물은 사이트 경로를 쓰는 편이 버전 관리에 유리합니다.
