内网访问自家域名失败？详解旁路由与非对称路由的终极解决方案

type

status

date

slug

summary

1. 引言：那个令人困惑的现象

前阵子帮一位朋友解决了一个挺有代表性的家庭网络问题：在内网环境下，无法通过自己的域名访问家里的服务（比如 Unraid 管理页面、各类 Docker 服务），但用手机流量（外网）访问却一切正常。

这个问题的本质是多层网关环境下的规则冲突与非对称路由。本文将详细剖析问题产生的过程与原理，并提供相应的解决思路。理解其中的逻辑后，读者将能更好地维护自己的网络环境。

2. 环境介绍：典型的双路由家庭网络

2.1 双路由架构详情

这位朋友的家庭网络是一个典型的“主路由+旁路由”双路由架构，设备虽不多，但各自设备的定位清晰，具体如下：

主路由（iKuai）：IP 地址为 192.168.10.250。这是一台物理软路由，承担最基础、最核心的网络职能：PPPoE 拨号、DHCP 服务（为全屋设备分配IP），以及端口映射/DDNS（将外网访问导向内网服务器）。

旁路由/透明网关（OpenWrt）：IP 地址为 192.168.10.251。作为运行在 Unraid 上的虚拟机，它不直连光猫，核心职责是处理“科学上网”、广告过滤、DNS 优化等特定业务。因此，客户端的默认网关被手动指向此处（192.168.10.251）。

配置提示：在旁路由模式下，OpenWrt 通常只需一个 LAN 接口。许多固件预置的 WAN 接口及相关防火墙规则并非必需。为简化路由逻辑便于维护，建议删除 WAN 接口及相关的防火墙区域，仅保留 LAN 。

业务服务器（Unraid+Lucky）：IP 地址为 192.168.10.35 。这是一台 Unraid 服务器，上面通过 Docker 运行了 Lucky 反向代理工具。它的作用是将复杂的内部服务（如多个 Docker 应用的管理页面）统一到简单的域名和端口（例如 qb.home.com：8888）下来访问和管理。Unraid 服务器的网关指向了旁路由（192.168.10.251）。

客户端（PC）：IP 地址为 192.168.10.95 。这就是日常使用的台式机电脑，其网络设置中的网关指向了旁路由（192.168.10.251）。

2.2 理想的数据流

在这个环境下，数据流的理想路径是：

同时，由 Lucky 服务对外提供访问的内部服务，其标准的数据流入路径是：

实现上述两条理想路径的关键，在于作为网关的 OpenWrt 必须启用 “IP 动态伪装” 功能，其本质是 源地址转换（SNAT）：

其作用简明扼要：当数据包从 OpenWrt 的 LAN 口转发出去时（无论目的地是主路由 iKuai 还是内网其他设备），它会将数据包的源 IP 地址统一改写为 OpenWrt 自身的 LAN 口 IP（192.168.10.251）。

这个功能之所以关键，正是因为它确保了回程路径的对称性：

以第一条路径为例：PC 访问互联网时，OpenWrt 将源 IP 从 PC 的 .95 伪装成自己的 .251 。当互联网的响应数据包回到 .251 时，OpenWrt 能准确识别这是“属于 PC .95 的包”，并完成反向地址转换后送回 PC ；

对于第二条路径同样如此：从互联网返回 Lucky 的数据包，其目的 IP 是 OpenWrt 的.251 ，由 OpenWrt 负责最终转发给 Unraid 服务器上的 Lucky 容器。

若关闭此功能，数据包将保持原始源 IP。在复杂的多层转发中，这极易导致接收方（如 Lucky 服务或互联网服务器）将响应直接发回原始客户端，而非经过 OpenWrt，从而破坏通信链路的对称性与完整性。

2.3 公网服务的正确配置

请思考：在已部署旁路由并开启 IP 动态伪装的环境中，若需将 Unraid 上的 Lucky 反向代理服务（端口 8888）映射至公网，应如何配置端口映射？

正确的配置逻辑是：仅需在主路由 iKuai 上配置一条端口映射规则，旁路由 OpenWrt 无需（也不应）为此服务配置任何额外的端口转发。

具体过程如下：

目标分析：我们的最终目标是让公网用户访问 你的域名：8888 时，流量能抵达 Unraid 服务器（192.168.10.35）上 Docker 中的 Lucky 服务。

配置位置：在主路由 iKuai 的 端口映射/转发（或 DNAT）功能页面中，创建一条新规则。

规则填写：

外网线路/接口：选择你的宽带线路（如 WAN1）。

