内网使用域名无法访问同网设备是什么原因？怎么解决？

在折腾各种服务的时候，总会遇到奇怪又“理所当然”的问题。比如 RustDesk、各种自建面板、NAS 服务、反向代理……它们在公网访问时必须配置一个域名，镜像/客户端也要求填写域名。

结果就有意思了： 内网设备也只能通过这个同一个域名访问你的服务。

然而—— 这个域名解析到的是公网 IP（或者 Cloudflare / ISP 的 Anycast IP）。 于是，内网访问一个“明明就在隔壁的设备”，却偏偏要绕一圈公网，甚至直接访问失败。

这篇文章就是记录我解决这个问题的过程，顺便留下一个“不要乱改”的提醒。

现象：内网访问自己的服务，必须走域名，但访问不了

以 RustDesk 为例：

1. 服务端已经绑定了一个域名，比如 desk.example.com。
2. RustDesk 配置项也必须填写 desk.example.com。
3. 内网机器想连控制端，也只能输入 desk.example.com。

这在公网下完全没问题，可到了内网，就常见两种情况：

• 访问失败：路由器无法把这个域名转回内网 IP。
• 绕外网炸延迟：域名解析走公网，然后 NAT，奇慢无比。

很多路由器默认不会做 NAT Loopback（又叫 Hairpin NAT / NAT Reflection），更不会主动把域名“指回”内网。

折腾过程：原来是路由器的桥接防火墙在捣乱

我是在 OpenWrt/GL-BE3600 路由器上排查到的。 系统日志里几次提示让我注意到了 bridge-nf-call-iptables 相关的设置。

简单说：

• Linux 的 bridge（用于交换机/桥接）收到数据包时，是否丢给 iptables 处理，取决于这三个参数：

net.bridge.bridge-nf-call-arptablesnet.bridge.bridge-nf-call-ip6tablesnet.bridge.bridge-nf-call-iptables

在不少路由器上，这些参数默认为 1，也就是：

桥接转发的包会被防火墙规则拦截/处理。

这在大多数时候是好事，比如隔离、访客 WiFi、防 ARP 攻击都要依赖这些。

但坏处也显而易见：

NAT Loopback / Hairpin NAT 会因此直接失败。 也就是说，同一个 LAN 的设备无法通过域名访问另一台 LAN 设备提供的服务。

解决方案：临时关闭桥接防火墙检查

在路由器后台修改 /etc/sysctl.conf：

net.bridge.bridge-nf-call-arptables=0net.bridge.bridge-nf-call-ip6tables=0net.bridge.bridge-nf-call-iptables=0

刷新配置：

sysctl -p/etc/init.d/sysctl restart

几乎是立刻，所有内网设备都能通过域名正常访问内网服务了。

RustDesk、Nginx、NAS、内网面板……通通恢复畅通。

你甚至能感觉到那种「终于不用绕公网走一圈」的顺畅。

但问题也来了：这算是把防火墙给“抬走了”

把这三个参数设置为 0，本质上是告诉 Linux：

桥接转发的数据包不要经过 iptables 了。

这意味着：

• 隔离功能无效：例如访客网络、VLAN 隔离、AP 隔离都可能失效。
• 安全策略失效：bridge 层的过滤无法生效。
• ARP 相关的攻击检测也会被绕过。

对家庭用户可能影响不大，但对分 VLAN、访客 WiFi、NAS 隔离等需求，就得小心一点。

从某种意义上说，你是在“以功能换安全”。

更优雅的解决方式（如果你的路由器支持）

很多路由器其实已经内置：

• NAT Loopback / Hairpin NAT
• DNS Rebind
• 本地 DNS 覆盖

理想做法是：

1. 让路由器的 DNS 把域名解析为内网 IP 例如在 OpenWrt 的 dnsmasq 加一条静态解析：address=/desk.example.com/192.168.1.10
2. 确保 NAT Loopback 正常开启 不同路由器的开关名字不一样，有的直接写“Hairpin NAT”。
3. 尽量不要动 bridge-nf-call- 参数

但很多厂商路由器隐藏了这些功能，尤其是 ISP 光猫、旅行路由、小众固件。如果正好遇上这种情况，上面那个“修改 sysctl 的办法”就变成了一条可用但要谨慎的捷径。

最后总结

如果你在内网用域名访问内网服务失败，很可能就是桥接层防火墙拦了你的 NAT Loopback。

简单粗暴的做法：

net.bridge.bridge-nf-call-iptables=0net.bridge.bridge-nf-call-ip6tables=0net.bridge.bridge-nf-call-arptables=0

的确能立刻解决问题，但这也是在“绕过部分防火墙机制”。

更稳妥的方式还是：

• 开启路由器的 NAT Loopback
• 在本地 DNS 里给域名解析一个内网 IP

这样既安全，也不需要削弱系统的过滤能力。