凌晨两点十七分，误无网地监控大屏上跳出一行红色告警：Agent错误无法请求内网地址。法请我盯着那串熟悉的求内IP，后背发凉——这个地址昨天还能ping通，误无网地今天怎么就成了一道墙？法请

问题出在配置中心。新上线的求内Agent从Nacos拉取配置时，把服务发现地址写成了公网域名。误无网地内网环境没有DNS解析，法请请求直接超时。求内这事太常见了，误无网地常见到让人想骂人。法请开发环境能跑，求内测试环境能跑，误无网地一到生产就翻车，法请翻车原因永远是求内“环境差异”这四个字背锅。

我打开Agent的日志文件，发现它在启动后第3秒尝试连接内网数据库，第7秒重试，第15秒再次重试，然后放弃。日志里没有堆栈，没有错误码，只有一行冰冷的“Connection timed out”。这种日志写出来就是给人添堵的——你根本不知道它到底连的是哪个地址，端口对不对，防火墙拦没拦。

排查还得靠老办法。我登上跳板机，用tcpdump抓包。等了三十秒，看到Agent发出的SYN包反复发往一个192.168.1.100的地址，但响应包始终没回来。用ping试了下，通了。用telnet试端口，不通。问题锁定了：不是网络不通，是端口被防火墙策略挡了。

这里有个细节，大多数新手会忽略——Agent进程可能同时发起了多个连接，但日志只记录了最终失败的那一个。你得用lsof或者netstat看它到底占用了哪些端口，再对照防火墙规则一条条比对。我见过有人花了三个小时查DNS，最后发现是iptables的一条规则顺序错了，放行规则写在了拒绝规则后面。

改配置容易，改完重启Agent，三秒后连接成功。但真正让我恼火的是，这个错误本可以避免。Agent的配置文件里明明有内网和公网两套模板，部署脚本却因为一个环境变量没传，默认选了公网模板。这种低级错误，靠人眼检查永远防不住。

后来我在监控系统里加了一条规则：凡是Agent启动后五分钟内出现“Connection timed out”的，自动把配置文件和实际网络参数做对比，差异超过两项就触发告警。上线两周，抓到了七个类似问题。其中一个同事还跑来问我：“你怎么知道我这边的配置有问题？”我指了指监控屏：“它比你诚实。”

说到底，Agent错误请求内网地址不是技术难题，是工程管理问题。你写代码的时候想着“这地方肯定能通”，但网络环境从来不会按你的假设运行。防火墙策略会变，DNS记录会过期，子网掩码会配错。与其事后抓包，不如在Agent启动时做一次自检——把要连接的地址、端口、协议全部打印出来，哪怕只是log一行“connect to 10.0.0.5:3306 using TCP”，也能让排查时间缩短一半。

现在凌晨三点，问题解决了，咖啡也凉了。我关掉终端，想起那个被防火墙挡住的端口——3306，MySQL的默认端口。谁也没想到，部署新Agent时，安全团队顺手把3306的入站规则收紧了，只允许特定网段访问。而Agent的配置里，数据库地址刚好写成了那个被限制的网段。你说巧不巧？