域名防封锁技巧：换IP只是缓兵之计

换IP解决不了被封的问题，它只是把麻烦往后推了几天。IP一换，当天访问恢复正常，过几天又打不开，再换，再封，最后手里攒了一串废弃地址，事儿还在原地。域名防封锁技巧这几个字被搜得很多，真管用的没几条，而换IP恰好是最容易被当成救命稻草的那一条。

域名防封锁技巧里，换IP为什么排不上第一位

封锁不是一个墙上的开关，是好几层东西叠在一起。解析层可以给你返回一个错的地址；链路上可以针对某个IP段直接丢包；TLS握手的时候，SNI字段里明文写着你要访问哪个域名；再往上还有一份域名级别的名单。换IP只动了其中一层，而且是最便宜、最好动、也最不持久的那一层。

于是就有了那种很典型的循环：换完能通，几天后又不行，再换。不是手法没用，是它只按住了症状里最表面的那一块，底下的东西一点没动。

先判断自己被卡在哪一层

判断的办法挺土，但好使：拿IP直接访问，通不通？换个域名指到同一台机器，通不通？只有域名访问不通、IP能通，那问题在域名这一侧；只有当前地址不通、换一个就好了，那才轮到换IP这招。不少人的顺序是反的，上来先换IP，换完发现还是打不开，白折腾一趟，顺手把原来的解析记录也搅乱了。

解析层能做的事比你想的多

多A记录、多线路智能解析、CNAME指向不同接入点，这些都是常规操作。国内几家的解析服务基本都支持按运营商、按地域返回不同地址，某些场景下确实能撑一阵。但得清楚，解析只负责告诉别人去哪儿，不负责能不能到。目标域名本身已经在名单里的时候，解析做得再花哨也没意义。另外TTL别设太长，真要切换的时候你自己都等不起；各家最短支持到多少，以服务商文档为准。

SNI这一层，很多人压根没意识到

现在大部分站点跑的是HTTPS，握手阶段客户端会把要访问的域名明文放进SNI里。这一层绕起来很麻烦，ECH那类方案的支持情况一直不怎么样，浏览器、CDN、服务端三边都得配合，能不能用要看当下的实现，以官方说明为准。有人的站换了IP照样打不开，原因就在这儿：人家根本不看你的IP，看的是你握手时报的那个名字。

域名进了名单，换IP就是无效操作

说直接的：如果拦截是针对域名做的，你换一百个地址也没用，因为拦的动作发生在解析之前，或者干脆发生在SNI那一层。这时候唯一的出路是换个名字进来。备用域名是很多做跨境业务的人手里的标配，但有几件事得提前想清楚——别和主域名用同一个注册商、同一套NS、同一台服务器、同一个IP段。IP段这条最容易被忽略，同一个C段下的地址，处理的时候经常是整段一起走。

CDN和反向代理能顶一阵，但别神化

CDN的作用是把源站藏起来，用户看到的是节点地址，封掉一个还能调度到别处去。听着挺好，可节点地址是公开的、数量有限，共享节点上还挂着别人的站，别人出事你也跟着受影响。自己搭反向代理也是条思路，不过那台前置机器的地址一样会暴露，维护的活儿还得自己扛。它是缓冲垫，不是盾牌。

备用域名的运营细节，别只顾着技术

换域名不是改条解析就完事。老用户的书签、外链、搜索引擎里已经收录的那一堆地址，全都指着旧域名。旧域名还能访问，做301是最省事的；彻底不通了，就只能在能触达的渠道里挨个通知。还有备案的事，国内节点上跑的站，域名换了备案信息一般也得跟着调整，具体要求以各地管局和服务商的说明为准，别自己猜。

动手前先过一遍这份清单

主域名和备用域名，是不是同一个注册商、同一套NS？备用域名指到的地址，和主域名在不在同一个C段？解析的TTL设了多久，切换时忍不忍得了？全站HTTPS的情况下，SNI这一层有没有考虑过？源站地址有没有通过邮件头、图片外链、历史DNS记录泄出去？出问题的时候谁去改解析，多久能改完？有没有一个不依赖主域名的通知渠道，能第一时间把情况告诉用户？

这几条不用全做到，但至少要能答上来。答不上来，基本就是一出事全靠手忙脚乱，谁也不知道下一步该点哪里。

换IP不是不能用，它是个应急动作，能给你争取几个小时去换正经方案。把它当长期策略，就等着每周重复一遍同样的操作。真正值得花时间的是把入口做成多个、把切换做成自动的，再把监控挂上，剩下的交给流程，而不是交给运气。