Whois查询结果中的域名状态码分别代表什么意思？

这篇整理得很到位，尤其 client / server 那一节，是新手最容易卡住的地方。我补几个帖子里没展开、但排查时最常用的点。

第一，状态码是可以并列出现多个的，只有 ok 是独占状态：一旦出现 ok 就不会再有其他状态。实际看到的往往是 clientTransferProhibited + clientUpdateProhibited 这类组合，这是注册商默认的安全锁（比如某云注册后自动上锁），属于正常现象，不影响解析，别一看锁就慌。

第二，你帖子里截断的 pending 系列，实际含义差别很大：pendingCreate、pendingTransfer、pendingRenew、pendingUpdate 是“操作已提交、等待注册局处理”的短暂中间状态，通常几小时内消失；而 pendingDelete 完全不是一个概念，它是赎回期走完后的倒计时，约 5 天，此时任何续费操作都无效。这两个别混。

第三，实战排查顺序我给一个：网站打不开 → 先看有没有 clientHold/serverHold（有就直接找注册商，serverHold 多半是实名或违规，人工处理）→ 没有就看 inactive（查 DNS 服务器是否填写、NS 是否有效）→ 都正常再查解析记录本身。域名转移失败 → 九成是 clientTransferProhibited 没关，另一成是刚转入不满 60 天还在 transferPeriod 里。

提醒一个坑：redemptionPeriod 的“赎回费”通常远高于正常续费价（几十到几百元不等，看后缀和注册商），而且不是所有注册商都提供赎回入口，别等过期一个月才想起来。

补充得很实在，尤其是“ok 独占、其余状态码可以并列”和 pending 系列分成两类这一点，很多人把 pendingDelete 和 pendingTransfer 混为一谈，结果白白错过赎回窗口。

顺着你说的排查顺序，我再加两个前置动作：一是看域名本身是否已过期或欠费。不少 clientHold 是欠费、实名信息过期，或备案与实名不一致触发的，不是违规处罚；让注册商解除处罚并不会恢复解析，关键是把钱补上或把实名补全。二是 clientUpdateProhibited 这个锁会让改 DNS 不生效。遇到“解析改了没反应”，别先怀疑解析商，要回注册商后台看这个锁在不在；在的话先解锁，再改 NS。

serverHold 的处置时间也说一句：.cn 这类因实名审核未通过被注册局 hold 的，提交材料后一般不是立刻恢复，常见要等一两个工作日；这期间 NS 填得再正确也不会生效，排查时直接按“等审核”处理，不必反复改解析。

另外，pendingDelete 释放后能否抢到，取决于后缀的删除时间规则和各家的抢注队列，不是准点刷新就能拿到。想接盘老域名的，提前在目标注册商挂好预订；域名的市场价值也要先评估，别为了一个普通域名付抢注服务费。最后提醒：赎回期的判断以注册局状态为准，注册商后台显示“可续费”并不代表还在正常续费期，这两个界面经常不同步，别只信其中一个。

你补的这几点正好补上了原帖最缺的“落地判断”，尤其是“先解锁再改 NS”和“别只信注册商后台一个界面”，这两条能省掉大半无效排查。

再往欠费这条线上补一个容易踩的：clientRenewProhibited 在的时候，注册商后台的续费按钮往往点不动或直接报错，很多人第一反应是“是不是欠费了、是不是账号有问题”，其实是这条锁在拦。反过来，autoRenewPeriod 里如果余额不足、绑定的支付方式失效，自动续费会静默失败，状态还挂着、看着像正常续费期，实际没续上，等到进 redemptionPeriod 就来不及了。这两种情况方向完全相反，建议先看状态码再动手充值，别靠猜。

关于后台不同步，实操上我会把注册商后台只当“操作入口”，状态判断一律以注册局侧为准：能装 whois 工具就直接查注册局 whois，或者走 RDAP 拿结构化结果，批量核域名也方便；.cn 直接查 CNNIC 的 whois 输出。两边不一致时，按注册局侧的时间线规划赎回和续费动作。

最后一句延伸：抢注那部分提醒得很对，但预算别只算抢注服务费，成交后的续费价、转入成本、甚至原持有人可能还在赎回期内的竞价溢价都要一起算，普通老域名大概率不划算。

对，“以注册局侧为准、把注册商后台只当操作入口”这个原则抓住了排查的核心，我再补充几个能让它更好用的细节。

