1. 어떤 증상부터 네트워크를 의심할까
deepseek.com 랜딩이나 채팅 UI는 보이는데 질문을 보낸 뒤 응답 스트림이 멈추거나, 데스크톱·CI·에이전트가 DeepSeek API(예: api.deepseek.com)를 부를 때만 “연결 시간 초과”가 반복되면, 개발자 도구·앱 로그에 실패한 호스트 이름이 남습니다. OpenAI 호환 클라이언트에서 base_url만 바꾼 경우가 많아, 브라우저 세션과 API 트래픽이 서로 다른 규칙 분류에 매칭되면 “웹은 되는데 스크립트만 실패”처럼 보이기 쉽습니다. 이때 원인이 항상 “노드 품질”만은 아니며, url-test 그룹이 짧은 주기로 출구를 바꿔 관측 IP가 흔들리면 인증·쿠키·리다이렉트 체인이 어긋나기도 합니다.
서비스 측 이용 제한·결제·조직 정책은 프록시만으로 해결되지 않는 경우가 많습니다. 본문에서는 사용자가 프로필에서 조정할 수 있는 규칙 순서·노드 고정·DNS·브라우저 DoH 충돌 여부를 중심으로 설명합니다. Windows 클라이언트 선택은 Clash Verge 비교를, 문법은 설정 가이드와 함께 보면 적용이 빠릅니다.
2. ChatGPT·Grok·Gemini 글을 그대로 가져오면 안 되는 이유
저장소의 ChatGPT·OpenAI 글은 openai.com·chatgpt.com 계열을, Grok·xAI 글은 grok.com·api.x.ai 등을, Google Gemini 글은 googleapis.com·gemini.google.com 등을 다룹니다. DeepSeek는 웹·채팅이 deepseek.com 네임스페이스에 머무는 동안, 공식 개발자 문서는 api-docs.deepseek.com, 추론 호출은 api.deepseek.com을 중심으로 동작합니다. 상태 페이지 등 부가 호스트(status.deepseek.com 등)를 열어볼 때도 별도 이름으로 잡히므로, 다른 브랜드용 규칙만 잘 써 두었다고 해서 DeepSeek 트래픽이 자동으로 같은 프록시 그룹에 들어가지 않습니다.
DOMAIN-KEYWORD,deepseek처럼 지나치게 넓은 키워드는 로그·분석용 서드파티 호스트까지 끌어올 위험이 있어, 가능하면 본인 환경에서 관측한 DOMAIN-SUFFIX 위주로 좁히는 편이 안전합니다. 제품 업데이트마다 하위 도메인·정적 자원 CDN이 늘 수 있으므로, 장애가 날 때마다 네트워크 탭·터미널 로그에 찍힌 정확한 FQDN을 규칙 목록에 덧붙이는 습관이 장기적으로 가장 비용이 적습니다.
3. DeepSeek 웹·API·문서가 자주 쓰는 호스트(개념)
브라우저에서 deepseek.com 또는 채팅 하위 호스트를 열면 HTML·자바스크립트 번들, 아이콘·폰트, 실시간 스트림(wss 등)이 서로 다른 이름으로 요청될 수 있습니다. 공식 문서에 따르면 OpenAI 호환 API의 베이스 URL은 https://api.deepseek.com이며, 호환을 위해 https://api.deepseek.com/v1 형태를 쓰는 경우도 있습니다(경로의 v1은 모델 버전과 무관하다는 설명이 문서에 있습니다). 키 발급·대시보드·과금 UI는 플랫폼 하위 도메인으로 갈라지기도 하여, “문서는 열리는데 콘솔만 실패” 같은 정책 분할과 맞물려 디버깅이 꼬이기 쉽습니다.
정적 자원이 글로벌 CDN·서드파티 호스트로 나가면 한 줄짜리 화이트리스트로는 부족합니다. 앱 빌드마다 추적·분석 도메인이 추가될 수도 있으니, 실패 시점의 호스트 목록을 모아 규칙을 확장하는 접근이 맞습니다. 모바일 앱은 OS 수준 DNS·프라이빗 릴레이·다른 VPN과의 상호작용까지 같이 봐야 할 때가 있습니다.
공식 문서와 실제 패킷
문서에 적힌 베이스 URL과 브라우저·러너가 실제로 여는 이름이 항상 같지는 않습니다. 릴리스 노트를 보면서 규칙을 주기적으로 점검하고, 스테이징에서 먼저 매칭 로그를 확인하는 편이 운영 부담을 줄입니다. 문서 사이트를 자주 여는 팀은 api-docs.deepseek.com을 별도 줄로 두어 개발자 워크스테이션의 출구를 고정해 두면, “문서만 느리다”는 이슈를 분리하기 좋습니다.
4. Clash 규칙 분류로 DeepSeek 도메인 묶기
Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. DeepSeek 관련 호스트를 하나의 정책 그룹(예: DEEPSEEK-AI)에 모으려면 구체적인 DOMAIN-SUFFIX를 위에 두고, 넓은 규칙은 아래에 두는 순서가 안전합니다. 아래는 이해를 돕기 위한 예시 스켈레톤이며, 실제 제품 변경에 따라 하위 도메인이 달라질 수 있으니 반드시 본인이 캡처한 호스트로 바꾸세요.
rules:
- DOMAIN-SUFFIX,deepseek.com,DEEPSEEK-AI
- MATCH,OthersDOMAIN-SUFFIX,deepseek.com는 보통 www·chat·api·status 등 해당 접미사 아래 호스트를 함께 묶습니다. 네트워크 탭에 다른 최상위 도메인이 보이면 그때마다 DOMAIN-SUFFIX 또는 DOMAIN 줄을 덧붙이세요. 구독에서 내려받은 대형 규칙 분류 세트를 쓰는 경우, “광고 차단”·“지역 직결” 같은 상위 규칙에 먼저 걸려 아래 줄이 실행되지 않는지 연결 로그로 확인하세요. proxy-groups에 DEEPSEEK-AI 이름의 그룹을 실제로 정의해 두어야 하며, 이름이 어긋나 있으면 구문 오류나 의도치 않은 REJECT로 이어질 수 있습니다. rule-providers로 외부 목록을 쓴다면 갱신 주기와 우선순위를 팀 표준에 맞춰 문서화해 두면 온콜 대응이 수월합니다.
5. 노드 선택과 정책 그룹
노드 선택은 ping이 가장 낮은 서버가 항상 정답은 아닙니다. 동일 구독이라도 회선 혼잡·피어링 구간에 따라 TLS 왕복과 패킷 손실이 달라지고, 긴 스트리밍 응답에서는 끊김이 체감으로 드러납니다. url-test가 짧은 주기로 최저 지연 노드를 바꾸면 출구 IP가 흔들려 세션 안정성이 떨어질 수 있으니, 증상이 있을 때는 select로 한 노드를 고정하거나 fallback 계열로 바꿔 비교해 보세요.
시스템 프록시만 쓰는 브라우저와 TUN으로 전체 트래픽을 덮는 구성은 증상 패턴이 다릅니다. TUN을 켠 상태에서는 로컬 망 예외·Windows 방화벽·다른 VPN과의 충돌을 함께 봐야 하므로 TUN 문서와 TUN 트러블슈팅 글을 참고하세요. 사내망에서는 분할 터널링 정책과 충돌하지 않는지 보안 팀 가이드도 한 번 짚는 것이 좋습니다.
6. DNS·DoH·fake-ip가 만드는 착시
규칙이 맞아 보여도 DNS 조회가 먼저 실패하면 애플리케이션은 프록시를 타기 전에 끊깁니다. fake-ip 모드에서는 도메인과 가상 IP 매핑 타이밍이 민감해, OS·브라우저 DoH·사내 리졸버가 동시에 개입하면 “간헐적으로만 된다”는 패턴이 나올 수 있습니다. api.deepseek.com이 의도와 다른 리졸버로 풀리면 엣지까지의 경로가 달라져 지연이 커지기도 합니다.
점검 순서로는 (1) Clash DNS 패널의 리졸버·폴백 설정, (2) 운영체제 캐시, (3) 브라우저 전용 DoH를 차례로 확인합니다. DIRECT로 나가야 할 내부 호스트가 오탐으로 프록시에 탄 경우에도 비슷한 증상이 나오므로, 코어 로그에서 어떤 규칙에 매칭됐는지를 습관적으로 읽는 것이 중요합니다. 터미널 도구가 시스템 프록시를 무시한다면 터미널 프록시·환경 변수 글과 병행해 점검하세요. 입문 시 모드 전환 실험은 튜토리얼과 함께 하면 부담이 적습니다.
7. 적용 후 검증 순서
설정을 저장한 뒤에는 (1) 코어 재시작 또는 프로필 핫 리로드, (2) 브라우저에서 채팅 페이지 강력 새로고침, (3) 터미널에서 프록시 환경 변수를 지정한 curl로 api.deepseek.com에 대한 TLS 핸드셰이크만 짧게 확인하는 순서가 실무적입니다. GUI 클라이언트는 연결 테스트 기능으로 동일 호스트를 찍어 볼 수 있습니다.
여전히 스피너가 길다면 네트워크 탭에서 실패한 요청의 상태 코드·CORS·WebSocket 종료 사유를 먼저 보고, 그 호스트명을 규칙에 추가합니다. API만 문제일 때는 애플리케이션 로그의 URL 문자열이 곧바로 힌트가 됩니다. 이때도 계정 측 제한 가능성을 열어 두고, 지원팀에 문의할 정보(시간대·요청 ID)를 함께 모아 두면 대응이 빨라집니다.
9. 증상별 자가 점검
아래 표는 DeepSeek 사용 환경에서 무엇을 먼저 볼지 정리한 것입니다.
| 증상 | 의심 지점 | 조치 |
|---|---|---|
| 페이지는 뜨는데 채팅·스트림만 실패 | WebSocket·SSE·API 하위 호스트 규칙 누락 | 네트워크 탭에서 실패 FQDN 확인 후 규칙 추가 |
| 브라우저는 되는데 SDK·curl만 오류 | api.deepseek.com이 다른 정책으로 매칭 |
로그의 URL을 기준으로 접미사 규칙 정렬 |
| 간헐적 타임아웃·끊김 | 혼잡한 출구, DNS 흔들림, url-test 전환 | 수동 select·DNS 고정·fallback 실험 |
| 문서·콘솔만 열리고 앱은 실패 | 문서 호스트와 API가 서로 다른 노드·DNS | 관련 호스트를 동일 그룹으로 묶기 |
LAN에서 Mixed Port를 열어 둔 경우 방화벽·포트 설정과 충돌하지 않는지도 함께 확인하세요.
10. 요약
DeepSeek 웹·채팅과 api.deepseek.com 기반 API는 서로 다른 호스트가 동시에 움직이기 때문에, 한 줄짜리 시스템 프록시 설정보다 도메인 기준 규칙 분류와 노드 그룹 실험이 체감 안정성을 좌우합니다. 화면이 비거나 계속 로딩만 돌 때도 네트워크 측에서는 경로 일관성·DNS·브라우저 DoH·출구 전환을 먼저 의심해 볼 수 있습니다.
공유된 규칙 세트를 가져왔더라도 본인 프로필에서의 매칭 순서는 직접 확인하는 것이 안전합니다. 연결 기록과 규칙 테스트가 읽기 쉬운 최신 Mihomo 계열 클라이언트를 쓰면 호스트가 늘어나는 SaaS에 맞춰 유지보수하기에도 유리합니다. 다른 벤더용 글과 마찬가지로, 여기서는 브랜드별 FQDN을 분리해 두는 패턴을 반복 적용하는 것이 시리즈 전체와 맞물립니다.
설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.
→ Clash를 무료로 내려받아 DeepSeek·deepseek.com·API용 규칙 분류와 노드 정책을 직접 맞춰 보세요