外网/协议端口：填入 8888（或希望公网访问的其他端口，建议使用高位端口，如 5 位数端口）。

内网 IP 地址：填入 Unraid 服务器的内网 IP，即 192.168.10.35。

内网端口：同样填入 Lucky 服务的监听端口 8888。

协议：通常选择 TCP 或 TCP+UDP（根据服务需求）。

关键点与原理：

为何不映射到 OpenWrt（.251）？因为 Lucky 服务（.35）的网关指向 OpenWrt（.251）。若 iKuai 将流量映射至 OpenWrt，路径将变为 互联网 -> iKuai -> OpenWrt -> Lucky。此举虽可能连通，但增加了不必要的跳转，且 OpenWrt 的防火墙规则可能干扰该流量（这正是后文故障的诱因之一）。

为何映射到 Lucky 服务（.35）可行？当 iKuai 将流量转发至 .35，数据包目的 IP 即为 .35。由于 Unraid 服务器的网关是 .251 （OpenWrt），其响应数据包会首先发往 OpenWrt。此时，OpenWrt 上已启用的 IP 动态伪装会发挥作用，它能对这个来自内网服务器、目的地为互联网的响应包进行正确的源地址伪装，并送回 iKuai，最终抵达公网用户。由此，形成一个完整、对称的路径：互联网用户 -> iKuai -> Lucky （35） -> OpenWrt -> iKuai -> 互联网用户 。

3. 故障重现：当伪装被关闭时

3.1 故障触发条件

在双路由架构中，一旦关闭 OpenWrt 的“IP动态伪装”功能，一个潜在问题便会显现。其特殊性在于：常规的网页浏览、下载等活动可能依然顺畅，但当你尝试通过域名访问内网搭建的反向代理服务时，就会立即出现“内网访问失败，外网访问正常”的诡异状况。

此现象的本质在于：数据包在多层网关间流转时，因缺少关键的源地址伪装（SNAT），导致“回程”路径的对称性被破坏，形成“去程”与“回程”路径不一致的非对称路由，最终被客户端严格的 TCP/IP 协议栈拒绝。

让我们模拟一个从内网 PC 发出的数据包，一步步复现问题产生的过程。

3.2 数据包的“不对称”路径产生过程

（1）请求发出

地点： PC（192.168.10.95）

事件： 在浏览器中输入 qb.myhome.com：8888 并回车。

PC 查询 DNS 后，发现该域名解析为宽带的公网 IP 地址（例如 123.123.123.123）。随后，PC 构造一个请求数据包，其关键信息如下：

源地址：192.168.10.95 （PC）

目的地址：123.123.123.123 （域名 qb.myhome.com 的公网解析结果）

目的端口：8888 （Lucky 服务端口）

PC的网关指向 192.168.10.251（OpenWrt 旁路由），此时数据包会被发往 OpenWrt 。

（2）OpenWrt 中转数据包

地点： OpenWrt 旁路由（192.168.10.251）

OpenWrt 检查数据包目的地址 123.123.123.123：8888，查询路由表后，确定下一跳为主路由 iKuai （192.168.10.250）。

关键决策点： 由于“IP动态伪装”功能已关闭，OpenWrt 不会对数据包进行任何修改，既不会改动源地址（.95），也不会改动目的地址（123.123.123.123：8888）。它仅依据路由表，将数据包原封不动地转发至下一跳—— iKuai 主路由。

（3）iKuai 没有做的事

地点： iKuai主路由（192.168.10.250）

作为网络枢纽，iKuai 发现数据包的目的地是公网 IP 123.123.123.123，且目的端口 8888 匹配了预设的端口映射规则。

于是，iKuai 执行了标准的 DNAT（目的地址转换）：

转换前： 目的地址 = 123.123.123.123：8888

转换后： 目的地址 = 192.168.10.35：8888

然而，问题恰恰出在它“没有”做的后续动作上。为实现完整的 “NAT 回环”（Hairpin NAT），iKuai 本应接着执行 SNAT（源地址转换），将数据包的源地址也改写为自身的 LAN 口 IP （.250）。但在本故障场景中，iKuai 仅执行了 DNAT，未执行 SNAT。

于是，数据包的状态变成了：

源 IP 地址： 依然是 192.168.10.95（PC 的真实 IP）

目的地地址： 已是 192.168.10.35（Unraid 服务器）

数据包被发送给了 Unraid 服务器。

（4）反向代理服务器的“本能”回应

地点： Unraid 服务器上的 Lucky 服务（192.168.10.35）

