围绕 Surge 构建家庭网络：桥接、Mesh 与远程访问

本文记录的是我现在实际使用的家庭网络。它不追求复杂的机柜、VLAN 或全屋万兆，而是围绕稳定的无线覆盖、统一的流量策略，以及 Apple 设备在家内外的一致体验进行搭建。

家庭网络是一套很容易越做越复杂的东西。最开始，我们可能只需要一台能拨号和提供 Wi-Fi 的路由器；设备变多、房间变大以后，又会开始考虑无线覆盖、代理策略和远程访问，最后在网络里叠加越来越多的设备。

我现在的选择相对克制：让不同设备各自只处理一类问题。光猫负责接入，主路由维持基础网络，Mesh 负责无线覆盖，Surge 负责流量策略与设备间连接。由于日常使用的设备几乎全部来自 Apple，这套网络也自然围绕 Surge Mac、Surge iOS 和 iCloud 进行了组织。

整体结构

当前网络可以概括为：

Internet
   │
光猫（桥接模式）
   │
主路由（拨号、NAT、DHCP）
   │
无线 Mesh（全屋 Wi-Fi 覆盖）
   │
家庭局域网
   ├── Surge Mac（旁路网关 / Ponte 服务端）
   ├── Mac
   ├── iPhone / iPad
   └── 其他 Apple 设备

家庭网络之外
   └── Surge iOS / Surge Mac
          │
          ├── 条件允许时直接建立 Ponte 连接
          └── 经 BandwagonHost 服务器辅助中转
                    │
                    └── Surge Mac → 家庭局域网

这里的拓扑图表达的是逻辑关系，而不是所有流量都必须依次经过每一台设备。Mesh、Surge 和主路由位于同一个家庭网络体系中，但承担的职责不同；普通设备可以直接通过主路由访问网络，需要 Surge 策略的设备则由 Surge 接管相应流量。

光猫只负责接入

光猫工作在桥接模式，不在这一层承担拨号、NAT 和家庭网络管理。宽带连接交给主路由建立，家庭局域网也由主路由统一管理。

这样做的好处不是让网络速度凭空变快，而是让边界更清楚。光猫变成相对单纯的接入设备，端口映射、DHCP 和网络故障排查都集中在主路由一侧，不需要同时面对两层路由和两套管理逻辑，也避免了无意中形成双重 NAT。

主路由维持基础网络

主路由是这套网络的基础。它负责宽带拨号、NAT、DHCP，以及在 Surge 暂时不可用时继续维持基本的互联网连接。

我不希望代理工具成为整个家庭网络唯一且不可替代的入口。如果 Surge 所在的设备正在升级、重启或者修改配置，基础网络仍然应该可以工作。将主路由和 Surge 分开以后，故障边界会更加明确：连接不上 Wi-Fi，首先检查 Mesh；无法获取地址，检查主路由；只有特定流量异常，再去检查 Surge 的策略和节点。

这也是我选择旁路由形态，而不是让 Surge 完全取代主路由的主要原因。网络的基础可用性和高级策略被拆开，平时维护起来更简单。

Mesh 只解决无线覆盖

无线部分使用 Mesh，主要目的就是在不同房间之间提供连续、稳定的 Wi-Fi 覆盖。

在这套结构里，我并不把 Mesh 当成所有功能的中心。它更接近主路由之后的无线接入层：让 iPhone、iPad、Mac 和其他设备在家中移动时保持连接，将设备稳定地带回同一个局域网。至于流量应该直连、经过哪个代理，或者如何从外部访问家庭设备，则交给 Surge 处理。

这种拆分也让更换设备变得容易。以后即使替换主路由或 Mesh，只要局域网的基本关系没有改变，Surge 上的大部分规则与 Ponte 连接仍然可以继续使用。

Surge 作为旁路由

Surge 是这套网络中负责“理解流量”的一层。相比让主路由同时承担拨号、无线覆盖、代理和远程访问，我更愿意让 Surge 专门处理规则匹配、策略选择、DNS 和连接观察。

家中的 Surge Mac 以旁路网关的方式接入局域网。需要统一策略的设备可以使用它处理流量，不需要的设备则保留普通的网络路径。这带来了两个直接好处：

