端口映射后看到的IP都是网关地址，想查真实源IP，唯一可靠的办法是查映射设备上的NAT会话表和连接跟踪日志，应用层日志里的IP只能做参考，不能当证据。这是很多运维同行踩过坑后的共识，下面我把排查思路、具体命令和工具用法拆开讲透。
端口映射源IP丢失，先搞懂数据包被改了什么
要查源IP,先得知道它去哪儿了，端口映射本质上是NAT（网络地址转换）的一种，叫DNAT（目的地址转换），当外部请求打到你的公网IP:端口时，路由器或防火墙会把目的IP改成内网服务器的IP，同时为了回包能原路返回，设备会在自己的连接跟踪表里记一笔映射关系。
这里有个关键点：大多数家用路由器、云平台安全组和部分企业防火墙，在做DNAT时默认不保留原始源IP，数据包到了内网服务器，看到的源IP就是网关的内网地址，比如192.168.1.1，这不是故障，而是NAT的工作机制。
行业共识是：只要流量经过NAT设备，源IP的“真身”就只存在于这台设备的会话记录里，查源IP的第一步，不是去服务器上看，而是去映射设备上找。
如何查看端口映射后的源IP：从NAT设备会话表入手
这是最核心、最权威的方法，不同设备查法不同，下面按常见场景给出具体操作路径。
Linux服务器做端口映射（iptables/nftables）
不少团队直接用Linux服务器做软路由或DNAT转发,登录这台服务器，用conntrack工具查连接跟踪表。
# 查看所有当前NAT会话 conntrack -L | grep <内网服务器IP> # 更精确地按端口过滤 conntrack -L -p tcp --dport <映射端口>
如果系统没装conntrack,用iptables也能看：
cat /proc/net/nf_conntrack | grep <映射端口>
输出里会明确显示src=，那就是原始源IP。这套命令是排查NAT源IP的第一选择，因为它直接读内核的连接跟踪状态，不经过任何应用层逻辑，数据最真实。
企业防火墙（华为、H3C、深信服）
以华为防火墙为例,命令行查会话表：
display firewall session table destination-ip <内网服务器IP>
display nat session table destination-ip <内网服务器IP>H3C设备类似：
display session table ipv4 destination-ip <内网服务器IP>
深信服AC/AF设备则在Web控制台的“连接会话监控”或“NAT会话列表”里找，这类设备通常还带抓包功能，配合抓包能直接看到数据包原始头部。
家用路由器或云平台安全组
家用路由器（如TP-Link、华硕、小米）的管理后台一般没有会话表导出功能，只能开日志，但日志能否记录源IP，取决于固件实现，多数家用路由器不记录，这种情况，思路要换，见下文。
云平台（简米云、酷番云、AWS）的安全组在NAT层面也不给你看会话表，但云平台的控制台里有“流量日志”或“审计日志”功能，开启后能记录访问来源，酷番云的“安全组流量日志”、简米云的“网络流日志”都能查到源IP，这部分功能一般是按流量计费的，需要主动开启。
端口映射源IP丢失，从服务器日志反向溯源
设备会话表查不到（比如家用路由器），或者时间久远会话过期了，只能从服务器侧想办法。
抓包是最直接的取证手段
在服务器上抓包,虽然看到的是网关IP，但可以通过TCP时间戳和TCP选项字段做参考，更实际的做法是：抓包抓的是网关IP没错，但你可以拿着这个网关IP和精确时间，去映射设备上反查那段时间的NAT日志，所以抓包的目的不是直接拿源IP，而是确定攻击或访问发生的精确时间节点，缩小排查范围。
应用层记录的X-Forwarded-For头
如果内网跑的是Web服务,且前面有Nginx、HAProxy等反向代理，那HTTP头里的X-Forwarded-For字段会携带原始客户端IP，前提是代理层做了配置：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
但必须清楚：X-Forwarded-For头可以被客户端伪造，如果请求直接到达Nginx（未经过代理链），客户端自己填什么，Nginx就转发什么，所以这个字段只能作为线索，不能当作定论，如果是多层代理，还要取最右边第一个非信任IP，这属于代理链信任判断的范畴。
数据库和应用日志里的Session记录
很多业务系统在登录或操作时会记录客户端IP,这个IP同样大概率是网关IP，但有一种例外：如果内网服务直接暴露在公网（没做端口映射），日志里的IP就是真实的，所以先确认你的网络架构，再判断日志的参考价值。
内网穿透后如何追溯真实IP：被动变主动的思路
遇到家用宽带没公网IP、用frp/ngrok做内网穿透的情况，源IP追踪又不一样。
穿透工具的日志机制
frp服务端（frps）的日志里默认记录的是客户端的连接来源，也就是穿透客户端所在网络的出口IP，如果要追溯访问穿透服务的真实用户IP，需要看frp服务端的vhost_http_port代理日志，或者看穿透到的内网服务日志后者看到的还是frp客户端的IP。
主动植入流量标记
比较实用的做法是在穿透链路中增加一层应用层代理,比如frp转发到内置的Nginx，由Nginx记录X-Real-IP和X-Forwarded-For，这样能拿到相对可信的IP，但仍然存在伪造可能。要拿到完全可信的IP，必须在最边缘的入口设备上做记录，这就是为什么很多企业干脆不用frp做生产环境映射。
部署Agent采集终端信息
对于自研系统,可以在页面或客户端埋点，采集更多指纹信息（IP、User-Agent、设备ID）关联分析，单看IP会误判，结合设备指纹准确率显著提升，这在反爬和风控场景中用得较多。
不同场景的排查优先级，按成本排序
结合上面的分析,按可行性和成本，给出一个排查顺序参考。
| 排查方式 | 适用场景 | 可靠性 | 成本 |
|---|---|---|---|
| NAT设备会话表 | 有管理权限的防火墙/路由器 | 极高 | 低 |
| 抓包+时间点反查 | 设备有日志但无实时会话 | 高 | 中 |
| X-Forwarded-For头 | Web应用有Nginx代理 | 中（可伪造） | 低 |
| 云平台流量日志 | 云服务器+NAT网关 | 高 | 中（按量付费） |
| 应用层业务日志 | 所有场景兜底 | 低（通常是网关IP） | 低 |
查源IP的常见误区，你可能正在犯
在服务器上last或netstat查来源
这些命令看到的是当前连接或最近登录记录,端口映射场景下，看到的IP几乎都是映射设备的IP，查了等于白查。
觉得改配置就能让源IP穿透进来
Linux的iptables确实能用--to-source做SNAT覆盖，但DNAT场景下想保留源IP，需要额外配置
route_localnet和策略路由，风险很高且影响转发性能，多数路由器固件根本没这个选项。与其纠结让源IP穿透，不如在入口设备上把日志留好。
忽略时间同步
查NAT会话表时,如果设备和服务器的时间不同步，比对日志会非常痛苦，排查前先确认设备时间准确，NTP同步是基本功。
建设长期可溯源的端口映射环境
查一次简单,难的是每次都能查到，建议从三个层面搭好机制：
- 入口设备层：开启NAT会话日志记录功能，设置日志服务器远程存储，避免设备重启日志丢失。
- 应用层：反向代理统一配置X-Forwarded-For并过滤伪造头，Web应用层增加安全过滤，信任代理发来的IP段。
- 数据层：业务核心操作（登录、支付、管理操作）强制记录IP和Session，保留周期至少6个月。
这样下次再有人问你“服务器端口映射的ip怎么查源ip”，你可以直接告诉他查设备会话表，同时把这份长尾词的答案同步给他，省去反复解释的功夫。
服务器端口映射后源IP是路由器地址，还能查到真实IP吗
能,但要看条件，如果路由器刚重启过、会话表已清空、日志没开那就查不到，这是很残酷的事实。端口映射部署第一天，就要确认映射设备是否开启了会话日志，没开就等于裸奔，如果日志没开，唯一补救机会是应用层是否有X-Forwarded-For或业务记录，但可靠性有限。
几个适合作为后续知识的延伸方向
- 内网穿透方案下,如何通过frp日志结合穿透客户端的内网日志，双向定位攻击来源
- IPv6环境下的端口映射与NAT-PT机制，溯源逻辑和IPv4的有何不同
- 等保2.0对网络访问日志留存的具体时限和格式要求，如何用日志审计系统自动溯源
- 云上部署时,通过VPC流日志打通安全组和NAT网关的访问链路，实现全链路IP回溯
据国内主流安全厂商公开的技术白皮书,多数企业NAT环境下的攻击溯源成功率不足三成，核心原因就是端口映射设备日志未开启或留存期过短，这不是技术问题，是运维习惯问题，排查源IP最可靠的操作，永远是第一时间登进映射设备，把会话表和日志导出来，时间越早，信息越全。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/655433.html
