打开浏览器的检测开发者工具，切到 Network 面板，到目P地刷新页面。标U部某个请求的存内 Response Headers 里赫然躺着一行：Location: http://192.168.1.100/login。这就是址泄内部 IP 泄露。不是检测漏洞扫描器误报，是到目P地实实在在发生在一次常规前端调试里的事。

我头一回碰到这种情况，标U部是存内帮朋友看一个刚上线的后台系统。登录时抓包，址泄发现服务器返回的检测重定向地址里直接写了内网 IP。当时我就问他：你这服务器是到目P地不是在 NAT 后面？他愣了一下，说对啊，标U部云主机前面挂了防火墙。存内问题就在这儿——外部用户请求 example.com/login，址泄服务器本该返回公网域名的跳转，结果它把内网地址吐了出来。

泄露是怎么发生的

常见场景有这么几种。反向代理配置不当，Nginx 的 proxy_redirect 没设好，后端应用返回的 Location 头带着 192.168.x.x 或 10.x.x.x 就原样透传给了客户端。再一种是应用代码里硬编码了内网地址，比如 Java 的 sendRedirect("http://10.0.0.5:8080/error")，开发环境跑得好好的，上线忘了改。还有一种是错误页面泄露——抛异常时把服务器内部路径、IP 全打印在页面上，连 X-Forwarded-For 都没处理干净。

有人觉得内网 IP 不算敏感信息。这个判断有问题。攻击者拿到内网地址段，等于知道了你的网络拓扑起点。配合 SSRF 漏洞，可以直接把请求打到 169.254.169.254 这类云元数据地址，或者探测 192.168.1.0/24 里哪些主机活着。信息收集阶段，一条内网 IP 的价值远超一个普通端口开放记录。

检测手段没多复杂

手动测的话，用 Burp Suite 挂代理，看每个响应里有没有 10.、172.16. 到 172.31.、192.168. 开头的地址。重点看 Location、Set-Cookie 的 domain 字段、Content-Location，还有 JSON 响应体里那些 serverIp、host 之类的键值。自动化工具像 OWASP ZAP 有对应的被动扫描规则，但误报率不低——有些页面正常展示内网设备列表，那不算泄露。

判断标准就一条：这个 IP 地址是否暴露了本不该让外部用户获知的网络结构。如果是个公开的 API 文档里写着 192.168.1.1 是示例，那没事。如果是生产环境登录接口返回了真实内网网关地址，那就是问题。

修起来不难，但容易漏

Nginx 加一行 proxy_redirect http://192.168.1.100/ /; 或者更干脆的 proxy_redirect off; 配合应用层用相对路径。应用代码里把所有硬编码的 http://内网IP 换成配置项，生产环境注入公网域名。错误处理中间件里过滤掉 server.address、localAddr 这类字段。云环境里检查元数据服务的访问控制，别让 SSRF 轻易摸到 169.254.169.254。

有个细节容易被忽略：X-Forwarded-For 和 X-Real-IP 头。如果应用信任了这些头却没做校验，攻击者可以伪造内网 IP 来绕过基于 IP 的访问控制。这不算直接泄露，但属于同一类信任边界问题。

我自己的习惯是，每次上线前跑一遍 curl -I 加 grep，把所有响应头里的内网地址段扫一遍。花不了两分钟，比事后被扫描器报出来再慌慌张张改配置强。内部 IP 泄露单看危害等级不高，但它经常是攻击链里的第一块拼图。别给它留位置。