优先用 RDAP，但不要把它当作唯一手段。 RDAP 返回结构化的 JSON，其中 events 直接给出注册、到期、最后更新时间戳，判断赎回期和宽限期比解析 whois 文本更可靠，也能避免因不同注册商的文本格式差异而出错。不过，并非所有 ccTLD 都提供 RDAP endpoint，.cn 仍然要回到 CNNIC 的 whois 查询，因此脚本里最好让两种方式互为后备：RDAP 拿不到结果时，自动改用 whois 查询。另外，RDAP 有速率限制，批量核域名时，比起逐个串行请求，带上间隔更稳定。

判断 autoRenewPeriod 是否真正续费成功，要去看账单，而不是看状态码。 状态码只说明域名处于自动续费宽限期这个阶段，并不能证明扣款已经完成。实际操作中，我会把续费订单记录和支付流水与状态码对照：如果状态码是 autoRenewPeriod，但查不到对应订单，基本可以认定是静默失败，需要手动重新续费。同样的思路也适用于 clientRenewProhibited 解锁后的续费：解锁只说明限制解除，并不等于续费已经生效，操作完成后还要再查一次订单。

抢注这笔预算，建议加入“转入锁定期”这一项。 抢到域名后，通常要等 60 天的 transferPeriod 才能转出，所以第一年的实际成本必须按原注册商的续费价计算，不能按你打算迁入的那家注册商计算。这一点常常被忽略，最后算下来，转到便宜注册商之前的那一年反而成了最贵的一年。

还有一个容易出错的地方：不要拿第三方 Whois 站的缓存结果去判断赎回期，那类页面的缓存时间可能是几小时，甚至几天，redemptionPeriod 只剩几天时，很容易因此判断错误，还是要以注册局的实时输出为准。

你提的「状态码只描述阶段、不证明扣款成功」这条，我建议再往前推一步：与其事后对账单，不如把自动续费开关本身也纳入巡检。不少静默失败其实是注册商后台的 auto-renew 被关掉了——换支付方式、做域名转移、促销套餐到期，都可能把这个开关重置。这种情况下状态码压根不会进 autoRenewPeriod，光看状态是查不出来的，只能定期进后台确认开关是开的、绑的卡没过期。

RDAP 那两个细节我赞同，补一个实现上的坑：events 里的 eventAction 命名各注册局不统一，expiration、registrar expiration、expiration date 几种写法都见过，脚本里别按数组顺序取，要按关键词匹配；而且 gTLD 常见同时返回注册局和注册商两个到期时间，判断赎回期要用注册局那条，registrar expiration 有时会晚一天，按它算容易误判还剩几天。

转入锁定期那句得加个限定：60 天是 ICANN 对 gTLD 的通用规则，ccTLD 各自为政，.cn 的转入规则和锁定期就跟 gTLD 不完全一样，算预算前先查对应注册局的政策，别一刀切按 60 天套。

缓存这条我再补一个观察：第三方站不光缓存时间长，有的还会把 redemptionPeriod 直接显示成「已过期」、把 pendingDelete 显示成「可注册」，这种语义偏差比时间偏差更误导人。所以第三方站我只用来做初筛，状态里一出现 hold 或 redemption 字样，立刻切回注册局实时查询确认。

同意，auto-renew 开关纳入巡检这个思路比事后对账更靠前——它把静默失败挡在扣款之前，属于预防而不是补救。

具体怎么落地，我的做法是分层：有 API 的注册商直接拉域名列表跑定时任务，把到期时间、锁状态、auto-renew 标记一起比对，不一致就告警；没有 API 的，RDAP 只暴露到期时间和 status，不暴露开关，那就退一步用“续费成功确认邮件 + 到期前 60/30/7 天提醒”兜底——扣款成功注册商基本都会发确认信，到期日过了还没收到，就当没续上，这个判断比看状态码可靠。另外补一个你提到的场景：域名转入完成后，不少注册商会把 auto-renew 默认置为关闭，所以转移成功后的第一件事应该是去新注册商把开关打开，而不是等它自己续。

eventAction 的匹配我一般做关键词归一化，比如用 /expir/i 去匹配，同时把命中 registrar 的那条单独拎出来排掉，不要按顺序取最后一条或第一条。顺带说一句，RDAP 里的 status 数组和 whois 的 Domain Status 是对应的，client/server 前缀一样在，两边各取一次做交叉校验，能提前发现界面不同步的问题。

60 天那条我同意别一刀切，再加一点区分：gTLD 转移后 60 天内限制的是再次转出，如果没挂 clientUpdateProhibited，改 DNS 是允许的，这两件事经常被混成一条。

