一、为什么域名这件事总在最后一刻出问题

服务器、代码、数据库都在自己的掌控里，出问题当场就能看到日志。域名不是。它是一个托管在第三方那里的、有明确到期时间的、出问题时最先影响全站的资产。而且它的故障形态很特殊：解析记录被改动时，你本地可能因为缓存还完全正常；域名过期时，站点不是变慢而是彻底打不开；注册商那边的账户出问题时，你连「改一条解析」都做不到。

我见过最典型的场景是：域名到期当天下午站点打不开，因为注册邮箱是一个早已不用的 QQ 邮箱，找回账号花了两天，两天的流量和收录直接归零。这类事故的技术含量很低，但破坏力极大，而且完全可以通过流程避免。下面是我给自己定的一套年度域名检查清单，按重要性排序。

二、先把资产清单建起来：一张表管住所有域名

所有域名问题都源于「不知道自己有哪些域名」。这件事听起来夸张，但对同时做过七八个站的人来说非常真实：有的是主站，有的是备用跳转，有的是早年注册的工具域名，还有的是从别人手里接过来的老站。任何一个到期没续上，都可能引发一片 404。

建一张表，字段至少包括：域名、注册商、到期日、DNS 托管在哪、是否开启自动续费、付款方式绑定的卡号或账户、用途说明、关联站点。做完之后贴到自己的笔记里，每季度核对一次。这张表的价值在于，它让「到期」从一件随机发生的事，变成一件有记录、有提前量的事。

一个具体建议：清单里给每个域名标出「如果这个域名丢了，会影响什么」。影响全站的排在最高优先级，只做跳转的放低一档。优先级决定了你愿意为它花多少钱续费、花多少精力保护。

三、到期日：三道防线，而不是一道

只靠「我记得续费」是最不可靠的防线，只靠「注册商自动续费」也不够——自动续费会因为卡过期、账户被风控、余额不足而静默失败。我的做法是三道并行：

第一道，全部打开自动续费，并且确认绑定的付款方式在未来一年内不会过期。换卡之后要第一时间回注册商那边更新，很多人换卡后忘了更新，第二年才发现续费失败。

第二道，自己算一个提前量。在日历里设置两个提醒：到期前 60 天和到期前 15 天。60 天是处理期（足够换注册商、换付款方式或做转移），15 天是最后确认期。

第三道，外部检查。用一个脚本每天查一次域名的到期时间，剩余天数小于 30 就发消息。这一路的意义在于它不依赖你记得，也不依赖注册商的邮件能送达。

要特别注意注册商的续费提醒邮件可能进入垃圾箱。多数注册商会在到期前几十天发多封邮件，如果这些邮件从来没出现在你的收件箱里，那说明收费邮箱规则把它拦了——这件事本身就是一个风险信号，必须解决。

四、注册商与 DNS 托管：两条腿都要能走

域名的生命周期分成两段：注册（在注册商）和解析（在 DNS 服务商）。这两段可以分开，也经常被分开，但很多人只关注其中一半。

注册商这一侧要确认四件事：账户能登录（邮箱和手机号都是自己现在能用的）、账户开启了两步验证、域名没有开启「转移锁」以外的额外限制、账单地址和付款方式正确。账户安全比大多数人想象的重要，域名被转走通常是从邮箱被攻破开始的。

DNS 这一侧要确认：托管在哪家、有几个人有权限、是否开启了双因素认证、是否有备份的解析记录导出。解析记录导出这件事非常少人做，但一旦 DNS 服务商出问题或者账户被锁定，你能在十分钟内把站点切到备用解析的前提，就是手里有一份完整的记录。

一个实用习惯：每季度把完整的解析记录导出一份，存到自己控制的另一个地方。这份文件包含所有 A、CNAME、MX、TXT 记录，是最有价值的域名资产快照，比截图强得多。

五、解析记录本身也要体检

到期和账户是「资产层面」的风险，解析记录是「配置层面」的风险，两者都要看。

