我假设你在谈论这样的结构：

   F
   |
  ISP
   |
   R   S
   |   |
===+===+===+===
           |
           C

如果您的路由器支持所谓的“发夹式路由”（或“发夹式 NAT”），那么如果您遇到这种情况，它将接受来自客户端 C 的请求并将其从 LAN 侧接口发送回服务器 S。这具有优势在于 C 和远客户端 F 的 DNS 是相同的。（流量实际上并没有从路由器传到互联网，正如您所建议的，它只是进出路由器的 LAN 接口，有点低效，但不会触及较慢的 WAN 接口。）

如果您的路由器不支持发夹式路由，则来自 C 的数据包将不会到达 S：根据配置，它们将通过以下方式之一失败： a) 被 R 丢弃；b) 从 R 发送到 ISP，然后丢弃它们；或 c) 从 R 发送到 ISP，然后循环返回，直到 TTL 到期。

如评论中所述，您可能更喜欢为本地和远程客户端提供不同的 DNS 答案，并将 C 发送到 S 的本地地址，将 F 发送到 R 中的 NAT 地址。您可以通过多种方式执行此操作，最简单的是本地解析器也是您自己域的名称服务器，为本地客户端提供私人答案，并使用典型的 DNS 服务的服务器向远程客户端提供公共答案。或者，如果您运行自己的 DNS 服务器，您可以使用“水平分割 DNS”，但我认为这对您来说可能不是最好的。

另一种解决方案是“公共局域网”或“DMZ”设置，其中有两个本地网段：

        F
        |
       ISP
        |
        R
       / \   
==+===+= =+===+===
  |           |
  S           C

这里有一个单独的 LAN 段用于公共可用的服务器。这样做的好处是您可以非常严格地控制 S 段的入口，并且不需要发夹功能。但它在您的网络设置上有更多的工作，并且没有任何性能优势。

如果可以的话，多个 DNS 肯定是最简单的答案。设置不是很困难，提供最好的本地性能，有最简单的组网。

编辑：正如评论中所建议的，在整个过程中使用公共地址不需要任何 NAT，因此您根本没有这个问题。但这可能是 IPv6，这对您来说可能实用，也可能不实用。