AI·프록시 추천 태그: Kimi Moonshot Clash

Kimi·Moonshot(월지암면) API·총 타임아웃?platform·api.moonshot.cn·api.moonshot.ai Clash 규칙·노드로 고정(2026)

국내 대규모 모델로 자주 언급되는 Kimi·月之暗面·Moonshot 개방 플랫폼은 2026년에도 개발자·팀·에이전트 체인에서 API 검색·도입이 활발한 편입니다. 공식 기준으로는 중국권 https://api.moonshot.cn·https://platform.moonshot.cn과 국제권 https://api.moonshot.ai·https://platform.moonshot.ai가 함께 문서에 등장하며, 팀마다 콘솔(키·과금·로그)과 API 호스트가 엇갈리는 구조입니다. 총 타임아웃·스피너·스트림 끊김은 TLS·DNS·노드 쪽과 서비스 측 제한이 겹쳐 보이기 쉬워, Clash규칙 분류·정책 그룹·노드 선택으로 동일한 Moonshot FQDN이 같은 출구를 타게 맞추는 절차를 정리합니다. DeepSeek·Z.ai(智谱)·OpenAI/ChatGPT 기사는 각각 deepseek.com·z.ai·openai.com 축이므로, 여기서는 moonshot 네임스페이스를 분리해 둡니다. 본문은 계정·쿼터·지역 정책 위반을 조장하는 내용이 아니라, 네트워크·클라이언트 측 경로를 일치시키는 데 집중합니다.

약 20분 읽기
Clash 편집부

1. 어떤 증상부터 네트워크를 의심할까

platform.moonshot.cn·platform.moonshot.ai 콘솔에서 API 키·과금·사용 로그는 열리는데, 채팅/플레이그라운드나 별도 앱이 붙는 https://api.moonshot.cn·https://api.moonshot.ai 쪽에서만 총 타임아웃·read timeout이 반복되면, 터미널·CI·개발자 툴 로그에 실패한 FQDN이 남는 경우가 많습니다. OpenAI 호환 스택을 쓰는 팀은 base_urlapi.moonshot 계열로 바꾸기 쉬운데, 브라우저(시스템 프록시)로 보는 콘솔과, SDK·curl이 타는 API서로 다른 규칙 분류·노드에 걸리면 “웹은 되는데 백엔드만 죽는다”는 패턴이 납니다. url-test로 저지연이 잦은 노드만 골랐다가 출구 IP가 흔들리면, 스트리밍 응답 중간에 끊기거나 재시도 비용이 커질 수 있습니다.

쿼터·결제·조직 정책·IP 제한은 프록시만으로 해소되지 않는 경우가 많고, 본문은 Clash에서 규칙 순서·정책 그룹·노드·DNS·터미널 프록시를 맞추는 쪽에 맞춥니다. 끊김이 반복될 때는 TLS·SNI터미널 HTTP(S)_PROXY를 함께 보는 것이 실무에 유리하고, 문서·튜토리얼과 병행하면 모드·YAML 실수를 줄이기 쉽습니다. Windows 팀은 클라이언트 비교도 짚고 가면 “시스템 프록시만”과 TUN·프로세스 경로 차이를 덜 혼동합니다.

2. DeepSeek·Z.ai(智谱)·OpenAI(범) 글을 그대로 쓰기 어려운 이유

DeepSeek 글은 deepseek.com·api.deepseek.com, Z.ai 글은 z.ai·bigmodel.cn, ChatGPT·OpenAI 글은 openai.com·chatgpt.com·api.openai.com 등을 겨냥합니다. Kimi·Moonshot·月之暗面개방 API·콘솔은 moonshot.cn / moonshot.ai 최상위와 그 아래 platform·api 호스트에 걸쳐 있으며, 국내용 엔드포인트(api.moonshot.cn 등)와 해외/글로벌 엔드포인트(api.moonshot.ai 등)를 문서에서 동시에 안내하는 구조로 자주 쓰입니다. 그래서 “범 OpenAI” 계열 규칙만 있어도 api.moonshot 트래픽이 의도한 정책 그룹에 붙지 않는 경우가 많고, 노드 선택·도메인·문서·과금 U가 서로 분리되어 디버깅이 꼬이기 쉽습니다.

