[Bug] zcode.z.ai 证书 SAN 仅含 IP 无 DNS 名：bigmodel OAuth 登录与 coding-plan 接口自 09-17 10:05 起全部失败

[Socrates666]

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

账号 / 登录 · Account / Login（疑似服务端 CDN 证书配置问题，非客户端缺陷）

涉及的 Agent 框架 · Agent framework

不涉及框架 · Not framework-specific（桌面端登录/订阅链路）

严重程度 · Severity

阻塞使用 · Blocking —— OAuth 登录与 coding-plan 订阅接口全部失败；已配置 API key 的模型会话不受影响

复现频率 · Reproducibility

必现 · Always（自 2026-09-17 10:05 起每次必失败）

问题描述 · Description

自 2026-09-17 10:05（UTC+8）起，ZCode 桌面端登录 bigmodel 账号（OAuth）以及 coding-plan 订阅相关接口全部失败。客户端日志统一报 fetch failed，底层错误为：

Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Cert does not contain a DNS name

排查确认：登录链路域名 zcode.z.ai（如 https://zcode.z.ai/api/v1/oauth/token）当前解析到 CDN 边缘节点，而这批节点在 443 端口返回的 TLS 证书 SAN（证书里"这张证书给哪些地址用"的清单）只包含两个 IP 地址，不含任何 DNS 域名，因此所有按域名 zcode.z.ai 校验证书的客户端都会在握手阶段失败。

对照：模型 API 通道 open.bigmodel.cn 证书正常（*.bigmodel.cn），所以 API key 模式的会话完全不受影响，故障仅限登录/订阅链路。像是今天上午服务端有一次证书/CDN 变更把域名证书换成了按 IP 签发的证书。

复现步骤 · Steps to reproduce

1. 桌面端 bigmodel 家族使用 OAuth（coding-plan）模式
2. 触发账号登录或任意订阅信息刷新
3. 请求失败，日志中 oauth.startOAuthWithPolling、coding-plan-subscription.* 等 RPC 全部 fetch failed

任意 HTTPS 客户端直连即可复现（不依赖 ZCode）：

curl -v https://zcode.z.ai/api/v1/oauth/token
# TLS 握手直接失败，HTTP 状态码 000

期望表现 · Expected behavior

OAuth 登录与订阅接口正常返回；zcode.z.ai 各节点出示包含 zcode.z.ai 域名的有效证书。

实际表现 · Actual behavior

TLS 握手阶段失败（证书不含 DNS 名称），登录与全部 coding-plan 订阅接口不可用，从 2026-09-17 10:05 持续至今（12 小时+）。

ZCode 版本 · ZCode version

桌面端 3.12.3（Windows）

设备 / 系统 · Device / OS

Windows 11（10.0.26200）· 中国大陆家宽网络

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

DNS 解析（两个公共 DNS 结果一致，非本机 DNS 污染）：

$ nslookup zcode.z.ai 223.5.5.5
名称:    zcode.z.ai.a1.initaa.com      ← CNAME 指向 CDN 调度域
Addresses:  61.170.79.151 / 61.170.79.127 / 61.170.79.183 / 61.170.79.125
（119.29.29.29 腾讯 DNS 返回相同结果）

问题证书本体（SAN 只有 IP，没有域名）：

$ echo | openssl s_client -connect zcode.z.ai:443 -servername zcode.z.ai | openssl x509 -noout -text
        Subject:                                ← subject 为空
        X509v3 Subject Alternative Name: critical
            IP Address:117.55.193.154, IP Address:2406:CB42:0:2018:0:0:0:2
                                              ^^^ 只有两个 IP，无任何 DNS 名

对照正常通道 open.bigmodel.cn（模型 API 不受影响的原因）：

$ echo | openssl s_client -connect open.bigmodel.cn:443 -servername open.bigmodel.cn | openssl x509 -noout -subject -ext subjectAltName
subject=CN=*.bigmodel.cn
X509v3 Subject Alternative Name:
    DNS:*.bigmodel.cn, DNS:bigmodel.cn

本地已排除的因素：

• hosts 文件无 bigmodel / z.ai 相关条目
• 系统代理关闭（ProxyEnable=0）
• 备用域 zcode.chatglm.site 同期连接超时

客户端日志统计（~/.zcode/v2/logs/）：

日期	ERR_TLS_CERT_ALTNAME_INVALID 出现次数
09-11 ~ 09-16	0
09-17	84（首次 10:05:53）

受影响接口：oauth.startOAuthWithPolling、coding-plan-subscription.getBillingDiscount / getManualClaimPlanPreviews / getStaticTeamProducts / getEnterprisePricing、client-scenes.list。

修复建议：给 zcode.z.ai 的 CDN 边缘节点（initaa.com 调度的 61.170.79.x 及对应 IPv6）重新部署包含 *.z.ai 或 zcode.z.ai DNS SAN 的域名证书；或回滚今天上午的证书变更。

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者看到后会尽快回复你。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will get back to you as soon as we can.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.

[wenxuanz495-eng]

补充证据：移动线路下模型通道 open.bigmodel.cn 也受同一事故影响

楼主提到“open.bigmodel.cn 证书正常，已配置 API key 的模型会话不受影响”——在中国移动宽带上不成立，模型链路也挂了。

环境：Windows 11 (10.0.26200) · ZCode 桌面端 · GLM Coding Plan · 中国移动家宽（含 IPv6）

时间线与主楼一致：2026-09-17 起持续，09-18 01:23 仍在发生。本地日志两天共 67 次 ERR_TLS_CERT_ALTNAME_INVALID（usage-stats 每 5 分钟轮询、coding-plan-subscription.* 全部失败），模型对话请求同样失败：

Turn execution failed
provider_code=MODEL_TLS_VALIDATION_FAILED  retryable=false
request=d0aafa2e-f729-4249-a8f0-dc740c045dd

坏节点与坏证书（与主楼的 zcode.z.ai IP-SAN 证书不是同一张，这里是 ESA 兜底证书）：

# ZCode 主进程实际连接的移动线路边缘节点（netstat 可见 ESTABLISHED）：
$ echo | openssl s_client -connect 120.222.220.156:443 -servername open.bigmodel.cn \
    | openssl x509 -noout -subject -ext subjectAltName
subject: CN=*.certfallback-esa.com            ← 兜底证书，不含 bigmodel.cn
X509v3 SAN: DNS:*.certfallback-esa.com, DNS:certfallback-esa.com
issuer: CN=GlobalSign GCC R46 OV TLS CA 2025
# 120.222.220.63 同样表现

# 对照：阿里云 GA 正常节点（223.5.5.5 / 119.29.29.29 当前解析结果）：
$ echo | openssl s_client -connect 47.104.143.223:443 -servername open.bigmodel.cn \
    | openssl x509 -noout -subject
subject: CN=*.bigmodel.cn                     ← 正确证书 (TrustAsia)

即 open.bigmodel.cn 在移动线路调度到的部分 ESA 节点上也出示了 *.certfallback-esa.com 兜底证书。撞到哪个节点取决于解析/调度路径，因此表现为“时好时坏”；由于连接池一直挂在坏节点上，retryable=false 的报错重试无效，需刷新 DNS / 重启 ZCode 才能恢复。

希望后端同事检查移动线路这批节点（120.222.220.x）的证书配置，或先将其从 open.bigmodel.cn 调度中摘除。