全屋隐私网关：用两台 NAS 藏起全家的 IP

起因

我一直想让家里的网络更「隐身」一点，不想让各种网站、App 和 IoT 云看到我的家宽 IP，再顺着 IP 知道我大概住在哪。

之前做得很有限。家里有一台合盖当服务器用的 MacBook Pro，上面跑着 Surge，但只有我自己的电脑在用；DNS 交给了 AdGuard Home。其他三十来台设备全是裸连的，家人的手机平板、电脑、投影仪、摄像头、智能床、喂食器，连电动牙刷都直接连着外网。

年初也试过一次让 Surge 接管全屋，但单靠一台 Mac 当网关不够稳，没多久就撤了。这次重新来过，要求就两条：除了内网，所有流量都不能用家宽 IP 出去；任何一台机器坏了，家里都不能断网。

前后折腾了一周左右，几乎全程是在和 Claude Code 聊天，我提需求、拍板，它测速、写配置、部署和排查。下面按模块讲讲最后的方案，以及哪些坑值得注意。

整体方案

家里的设备不用改任何设置。路由器的 DHCP 把网关下发成 192.168.5.2、DNS 下发成 198.18.0.2，连上 Wi-Fi 就自动被接管了。

这个网关地址平时由 Mac 上的 Surge 持有。另一台装了 fnOS 的小主机上跑着 mihomo 做备用，Surge 失联时由它接管，Surge 回来再还回去。要是两台都挂了，家里就直接断网，不会悄悄从路由器直连出去。

出口分三个。大部分流量走我自建的 Linode 新加坡（Egress SG）；目标是大陆 IP 的，走机场的香港专线（Egress HK）；夸克、喜马拉雅、B 站这类非要大陆 IP 的服务，再从香港接到深圳的一台阿里云（Egress CN）。

两台网关的配置由同一个仓库生成，每天早上自动部署一次。网关上的每一条请求也都会被记下来，每天早上让 AI 审查一遍。

网关：让网关地址漂移起来

一开始想直接在路由器上做，可家里这台 TP-Link 没有 SSH，没有 USB 口，也刷不了 OpenWrt，什么都装不上。不想换路由器，就只能做旁路网关：路由器照常分配地址，只是把下发的网关指向家里的另一台机器。

旁路网关最怕单点故障。DHCP 只能填一个网关地址，就算能填好几个，手机电脑也不会自己在网关之间切换，所以得让网关地址本身能在机器之间漂移。Surge 的 VM 网关会在局域网里单独占一个 IP，有自己的 MAC，我把它固定在了 192.168.5.2。备用的小主机上用 keepalived 盯着这个地址，配置核心就两个检测：用 arping -D 看局域网里还有没有别人在应答 .2，再看 mihomo 自己是不是健康，两个都满足才接管。

vrrp_script surge_absent {
  # arping -D exits 0 only when no other host answers for the address.
  script "/usr/sbin/arping -D -q -c 2 -w 2 -I eth0 192.168.5.2"
  interval 3
  rise 2
  fall 2
}

vrrp_instance gateway {
  state BACKUP
  interface eth0
  virtual_router_id 52
  virtual_ipaddress {
    192.168.5.2/24 dev eth0
  }
  track_script {
    surge_absent
    mihomo_ready
  }
}

keepalived 跑不了 macOS，所以切换逻辑只能放在 Linux 这一侧。备用网关整个放在一个单独的网络命名空间里，用 macvlan 拿到自己的 MAC 和 IP，宿主机的路由和防火墙一点都不用动。切换一次大概 10 秒，已有的连接会断开重连。

两台网关跑的是两个不同的引擎，配置却只维护一份：先生成 Surge 的配置，再自动转换成 mihomo 的。逻辑规则、规则集、链式代理、DNS 空应答这些写法上的差异都交给转换器处理，再用测试保证两边对同一个请求的处理是一样的。

监控上有一点值得注意：主网关出问题的时候，Surge 的进程和 API 可能都还好好的，只是网关的虚拟网卡不收包了。所以我在 Uptime Kuma 里检查的是有没有局域网设备的连接正在经过 Surge，而不只是接口能不能访问。

出口

WARP 太慢

