下午三点，不通办公室空调嗡嗡响。自己我盯着终端上那行“Request timed out”，不通又敲了一遍 `ping 203.0.113.7`——那是自己我们公司对外提供的公网IP，挂在电信机房的不通防火墙出口上。响应照样没回来。自己四条请求，不通丢了四条。自己 第一反应是不通线路断了。但奇怪的自己是，微信群里同事发来的不通外网截图都正常，我们自己的自己网站也能打开。我绕到机柜后面，不通看那台华为USG防火墙的自己WAN口指示灯，绿得发亮，不通流量统计也在跳。设备没死，链路没断，那问题出在哪？ 后来是运维老张一句话点醒了我：“你试试从内网ping网关，再ping一下出口的映射地址。”我照做了。内网ping网关，通。ping防火墙的内网接口，通。但一旦目标地址换成那个公网IP，包就像扔进了黑洞。 原因其实特别简单——NAT回流没做。我们防火墙的NAT策略只处理了从内网到外网的源地址转换，却没有给“内网访问自己公网IP”这个流量单独开一条hairpin规则。于是数据包从内网主机出发，目标是公网IP，防火墙一看目的地址不在本地路由表里，直接给丢了。它压根没意识到这个IP就是自己腰上挂的那个。 这种事在配置防火墙时太容易漏了。尤其是测试阶段，你从办公室电脑直接ping出口IP，潜意识里觉得“IP是我的，包一定能回来”，但设备层面根本不认这个逻辑。它只认路由表和NAT规则，不认“归属感”。 后来我加了一条策略：源地址指向内网网段，目的地址指向公网IP，动作是NAT到防火墙的内网接口。保存、提交，再ping，延迟稳定在0.3毫秒——那是内网到防火墙的物理距离，不是真的绕到外网再回来。 这个故障让我想起一个更常见的场景：家里路由器拨号上网，你从Wi-Fi下的手机去访问路由器的公网IP，大概率也是不通的。家用路由器同样默认不做hairpin NAT。很多人在NAS上搭了服务，出门用域名访问好好的，一回到家反而打不开，还以为是DNS问题，其实根子就在这。 别急着怀疑运营商，也别先重启设备。先画一张小图：源IP是谁，目的IP是谁，中间经过哪几层转发。多数时候，问题就藏在你自己画的这张图里——你太信任“公网IP等于设备自己”这个直觉了。防火墙可没学过这套人情世故。