DOMAIN-KEYWORD,moonshot처럼 키워드로 한 번에 묶는 방법도 있으나, 통계/분석·CD용 서드파티가 같이 끌려올 수 있어, 실패한 요청에 찍힌 FQDN을 수집한 뒤 DOMAIN-SUFFIX,moonshot.cn·DOMAIN-SUFFIX,moonshot.ai에 더해 DOMAIN으로 세부 호스트를 덧붙이는 쪽이 운영에 안전합니다. 제품 릴리스·문서 경로는 바뀌기 쉬우니, 2026년에도 개발자 콘솔·공식 API 문서의 베이스 URL을 ‘믿을 수 있는 기준’으로 두고, 로컬 관측과 주기적으로 대조하세요.

팁: 시크릿·확장 끄기, 기업 MITM·광고 차단이 SSE·stream을 가로막는지 먼저 짧게 확인하세요. 동일 키로 콘솔에서는 응답이 보이는데 터미널 SDK만 죽으면, 출구뿐 아니라 로컬 TLS·인증서 체인도 함께 봅니다.

3. 콘솔·API·문서가 자주 쓰는 Moonshot·Kimi 호스트(개념)

문서·콘솔·FAQ에 기준으로 자주 올라오는 이름은 (개념 예시) https://api.moonshot.cn·https://api.moonshot.aiChat Completions 등 OpenAI 호환 API, 그리고 https://platform.moonshot.cn / https://platform.moonshot.ai개발자 포털·가이드입니다. Kimi 제품·실험 U와 API 키·사용량 UI가 분리·병행되는 경우가 있어, 브라우저로 보는 HTTP(S)와 터미널/백엔드가 쏘는 api.가 서로 다른 TLD( .cn vs .ai )에 걸리면 “한쪽만 반복 타임아웃”이 생기기 쉽습니다. 규칙을 짤 때는 팀이 실제로 선택한 base URL·리전(국내/국제)에 맞춰 최상위 접미사를 먼저 잡는 편이 안전합니다.

배지·이미지·스크립트·분석·CDN이 추가 호스트로 갈리면, DOMAIN-SUFFIX만으로는 모자를 수 있어, 개발자 도구·프록시 연결 로그에 찍힌 FQDN을 누적해 두는 것이 좋습니다. 모바일·오프라인 빌드·사내 DNS·다른 VPN과의 조합은 증상이 달라질 수 있으니, 클라이언트별로 “어떤 인터페이스가 Clash(TUN/시스템 프록시/로컬 포트)를 실제로 타는지”를 분리해 기록하세요. 중국권/국제권 엔드포인트를 혼용하면, 같은 키라도 네트워크·정책·지연 특성이 달라 A/B·장애 대응이 복잡해질 수 있어, 도메인·노드·회선을 한 세트로 문서화하는 팀이 유리합니다.

문서·실패 로그·코드

문서·SDK·런칭 메모에 적힌 base_url과 런타임 curl -v·HTTP 클라이언트 로그에 나오는 SNI/호스트가 꼭 같지는 않을 수 있으니, 재현 시각·요청 ID·실패 FQDN을 한 줄에 묶어 보관하세요. 스테이징/프로덕트가 도메인 셋을 달리 쓰면, “규칙은 맞는데 환경만 틀림” 류의 오탐이 줄어듭니다. 문서·상태 U가 별 host이면(예: 범용 status·내부 대시보드) 그 줄을 콘솔·API와 같이 정책 그룹에 둘지, 모니터링용으로만 DIRECT할지 팀 합의를 두는 편이 운영에 편합니다.

4. Clash 규칙으로 Moonshot·Kimi 도메인·호스트를 한 그룹에

Clash(Mihomo 등) RULE 모드는 위→아래 첫 매칭입니다. Kimi·Moonshot API·platform 트래픽을 예를 들어 KIMI-MOONSHOT 정책 그룹에 보내려면, DOMAIN-SUFFIXmoonshot.cn·moonshot.ai를 먼저 잡고, 캡처한 단일 FQDN은 DOMAIN로 보강하는 흐름이 흔합니다. 아래는 이해를 위한 스켈레톤이며, 팀이 실제로 쓰는 base URL·국내/국제 엔드포인트에 맞게 줄을 늘려야 합니다.