第一层出口原本打算用 Cloudflare WARP。功能上没问题，家宽 IP 藏住了，出口变成了 Cloudflare 的共享 IP，但在我家的宽带上，速度实在没法看：

问题出在运营商身上：家里到 Cloudflare 新加坡要先绕一段国际线路，延迟 40 ms 左右，到 Linode、Hetzner 却只要 4–9 ms；就算不走 WARP，直接从 Cloudflare 下载也只有 200 多 Mbps，本地再怎么调也没用。而且 WARP 只能藏住 IP，藏不住国家，在新加坡连上去，出口照样显示新加坡。如果你家宽带到 Cloudflare 的线路也不好，WARP 就不适合拿来做全家的出口。

自建 VPS

机场节点同样不适合。VPS 还没选好的时候，我临时拿机场节点给全家当出口，当天晚上就断网了：机场每个节点给单个用户的并发连接只有 256 条左右，全家的连接压在一个节点上，很快就被打满。

挑 VPS 最要紧的是从家宽到机房的线路，就算都在新加坡，也能差出好几倍，所以最好从家里直接测。这是我在晚高峰实测的结果：

最后选了 Linode 新加坡最便宜的 Nanode 1 GB，一个月 $5。和机场节点比，新建连接的首字节从 230–500 ms 降到了 37–52 ms。这样出口会显示新加坡，家宽 IP 是藏住了，国家没藏住。

WireGuard 还是 SS2022

协议一开始用的是 WireGuard，内核自带，服务端不用另装软件，看起来最省心。但实测下来，SS2022 更好：

WireGuard 要对每个 1.4 KB 左右的包单独加解密、转发和 NAT，而 SS2022 走的是 TCP，能用上网卡的分段卸载和 AES 硬件加速，同样的流量只花一半的 CPU。对只有一个核的小 VPS 来说，这点余量很重要。现在服务端只跑 sing-box 的 SS2022，主备两台网关都差不多能跑满家里 1.1–1.2 Gbps 的宽带。

这个出口还屏蔽了 QUIC，浏览器会自己退回 TCP。每台设备的 TCP 连接在局域网里就被 Surge 接住了，Wi-Fi 上丢的包当场就能补回来，所以走 TCP 并不比 QUIC 差，还能给服务器省点 CPU。另外我不想老是断网，所以服务器上任何会中断连接的更新都不让它自动跑，sing-box 只手动升级。

回国线路

很多国内网站在新加坡都有 CDN，走 Linode 也就几十毫秒。真正要单独处理的是两类流量：目标服务器只在大陆的，和必须看到大陆 IP 的。

我原本有一台深圳的阿里云，但从家里过去一个来回要 330–440 ms，还丢包，卡在进入大陆的国际入口上。好在机场有几条香港专线，晚高峰到大陆一个来回只要 104–148 ms。于是目标是大陆 IP 的流量走香港专线，需要大陆 IP 的服务再经香港链式连到阿里云。配置大致是这样的，节点名做了简化：

[Proxy Group]
Egress SG = fallback, 新加坡 Linode, 新加坡机场节点
Egress HK = fallback, 香港专线 1, 香港专线 2, 其他香港节点, url=http://oss-cn-shenzhen.aliyuncs.com/
Egress CN = fallback, 深圳阿里云, Egress HK, Egress SG

[Rule]
DOMAIN-SUFFIX,cn,Egress HK
GEOIP,CN,Egress HK
FINAL,Egress SG

阿里云那台跑的是 sing-box 的 AnyTLS，在 Surge 里用 underlying-proxy = Egress HK 把它套在香港出口后面，mihomo 里对应的是 dialer-proxy。

这里有几个 Surge 的坑。测速组最好用 fallback 而不是 url-test：url-test 一天会换十来次节点，套在后面的链路每换一次就慢上一阵，fallback 只有当前节点测试失败了才会往下切。Surge 还会忽略组上的 url=，只拿每个节点自己的 test-url 去测，没设就测全局的地址，所以想按到大陆的延迟来测速，得给每个节点单独加上 test-url。另外全局 3 秒的测试超时对跨境线路太紧，晚高峰只要慢一次就会被判失败，我给跨境节点单独放宽到了 8 秒。

堵住漏洞

网关上线以后，真正花时间的是把那些悄悄绕过它的流量找出来。

