一、总超时从哪来：控制台、文档与 API
从网络侧缩小「总超时」时，建议先把现象拆成三条链路：浏览器里打开月之暗面文档与控制台（常见 platform.moonshot.cn 系页面）、账号、密钥、用量或计费相关请求（若子域与主站分离）、以及程序里直连 api.moonshot.cn 的调用。三者都可能是 HTTPS，但实际 SNI、路径与保持连接的方式并不相同：控制台要加载大量脚本与内嵌资源，API 客户端则长连接、流式输出、重试与连接池，往往最先在首包延迟、TLS 与中间盒上暴露问题。若 Clash 规则分流在浏览器里漏了某个子域，你会看到白屏剩一半、按钮灰掉或一直读秒；若仅有 Python、Node 或服务器上报 timeout、而本机网页正常，更常见是终端未走系统代理、Docker 桥接旁路，或 api.moonshot.cn 没有和开放平台落在同一策略组与相近节点，从而出现「人眼觉得官网好好的，服务却红一片」的割裂感。
企业网络、校园网或出口审计设备，还可能叠加 HTTPS 检查、固定内网 DNS 或按目的国分流，让「小地球图标已亮、部分 SNI 仍走直连或走了意料之外的下一跳」难以直觉判断。在动手改大段 YAML 前，把问题先归类为仅网页、仅 API / CLI 还是全不可用，再选择补域名、调进程级环境变量、或加强 TUN 覆盖，能避免把别家厂商现成的规则做关键字替换后仍对不上 Kimi 实际主机名。若你跑了批量压测，也要留意单节点连接数与带宽是否先把出口打满，这类症状与单用户偶尔点一次控制台、看起来完全不同。更多「策略组与测速总乱跳」的调参，可结合 《url-test 与容差》 一起阅读。
DIRECT 还是 PROXY。若已走代理仍 TLS 握手失败，多怀疑节点质量与对端线路，而不是在规则里继续堆 KEYWORD 扩大误伤面。
二、与 DeepSeek、智谱、OpenAI：主机名不要混抄
站内 《DeepSeek 规则分流》 围绕 deepseek.com 与 api.deepseek.com；《智谱 Z.ai》 覆盖 open.bigmodel.cn、api.z.ai 等；《OpenAI API》 则对应 openai.com、api.openai.com 等。上述厂商与 月之暗面 Kimi 使用彼此独立的域名与证书体系，没有可互换的「大模型通配后缀」。把 DEEPSEEK 或 OPENAI 规则整段改几个关键字就当作 Moonshot 用，往往仍漏掉真实请求里的静态域、鉴权回跳、统计或新上线的前台子域。本文刻意与那几篇「模型 API + Clash」并排放，方便你在多模型同机部署时，按「一家厂商一策略组、一份可审计的抓包附注」维护，而不是一个笼统的「海外大模型」组里全体混跑。
多模型联调时，独立组名（如 MOONSHOT 或 KIMI_API）还能减少同一会话出口 IP 在 url-test 下频繁变化带来的额外不稳定性。若你同时用 OpenAI 兼容客户端把 base_url 指到 api.moonshot.cn，请仍按月之暗面主机名建规则，而不是沿用 OpenAI 专文里的主机名。团队共享配置时，在 YAML 中保留明确注释，注明更新日期与抓包范围，能显著降低以后合并订阅时的回归成本。
| 对比项 | 站内互补专文 | Kimi / Moonshot（本文） |
|---|---|---|
| 典型控制台与文档 | 各文对应厂商控制台与文档域，见单篇 | platform.moonshot.cn 及抓包中出现的子域（以当时页面为准） |
| API 基主机名 | 如 api.deepseek.com、智谱/ OpenAI 各自文档域 |
常见为 api.moonshot.cn；路径常以 /v1 为前缀（以官方当前文档为准） |
| 与本文的边界 | 各篇独立主机名表，互不完全重叠 | 不重复展开 DeepSeek / 智谱 / OpenAI 细节，只锁 Moonshot 系 |
| 系列一致写法 | 规则顺序 + 策略组 + 节点与 DNS 分层 | 同样思路，方便垂直检索「某家模型 API + Clash」 |
维护共享仓库时，更新在线规则集后记得复查：本地为 Kimi 写的细粒度规则是否仍排在 GEOIP 与 MATCH 之前，避免「肉眼看配置齐全、日志里却是直连或走了默认出口」的错位。
三、月之暗面常见主机名（示例）
控制台与 API 会随产品迭代增改域或拆子域，请勿只依赖过期的二手清单。实用做法仍是：在浏览器 Network 中按 Domain 聚类，记录与登录、密钥管理、流式输出、用量统计与静态资源强相关且多次出现的名称；在命令行或后端场景，用 curl -v、服务日志或 mtr 观察实际 SNI。下表是常见形态示例，用于你编写 DOMAIN-SUFFIX 时对齐思路，实施前务必以官方当前文档与你在目标环境的抓包为准。若你同时看到 platform.kimi.com 等国际站文档，也应在确认业务确实访问后再写入规则，避免凭标题猜测补域。
- 开放平台与文档：
platform.moonshot.cn及其在加载过程中出现的子域，用于查文档、开控制台、管理 API 密钥等。 - API 调用：与官方示例一致的
api.moonshot.cn；在网关或反向代理后转发时，确认出站到公网的一跳上主机名仍被 Clash 命中，而不是只代理到内网前置机就结束。 - 静态与前端资源：大版本升级时，脚本与样式可能落在额外主机名上；只匹配地址栏里一个域，容易留下「壳子代理了、子请求直连失败」的半屏问题。
- 与登录态相关的跳转：邮件、单点或活动页回跳时，看最终落地主机名是否仍在同一策略组，否则会出现「偶发能登、刷新又要求重新验证」的体验抖动。
- 与 IDE / 插件：部分工具单独配置代理或证书，和系统代理、TUN 不叠好时，会表现为单通道异常，需要结合进程或环境隔离排查。
在已确认业务相关的前提下，优先用 DOMAIN-SUFFIX 收敛到可验证的后缀，慎用过于宽泛的 DOMAIN-KEYWORD，以免误把无关流量卷进 代理。与 Cursor、GitHub 等开发工具向规则同仓时，保持顺序与注释可读，能减轻后续合订冲突。若 TLS 日志里频繁出现握手阶段卡住，可交叉阅读 《TLS 握手超时》。
四、Clash 规则分流：锁进 MOONSHOT 策略组
规则分流依旧遵循顺序优先：业务向更具体的条目在前，国内直连、私有网段与运营商优化在后，MATCH 等大规则兜底。在通用订阅规则之后，为 月之暗面单独增加指向自定义策略组（如 MOONSHOT）的条目，并保证 控制台页与 api.moonshot.cn 同组，避免「能改密钥、调不通推理」的奇怪组合。下面是一则示意片段，组名、域名行均须以你的抓包与策略结构为准。
# Example only — replace group names and domains after your capture
rules:
- DOMAIN-SUFFIX,platform.moonshot.cn,MOONSHOT
- DOMAIN-SUFFIX,moonshot.cn,MOONSHOT
- DOMAIN-SUFFIX,api.moonshot.cn,MOONSHOT
- GEOIP,CN,DIRECT
- MATCH,PROXY收窄与维护
上例用 moonshot.cn 后缀覆盖常见子域，若你希望尽量收窄，可改为只写已核实的前缀，并在发现新子域时再追加一行；若更看重可维护性，可单独维护 rule-providers 或「本地 rules 附注段」，在官方文档有变更时只改这一处。不要对不明域名做批量 REJECT；也注意在线规则集与本地精细规则的相对顺序。使用 Mihomo / Meta 等扩展能力时，语法仍以你在用客户端的文档为最终依据。
在内网能直连公网、而出境需要代理的混合环境，有时会出现「按道理应 DIRECT 却更慢」与「必须 PROXY 才快」的反差，这往往与对端对特定路径的选路有关；此时以连接日志和延迟表现为准，而不是只凭常识写死 GEOIP,CN。任何路由决策仍须符合当地法规与服务商政策。
五、节点选择与流式、长连接
在规则已正确把流量送进策略组后，节点选择决定吞吐与流式体验。Kimi 的开放 API 与兼容 OpenAI 的长输出场景，对高延迟、严重抖动与单连接长时间占用都敏感：一旦节点在晚高峰频繁丢包，客户端往往表现为读秒、直至总超时。实操上建议：
- 更重视丢包与抖动，而非只看最低 ping：短连接测速好看、长流式一跑就断的节点，对推理并不友好。
- 为
MOONSHOT单独做 fallback 或更温和的 url-test：过灵敏的自动切换会在同一工作会话中频繁换出口，易放大不稳定性，详见 《url-test 与容差》。 - 在合规前提下，保持同一工作时段出口地域相对稳定，减少网页控制台与 API 工具观测路径不一致时的心理噪音。
- 批量任务与日常浏览器分流：大批量调用尽量不要与全站视频下载、超大对象同步抢同一节点带宽；必要时为推理侧单独指定子策略组，降低互相干扰。
若「同节点访问其他服务正常，只 api.moonshot.cn 异常」，可能是对端在特定线路上有限速或选路，可尝试更换干净出口或联系你的订阅方；只反复改规则而不看日志，很难收敛问题。对 UDP 等选项的开关，请以你当前内核与客户端文档为准，避免为「玄学加速」而全局乱开。
六、DNS、Fake-IP 与终端 / TUN
很多「规则写了走代理、现象仍像直连失败」来自 DNS 解析与 Fake-IP 链路与模式不一致。建议依序核对：
- Clash 内 DNS、系统 DNS 与上游是否一致；企业内网或路由器若劫持 DoH/DoT，会放大解析偏差。
- sniff、SNI 与 TUN/系统代理是否与当前使用方式匹配，见你所用版本文档及 本站文档入口。
- IPv6 路径是否与代理不同步，若偶发「解析到了 v6、实际却走了另一条直连」，可暂关 v6 做 A/B 对照（仅排障，勿作为长期唯一手段）。
- 终端、CI、Docker 与 IDE 经常不继承系统代理，于是出现「浏览器里控制台正常、服务里 API 全超时」。请对照 《终端代理与环境变量》，必要时用 TUN 让进程无感走同一策略。
排障时先锁定日志里该主机名是 DIRECT 还是 PROXY，再动 DNS 与节点，避免三处同时大改。若 TUN 打开后本机其他应用异常，可参考 《TUN 与 Windows 排查》。若高度怀疑 Fake-IP 与少数域冲突，再读 《fake-ip 与 DNS 排查》 做受控实验。
七、自检对照表
下表用现象对应优先检查项，帮助你在几分钟内把范围从「全栈玄学」收束到可验证的几步：
| 现象 | 建议优先检查 |
|---|---|
| 控制台或文档白屏、半拉子加载 | 失败请求的 主机名；是否只代理了主域、漏了子域或第三方静态域；节点选择是否高延迟 |
仅 api.moonshot.cn / SDK 总超时，网页尚可 |
运行环境是否未走 Clash；MOONSHOT 是否命中；TUN 是否覆盖 |
| 规则显示 PROXY 仍 TLS 或握手失败 | Fake-IP 与 SNI、DNS；节点到对端是否被限；本机安全软件是否截 TLS |
| 晚高峰才明显，低峰又恢复 | 单节点拥塞、并发、与其他应用抢带宽；尝试 fallback 或换池 |
与 局域网内共享代理 时，请确保旁路设备上的连接在代理机一侧也命中为 Kimi / Moonshot 准备的规则，避免「本机可测、他机不行」的假象。
八、小结
要把 Kimi 与 月之暗面 开放平台、API 在 Clash 下跑得更稳，可以归纳为三件事：用抓包与文档锁定 platform.moonshot.cn、api.moonshot.cn 等 Moonshot 系主机名，并把它们与控制台相关资源一起放进同一套策略组；在组内做节点选择，优先低抖动与可预期的出口，再按需调节 url-test；分层自查 DNS、Fake-IP、TUN/系统代理与终端环境，把「只网页、只 API 或全链路」分清。与站内 DeepSeek、智谱、OpenAI 专文一起阅读时，可形成互补的「国内常见模型 API + Clash」排障体系，而无需在规则里用别的厂商的域名充数。
相比只提供单一路径的轻量小工具，Clash 在规则、内核与图形客户端上生态完整，适合既要照顾浏览器、又要照顾脚本与后端的开发者。需要安装或更换客户端时，可优先从本站 下载页 获取，再为 月之暗面单独维护一小段可注释、可回滚的规则分流与节点策略，把「总超时」里可被你掌控的网络因素压到最低。