主路由不需要安装额外的第三方系统，也不需要为了代理功能改变整个家庭网络。
Surge 出现问题时，影响范围可以控制在使用旁路网关的设备内，基础网络仍然存在。

不过，我日常使用最多的并不是“让所有设备强制经过旁路由”，而是在 iOS 和 macOS 上直接运行 Surge。Apple 设备上的 Surge 使用相同的规则思路和策略命名，配置与使用体验更容易保持一致；设备离开家庭 Wi-Fi 后，Surge iOS 也可以继续在蜂窝网络或其他 Wi-Fi 下工作。

旁路由因此更像家庭网络的公共能力，而不是每一台设备都必须经过的强制入口。对于能够直接安装 Surge 的 iPhone、iPad 和 Mac，我倾向于让设备自己处理策略；对于无法安装或不适合单独维护配置的设备，再由旁路网关提供能力。

用 Surge Ponte 连接家内与家外

仅有代理还不足以解决远程访问问题。我希望设备离开家以后，仍然能够安全地连接家中的服务，也希望不同 Apple 设备之间的连接方式尽量统一。Surge Ponte 正好承担了这一部分。

Ponte 会将运行 Surge 的设备组织成一个私有的设备网络。同一 iCloud 账户下的设备可以自动登记，远端设备既可以通过 <设备名>.sgponte 访问特定设备，也可以使用 DEVICE:<设备名> 策略，将匹配的流量发送到对应的 Ponte 设备。对我来说，它最大的意义不是“又多了一种代理”，而是把 Surge Mac 变成了从外部返回家庭局域网的入口。

理想情况下，Ponte 可以直接连接或通过 NAT 穿透建立通道。但实际网络环境并不总是理想：运营商 NAT、上游防火墙和 UDP 质量都会影响连接结果。为了让这条路径更加稳定，我使用了一台 BandwagonHost 服务器作为代理辅助通道。

这台服务器不是家庭网络的控制中心，也不保存家庭局域网的设备关系。它的任务是提供一条支持 UDP 转发的公网路径，在无法稳定直连时帮助 Ponte 建立连接。Ponte 会根据当前网络条件选择可用通道，数据链路保持端到端加密；中转服务器解决的是可达性问题，而不是代替 Surge 处理设备身份和家庭网络策略。

于是，在外面使用 iPhone 或 Mac 时，连接过程大致是：

iPhone / Mac
   │
Surge iOS / Surge Mac
   │
Surge Ponte
   ├── 直接连接或 NAT 穿透
   └── BandwagonHost 服务器辅助中转
             │
             └── 家中的 Surge Mac
                        │
                        └── 家庭局域网服务

我不需要把家庭服务直接暴露到公网，也不需要为每一个服务分别配置公网端口。远程设备只要运行 Surge 并加入同一个 Ponte 网络，就可以按照规则访问需要的目标。

为什么它适合 Apple 生态

这套配置和我的设备构成有很大关系。我的主要设备是 iPhone、iPad 和 Mac，网络工具则统一使用 Surge。

统一生态带来的优势并不只是“应用界面相似”。Surge Mac 和 Surge iOS 共享相同的核心配置思路，Ponte 设备又可以通过 iCloud 建立身份关系。设备在家里连接 Mesh，离开家以后切换到蜂窝网络，网络环境虽然改变了，但使用方式没有完全改变：规则仍然由 Surge 处理，需要访问家中网络时则交给 Ponte。

这种一致性比堆叠更多网络功能重要。家庭网络最终是为设备服务的，如果每一种设备都需要一套不同的连接方式和维护方法，系统很快就会变得难以管理。而在当前的设备构成下，Apple 生态与 Surge 的组合恰好减少了这部分差异。

这套配置的取舍

它并不是一套适用于所有人的标准答案。

首先，Surge Mac 作为旁路网关和 Ponte 服务端，需要一台能够长期在线的 Mac。其次，代理辅助的 Ponte 通道依赖外部服务器；服务器故障时，Ponte 仍可能尝试其他通道，但远程连接的稳定性会受到当时网络条件影响。最后，iOS、macOS 与非 Apple 设备之间的使用体验并不完全相同，这套方案的统一感很大程度上来自我的设备本身就集中在 Apple 生态。

作为交换，我得到的是清楚的职责划分：