基础的几项先做好：hijack-dns = *:53 接管所有经过网关的 DNS 查询，不管设备自己填的是哪个 DNS，普通域名统一返回假 IP，方便按域名分流；节点转发不了的 UDP 直接丢掉，不回退成直连；ICMP 不转发，免得 ping 带着家宽 IP 出去；节点服务器的域名提前用 DoH 解析成 IP 写进配置，网关找节点就不依赖自己的 DNS。

最隐蔽的是 Surge 的「UDP 快速路径」。一台设备在 1 秒内往 40 个高位端口发 UDP 之后，出口就变成了家宽 IP。原来 Surge 会把「UDP 连接很多的设备」自动降级成直接转发，所有规则都被绕了过去，P2P、部分游戏、多人视频通话都有可能触发它。Surge 没有全局开关，只能在设备列表里一台台取消「允许 UDP 快速路径」，新设备默认又是开着的，这一处到现在都还没彻底解决。

iCloud 专用代理是另一个坑。它在家里的 Wi-Fi 上开着的时候，苹果设备的 DNS 查询都会被加密交给专用代理那边的解析服务，网关只能看到一堆裸 IP，按域名写的分流和去广告规则全都失效。好在 Apple 给网络管理员留了正式的关闭办法：只要网络的 DNS 对 mask.icloud.com 和 mask-h2.icloud.com 返回空结果，苹果设备就会在这个网络上自动停用专用代理。在 Surge 里加两条规则就行，pre-matching 会让它在 DNS 阶段直接返回 NOERROR、但不带任何记录：

DOMAIN,mask.icloud.com,REJECT,pre-matching
DOMAIN,mask-h2.icloud.com,REJECT,pre-matching

加上以后，我那台 MacBook 只有 IP、没有域名的请求从 70–82% 降到了 7–9%，专用代理的 QUIC 重试也没了。出了家门，专用代理照常工作。

另外，常用的手机平板最好在家里的 Wi-Fi 上关掉「私有无线局域网地址」，网关才能按固定的 MAC 认出它们。还有些设备会一直用着旧的网关配置，比如我家的喂食器，切换后整整一周都没经过网关，断电重启才回来。

该直连的流量

也不是所有流量都适合走代理。有的服务不认机房 IP，有的流量太大，还有的任务本身就该用家宽 IP，这几类最后都让它们从家里直接出去。

不认机房 IP 的服务

家里的 iPhone 在 Wi-Fi 下检查系统更新，一直提示「Unable to Check for Update」，切到蜂窝数据就好了。原来 Apple 对来自 Linode 的更新查询，每次都回一个固定的拒绝回复，于是检查更新、安装前的签名验证和更新包下载都改成了直连。

淘宝也一样。在机房 IP 后面，登录和打开页面老是被滑块拦住，只好让淘宝、天猫和它们的 CDN 也直连。不过直连规则排在广告拦截后面，阿里的跟踪和设备指纹接口照样拦着。

流量太大的

Linode 的 Nanode 每月只含 1 TB 出站流量，而它是中转，家里的上传和下载在它那里都算出站。第一个大头是 Home Assistant 的测速集成，它每小时自动测一次，一个月就要 350 GB 左右，而且全屋走网关以后，它测的已经不是家里的宽带了，直接关掉。

关掉以后还是每天 70–77 GB，是额度的两倍多，这回的大头是 Apple：Mac 上开着的 macOS 内容缓存每天替全家往 iCloud 传 15–21 GB，再加上 App Store 和 Apple CDN 的下载。超额其实不贵，每 GB 才 $0.005，不过为了省 Linode 的流量，我还是让 iCloud 上传、App Store 下载和 Apple CDN 走了直连。iCloud 还有一部分存储放在 Google Cloud 和 Amazon S3 上，一台 iPhone 一天就往 Google 那边传了 17.5 GB，这些也一起直连，S3 那边用 DOMAIN-WILDCARD 只匹配 Apple 的桶名：

DOMAIN-SUFFIX,content-storage-upload.googleapis.com,DIRECT
DOMAIN-SUFFIX,content-storage-download.googleapis.com,DIRECT
DOMAIN-WILDCARD,??-???-000??.s3.dualstack.*.amazonaws.com,DIRECT

本该用家宽 IP 的任务