proxy-groups:
  - name: KIMI-MOONSHOT
    type: select
    proxies: [DIRECT, proxy-a, proxy-b]
rules:
  - DOMAIN-SUFFIX,moonshot.cn,KIMI-MOONSHOT
  - DOMAIN-SUFFIX,moonshot.ai,KIMI-MOONSHOT
  - MATCH,Others

상위 지오IP·광고·직연결 세트에 먼저 걸리면 이후 줄이 실행되지 않을 수 있으니, 연결 로그에서 api.moonshot·platform.moonshot이 어떤 줄에 매칭됐는지를 확인하세요. proxy-groups 이름이 YAML·GUI와 어긋나면 dial·의도치 않은 REJECT로 이어질 수 있고, rule-providers 쓰면 갱신·우선순위를 문서로 남기는 것이 개발자 팀·온콜이 편합니다. 팀이 .cnDIRECT·.ai는 해외 노드처럼 규칙을 쪼개는지에 따라 품질·정책이 달라질 수 있으니, “같은 키·같은 앱”이라도 도메인 셋을 기준으로 정책을 합의하세요.

5. 노드 선택·정책 그룹(총 타임아웃과의 관계)

노드 선택에서 ping·지연만 보고 고르면, TLS·장문 스트림·혼잡 구간에서 “숫자는 낮은데 API만 끊김”이 나올 수 있습니다. url-test가 잦은 전환을 하면 출구 IP·세션·재시도 정책이 흔들리니, 총 타임아웃·스트림 끊김이 있을 때는 select로 한 노드를 잠시 고정하거나 fallback을 비교용으로 쓰는 흐름이 흔합니다. Kimi·Moonshot API는 긴 컨텍스트·stream이 붙는 경우가 많아, “스루풋+지터”를 함께 보는 편이 개발자 경험에 맞습니다.

시스템 프록시만·TUN·프로세스 분류는 트래픽이 타는 경로가 달라, 동일 도메인도 클라이언트마다 다른 규칙에 붙는 일이 납니다. TUN 라우팅·Windows 방화벽·다른 VPN·LAN 예외는 TUN·TUN 트러블슈팅을 함께 보고, 사내망이면 사내 분할 터널·보안과 충돌이 없는지 점검하세요. 콘솔은 브라우저·APInode·러너·컨테이너의 조합이 다를 수 있어, 정책 그룹·KIMI-MOONSHOT 같은 태그를 “어느 프로세스가 쓰는지”에 맞게 나누는 팀이 온콜에 강합니다.

주의: 출처 불명·공용 노드API 키·사내 데이터 유출 위험이 큽니다. 개발·프로덕은 신뢰할 수 있는 출구·최신 클라이언트·모니터링을 쓰고, 본문은 인증·쿼터·이용 약관·지역·IP 정책 우회를 다루지 않습니다.

6. DNS·DoH·fake-ip가 총 타임아웃에 끼치는 착시

규칙·노드를 맞춰도 DNS가 먼저 어긋나면 api.moonshot.cn / api.moonshot.ai·platform.moonshot 풀림이 끊기고 앱은 프록시 앞에서 실패한 것처럼 보입니다. fake-ip와 OS·브라우저 DoH·사내 리졸버가 겹치면 “콘솔은 가끔·API만 항상” 식의 간헐 타임아웃이 납니다. Moonshot FQDN이 기대한 A/AAAA·ECS·리졸버 위치에 따라 엣지까지 경로가 달라질 수 있으니, 실패 직전의 이름 해석·캐시·쿼리 경로를 함께 봅니다.

권장 점검 순서는 (1) Clash·Mihomo DNS·폴백·(필요 시) fake-ip-filter, (2) OS 캐시·/etc/hosts, (3) 앱/브라우저 DoH·프록시 무시, (4) 컨테이너·systemd·CI 러너의 리졸버입니다. DIRECT여야 할 사내 도메인이 오탐이면 유사 증상이 납니다. 터미널·SDK가 시스템 프록시를 안 타면 HTTP(S)_PROXY·튜토리얼fake-ip·필터를 함께 쓰면 재현·해결이 빨라집니다.

