为什么我现在不再直接记 IP：给节点套个域名之后，排障思路变了

前一阵子折腾节点，最让我头疼的不是配置本身，而是 IP 一变，之前记下来的东西全得跟着改。客户端里写的是 IP，笔记里记的也是 IP，换一次 IP 就要翻一圈去改，改漏一个地方，晚上就得爬起来排障。后来我换了个思路：不再直接记 IP，中间加一层域名，客户端和笔记里都只写域名，IP 变了只改域名解析那一处。这个改动看起来很小，实际用下来，省的心远比想象中多。

先说最直接的好处：换 IP 不用再到处改配置。以前换 IP 的流程是先在云厂商后台绑定新地址，再打开每一个客户端，把旧 IP 换成新的，换完还要一个个测试有没有漏改。现在是反过来的：客户端里写的是域名，换 IP 只需要去改一条解析记录，客户端不用动。域名解析的生效时间我设得很短，这样改完等一小会儿，各地陆续就能拿到新地址。这个习惯养成之后，换 IP 从一件“要专门抽时间干的活”变成了一件“改一行就完事的小事”，心理负担小了很多。

第二个好处是排障的时候变量更清楚。以前出问题，我第一反应总是怀疑配置写错了，反复改协议、改端口、改加密方式，折腾半天才发现，问题根本不在配置上，在路上。现在有了域名这一层，我排障的顺序也固定下来了：先看域名能不能解析到正确的地址，再看这条路通不通，最后才去怀疑配置。把“地址对不对”和“配置对不对”分开，能少走很多弯路。有一次延迟突然变高，我按这个顺序查了一圈，发现是去程绕路了，跟配置一点关系都没有——如果还按以前的习惯先改配置，那一晚估计又白折腾了。

域名还有一层很多人容易忽略的用途：把真实地址藏一藏。客户端直接连 IP，等于把机器的真实地址摊在明面上；中间隔一个域名，日常使用里看到的都是域名，真实地址只出现在解析记录里。当然这不是什么高深的防护手段，懂行的人还是能查到，但至少日常层面多了一道缓冲。而且域名这层还可以根据需要再加一层转发或 CDN 做备用，平时走直连，需要的时候切到备用路径，切换同样只需要改解析，不用动客户端。这个“平时一条路、备用一条路”的思路，我现在觉得比一开始就把所有东西堆在一起要稳得多。

不过域名也不是万能的，用的时候有几个坑我也踩过。第一个是缓存：解析记录改了，客户端不一定马上拿到新的，有时候是本地缓存，有时候是运营商缓存，表现就是“我这边明明改了，你那边还是旧地址”。后来我学乖了，改之前先把 TTL 设短，改完之后多等一会儿再下结论，不再一改完就急着判断成没成功。第二个是别把域名当成配置的替代品：域名只解决“找到机器”这一步，端口、协议、密钥这些还是要自己管好，域名套上去了不代表配置就可以马虎。第三个是记录要写清楚：域名指向哪台机器、这台机器是干什么的、备用路径是什么，都要记在笔记里，不然过几个月自己都忘了当初为什么这样搭。

还有一点体会是关于“分层”的。以前我喜欢把所有东西都写进一个配置里，觉得这样直观；现在更习惯分层：域名管寻址，客户端管连接方式，服务端管具体的服务。每一层只干一件事，出问题就先定位是哪一层，再往下细查。这个思路不只适用于节点，搭别的服务也一样：先把层次分清楚，再去填每一层的内容，比一开始就把所有细节混在一起要好维护得多。刚开始学的时候总想一步到位，现在反而觉得，慢一点、分清楚、每一步都验证一下，最后反而更快。

回过头看，给节点套域名这件事本身技术含量并不高，难的是改变习惯：不再贪图“直接写 IP 最省事”，而是多花几分钟加一层抽象。这层抽象换来的是换 IP 不折腾、排障有顺序、备用路径好切换。如果你手里也有几台经常要动的机器，不妨试试这个办法：客户端和笔记里只写域名，IP 只出现在解析记录里。等下一次换 IP 的时候，你会发现，改一行就完事的感觉，真的挺舒服的。