网盘备份就是典型：光鸭对机房 IP 拿到的下载链接会限速到 35 KiB/s 左右，夸克在一阵大量上传之后，干脆拒绝了机房 IP 的 TLS 握手。iCloud 照片下载也属于这类。

这类任务都跑在 Docker 里，我在群晖和备用小主机上各建了一个固定网段的 Docker 网络 direct（172.30.0.0/24），再用源地址策略路由把它直接送到路由器：

100: from 172.30.0.0/24 lookup main suppress_prefixlength 0
101: from 172.30.0.0/24 lookup 100   # 表 100 里只有一条：default via 192.168.5.1

第一条查 main 表，但忽略里面的默认路由，所以访问内网和其他容器都照常；剩下去外网的包会落到第二条，从路由器直接出去。哪个容器要直连，在它的 compose 里加上这个网络就行：

services:
  app:
    networks:
      - direct

networks:
  direct:
    external: true

要注意的是，有些 NAS 系统会在开机或修改网络设置时重写路由规则，比如 fnOS 就会把写在 NetworkManager 里的规则冲掉，最后还是得用一个 dispatcher 脚本把它们补回来。

Mac 上的容器又是另一回事。OrbStack 里所有容器的流量，在 Surge 看来都是同一个进程发出来的，根本分不开。所以 Surge 开了一个只绑本机回环地址的直连入口 127.0.0.1:6160，配一条 IN-PORT,6160,DIRECT，要直连的容器把 HTTP_PROXY 指向 host.docker.internal:6160 就行。

广告和遥测

设备改成找网关要 DNS 以后，查询就不经过 AdGuard Home 了，所以过滤也得搬到网关上。我把 AdGuard Home 用的过滤列表转成了 Surge 的域名集，mihomo 那边是规则集。

让我开始重视遥测的，是审查发现我的 MacBook 一天往 sentry.netease.com 传了四五百 MB。查下来是网易 UU 远程的 Mac 被控端，它把两个各 10 MB 的日志文件挂在每个 Sentry 事件上，iPad 每连进来一次就发一次。拦掉之后，我开始找有没有别人维护好的隐私和上报拦截列表。测法是从网关日志里取出家里两天里实际访问过的 1,591 个主机，看每个列表加进来以后，会新增拦掉哪些：

现在用的是 AdGuard DNS filter、uBlock Badware、HaGeZi Pro，再加上 HaGeZi 的威胁情报列表 TIF medium，加起来一百万条左右。威胁情报要新鲜才有用，所以每天早上自动部署一次。

列表这么大，Surge 有两个坑要注意。一是单个域名集最多只能放 100 万条，超过了会直接拒绝加载，配置检查却发现不了，我第一次上完整版 TIF 时，主网关整整 3 分钟什么都没拦。二是 Surge 重载时只应用有变化的配置段，域名集又按路径缓存，所以只更新列表、不改配置的话，新列表根本不会生效，得给每个版本换一个文件名。

拦得多了，难免误伤。豆包输入法要从 is.snssdk.com 下载语音识别的配置，拿不到就直接无视语音快捷键，连个报错都没有；淘宝直播的分享页也打不开。碰到这种情况，只放行必要的那一个域名就好，后面的统计和设备指纹接口照样拦着。

国内服务和智能家居

B 站

B 站看到新加坡 IP，就把视频分给海外镜像，没缓存过的视频单连接只有 3–10 Mbps，高画质根本跟不上。换成大陆 IP，B 站会分配大陆的 CDN 和 PCDN，实测 30–80 Mbps，冷门视频也很稳。只让 api.bilibili.com 走大陆还不够，打开视频页的时候，播放地址就直接嵌在页面里，B 站是按请求页面的 IP 来分配 CDN 的，所以 B 站的网页和 App 接口都得走 Egress CN。

看直播时还碰上过机场的「公平使用」限速。原因是直播播放器的 P2P 每 20 秒向 stun.chat.bilibili.com 一口气发两百多个 STUN 请求，经过阿里云这条链路，每个请求都要在机场那边新开一条连接，这么多短连接成批冒出来，大概就被当成了在跑 P2P。可这个 P2P 几乎没干活，画面都是从 CDN 拉的，所以干脆在 DNS 阶段拒绝掉 B 站的 STUN 服务器，弹幕不受影响：

