部署VPS服务时，常遇到一种矛盾现象：公网把80端口转到后端8080，外部访问正常，应用日志中的来源却变成网关或内网地址，IP白名单随之失效；服务器本机访问自己的公网IP还会超时。这里混着DNAT、SNAT、NAT连接跟踪和Hairpin回环，不能只看端口映射。用随身服务器管理节点时，回程通知更易触发故障。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：zgovps（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、DNAT改目的，SNAT改来源
DNAT只改入站报文的目的地址，例如把公网IP的80端口指向后端8080，通常不改变客户端源地址。SNAT或MASQUERADE才把源地址替换为出接口地址或网关地址。应用日志出现内网来源，说明路径上另有源地址转换，并非DNAT造成。
NAT连接跟踪保存双向转换所需的状态。请求若只命中DNAT，原始源仍应是客户端公网IP，响应再由网关按跟踪表恢复目的地址；若报文还命中SNAT，后端看到的源地址就可能变成网关。这个状态也决定回程走哪条路由，不能只依据路由表推断。
Hairpin回环是本机访问自己的公网IP：请求先离开主机，经网关DNAT后再指回后端，因此还需回环转发与相应SNAT。缺少它时，包可能停在网关，或误入本地监听地址；“本机失败、外部成功”正是常见信号。
二、从规则计数到双端抓包
先核验生效规则，而非面板残留配置。检查iptables、nftables的DNAT、SNAT及计数器，确认协议、监听地址、入接口与路由表一致；再用conntrack -L查看连接五元组和reply方向。规则更新不改写既有会话，清理连接跟踪前要评估生产影响。
随后在公网侧、网关与后端同步抓包：按公网端口筛入站包，再按后端端口筛转发包，对照源IP、源端口和目的IP。若公网侧来源正确、后端侧变成网关地址，转换点就在转发链上的SNAT；若后端来源正确而响应走错，检查策略路由、默认网关、严格反向路径过滤及多wan选路。容器还要多查一层网桥NAT。
最后用抓包区分地址与路径问题。若握手正常而TLS或大响应卡住，可让禁止分片的ping逐步减小载荷，结合tracepath和MSS协商做MTU路径探测，再决定是否启用路径MTU发现或MSS钳制。PROXY协议能传递客户端地址，但需入口代理和应用共同支持，不能替代正确路由。
DNAT 回程与连接跟踪
公网请求到达 VPS 后，DNAT映射规则会把“公网 IP:端口”改写为“内网主机 IP:端口”。DNAT 只改变目标地址，网关还会按源/目的地址、端口和协议创建 NAT连接跟踪；后端响应命中该状态后，才会被反向转换成公网地址和原端口。因此调整映射前应清理旧表项，并明确入口接口、公网地址、协议和目标端口，否则旧连接仍可能命中过期规则。
回包能否正常还取决于 SNAT回源转换和回程路由。若后端默认网关指向 VPS，可把源地址转换为网关内网地址，使响应必经转发链；若业务要求保留源地址，就要为客户端网段配置回程路由，并允许已建立连接反向通过。只做 DNAT 而未处理回程，常表现为请求能进入、响应却超时。
Hairpin 回环与 MTU 陷阱
内网客户端访问公网域名时，流量先到 VPS，再被 DNAT 到内网服务，这就是 Hairpin回环访问。若后端直接回包，客户端看到的源仍是公网 IP，可能因非对称路径丢包。通常应对回包追加 SNAT，把源改成 VPS 内网地址；规则仅匹配内网接口、DNAT 目标及原公网端口，避免影响普通公网访问。
另一类故障来自路径 MTU小于接口 MTU。隧道、PPPoE 或云网络可能进一步降低有效 MTU，而 DNAT 不会自动修正分片；一旦 ICMP“需要分片”被过滤，TCP 常见现象是握手正常、小请求正常，大上传卡住。可启用 TCP MSS clamping，按实际隧道值设置接口 MTU，并通过 MTU路径探测确认端到端可用大小。超大响应还可能遭遇反向路径 MTU 黑洞，不能仅凭普通 ping 下结论。
最后执行检查：①用 ss -lntup 确认监听状态与端口冲突；②用 nft list ruleset 或 iptables-save 核对 DNAT、转发、SNAT 顺序；③用 conntrack -L 确认连接状态；④分别从公网、内网测试普通访问和 Hairpin 回环；⑤用 tracepath、ping -M do 及 tcpdump 定位 MTU；⑥确认云安全组、主机防火墙与容器端口发布均已放行。变更后清理旧连接，让客户端重连，再复测 TCP、UDP 和大包传输。
喜欢 
顶
难过
囧
围观
无聊
