日志里客户端 IP 全是 10 开头内网段，按 IP 限流把全站算成一个人，转发头那串地址该取哪一段？

结论先行：日志里客户端 IP 显示成 127.0.0.1、10.x.x.x 或负载均衡内网地址，多数不是代理把 IP 弄丢了，而是应用读的是 TCP 连接来源地址，而这条连接是代理发起的。真实用户 IP 通常由代理写进 X-Forwarded-For（下文简称 XFF）这类转发头，但它是一串可拼接的文本，左端来自客户端、可伪造，取值应按可信代理层数从右往左数，或由入口代理统一重写成单值头，应用只读这一个头。取值位置不对，按 IP 限流、风控黑名单和审计定位都会失真。

一、来源地址是在哪一层被换掉的

一次对外请求的常见链路是「浏览器 → CDN 或负载均衡 → Nginx → 应用」。应用在 socket 上看到的对端地址，是发起这条连接的那台机器，也就是代理本身。代理和应用同机，这个地址就是 127.0.0.1；代理在容器或内网里，通常是 10.x.x.x、172.16.x.x 这类内网段。日志出现这些地址属于链路结构导致的正常现象，不是网络故障。

要不要拿真实 IP，判断依据是业务是否依赖「是不是同一个访客」。按 IP 限流、风控封禁、地区统计、客服定位投诉用户，都属于这类场景；继续用连接来源地址，限流会把所有访客算成同一个，封禁则可能连坐整台代理。

转发头是怎么一层层长出来的

Nginx 常见写法 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，语义是保留请求里已有的 XFF，再把当前连接的来源地址追加到末尾。经过多级代理后，这个头会变成「客户端自带值, 代理1 地址, 代理2 地址」这样的串。

• 左端部分来自客户端自带的请求头，内容可以自行填写，代理若原样保留，后端看到的就是被污染的值。
• 右端是各级代理追加进去的，可核对的部分在这里，取值要按可信层数从右边数。
• 代理链层数变化（例如新接一层 CDN）后，取值位置也要同步调整，否则会把某台代理误判成真实访客。

二、数清可信代理层数，再决定取哪一段

这不是选一个头名那么简单，而是先确认「从访客到应用之间，有多少层是自己可控的代理」。评审时按下面三步对齐，顺序换了容易返工。

1. 数代理层数：把访客到应用之间的转发节点列出来，典型是 CDN 加内网负载均衡，常见区间是 1~3 层。层数不确定时，抓一次真实公网请求的头部内容再定，不要凭记忆拍。
2. 划可信边界：只把自己可控、会重写或追加转发头的代理算进去，客户端和不可控的第三方节点不算。这一步决定从右边数第几个值可用。
3. 定取值位置：按可信层数从右往左取，或让入口代理统一重写成 X-Real-IP 这类单值头，应用只读这一个。两种方式选一种，不要混用。

三条常见路线可以按团队情况取舍，改动量和可信度差别较大：

• 路线 A（直接取 XFF 左端）：后端改动很小，只读一个值；但对外服务不可信，伪造一个头就能绕过按 IP 限流，通常只用于内网或调试环境。
• 路线 B（按可信层数从右往左取）：自建反代场景较常见，判断依据明确；代价是代理层数变化时要同步改代码或配置，需要把层数记录在同一份文档里。
• 路线 C（入口代理重写成单值头）：应用侧逻辑简单，只认一个头；依赖入口配置正确，云上环境以各厂商官方文档说明为准，不要照抄别家写法。

经验区间上，接入节点少的项目（1~2 层）用 B 或 C 都容易收敛，验证一轮基本能对齐；接入节点多、跨团队改动慢的项目，常见做法是先固定入口重写（C），把应用侧的不确定性降下来。

三、日志、限流、风控三处口径，加上一段现场经验

同一个真实 IP，在这三个地方的要求不同：日志在意能不能定位到人，限流在意能不能被伪造绕过，风控与审计要留下判断依据。统一口径可以记成一句话：入口代理负责剥离和重写，应用只信任被重写后的值。

• 日志：记录解析后的可信 IP，必要时保留原始头用于排查；原始头里可能带个人信息，输出前按合规要求做截断或脱敏。
• 限流：入口先把访客自带的转发头清掉或覆盖，再按可信 IP 计数，否则伪造一个头就等于自带钥匙。
• 风控与审计：留链路信息时标注哪几跳是可信代理，避免几个月后复盘时说不清当时的取值规则。
• IPv6 与存储：地址更长，字段宽度按完整地址预留，常见做法是留 45 个字符左右，解析库也要确认支持，避免存储层截断。

现场常见的情况是这样：项目周期紧、只有一台 Nginx 加两台应用，测试报「日志里全是 10.0.0.2」，甲方又不想动网络拓扑。约束是不增加转发层、不拉长工期，做法是在 Nginx 转发段显式重写 X-Real-IP，应用改读这一个头，上线前用一次真实公网请求核对日志。代价是如果只改了 Nginx 没改应用读取方式，就要多返工一轮，日志里仍然是代理地址，这类问题往往拖到运营发现限流异常才暴露。

四、适用与不适用边界

• 适合做：有 CDN、负载均衡或 Nginx 反代的对外服务；需要按 IP 限流、封禁、地区统计；有审计留痕或客服定位诉求。
• 不必做：纯内网后台、单机直连、没有按 IP 做任何判断的系统；代理链不可控、层数无法对齐时，强行解析反而增加取错跳的概率。
• 常见坑：只加转发头不改应用读取逻辑；多级代理后没更新层数；把访客自带的头当真；不同环境层数不同却共用一套取值代码。

一条边界可以记牢：如果应用与代理处在同一个可信网络里，业务也不需要按 IP 区分访客，直接记录连接来源地址反而省事，额外解析转发头只会引入取错跳的风险。按 2026 年常见交付习惯，对外服务只要有反代或负载均衡，通常建议在入口就把真实 IP 口径固定下来，后面再补限流与风控时，返工成本会比一开始统一口径高。

常见问题

Nginx 里已经加了 X-Forwarded-For，日志里怎么还是 127.0.0.1？

多数是应用仍读连接来源地址，没读转发头；也可能是 proxy_set_header 写在了不生效的层级，按请求链路逐段核对一次通常能找到。

X-Forwarded-For 左端那个 IP 能当成真实用户吗？

不建议。左端来自访客自带的请求头，可以随便填；只有可信代理追加进去的值才可核对，取值位置要按可信层数从右往左数。

按 IP 限流直接用转发头，会不会被绕过？

会。请求方伪造一个头就换了个身份，所以入口代理先剥离或覆盖访客自带的值，限流再按重置后的可信 IP 计数。

IPv6 访客的地址，日志里该怎么存？

先确认代理是否透传完整地址，字段与解析库按完整 IPv6 预留空间，常见做法是留 45 个字符左右，避免存储截断导致定位失败。

要在现有项目里动手，可以先在入口代理统一重写真实 IP，再用一次真实公网请求验证日志，确认之后再考虑限流与风控规则。这套做法适用于有反代、需要按 IP 做判断的服务；纯内网直连、不按 IP 区分访客的系统，不必为了看起来规范而额外引入解析逻辑。