因此，假设您有一个专用网络，该网络通过 NAT 盒连接到公共互联网。在 nat 框上，明确的规则（有时称为“端口转发”）被配置为允许从公共网络访问专用网络上的服务器。

在这种情况下，连接是否成功归结为 NAT 框的行为。

通常，NAT 框会修改从专用网络到公共网络的传出连接*的来源。由于配置了显式规则，它还根据这些规则修改传入连接的目的地。NAT 维护一个跟踪表，以便一致地处理给定连接的数据包。

从 nat** 后面的客户端到同一 NAT 用于传入连接的公共地址的连接是一种特殊情况。NAT 必须修改目的地，尽管连接来自内部。此外，在大多数情况下，NAT 还必须修改连接的来源，尽管事实上连接不会到外部。

这是完全可行的，但它通常需要 NAT 引擎中的额外规则，例如https://unix.stackexchange.com/questions/282086/how-does-nat-reflection-nat-loopback-work讨论了这些规则必须使“nat 反射”在 iptables NAT 中工作。

允许这是否是一个好主意也值得怀疑。从内部主机到公共 IP 的流量将不必要地通过 NAT 框，并且为此类流量登录服务器不会显示流量的真实来源。由于这些原因，一些网络管理员不希望允许此类连接，而是使用“拆分 DNS”将流量从内部主机定向到服务器的内部 IP。

* 这里的连接是指可以用来匹配请求和响应的数据包元数据的组合。这比通常的连接定义要宽泛一些。

** 有时同一私有网络上的机器可以在不同的 NAT 后面，特别是如果私有网络很大，在这种情况下，NAT 不必做任何特殊的事情。

使用源 NAT 路由到 WAN 并立即使用目标 NAT 路由回称为NAT 发夹。

有些 NAT 路由器根本不支持 NAT 发夹，有些可以配置为这样做但性能不佳，有些则可以。

通常，通过完全不必要的 NAT 结构路由数据包是一个坏主意。此外，强制流量通过并非真正需要的网关通常会浪费资源和潜在的瓶颈。此外，发夹对服务器隐藏了客户端的 LAN 地址，这可能是一个安全问题。

您应该确保 LAN 客户端使用其 LAN 地址访问 LAN 服务。实现这一目标的一种简单方法是使用 DNS 名称并配置您的本地 DNS 服务器，以便将这些服务解析为它们的 LAN 地址（裂脑 DNS），而不是依赖公共域的 DNS 解析。