Lucky 服务处理请求后，准备发出响应。它检查到请求源自 192.168.10.95 （PC）。根据基础网络规则，服务器判定请求者（.95）与自身（.35）位于同一局域网网段 （192.168.10.0/24）。

于是，它不经过任何网关，直接通过二层交换机将响应数据包发往 192.168.10.95。响应路径被简化为：

（5）对称路径被打破

地点： PC（192.168.10.95）

PC 正等待与 123.123.123.123：8888 的通信回应，却收到了一个源地址为 192.168.10.35：8888 的数据包，而非预期的 123.123.123.123：8888。

根据 TCP 协议的严格规定，为保证通信的可靠与安全，一次连接中请求方与应答方的 IP 地址及端口必须一致。面对这个“身份不符”的响应，操作系统协议栈会将其判定为非法或无关数据包。

PC 的协议栈将：

静默丢弃此数据包；或

发出一个 RST（连接重置）包，强行终止此次连接。

在浏览器中，最终表现为页面持续加载直至超时，并显示连接失败

3.3 故障核心

从更高层面看：

故障路径（内网访问失败）：

问题： 回程路径完全绕开了去程途经的路由设备（OpenWrt 和 iKuai），构成典型的非对称路由。

成功路径（外网访问正常）：

关键： iKuai 执行了完整的 NAT（DNAT+SNAT），迫使回程路径必须经过它，从而形成一个对称、可控的闭环。

根本原因由此明晰：在内网客户端通过公网域名访问内网服务的特定场景下，因 OpenWrt 伪装功能关闭，且 iKuai 未对此类“内到内”流量执行 SNAT，导致服务器看到的源地址仍是原始客户端 IP，继而引发直接回包，破坏了通信链路的对称性，最终被 TCP 协议栈的安全机制阻断。

4. 解决方案

在明确故障核心是 “非对称路由导致 TCP 连接状态不一致” 后，解决方案的方向便清晰了：重建或强制实现数据“去程”与“回程”路径的对称性

无论网络拓扑如何，其解决思路均可归结为以下三种根本性方案。本文按从易到难、从治标到治本的顺序进行梳理，读者可根据自身情况与技术偏好进行选择。

4.1 方案一：启用 OpenWrt 的 IP 动态伪装（最直接）

这是最广为人知、操作最简便的方案，适用于希望快速解决问题的用户。

（1）操作步骤

在 OpenWrt 管理界面中，进入 “网络” → “防火墙”。在 “区域” 选项卡下，找到并勾选 “IP动态伪装” 选项，然后点击 “保存并应用”。

启用此功能后，OpenWrt 会对所有经其转发的 LAN 区域流量执行强制性的源地址转换（SNAT）

（2）原理解析

故障时（伪装关闭）的数据流：

启用伪装后的数据流：

通过让 OpenWrt “冒充”所有内网客户端，强制服务器将所有回包都先送到 OpenWrt 这里，由 OpenWrt 完成最终的派送，从而保证了回程路径必须经过它，实现了路径的对称。

（3）优缺点

优点：

操作简单：配置改动极小，效果立竿见影。
广泛有效：不仅能解决本文所述问题，通常也能规避其他因非对称路由引发的异常。

缺点：

丢失客户端真实 IP：内网设备访问服务时，Nginx、Lucky 等反向代理的访问日志中，源 IP 将全部记录为 OpenWrt 的 IP （192.168.10.251），无法追溯具体的内网客户端。
掩盖根本问题：它通过强制统一出口来修正结果，并未优化有缺陷的网络路径逻辑本身。
存在轻微 NAT 开销：会引入额外的地址转换处理负担。

（4）适用场景

你希望用最小的代价快速恢复服务。

你不需要在内网服务的日志中查看客户端的真实 IP。

你的网络结构简单，未来变动的可能性小。

4.2 方案二：在主路由 iKuai 配置 NAT 回环（最规范）

此方案将解决问题的职责交还给主路由，符合网络分层设计原则，是更规范、可持续的解决方案。

此方案分为两步，核心是让主路由 iKuai 处理所有与公网 IP 相关的 NAT 逻辑。

（1）操作步骤

第一步：清理 OpenWrt 的干扰规则

检查 OpenWrt 的防火墙设置，移除或禁用任何可能拦截内网访问公网 IP 流量的自定义规则（例如，针对特定端口的 LAN 到 LAN 端口转发规则）。

第二步：在 iKuai 上配置 SNAT 规则

添加一条新规则，配置如下

动作： 源地址NAT

进/出接口： 均选择内网接口（如 lan1）

