真实客户端IP需通过X-Forwarded-For等头结合可信代理配置获取：ASP.NET Core启用ForwardedHeadersMiddleware并设置KnownProxies；Framework中需手动解析X-Forwarded-For首IP并校验格式，避免直接使用UserHostAddress。
在 ASP.NET 中，HttpContext.Current.Request.UserHostAddress 已过时且不可靠，直接取到的很可能是代理 IP 或 127.0.0.1；真实客户端 IP 必须结合 X-Forwarded-For、X-Real-IP 等请求头综合判断。
ASP.NET Core 中获取真实客户端 IP 的标准做法
ASP.NET Core 不再提供 UserHostAddress 这类易误导的属性，而是统一通过 HttpContext.Connection.RemoteIpAddress 获取连接端 IP —— 但它仍是反向代理（如 Nginx、IIS ARR）后的 IP，不是原始客户端 IP。
要拿到真实 IP，需启用 ForwardedHeadersMiddleware 并正确配置信任的代理段：
services.Configure<forwardedheadersoptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
// 只信任内网代理，避免伪造 X-Forwarded-For
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
options.KnownProxies.Add(IPAddress.Parse("10.0.0.1")); // 替换为你的 Nginx/LB 真实 IP
});</forwardedheadersoptions>
之后在控制器中用 HttpContext.Connection.RemoteIpAddress 即可得到解包后的原始客户端 IP。
- 不配置
KnownProxies→ 任意请求都能伪造X-Forwarded-For，导致 IP 被污染 - 若代理是 IPv6 或多层（如 CDN + Nginx），需把所有上游代理 IP 都加进
KnownProxies -
RemoteIpAddress在中间件启用后才有效；未启用时它和X-Forwarded-For值无关
ASP.NET Framework（.NET 4.x）中手动解析 X-Forwarded-For 的坑
老项目没上中间件，只能自己从 Request.ServerVariables 或 Request.Headers 提取头信息。但注意：X-Forwarded-For 是逗号分隔的字符串（如 "203.0.113.195, 198.51.100.100"），最左才是原始客户端 IP。
典型错误写法：Request.Headers["X-Forwarded-For"] 直接取整串 → 拿到的是整个列表，不是单个 IP。
- 正确提取：用
.Split(',').First().Trim()，并做空值和格式校验 - 必须校验 IP 格式（用
IPAddress.TryParse），否则可能被注入恶意字符串 - 如果前端有 CDN（如 Cloudflare），优先看
HTTP_CF_CONNECTING_IP，它比X-Forwarded-For更可靠 - IIS 自身可能插入
X-Original-Host或改写头，建议在 ARR 日志里确认实际转发头内容
为什么 Request.UserHostAddress 经常返回 127.0.0.1 或内网地址
这个属性只读取 TCP 连接来源，当应用部署在 Docker 容器、K8s Pod 或本地反向代理后，它看到的就是代理进程本机的连接，而非浏览器真实出口。
- Docker 默认桥接模式下，容器内
UserHostAddress是宿主机的 docker0 网卡地址 - Kestrel 直接暴露时它才接近真实，但生产环境几乎不会这么干
- 即使没配代理，某些杀毒软件或 Windows Hyper-V 网络栈也会插入虚拟网卡，干扰识别
- 不要用它做风控或限流依据，极易误伤
真正难的不是“怎么取”，而是“信谁”——每层代理都可能伪造或遗漏头信息，没有银弹。上线前务必用 curl -H "X-Forwarded-For: 1.2.3.4" http://yoursite/ 手动测试头透传是否完整，再检查日志中最终落到服务端的 IP 是否符合预期。
