问题背景
这次排查的是 macOS 上使用 Shadowrocket 开启 TUN 后，UU 远程桌面连接是否被 Shadowrocket 接管的问题。
当时的担心很直接：UU 远程本来应该尽量走国内节点直连，如果被 Shadowrocket 的代理线路接管，就可能出现速度慢、延迟高或者远程桌面体验不稳定。尤其是在 TUN 模式下，系统默认路由会进入 Shadowrocket 的虚拟网卡，单看路由表很容易误判。
最后确认下来，关键不是看应用流量有没有进入 TUN，而是看 Shadowrocket 核心最终是不是把 UU 节点按 `DIRECT` 从真实网卡发出。
现象
排查时看到 UU 远程进程里有类似这样的连接：
“`text
198.18.0.1 -> 61.153.100.68:443
198.18.0.1 -> 221.228.204.188:443
127.0.0.1 -> 127.0.0.1:1082
“`
系统路由也显示默认流量进入了 TUN：
“`text
default -> utun7
61.153.100.68 -> utun7
61.174.14.98 -> utun7
“`
一开始很容易把这理解成“UU 已经走了 Shadowrocket 的代理”。但后来对照 Shadowrocket 核心进程的最终出口后发现，这个判断不完整。
在 TUN 模式下，应用侧看到 `198.18.0.1`，往往只是说明流量先进入了 Shadowrocket 的虚拟入口。真正要判断是否走代理，要看 Shadowrocket 核心最后怎么出网。
后续测试中，`MacPacket` 显示 UU 节点是从本机真实局域网地址直连出去的：
“`text
192.168.2.3 -> 61.153.100.68:443
192.168.2.3 -> 61.153.100.70:443
192.168.2.3 -> 61.153.100.69:2680
192.168.2.3 -> 61.153.100.70:2681
192.168.2.3 -> 61.174.14.98:2680
192.168.2.3 -> 101.69.115.21:2680
“`
这说明 UU 远程最终是直连出去的，`default -> utun7` 本身并不等于“最终走代理”。
排查过程
一开始先尝试用比较宽的规则：
“`text
GEOIP,CN,DIRECT
“`
这条规则的作用是：访问中国大陆 IP 时全部直连。它确实能让 UU 的国内节点直连，但问题也很明显：它影响的是所有应用，不只是 UU 远程。
如果目标只是让 UU 远程直连，而其他 App 仍然按原来的代理规则走，`GEOIP,CN,DIRECT` 就太宽了。
随后把注意力放到几个更窄的方向：
第一种是按进程直连，例如：
“`text
PROCESS-NAME,UURemoteS,DIRECT
“`
这是最理想的方向，因为它只影响 UU 远程这个进程。但当时没有确认当前 Shadowrocket 配置界面是否支持这类进程规则。
第二种是按 UU 当前实际连接到的 IP 或 IP 段直连。这个方案比 `GEOIP,CN,DIRECT` 窄很多，也更符合“不影响其他 App”的目标。
排查过程中抓到的 UU 节点包括：
“`text
61.153.100.68
61.153.100.69
61.153.100.70
61.174.14.98
221.228.204.185
221.228.204.188
223.252.194.149
101.69.115.21
“`
为了避免单个 IP 过窄导致下次节点变化就失效，最终建议使用几个相对收敛的 IP 段和单 IP 组合。
解决方法
最终建议在自己的 Shadowrocket 配置 `my.conf` 的 `[Rule]` 中加入这些直连规则。
如果 `my.conf` 已经包含默认配置，可以保留：
“`text
[General]
include = default.conf
“`
然后在 `[Rule]` 里使用这种结构：
“`text
[Rule]
# Local network
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
# My VPS
IP-CIDR,161.117.251.238/32,DIRECT
IP-CIDR,8.219.75.241/32,DIRECT
# UU Remote
IP-CIDR,61.153.100.0/24,DIRECT
IP-CIDR,61.174.14.0/24,DIRECT
IP-CIDR,221.228.204.0/24,DIRECT
IP-CIDR,223.252.194.149/32,DIRECT
IP-CIDR,101.69.115.21/32,DIRECT
# Custom proxy rules
DOMAIN-SUFFIX,steampowered.com,PROXY
DOMAIN-SUFFIX,campsaver.com,PROXY
DOMAIN-SUFFIX,99re.com,PROXY
DOMAIN-SUFFIX,reddit.com,PROXY
DOMAIN-SUFFIX,heiliao.com,PROXY
DOMAIN-SUFFIX,decathlon.com.hk,PROXY
DOMAIN-SUFFIX,w1226.9p58b.com,PROXY
DOMAIN-SUFFIX,missav.ws,PROXY
# Custom direct rules
DOMAIN-SUFFIX,cloud.sinovale.com,DIRECT
DOMAIN-SUFFIX,route.sinovale.com,DIRECT
DOMAIN-SUFFIX,sinovale.com,DIRECT
“`
如果不想让所有国内 IP 都直连，可以把这条保持注释：
“`text
#GEOIP,CN,DIRECT
“`
这样配置更精确：只让局域网、自己的 VPS、UU 远程相关节点直连，不会像 `GEOIP,CN,DIRECT` 那样影响所有中国大陆 IP。
保存后需要重启 Shadowrocket，或者至少断开后重新连接配置；UU 远程也建议退出后重新打开，再重新发起一次远程桌面连接。
注意事项
第一，不要只看 `UURemoteS -> 198.18.0.1` 就判断 UU 最终走了代理。TUN 模式下，应用流量先进 Shadowrocket 是正常现象。
更可靠的判断标准是看 Shadowrocket 核心的最终出口。如果能看到类似：
“`text
192.168.2.3 -> 61.153.100.68:443
192.168.2.3 -> 61.174.14.98:2680
“`
说明 Shadowrocket 最终是用真实网卡直连 UU 节点。
第二，`default.conf` 里的“跳过代理”和“TUN 旁路路由”主要覆盖内网地址，例如：
“`text
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
“`
这些能保护访问路由器、NAS、局域网远程桌面、Docker 或虚拟机地址，但不会自动覆盖 UU 的公网节点。
第三，UU 节点可能会变化。现在这组 IP 段是根据当时实际连接观察整理出来的，如果以后 UU 远程又变慢，可以重新抓当前连接，补充新的 UU 节点 IP 段。
第四，`alisgp2` 和 `alisgp3` 的两条规则是为了让访问这两台 VPS 的流量也直连：
“`text
IP-CIDR,161.117.251.238/32,DIRECT
IP-CIDR,8.219.75.241/32,DIRECT
“`
这会让访问这两个 IP 的所有流量都直连，包括 SSH、面板和代理节点本身。这个行为符合当时的目标，但如果以后网络策略变化，需要重新评估。
总结
这次问题的关键结论是：Shadowrocket 开启 TUN 后，看到 UU 远程进入 `198.18.0.1` 或系统默认路由进入 `utun7`，并不能直接说明 UU 最终走了代理。
真正要看的是 Shadowrocket 核心最后的出口。如果 `MacPacket` 使用本机真实局域网地址连接 UU 的国内节点，就说明 UU 已经按 `DIRECT` 直连。
最终采用的做法，是不用宽泛的 `GEOIP,CN,DIRECT` 兜底，而是在 `my.conf` 里添加更窄的 UU 节点规则。这样既解决了 UU 远程走 Shadowrocket 流量的担心，也尽量避免影响其他 App 的分流策略。