7. 적용 후 검증 순서(콘솔 + API + 로그)

프로필 반영 뒤 (1) 코어 재시작/핫 리로드, (2) platform 콘솔·문서 강력 새로고침, (3) 터미널에서 curl -vI·TLS만 짧게 찍어 api.moonshot.cn / api.moonshot.ai SNI·인증서 체인을 확인, (4) 개발용 스크립트·SDK에 동일 base URL·프록시를 씌운 스모크를 한 번에 돌리는 순서가 실무에 잘 맞습니다. GUI는 내장 연결 테스트로 동일 FQDN을 집어넣는 편이 빠릅니다. 팀이 .cn / .ai번갈아 쓰면, 각각 규칙·로그 행이 분리돼야 정상인지 먼저 합의하세요.

여전히 총 타임아웃이면 네트워크 탭·앱·코어 로그의 호스트·상태·stream 종료·재시도를 보고, 누락 FQDN을 도메인 규칙에 추가합니다. API만 죽을 때 URL 문자열이 가장 확실한 힌트이며, 쿼터·결제·서비스 측 점검·IP 정책 여부는 별도로 열어 두고, 지원에 줄 타임스탬프·요청 ID·환경(클라이언트/리전)을 묶어 두면 대응이 빨라집니다.

9. 증상별 자가 점검(Kimi·Moonshot·API·개발)

아래는 Kimi·Moonshot 콘솔·API를 쓰는 개발 맥락에서, 무엇을 먼저 볼지 압축한 표입니다.

증상 의심 지점 조치
콘솔·문서는 열리는데 API총 타임아웃 api.moonshot·platform.moonshot 규칙·노드 엇갈림 로그 FQDN으로 DOMAIN·proxy-groups 정렬, 스모크 curl
.cn.ai 중 한쪽만 실패 엔드포인트 TLD·DNS·지오/직결 충돌 base URL에 맞춰 접미사·직연결 재검토
SDK·node·CI만 죽고 브라우저는 OK 시스템 프록시 미적용·환경 변수·컨테이너 DNS 터미널 프록시·리졸버·TUN·경로
간헐 타임아웃·스트림 중단 url-test 전환·TLS·fake-ip·DoH select·폴백·fake-ip·SNI

Mixed 포트·LAN·방화벽·다른 VPNClash가 겹치면 동일 FQDN도 경로가 달라질 수 있으니, Mixed·LAN 글과 함께 보세요.

10. 요약

Kimi·Moonshot(月之暗面) 개방 API·platform 콘솔은 api.moonshot·platform.moonshot·.cn / .ai TLD를 동시에 쓰는 경우가 잦아, Clash에서 도메인·규칙 분류·정책 그룹·노드 선택을 한 덩어리로 잡는 것이 총 타임아웃·stream 끊김·콘솔·API 불일치를 줄이는 데 유효합니다. 개발자·팀·CI·에이전트는 시스템 프록시·DNS·fake-ip·url-test 흔들림과의 상호작용까지 같이 봐야 “노드만 갈면 된다”로 끝나지 않는 케이스를 줄일 수 있습니다.

다른 LLM API Clash 기사( DeepSeek·Z.ai·OpenAI·범)와 도메인·베이스 URL이 다르다는 점을 머릿속에 두고, 팀 YAML·온콜 표에 moonshot FQDN을 별 섹으로 두면 반복 장애 대응이 단순해집니다. 최신 Mihomo 계열 UI로 매칭·로그를 읽기 쉽게 두면, 2026년에도 개발 툴체인·멀티 제공자에 맞춰 유지보수하기에 유리합니다. 오픈 소스 저장소는 이슈·빌드·신뢰용으로, 설치 패키지이 사이트 다운로드 페이지를 쓰는 흐름이 대체로 혼선이 적습니다.

다른 벤더 규칙을 복붙해도 Moonshot FQDN이 자동으로 맞지 않으니, 본고처럼 moonshot.cn / moonshot.ai·api·platform을 명시한 뒤 로그로 덧씌우는 식이 안전합니다.

Clash를 무료로 내려받아 Kimi·Moonshot·API·콘솔규칙 분류노드 정책을 직접 맞춰 보세요