真实IP丢失源于请求链路中IP信息被覆盖且未正确传递，需反向代理透传X-Forwarded-For、应用启用信任代理机制、Nginx容器启用real_ip_module并配置可信网段，必要时调整Docker网络模式。
根本问题不在容器本身，而在整个请求链路中 IP 信息被层层覆盖却未被正确传递和识别。真实 IP 的丢失是网络转发、代理配置、应用解析三者脱节的结果，必须全链路协同处理。
反向代理必须透传 X-Forwarded-For 头
这是最常被忽略的第一环。Nginx、Traefik 或 Cloudflare 等前端组件若不主动注入客户端 IP，后续环节无从还原。
- Nginx 配置需包含：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme; - Traefik v2+ 默认透传，但若自定义中间件或使用 IngressRoute，要确认
forwardedHeaders已启用 - 用 Cloudflare 时，必须在 Nginx 中用
set_real_ip_from显式声明 CF 的可信 IP 段，否则$remote_addr会被当成 CF 节点地址
容器内应用必须启用信任代理机制
Docker 不会自动解析代理头，框架默认只认 TCP 层的 remote_addr。必须显式告诉应用：哪些来源的 X-Forwarded-For 是可信的。
- Express（Node.js）：
app.set('trust proxy', '172.16.0.0/12');（推荐指定网段而非true） - Spring Boot：
server.forward-headers-strategy=framework，并确保internal-proxies匹配 Docker 网络（如172\.\d{1,3}\.\d{1,3}\.\d{1,3}） - Flask（Python）：
ProxyFix(app.wsgi_app, x_for=1, x_proto=1)，且需配合 Nginx 的real_ip_header X-Forwarded-For
Nginx 容器自身需启用 real_ip_module 解析
当 Nginx 本身作为反向代理运行在容器中时，它也面临同样问题——不能只靠 $remote_addr 记录日志或限流。
- 在
http块中添加：
set_real_ip_from 172.18.0.0/16;（按实际 Docker 网络 CIDR 调整）
real_ip_header X-Forwarded-For;
real_ip_recursive on; - 自定义日志格式示例：
log_format realip '$http_x_real_ip - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; - 避免使用
set_real_ip_from 0.0.0.0/0，这会带来安全风险，仅对已知代理网段开放
必要时调整 Docker 网络模式或路由路径
当链路极简（如无外部 LB，Nginx 直接对外提供服务），可绕过代理头机制，让容器直接看到原始连接。
- 使用 host 网络模式：
docker run --network host，容器共享宿主机网络栈，request.remote_addr即为真实 IP - 若仍需 bridge 网络，确保宿主机 iptables 未做 SNAT；可检查
iptables -t nat -L POSTROUTING是否存在异常 MASQUERADE 规则 - 对高要求场景（如风控、审计），建议在入口层（如边缘网关）完成 IP 提取并注入唯一标识头（如
X-True-Client-IP），避免多层X-Forwarded-For堆叠带来的歧义
