2026년 Clash로 Kimi 안정 접속:
Moonshot 웹·API 분할 (DOMAIN-SUFFIX·Rule Provider)

1 Kimi·Moonshot만 따로 규칙을 두는 이유

2026년에도 국내외 LLM을 문서 요약·코딩 보조·에이전트 워크플로에 함께 쓰는 팀이 많습니다. 벤더마다 인프라와 도메인 설계가 달라, DeepSeek는 deepseek.com 축에 모이고, 해외 서비스는 OpenAI처럼 openai.com·chatgpt.com에 가깝게 묶입니다. Moonshot는 moonshot.cn 계열(중국 본토 콘솔·API)과 moonshot.ai 계열(해외 콘솔·API), 그리고 브랜드 웹 kimi.com이 동시에 등장하는 패턴이 흔합니다. «해외 AI 한 줄»이나 거대 GEOSITE 한 덩어리만 쓰면 api.moonshot.cn만 프록시하고 kimi.com 정적 자원은 직행하는 식으로 출구가 엇갈리기 쉽고, 스트리밍 응답이 끊기거나 로그인·결제 페이지만 간헐 실패하는 증상이 납니다.

Clash(Mihomo 계열)에서는 DOMAIN-SUFFIX와 Rule Provider로 호스트 묶음을 명시하고, 지연·안정성에 맞춰 둔 프록시 그룹 이름을 규칙에서 참조합니다. 목표는 속도 경쟁이 아니라 연결 로그에 찍힌 호스트마다 기대한 정책이 걸리게 해서, 브라우저 채팅과 Python·Node SDK가 같은 노드 정책을 쓰게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 Mihomo를 지원하는 GUI를 고른 뒤, 아래 YAML 조각을 기존 프로파일에 합치면 됩니다.

2 moonshot.cn·moonshot.ai·kimi.com 세 축 잡기

실무에서는 최소한 다음 접미사를 한 번에 잡는 편이 안전합니다. 서비스 지역·계정 유형에 따라 실제로 쓰는 호스트만 남기고 나머지는 주석 처리해도 됩니다.

• DOMAIN-SUFFIX,moonshot.cn — api.moonshot.cn, platform.moonshot.cn, kimi.moonshot.cn 등 본토 스택을 폭넓게 포함합니다.
• DOMAIN-SUFFIX,moonshot.ai — 해외권 api.moonshot.ai, platform.moonshot.ai 등 문서·콘솔이 이 축으로 열리는 경우가 있습니다.
• DOMAIN-SUFFIX,kimi.com — 공개 웹 챗·마케팅 페이지가 이 도메인으로 서빙되는 경우가 많아, API만 맞추고 웹을 빼면 UI 자원이 직행해 깨지는 일이 생깁니다.

회사 공용 프록시나 보안 장비 앞에서는 TLS 검사·SNI 정책 때문에 «문서에는 있는데 실제로는 리다이렉트된 호스트»가 추가로 보일 수 있습니다. Connections 로그에 뜨는 실제 호스트 이름을 기준으로 Rule Provider 목록을 주기적으로 보강하세요.

3 웹 브라우저와 API: 두 갈래를 동시에 맞추기

웹: 사용자는 kimi.com 또는 kimi.moonshot.cn 계열 UI로 들어갑니다. 정적 자원·분석·고객 지원 스크립트는 CDN·별도 서브도메인으로 갈 수 있어, API 호스트만 프록시 그룹에 넣고 프런트 자원을 빼면 «응답은 오는데 화면만 반쯤 로드» 같은 증상이 납니다.

API: 개발자·자동화 스크립트는 보통 https://api.moonshot.cn/v1 또는 https://api.moonshot.ai/v1 같은 OpenAI 호환 베이스를 씁니다. 키 발급·과금·쿼터는 platform.moonshot.cn·platform.moonshot.ai 등 플랫폼 호스트로 이어집니다. Python·Node SDK와 curl은 시스템 프록시를 무시하는 경우가 많아, 브라우저만 정상이고 터미널만 타임아웃하는 패턴이 자주 나옵니다. 이때는 TUN 모드로 커널 라우팅을 통일하거나, 셸에 HTTPS_PROXY를 Clash 리스닝 주소에 맞추는 편이 낫습니다.