第三方站还有种更隐蔽的偏差——模板不认识的 status 会落回默认值，把 clientHold 直接显示成“正常”。所以你的阈值定得对：出现 hold、redemption、pending 字样就立刻切注册局实时查询。这类经验攒多了，建议整理成一张排查清单置顶在版块里，新人照着走能少绕不少弯路。

层次分明的巡检方案我基本照搬，但邮件兜底那条建议再加一层对账，别把续费确认全交给收件箱。

隐患在于，静默失败恰恰常常没有邮件。不少注册商只在续费成功时发确认信，扣款失败只在后台站内消息里提示一行，甚至什么都不发；再加上发信域名被误判进垃圾箱，单靠邮件就风险很大。更稳的做法是固定每月做一次：从注册商账单或订单页导出一份（没有 API 就手动导 CSV），用到期日加订单号对账，邮件只当辅助信号。

eventAction 我是先 toLowerCase 再匹配，正则放宽到 /expir|expiry|validity/i，ccTLD 那几种写法都能覆盖；排 registrar 那条时顺手把 last changed、registration 也归类掉，别让它们混进到期判断。交叉校验补一个时间维度：注册局 whois 本身也有缓存和限速，两边不一致时先比时间戳取新的那条，不必无条件相信注册局侧。

60 天那条我同意再给个操作顺序：确认没挂 clientUpdateProhibited 之后，先把新 DNS 的解析记录建好、原 TTL 提前降下来再改 NS，否则切换窗口站点会挂，证书自动续签也可能跟着失败。

排查清单我赞成置顶，字段不用多：域名、注册局到期、注册商到期、status 数组、auto-renew 开关、支付方式有效期、上次核对时间，这七列就够新人跑一遍。

最后一个坑：转入时“含一年续费”是从原到期日顺延，不是重新计一年，算预算和排到期提醒时别按自然年套，不然容易差出整年。

这套「对账 + 归一化 + 时间戳」的思路我认同，只补三处细节，都属于容易多算一步、漏掉就会出错的地方。

对账别只用到期日加订单号，再加一列扣款凭证号或交易流水号。原因很实际：续费失败时注册商往往照样生成订单，状态是未支付或已取消，光按订单号匹配，很容易把失败单当成成功单；交易流水号只有真正扣款才有，这一列能把静默失败直接筛出来。

时间戳那条要补时区。RDAP 的 events 是 UTC 带 Z 的，whois 文本里不少注册局输出的是本地时间，直接比大小会差几个小时，遇到临近赎回期的域名正好能误判一天。比较前统一转 UTC，再取较新的那条。

改 NS 的操作顺序再拆细一点：降 TTL 要提前至少一个原 TTL 周期，原来 86400 就提前 48 小时降，只提前一天降不下来。另外改 NS 前先确认 DS 记录，如果开了 DNSSEC，换 DNS 服务商必须同步换 DS，否则新旧解析都不通，比单纯切 NS 挂站更难排查。

七列清单建议加「DNSSEC 状态」和「扣款凭证号」，凑九列，一轮跑完不用回头补。

转入顺延那条我同意，但要加个前提：gTLD 转移加一年是在域名处于正常期时成立，如果转入前已经过期进入赎回期，年数算法和正常顺延不一样，算预算前先确认当前到期日还在不在正常期。

三条都补在关键处，我完全认同，尤其扣款凭证号那条，它是把「对账」从形式变成实质的关键一列。

顺着再补几个实际操作中容易出错的点。流水号匹配别只按号对号，要按「域名 + 金额 + 时间窗」三元组匹配：一是多域名常合并成一张发票扣款，一笔流水对多个域名；二是信用卡和 PayPal 走的是预授权+请款两笔，注册商后台显示的和账单上的是两个号；三是转入费、赎回费和续费金额不同，光有号对不上金额照样判断不出是不是这笔续上了。

时区那块再具体一点：RDAP 的 Z 好处理，麻烦的是部分注册局输出带偏移量的本地时间（+08:00 这种），别用字符串截取前 19 位，直接交给能识别偏移的解析器，whois 文本里 last updated、changed 这类字段很多干脆不带时区标记，那些字段就别拿来参与先后比较，只作参考。

DNSSEC 换 DS 我再展开一步：提交新 DS 前先确认摘要类型（现在基本是 SHA-256，即 digest type 2），新旧 DS 可以短暂共存，正确顺序是先加新 DS、等旧 DS 的 TTL 过去、再删旧 DS，全程用 dnsviz 或 dig +dnssec 盯着，比一次性替换安全得多。另外降 TTL 别忘了 NS 记录本身也有 TTL，很多人只降了 A 记录。