源地址： 192.168.10.0/24 （你的内网网段）

目的地址： 192.168.10.35 （或你的服务器 IP。为简化，也可填写整个网段 192.168.10.0/24）

NAT 地址： 192.168.10.250（iKuai 自身的 LAN 口 IP）

（可选）目的端口： 8888 （增加规则精确性）

（2）原理解析

此规则意为：“所有从内网发往指定内网服务器（或服务）的流量，在流经 iKuai 时，其源地址均被改写为 iKuai 自身的 LAN 口 IP。”

配置后的数据流：

本质： 在 iKuai 上，强制修改内网数据包的源地址，迫使服务器必须通过这个路口回信，从而在主路由层面人工建立了一个对称的、闭合的环路，这就是标准的“Hairpin NAT”（NAT回环）实现。

（3）优缺点

优点：

架构清晰：NAT 逻辑回归主路由，旁路由职责单一，便于维护和理解。
集中管理：所有出口和回环策略在一个设备上配置，避免规则冲突。
解耦：旁路由的配置变更（如重装、更换固件）不会影响基础网络功能。

缺点：

配置稍复杂：需要理解并正确配置 iKuai 的 NAT 规则。
同样丢失真实IP：服务器看到的源 IP 变成了 iKuai 的 IP 。
同样存在轻微 NAT 开销

（4）适用场景

你重视网络架构的规范性和可维护性。

你希望网络策略的管控点集中。

4.3 方案三：实施 DNS 分流（最优雅）

这是从根源上解决问题的方案，它彻底规避了“通过公网IP访问内网服务”这一会触发 NAT 回环问题的场景，是性能最佳、逻辑最清晰的解决方案。

（1）操作步骤

此方案的核心是：让内网设备在解析你的域名时，直接获得内网 IP 地址，而非公网 IP。

以下提供不同 DNS 服务下的一些设置参考：

iKuai 设置示例：若内网设备以 iKuai 为 DNS 服务器，可在 iKuai 的 “网络设置” → “DNS 设置” → “DNS 反向代理” 中添加规则。

OpenWrt 设置示例：在 OpenWrt 的 “网络” → “DHCP/DNS” 页面中，切换至 “DNS 记录” 选项卡，于 “主机名映射” 部分添加规则。

如下图所示，添加规则即可

AdguardHome 设置事例：“过滤器” → “DNS 重写”

（2）原理解析

此方案生效后，内网的网络访问行为发生了根本变化：

实施前：

PC查询 myhome.com → DNS返回公网 IP 123.123.123.123

PC向 123.123.123.123：8888 发起请求 → 触发复杂的 NAT 回环流程。

实施后：

PC查询 myhome.com → 内网 DNS 返回内网 IP 192.168.10.35

PC 向 192.168.10.35：8888 发起请求 → 通过交换机直接抵达服务器。

本质： 通过 DNS 这一更高层级的服务，将流量引导至最直接的路径上。内网访问变为纯粹的局域网通信，完全不经过主路由的 WAN 口 NAT 逻辑，也彻底避开了所有因 NAT 回环可能产生的问题。

（3）优缺点分析

优点：

性能最佳：无 NAT 转换开销，延迟最低。
保留真实客户端 IP：服务器日志可准确记录发起请求的内网设备 IP。
根治问题：从 DNS 层面规避问题，不依赖特定 NAT 行为。
路径最优：内网访问无需绕行网关，路径最直接。

缺点：

需维护 DNS 记录：每增加一个需内网访问的服务，都需添加相应的 DNS 记录。

（4）适用场景

你追求极致的内部网络访问性能和简洁性。

你需要在内网服务中记录并区分不同客户端的访问。

你愿意并能够维护一个简单的内网 DNS 配置。

4.4 方案对比与选择建议

为方读者快速决策，现将三种方案的核心特性对比如下：

对比维度	方案一：启用伪装	方案二：iKuai NAT 回环	方案三：DNS 分流
解决思路	在旁路由强制统一出口	在主路由集中修正路径	通过 DNS 从源头改写目标
配置复杂度	⭐☆☆☆☆（最简单）	⭐⭐☆☆☆（需配置）	⭐⭐⭐☆☆（需理解DNS）
网络性能	有轻微 NAT 开销	有轻微 NAT 开销	无 NAT 开销，最佳
客户端真实IP	❌ 丢失	❌ 丢失	✅ 保留
架构合理性	较低（掩盖了根本问题）	优秀（责任分明）	优秀（路径最优）
长期维护性	低	中	低