AND,((DOMAIN-SUFFIX,chat.bilibili.com),(DOMAIN-KEYWORD,stun)),REJECT,pre-matching

智能家居

智能家居设备是另一类麻烦，它们大多离不开厂商的云，而且很在意自己是从哪个地址连过去的。

家里的海马爸比婴儿摄像头，视频走的是腾讯云物联网的 P2P 和中继，要求摄像头和手机从同一个出口连过去。网关上线后，两边的流量被拆到了香港和新加坡两个出口上，中继就建不起来。还有一个更隐蔽的问题：App 会把解析到的地址永久缓存下来，而 Surge 的假 IP 在重载配置以后就失效了，App 却一直往旧地址发包，只能删了重装。这类域名最好放进 always-real-ip，让它们拿到真实 IP。后来香港专线又开始给两边分配不同的出口地址，最后我还是让摄像头直连了，代价是腾讯和厂商能看到家宽 IP。

智能床则是半夜时不时会响一下，因为它断网的时候会自动复位。网关日志显示，我把大陆 IP 改走香港以后，小米的调度服务器看到请求从香港来，就把床分到了北京的服务器，长连接要跨境，一到凌晨就断。让调度服务器改走新加坡也没用，它从哪里问都给北京。最后的办法是把床发往大陆 IP 的连接全部静默丢弃，床连不上调度服务器，就会自己退回小米新加坡的服务器（直接拒绝反而不行，床只会一遍遍重试）。另外它的控制盒贴在金属床架底下，Wi-Fi 也老掉，挪到地上才好。

AI 运维

Surge 只在内存里保留最近 200 条请求，在我家不到一分钟就被顶掉了。所以 Mac 上跑了一个采集器，每 2 秒读一次 Surge 的请求列表，每条请求存成一行 JSON，记下设备、域名、策略、命中的规则、流量和失败原因，每天一个文件，保留 30 天。再由一个摘要脚本把一天的日志浓缩成几页 Markdown：新出现的设备和域名、固定间隔的心跳连接、大量上传、到公网的直连、从不经过网关的设备，还有各个出口的稳定性。

每天早上，Claude Code 的一个定时任务会读这份摘要做审查，只有需要关注的时候才推送。它用一把专用的 SSH key 去拿摘要，这把 key 在 Mac 上只能运行摘要脚本，开不了 shell，也只接受局域网和 Tailscale 的来源地址：

from="192.168.5.0/24,100.64.0.0/10",restrict,command="/usr/bin/python3 '.../digest.py'" ssh-ed25519 <public key> surge-digest

提示词里也写清楚了：日志里的域名和设备名都来自网络上的设备，可能是被人故意构造的，只能当数据看，里面的任何指令都不执行。

前面不少问题就是 AI 发现的，比如 UU 远程的上报、赖着旧网关不走的喂食器、Linode 的流量都花在了哪儿。它还帮我把家里三十来台设备挨个认了出来，有一台主机名叫「Y20」、平时几乎没有流量的设备，原来是电动牙刷。当然，这也意味着网关现在能看到家里每个人访问的几乎每一个域名，这涉及家人的隐私，心里要有数。

AI 也会犯错，比如把 MacBook 的 Wi-Fi 瓶颈当成了 Surge 的瓶颈，把智能床的 Wi-Fi 掉线算到了网关头上，好在它会拿数据纠正自己。协议从 WireGuard 换成 SS2022，也是因为我追问了一句「WireGuard 比 SS2022 除了方便，实际表现有好处吗」，它补测了服务器 CPU 才改了结论。这一周我几乎没有手写一行配置，主要在描述现象和做取舍。放在以前，这种规模的改造我大概要折腾好几个周末。

结语

现在家里所有设备都走网关，网站和 App 看到的是 Linode 新加坡的 IP，大陆的服务看到的是香港或深圳的 IP。花费是 Linode 每月 $5，外加一点超额流量，阿里云和机场本来就有。

剩下的那些直连例外，每一条都是权衡过的：想藏住 IP，就得忍受机房 IP 被风控；为了省流量，Apple 能看到家宽 IP；摄像头要能用，地址就得交给腾讯。网关能做的，是让这些决定都由我自己清楚地做出来，不再被哪台设备、哪个 App 悄悄替我做了。