为什么网站日志里都是 10.x.x.x 或 192.168.x.x？真实客户端 IP 怎么找

如果你的网站日志里反复出现 10.x.x.x、192.168.x.x、172.16.x.x - 172.31.x.x，大概率不是“真实访客都来自内网”，而是你的代理链把真实客户端 IP 藏住了。 这种情况在 Nginx、Apache、Node.js、PHP、CDN、WAF、Kubernetes、Docker、Ingress、负载均衡和反向代理场景里非常常见。

很多人第一次遇到这个问题时会误判为“日志被伪造”“有人通过内网打我”或者“网站拿不到真实来源地址”。更准确的说法是：应用层当前看到的只是上一跳代理的内网源地址，而不是真实访客的公网地址。

为什么日志里会出现 10.x.x.x 或 192.168.x.x？

因为你的应用并不一定直接面向公网。真实请求通常会先经过 CDN、反向代理、云负载均衡、WAF、Ingress 网关或容器网络，然后再转发给应用。此时应用服务器看到的对端地址，经常只是“上一跳”的地址，而上一跳很可能恰好是内网地址。

举例来说，如果公网流量先到 CDN，再到云 LB，再到 Nginx，再到容器里的应用，那么应用里拿到的 remote_addr 很可能是容器网桥地址、Ingress 地址或代理内网地址，而不是真实用户公网 IP。

哪些头部通常包含真实客户端 IP？

• X-Forwarded-For
• X-Real-IP
• 某些 CDN 或云厂商自定义头部，例如真实源 IP 头
• 代理链里追加的 Forwarded 头

其中最常见的是 X-Forwarded-For。它通常会记录一串地址，从最左侧开始往往更接近原始客户端，但前提是你的代理链可信、配置正确，而且没有被外部恶意伪造。

为什么不能盲信 X-Forwarded-For？

因为如果应用直接暴露公网，或者代理没有限制可信来源，客户端可以自己伪造 X-Forwarded-For。这就是为什么在生产里，不能只“读取头部”，而要先定义“哪些代理是可信代理”，再从可信代理转发的头里恢复真实客户端 IP。

也就是说，排障顺序应该是：

1. 确认公网入口层到底是谁：CDN、LB、Nginx、Ingress 还是应用直连。
2. 确认哪一层负责写入真实客户端 IP 头。
3. 确认 Web 服务器是否把这个头透传到后端。
4. 确认应用框架是否从“可信代理头”中提取真实 IP。

Nginx 里最常见的问题是什么？

• 没启用 real_ip 相关配置
• 配置了 X-Forwarded-For，但没声明可信代理网段
• 日志格式仍然写的是默认 remote_addr
• 前面有多层代理，但只恢复了一层

如果 Nginx 自己都没恢复真实客户端 IP，那么后面的 PHP、Node.js、Java、Python 应用通常更拿不到真实地址。

应用日志里看到容器 IP 又是怎么回事？

在 Docker、Kubernetes 和 Service Mesh 环境里，应用常常部署在容器网络后面。应用看到的来源地址可能是 Sidecar、Ingress Controller、NodePort、Overlay 网桥地址，而不是公网源 IP。这时如果边缘层没有把真实客户端 IP 透传下来，应用日志自然只会剩下一串内网地址。

怎么快速判断哪一层丢了真实客户端 IP？

1. 先查 CDN 或云负载均衡访问日志，看最外层是否有公网源地址。
2. 再看 Nginx / Apache 访问日志，确认 Header 是否到达。
3. 最后看应用日志，判断是服务器层没恢复，还是应用层没读取。
4. 必要时抓包或临时回显 Header，验证链路中哪一跳断了。

这一步的核心是“分层看日志”，不要只盯应用层一处。

真实客户端 IP 的一个实用判断原则

如果你在做风控或归因，为什么这件事很重要？

因为一旦拿错 IP，后面的 IP 地理位置、ASN、WHOIS、威胁情报、频控、黑名单、广告归因和用户画像都会偏掉。你以为在分析访客，实际上分析的是自己的代理链。

这也是为什么在排查时，建议把真实客户端 IP 先恢复正确，再去做 IP 查询、ASN 查询、WHOIS 和访问来源分析。

结论

日志里出现 10.x.x.x 或 192.168.x.x，最常见的解释不是“访客来自内网”，而是“你的代理链、日志格式或应用层 IP 恢复方式没有正确拿到真实客户端 IP”。 真正该优先检查的是 CDN、反向代理、LB、容器网络和 X-Forwarded-For / X-Real-IP 的透传与信任配置。