4 규칙 순서·전용 프록시 그룹

규칙 순서는 실수하기 쉽습니다. 너무 넓은 MATCH나 «해외 전체» 규칙이 위에 있으면 Kimi 전용 줄이 도달하기 전에 흡수되거나, 반대로 직접 연결이 먼저면 TLS 단계에서 끊길 수 있습니다. Moonshot·Kimi 묶음은 구독이 준 «큰 덩어리»보다 앞쪽에 두고, 디버깅 시 Connections에서 moonshot·kimi로 필터해 기대한 PROXY_KIMI 같은 그룹 이름이 찍히는지 확인하세요.

DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추는 것이 안전합니다. SNI와 정책이 어긋나면 «가끔만 인증서 오류»처럼 보이기도 합니다.

5 Rule Provider와 rules: 예시

아래는 개념 예시입니다. proxy-groups 이름·노드 목록은 본인 프로파일과 맞추고, rule-providers의 url은 실제로 신뢰하는 목록으로 바꾸세요. 원격 목록이 없으면 RULE-SET 줄을 빼고 DOMAIN-SUFFIX만 써도 됩니다.

# Example only — merge with your full profile
proxy-groups:
  - name: PROXY_KIMI
    type: select
    proxies:
      - AUTO-BEST
      - DIRECT

rule-providers:
  moonshot_kimi:
    type: http
    behavior: classical
    url: "https://example.com/rules/moonshot-kimi.txt"
    path: ./ruleset/moonshot_kimi.yaml
    interval: 86400

rules:
  - RULE-SET,moonshot_kimi,PROXY_KIMI
  - DOMAIN-SUFFIX,moonshot.cn,PROXY_KIMI
  - DOMAIN-SUFFIX,moonshot.ai,PROXY_KIMI
  - DOMAIN-SUFFIX,kimi.com,PROXY_KIMI

6 GEOSITE 한 덩어리에만 기대지 않기

구독에 들어 있는 GEOSITE·거대 «AI» 묶음은 편하지만 해상도가 거칠고 갱신도 커뮤니티 속도에 묶입니다. Kimi 트래픽만 낮은 지연 노드로 보내고 싶은데 무관한 사이트까지 같은 출구를 타게 되거나, 새 CDN 호스트가 목록에 없으면 직접 연결로 새었다가 끊기는 일이 생깁니다. 범용 규칙 위에 Moonshot 전용 RULE-SET 또는 위 DOMAIN-SUFFIX 줄을 덧씌우는 편이 팀에서도 설명하기 쉽습니다.

7 TUN·시스템 프록시·터미널 환경 변수

시스템 프록시만 켜면 브라우저는 따라오지만 CLI·일부 IDE 런타임은 그대로 직접 연결합니다. 웹 채팅과 API 스크립트를 동시에 쓰는 환경이라면 TUN으로 한 번에 규칙 엔진에 넣거나, 셸마다 HTTPS_PROXY를 맞추고 NO_PROXY에 moonshot.cn·kimi.com이 빠져 있지 않은지 확인하세요. 이중·삼중 프록시 체인은 지연과 인증서 이슈만 키우는 경우가 많습니다.

IDE·확장 마켓 쪽은 Cursor·Clash 글이 보완합니다. 본문은 OS 레벨에서 Kimi·Moonshot 호스트가 한 그룹으로 가게 만드는 데 초점을 둡니다.

8 SDK·OpenAI 호환 베이스 URL·플랫폼