九列我认可，够用，剩下情况记备注。赎回期那条完全对，赎回续费一般包含赎回费，实际延长到哪天以操作后 whois 的 expiration 为准，不要用计算器算，各注册局口径真的不一样。

三元组匹配那层我建议给金额加个容差，不然容易被汇率和税费误伤——信用卡跨境扣款带货币转换费，账单金额和注册商后台显示的可能差几毛到几块，硬做等值匹配会把成功单判成失败，按原始币种金额比、或者给个 2% 左右的容差更稳。另外预授权和请款两笔里只认请款（capture）那笔，预授权号是占位用的，别拿它去对账。

NS 的 TTL 还能再往下挖一层：你降的是自己权威侧那套 SOA/A 的 TTL，但父区委派里那组 NS 的 TTL 在注册局侧，.com 常见是 172800 秒，正好两天，这部分谁也改不了。所以「提前 48 小时」对 .com 刚好卡线甚至不够，实际按提前 3–5 天排；改之前先用 dig NS 域名 @a.gtld-servers.net 这类方式查父区委派，确认里面已经是新 NS、再去做解析记录切换，顺序反了会出现新旧都不通的窗口。

赎回那条再补一句：操作完别立刻查 whois，注册局侧同步有延迟，看到旧值很正常，隔几小时再看；中间千万别重复提交赎回，容易重复扣费。到期日以最终 expiration 字段为准这点我完全同意，各注册局口径确实不一样。

容差那条我同意加，但建议用绝对额而不是百分比：小额续费按 2% 算只有几毛，反而卡不住跨境货币转换费的常见区间，直接给 1–2 美元或等值本币的绝对容差更实用，同时保留原始币种金额做第一比对，换算后金额只作辅助。

预授权只认 capture 这点没问题，再补一条：退款和冲正（reversal）要单独标一列状态，很多注册商是先扣后返，账单上两笔都在，如果只按金额窗口匹配，下个月对账很容易把这笔已经退回的款当成有效续费，等到期才发现没续上。

你挖的父区委派 TTL 是真关键，比我前面说的提前降 TTL 更靠底层。实际操作里还有一层：父区改了 NS 之后，各地递归解析器手里的旧记录要等缓存自然过期，所以真实生效窗口是 max(父区 TTL, 递归剩余缓存)，.com 按 3–5 天排是对的，落到跨周末或节假日还要再往后放。改之前用 dig +trace 走一遍，能直观看到卡在哪一层的缓存上，比只看父区单点查询更接近用户实际会遇到的解析路径。

赎回那条补一个操作纪律：提交前把最终到期日和费用截图存进工单，赎回单多数注册商不可撤销，重复提交基本等于白扣一次；查状态别只看 whois 文本，RDAP 的 events 里 expiration 更新通常更快，两边都看再决定要不要再催。最常见的坑是赶上长假前到期，赎回工单排到 pendingDelete 那 5 天里还没处理完，直接失去恢复机会，发现过期第一件事就是确认还剩几天。

绝对额容差这条我服气，2% 在小额单上确实形同虚设，跨境货币转换费本来就是固定的几毛到一两美元区间，直接给 1–2 美元等值本币的绝对额更贴合实际情况，原始币种金额作为第一比对、换算后金额只作辅助，我也认同。

退款列我建议记带符号的金额而不是只记状态，类型标成 capture / refund / reversal / chargeback，月度直接求和看净额。原因是有部分退款的情况，比如赎回单只退赎回费不退年费，或者转入失败只退转入费，只有状态位的话金额对不上就没法判断；另外 chargeback 要单独标，它跟注册商主动退款性质不同，前者往往还伴随账户风控。

dig +trace 那条我再提一句：它走的是你本机当前的递归出口，不同地区、不同运营商缓存状态完全不一样，建议再用 @8.8.8.8、@1.1.1.1 这种外部解析器交叉查一次，或者上多节点检测工具，比单机 trace 更接近真实用户路径。

长假前到期这条是真正的重灾区，建议单独拉一份 45 天内到期的域名清单，顺手核对绑定的付款方式有效期——卡过期导致的续费静默失败比对账漏单更常见，而且往往一批域名一起中招。pendingDelete 阶段是注册局按固定批次执行的，进了这个状态基本没有商量空间，所以倒推的时间点是赎回截止日而不是到期日。

最后一句提醒：净额对账记得把跨月的退款单独挂账，别让它自动冲抵下个月的续费额。