部署于AWS Fargate的ASP.NET Core Web API如何正确获取客户端IP、主机名

云原生阿岚

2026-10-28

现有实现的本质问题

你写的var ip = this.HttpContext.Features.Get<IHttpConnectionFeature>()?.RemoteIpAddress?.ToString();这段代码，语法和读取逻辑本身没有任何错误——它读取的是和当前应用进程直接建立TCP连接的对端IP，这个机制只适合没有任何前置代理的裸机部署场景。你的场景完全不满足这个前提，所以才会拿不到符合预期的IP：

本地测试对不上的原因：
如果你本地调试时开启了VPN、系统全局代理，或是Postman本身配置了自定义代理，代码拿到的是代理节点的IP，不是你本机的实际出口公网IP；如果调试时通过本地Nginx、本地API网关转发请求到调试端口，没有配置透传真实客户端IP的请求头，应用收到的对端IP就是本地网关的环回地址，和你预期的客户端IP完全对不上。
线上Fargate环境拿不到正确IP的原因：
Fargate容器前面必然配置了AWS ALB/NLB负载均衡，所有客户端请求都是先到负载均衡，再由负载均衡向容器发起新的TCP连接，这时候代码读取的RemoteIpAddress永远是负载均衡的内网IP，根本不是真实调用方的公网地址。

正确获取真实客户端IP的操作步骤

第一步：在ASP.NET Core管道中靠前位置配置转发头中间件
框架默认会忽略代理转发过来的客户端标识头，你需要手动明确信任前置的负载均衡，让框架自动解析代理透传的真实IP。示例代码：
```
// 服务注册阶段配置转发头规则
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    // 只处理标准的转发头，避免无效头的干扰
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // 清空框架默认的可信代理列表，避免安全风险
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
    // 把你AWS VPC中负载均衡所在的内网网段加入可信列表
    // 比如你的VPC网段为10.0.0.0/16，按实际值替换即可
    options.KnownNetworks.Add(IPNetwork.Parse("10.0.0.0/16"));
});

// 管道启动阶段启用转发头处理，必须放在路由、MVC、授权等中间件之前
app.UseForwardedHeaders();
```
AWS ALB默认会在转发请求时自动把真实客户端公网IP拼到X-Forwarded-For头中，不需要额外修改负载均衡的配置，只要你把对应网段加入可信列表即可正确解析。
配置完成后，框架会自动把ALB透传的X-Forwarded-For头中最左侧的真实客户端公网IP，赋值给HttpContext.Connection.RemoteIpAddress，这时候你之前写的那段读取代码就可以拿到正确的客户端IP了。
注意：不要为了图方便把所有IP段都设为可信，否则第三方调用者可以直接伪造X-Forwarded-For头传入假IP，破坏日志审计的准确性。
第二步：关于主机名的获取
HTTP协议本身没有强制要求传输终端客户端的主机名，你无法直接从请求头里读到固定的客户端主机名。如果确实需要对应主机名，只能在拿到真实客户端IP后，做反向DNS解析查询该IP的反向解析记录——但大部分公网IP都没有配置反向解析记录，大概率是拿不到可用值的。
如果你需要获取的是用户实际访问的服务端主机名，直接读取HttpContext.Request.Host即可，这个值对应请求Host头里的域名信息。

本地测试的快速校验方法

把Postman的自定义代理、本地VPN全部断开，再调用本地调试的接口，这时候拿到的IP才是你本机的真实公网出口IP，可以和你查询到的本机公网IP做比对，确认读取逻辑是否正常。

内容的提问来源于stack exchange，提问作者clarifier