体检项目包括：A 记录是否还指向正确的 IP（换过服务器后留着的旧记录是最常见的遗留问题）；泛解析是否无意中开着（会让不存在的子域名都解析到主站，既浪费资源也可能造成重复内容）；MX 和 TXT 记录是否还有效（尤其是做邮箱验证和第三方服务的验证记录，清理时容易误删仍在使用的条目）；TTL 设置是否合理（迁移前调小到几百秒，稳定后再调回一小时以上）。

还有一个很多人忽略的点：域名出现在证书、备案、第三方服务白名单里的位置。换解析很方便，但如果某个第三方服务里登记了回调域名，解析一改它们就全挂。所以改动解析之前，先想一遍有哪些地方依赖这个域名。

六、域名转移：为什么要在到期前做

如果决定换注册商，时机非常关键。绝大多数注册商的规则是：域名到期后的若干天内可以续费，但进入赎回期后费用会高出一个数量级，而且转移通常在到期前后的窗口内会被拒绝。

正确的节奏是：到期前 60 天开始准备，拿到转移码（Auth Code），确认域名没有转移锁，域名注册满 60 天（新注册的域名常有这个限制），然后发起转移。转移过程一般需要三到七天，这期间解析不受影响，但不要安排在重要的时间点。

转移完成之后要做的检查：确认到期时间已经延长、确认 DNS 记录没有被重置、确认原来的自动续费已经关掉（避免两边重复扣费）、更新资产清单里的注册商字段。

七、一个每天跑一次的到期检查脚本

不需要复杂的工具，一次简单的查询加一个判断就够。查询方式有两种：用 whois 命令取到期时间字段，或者调用注册商的 API。前者更通用，后者更准确，个人站用 whois 就够。

#!/bin/bash
# 用法：把要检查的域名写进 DOMAINS，每天由 cron 跑一次
DOMAINS="example.com example.net"
WARN=30
for d in $DOMAINS; do
  exp=$(whois $d 2>/dev/null | grep -iE 'Registry Expiry Date|Expiration Date|Expiry Date' | head -1 | grep -oE '[0-9]{4}-[0-9]{2}-[0-9]{2}')
  [ -z "$exp" ] && echo "WARN $d 到期时间解析失败" && continue
  days=$(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 ))
  echo "$d 到期 $exp 剩余 $days 天"
  [ "$days" -lt "$WARN" ] && echo "ALERT $d 剩余 $days 天，请立刻处理"
done

几个实现上的注意点：不同后缀的 whois 输出字段名不一样，比如有的叫 Registry Expiry Date，有的叫 Expiration Date，所以要用 or 的方式匹配多个；有些注册商的 whois 会限制查询频率，一天一次完全没问题，但不要写成循环高频查询；whois 查询失败的时候必须显式报警，否则「查不到」会被静默当成「没问题」，这是这类脚本最危险的失败模式。

脚本产出的「剩余天数」还应该记录下来，一个月看一次趋势。如果某个域名的数字突然变大，说明有人替你续费了（可能是自动续费生效）；如果突然变小，说明之前的续费没有成功。

八、把检查装进流程，而不是记在脑子里

清单和脚本的价值在于它们不依赖记忆。我的做法是把它拆成三个不同频率的动作：

每天：脚本自动跑，只看有没有告警。这一步是零成本的，因为完全自动。

每季度：手动做一次资产清单核对，确认所有域名都在表里、账户都能登录、解析记录导出一次存好。

每半年：做一次「最坏情况」演练。假设主域名明天就丢了，我需要多长时间恢复？恢复需要哪些信息？这些信息现在在哪？演练的重点不是真的操作，而是确认信息是否齐全、是否只有你一个人知道。

最后这一点经常被忽略。如果所有账号密码、注册信息都只在自己脑子里，那么你出差、生病或者手机丢了的那些天，站点就处在无人可救的状态。把关键信息整理成一份加密的说明，交给一个信任的人保管，是这种单人站点最实际的「应急预案」。

九、小结

域名没有性能问题，它只有到期、账户和配置三类风险，而这三类都可以用流程覆盖：一张资产表管住知道，三道提醒管住到期，季度核对管住账户与解析，一个每天跑的脚本管住遗漏。真正要防的不是「忘记续费」这个动作，而是「以为有自动续费所以不用管」这个心态。