换完地址不是结束。地址变了，跟着要变的还有四处：客户端的配置、任务里写死的地址、监控里记录的旧值、交接文档里的说明。四处漏一处，过几天就会以另一种形式冒出来，查起来还找不到源头，只能从头翻一遍，翻完往往还得补一遍流程。
先确认引用，再改配置，最后改文档，顺序反过来会留下隐患。
顺序有讲究。先确认哪些地方引用了旧地址，再改配置，最后改文档。引用没清干净就改配置，验证的时候会被旧引用误导，明明改了却还是不通，白白多查半天。
- 客户端里每一处填地址的地方，包括备用项
- 任务脚本里写死的地址或者线路编号
- 监控面板上的地址字段，留着旧值会误判
- 交接文档里的说明和截图
怎么快速找出所有引用
最笨也最有效的办法是全文搜索旧地址。代码、配置、文档三类文件都搜一遍，搜出来的地方逐个确认。代理IP的地址是数字组合，搜索的命中率很高，不容易漏，比凭记忆逐个翻快得多。
搜索结果里最容易被忽略的是截图，图里的地址搜不到，只能人工翻一遍，这一步省不掉。
截图这种东西，过期了要删。
文档和截图之外，还有一种引用藏在别人那里。同事的笔记、群里的聊天记录、外包的交接单，这些地方改不到，只能在改完之后通知一声。通知的模板可以固定，写清楚改了哪几个代理IP地址、从什么时候生效、影响哪几个任务，收到的人自己去核对，核对完回一句，这件事才算真正收口。
改完之后怎么确认没漏
跑一轮完整任务，看失败率和改之前比有没有变化。有变化，说明还有地方指向旧地址；没变化，说明改干净了。这一轮不要省，省了之后问题会在别的时间点爆出来，那时候更难定位，也更难判断是哪一次改动引起的。
验证跑一轮，比看十遍配置有用。
还有一种情况是改了之后一切正常，过几天才出问题。这种多半是缓存或者定时任务还在用旧值，把定时任务的执行时间和涉及的文件列出来，逐个确认一遍，确认完把旧的时间点一起删掉。定时任务最容易被忘，因为它不在视线里，平时也不报错。
最后把这次的改动记一笔，写清改了什么、什么时候生效、影响哪些任务。下次再换代理IP的时候，这一笔就是现成的清单，照着走一遍就行。
换地址是个连锁动作，四处引用一处文档，都跟上才算换完，少一处都要返工。