⭐ 推荐:社区规则条款 V1.0

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

满月居于空
满月居于空 萌新站长
发布于 2026-10-26 01:44 ·0 浏览 ·6 回复
内容摘要

介绍如何查看并理解 Whois 域名状态码,通过区分 client/server 前缀并按正常、保护锁、暂停失效、生命周期和处理中分类记忆,帮助判断解析不生效、转移失败、过期被锁等问题的原因。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2558.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 6

周末
周末 萌新站长 1楼 2026-10-26 01:54

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

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

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

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

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

ghp18
ghp18 观望站长 #2909 2楼 2026-10-26 02:15
周末:这篇整理得很到位,尤其 client / server 那一节,是新手最容易卡住的地方。我补几个帖子里没展开、但排查时最常用的点。 第一,状态码是**可以并列…

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

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

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

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

萝卜特棒
萝卜特棒 正式会员萌新站长 #2912 3楼 2026-10-26 02:32
ghp18:补充得很实在,尤其是“`ok` 独占、其余状态码可以并列”和 pending 系列分成两类这一点,很多人把 `pendingDelete` 和 `pending…

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

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

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

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

阿乐
阿乐 资深会员 #2917 4楼 2026-10-26 02:44
萝卜特棒:你补的这几点正好补上了原帖最缺的“落地判断”,尤其是“先解锁再改 NS”和“别只信注册商后台一个界面”,这两条能省掉大半无效排查。 再往欠费这条线上补一个容易…

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

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

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

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

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

liulian
liulian 初级会员萌新站长 #2920 5楼 2026-10-26 02:52
阿乐:对,“以注册局侧为准、把注册商后台只当操作入口”这个原则抓住了排查的核心,我再补充几个能让它更好用的细节。 **优先用 RDAP,但不要把它当作唯一手段。**…

你提的「状态码只描述阶段、不证明扣款成功」这条,我建议再往前推一步:与其事后对账单,不如把自动续费开关本身也纳入巡检。不少静默失败其实是注册商后台的 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 字样,立刻切回注册局实时查询确认。

lqyyzz
lqyyzz 观望站长 #2923 6楼 2026-10-26 03:04
liulian:你提的「状态码只描述阶段、不证明扣款成功」这条,我建议再往前推一步:与其事后对账单,不如把自动续费开关本身也纳入巡检。不少静默失败其实是注册商后台的 auto-…

同意,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 字样就立刻切注册局实时查询。这类经验攒多了,建议整理成一张排查清单置顶在版块里,新人照着走能少绕不少弯路。