공식 SDK나 OpenAI 호환 클라이언트가 최종적으로 api.moonshot.cn 또는 api.moonshot.ai를 부르면 네트워크 레이어에서는 브라우저와 같은 프록시 그룹을 타야 합니다. 앱이 시스템 프록시를 지원하면 Clash와 동기화하고, 아니면 TUN이 더 단순합니다. 키 관리·쿼터 확인을 위해 플랫폼 호스트에 브라우저로 접속할 때도 동일 정책이 걸리게 두는 것이 로그 분석에 유리합니다.

출처 불명의 공용 프록시에 API 키를 태우지 마세요. 회사망에서는 보안 정책에 따라 프록시 사용 자체가 제한될 수 있습니다.

9 API 키·쿼터·준수

연결이 되어도 401·403·429·쿼터 초과·결제 오류는 계정·프로젝트 설정 문제일 수 있습니다. 키는 저장소에 올리지 말고 비밀 저장소·최소 권한으로 관리하세요. 본문은 클라이언트 측 경로 가용성만 다루며 지역 법규·고용 계약·서비스 약관 해석을 대신하지 않습니다.

10 DNS·로그·자주 보는 오류

«해석은 되는데 연결이 안 된다»면 DNS 단계와 TCP·TLS 단계를 나누어 보세요. FakeIP·DoH·fallback이 꼬이면 규칙은 맞는데 세션이 다른 출구로 나가기도 합니다. 노드를 바꿀 때마다 같은 호스트가 들쭉날쭉하면 선로 품질을 의심하고, 노드를 고정한 채 로그의 호스트 목록을 한 번에 모아 보는 편이 빠릅니다.

스트리밍 응답이 중간에 끊기면 HTTP/2와 불안정한 회선 조합도 흔한 원인입니다. 브라우저에서 채팅까지 확인 → 최소 스크립트로 API 헬스 체크 → 실제 업무 트래픽 순서를 권장합니다.

• 브라우저만 되고 터미널만 실패: 프록시 미적용·NO_PROXY·TUN 미포함 프로세스를 의심합니다.
• 웹은 되는데 API만 403/401: 규칙보다 키·지역·계정 상태를 먼저 확인합니다.
• cn과 ai 중 한쪽만 실패: 해당 지역 엔드포인트·계정이 실제로 어떤 호스트를 쓰는지 문서와 로그를 대조합니다.
• 간헐적 TLS 오류: DNS·SNI·중간 프록시 충돌 가능성을 점검합니다.

11 자주 묻는 질문

• DeepSeek 규칙만 있으면 되나요? deepseek.com과 moonshot.cn은 다릅니다. 본문의 Moonshot·Kimi 묶음을 추가하세요.
• API만 좁히고 싶다: 가능은 하지만 웹·플랫폼 호스트를 빼면 다시 로그로 검증해야 합니다.
• kimi.com이 필요 없어 보인다: 실제 UI가 해당 도메인을 쓰면 자원이 직행해 깨질 수 있으니, 로그로 확인 후 제거하세요.
• UWP 앱에서만 이상하다: Windows UWP·Loopback 글을 참고해 스토어 앱 예외를 점검하세요.

12 정리

2026년에도 Kimi 웹과 Moonshot API를 안정적으로 쓰려면 «전역 스위치 하나»보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash에서 DOMAIN-SUFFIX·Rule Provider로 moonshot.cn·moonshot.ai·kimi.com 축을 전용 프록시 그룹에 묶고, 웹과 API 두 갈래를 TUN 또는 환경 변수로 맞추면 로그 기반 디버깅이 쉬워집니다. 규칙 가독성과 클라이언트 선택 폭에서 다른 도구들보다 실무에 잘 맞는 경우가 많습니다.

설치 패키지는 공식 다운로드 페이지를 우선하세요. 소스·이슈는 GitHub 등을 참고하되, 배포물은 사이트 경로를 쓰는 편이 버전 관리에 유리합니다.

→ Clash 무료 다운로드 후 Kimi·Moonshot 규칙을 적용해 보세요