玩转利群马年创始版CN2／9929 双出口主机

利群LeiKwan Host

• 利群（LeiKwan Host）马年创始版CN2&9929 出口机能让普通海外落地“借道”CN2 或 9929，但它没有独立公网 IPv4，入站只有会变化的 IPv6，日常直接连接很不方便。
• 解决办法：用一台阿里云或腾讯云服务器做固定的公网 IPv4 入口，利群主动用 WireGuard 连上它；客户端连接云服务器，流量经隧道进入利群，再按落地 IP 选择 CN2（eth1）或 9929（eth0）出口，最后到达已有的 Snell v6 落地。
• 前置和利群都不运行 Snell，只做 DNAT/SNAT 和策略路由。整套基于 Debian 12/13 + WireGuard + nftables + systemd，可重复部署、可回滚。

[!NOTE] 文中所有公网 IP 和入口端口均已替换为 RFC 5737 文档保留地址（192.0.2.0/24、198.51.100.0/24、203.0.113.0/24）和示例端口，请换成你自己的实际值。利群的 10.7.x.x / 10.8.x.x、隧道 10.204.0.x 等私网地址保持原样，便于对照。

目录

1. 认识利群双出口主机
2. 为什么需要阿里云或腾讯云做入口
3. 整体架构与关键概念
4. 购买前用 Looking Glass 预判落地
5. 利群主机初始化
6. 套件文件与参数
7. 前置准备和防火墙
8. 确认利群出口并测量落地
9. 创建密钥并配置拓扑
10. 安装前置与利群中转
11. 客户端接入及验收
12. 新增、删除落地和切换出口
13. 阿里云与腾讯云同时做前置
14. 排错、重载与重启
15. 备份、回滚和迁移
16. 实测数据与参考资料
17. 写在最后

1. 认识利群双出口主机

1.1 产品规格

本文使用的是利群上海的 CN2&9929 双出口产品（以“馬年創始經典 CN2&9929”为例，价格和库存以官网为准）：

1.2 它不是“线路机”，而是“出口中转机”

平时说某台 VPS 是“CN2 线路机”“9929 线路机”，指的是商家为机房购买了优化线路带宽，用户连到这台 VPS 的那一段质量更好。

利群这款产品的玩法不同：它位于上海，它自己连出去的时候可以选择走 CN2 还是 9929。也就是说，你可以让它通过 CN2／9929 去连接你已有的海外落地，把一台原本绕路、高延迟、丢包明显的普通落地，“改造”成体验接近线路机的节点：

日本、新加坡、中国香港、中国台湾以及部分欧美落地都可以尝试这样优化。但它并不能让任何落地都“立刻变好”，实际效果仍取决于目标机房的上游、互联质量和回程策略——所以购买前一定要先做第 4 节的测试。

1.3 网络形态：4 个 IPv6，没有独立 IPv4

这是理解本文方案的关键。利群主机的网络和普通 VPS 很不一样：

也就是说：利群“出去”很强（两条优化 IPv4 出口），但“进来”很弱（只有动态 IPv6）。

1.4 适合谁、不适合谁

• 适合：已有海外落地，想通过 CN2／9929 优化到落地这一段链路；能看懂 ip、nft、wg 输出的用户。
• 不适合：只想买一台普通国内 VPS 建站的用户，或者完全不了解路由配置的新手。

2. 为什么需要阿里云或腾讯云做入口

既然利群只有 IPv6 入口，为什么不让客户端直接连它的 IPv6？在实际使用中会遇到这些问题：

1. 很多网络没有 IPv6：公司网络、部分家庭宽带、酒店／公共 Wi-Fi、境外漫游等场景只有 IPv4，客户端根本连不上。
2. IPv6 地址会变：入口地址是动态的，必须配合 DDNS；而 DNS 缓存、客户端是否重新解析都会带来断连窗口。
3. 运营商匹配问题：只有电信、联通两个入口，移动用户或跨运营商访问时质量不可控。
4. IPv4 端口映射只给 SSH：不能把它当成通用业务入口。

所以本文的思路是：用一台国内云服务器补上“稳定的 IPv4 入口”。

为什么这样做可行？因为利群虽然“进不来”，但“出得去”：

• 利群主动向云服务器公网 IPv4 的 8443/UDP 发起 WireGuard 握手，并每 25 秒发送一次 Keepalive；
• 利群 NAT 后的公网地址即使变化，也会随下一次握手自动更新，完全不依赖利群的 IPv6，也不需要 DDNS；
• 云服务器只负责“接客”，收到流量后通过隧道交给利群，由利群决定走 CN2 还是 9929。

实测范围说明：本文的阿里云单前置 → 利群 → 六台 Snell v6 落地已通过 Surge 的 HTTPS、UDP 与出口 IP 验收；腾讯云前置与双前置使用完全相同的 Linux 转发方案，脚本已在隔离网络命名空间中验证，但没有在腾讯云上做端到端部署，请自行验收。

3. 整体架构与关键概念

数据流分三段：

1. 前置：对指定 TCP 端口做 DNAT + SNAT，把流量送到利群的隧道地址。
2. 利群：按入口端口 DNAT 到具体落地；用目标 IPv4 的 /32 路由选择出口，并按该出口的源地址做 SNAT。
3. 回包：沿同一条 conntrack 记录逐级还原。

几个容易混淆的点：

• 前置和利群都不运行 Snell。认证和代理协议仍由落地的 Snell 处理，所以落地 IP、端口、PSK、版本必须一一对应；客户端只需把服务器地址改成前置公网 IP、端口改成 entry_port。不要把 Snell 配置当成 SOCKS5 配置。
• 只转发 TCP。Snell v6 的 UDP 代理业务通过它自己的 TCP 连接承载，因此本方案只映射业务 TCP 端口；WireGuard 隧道本身另用 UDP。它不是通用的原生 UDP 端口转发器。
• 带宽和流量要算两遍。整条链路的速度取决于“前置带宽、利群 100 Mbps、落地带宽”中最小的一个。利群的 399 GiB 是双向计费，作为中转时流量“从落地进、向前置出”，用户每用 1 GB，利群大约消耗 2 GB 额度（另加少量 WireGuard 封装开销）。云服务器前置如果按流量计费，也要算上它的出网费用。

4. 购买前用 Looking Glass 预判落地

买之前最难判断的是：我的落地到底适不适合接在利群后面？ 利群提供了官方 Looking Glass，可以直接从 CN2 和 9929 两个节点测试你的落地 IP。

1. 左侧选择 CN2 或 9929 节点（SDWAN 节点本质上也是 CN2／9929 的应用，测这两个就够了）；
2. 选择 PING，输入落地 IP 开始测试，两个节点各测一次；
3. 选择 NEXTTRACE，输入落地 IP，查看两条出口的实际路径。

举个例子：某个日本落地从 CN2 节点 Ping 约 78 ms，从 9929 节点约 34 ms；NextTrace 显示 CN2 是先绕香港再去日本，而 9929 是从上海直达东京。那么这台落地就更适合走 9929。

5. 利群主机初始化

5.1 重装系统

在利群面板中重装系统，推荐 Debian 12（bookworm）：部分软件和脚本对 Debian 13 的兼容性还不够好。本文套件在 Debian 12/13 上均可运行。

5.2 首次登录与开启 root SSH

利群使用的是官方 Debian 镜像，默认不允许外部 SSH 工具用 root 登录（参考官方说明）：

1. 在面板点击 Open Xterm.js Console，用 root 和面板提供的密码登录；
2. 在控制台执行官方脚本（10.10.10.10 是利群内网地址，只能在利群主机内访问）：

wget http://10.10.10.10/fix-root.sh
less fix-root.sh
chmod +x fix-root.sh
bash fix-root.sh

5.3 外部 SSH 登录

IPv6 登录：在控制台执行 ip a，在 eth0 下能看到类似内容：

240e: 开头的是电信入口，2408: 开头的是联通入口，优先选择和你本地宽带同运营商的地址。注意上例中电信地址已是 deprecated（preferred_lft 0sec），说明它即将被替换——这正是“IPv6 入口会变”的直观体现。看不懂输出可以参考官方快速入门。

IPv4 登录：按官方说明找到分配给你的 SSH 映射端口，用 ssh -p 端口 root@地址 登录。日常管理推荐用这个方式，比 IPv6 稳定。

5.4 系统更新与基础优化

apt update && apt upgrade

如果升级了内核等需要重启的组件，重启后确认 SSH、网卡是否正常。

利群官方提供了 BBR／系统优化脚本（说明）。建议先下载阅读再执行，并记录前后参数：

[!NOTE] 本方案中前置和利群只做透明 TCP 转发，并不终止客户端到落地的 Snell 连接；WireGuard 外层又是 UDP。所以只在中转机开 BBR，不会让端到端连接自动用上 BBR，也无法消除线路绕行。真正决定体验的仍是出口选线。

5.5 安装诊断工具

NextTrace（查看路由路径）。原帖用的是 curl -sL nxtrace.org/nt | bash，更稳妥的做法是先下载再执行：

apt-get install -y curl
curl -fL https://nxtrace.org/nt -o nexttrace-install.sh
less nexttrace-install.sh
bash nexttrace-install.sh
nexttrace --help

iperf3（吞吐测试）：

apt install iperf3

安装时可能弹出“是否作为系统服务开机自启”的对话框，选择 No。用完后执行 pkill iperf3，避免服务端一直挂着被人刷流量。

6. 套件文件与参数

配套套件的目录结构如下：

默认参数如下。隧道内网地址需要避开你现有的 VPC、VPN 和容器网段。

示例里的腾讯云地址 203.0.113.20 是占位符，必须替换。所有 REPLACE_*_PUBLIC_KEY 都要填入新主机自己生成的公钥，不能照搬旧服务器的公钥。

7. 前置准备和防火墙

以下步骤会区分“前置”和“利群”；所有 Linux 命令以 root 执行。沿用你现有的 SSH 登录方式即可，不必为了本文重装已正常工作的云服务器或修改 root 登录策略。

7.1 安装依赖、上传套件

在每台前置和利群上：

apt-get update
apt-get install -y python3 wireguard-tools nftables iproute2 iputils-ping traceroute tcpdump unzip

在本地终端用 scp/SFTP 把套件上传到每台服务器的 /root/（地址和端口按自己的实例填写）：

scp leikwan-rebuild-kit-2026-10-18.zip root@前置公网IP:/root/
scp -P 利群SSH映射端口 leikwan-rebuild-kit-2026-10-18.zip root@利群SSH域名:/root/

在每台服务器上解压并校验：

cd /root
unzip leikwan-rebuild-kit-2026-10-18.zip -d /opt
cd /opt/leikwan-rebuild-kit
sha256sum -c SHA256SUMS

所有机器使用同一份拓扑文件。以阿里云单前置为例：

cp examples/topology-ali.json topology.json

腾讯云单前置改用 topology-tencent.json，双前置改用 topology-dual.json，三选一即可。

7.2 先记录现有网络和防火墙

ip -br -4 addr
ip -4 route show table all
ip -4 rule
nft list ruleset
sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
ss -lntup

首次安装时，套件会把原始路由、策略规则和 nftables 规则备份到 /var/backups/lq-rebuild-<时间戳>/。它只管理 table ip lq_rebuild 和自己记录在案的目的路由，不会执行 flush ruleset，也不会覆盖 /etc/iproute2/rt_tables。

已有的 UFW、firewalld、Docker 或其他 nftables 基础链可能会另外丢弃转发包——本套件里的 accept 无法绕过其他基础链的 drop，需要在原防火墙中按相同方向放行。如果是新建的专用中转机，建议只保留一种、自己看得懂的防火墙管理方式。

7.3 需要放行的端口

示例拓扑中六台落地的入口端口为 20001–20006/TCP，不需要再开放同号 UDP。如果落地限制了来源 IP，应放行利群对应出口 NAT 后的公网源 IP——既不是利群的 10.7/10.8 私网地址，也不是前置的公网 IP。

8. 确认利群出口并测量落地

8.1 逐台确认接口映射与骨干特征

本次利群主机的两套出口对应关系如下：

换机器后，先执行 ip -br -4 addr 查看真实网卡地址，再结合服务商说明和 NextTrace／traceroute 确认对应关系。例如用 NextTrace 测一台东京落地（以示例地址 198.51.100.50 说明）：

• 走 CN2 时：第一跳 10.8.0.1，中间经过 59.43.* [CN2-BackBone]；如果该落地对 CN2 不友好，可能会看到先绕香港（如 59.43.183.* 中国 香港 → NTT／GSL 清洗）再到东京，延迟升到 75–80 ms；
• 走 9929 时：第一跳 10.7.0.1，中间经过 210.13.67.* / 218.105.* AS9929 [CNC-BACKBONE]，从上海直跳东京 NTT，延迟降到 35 ms 左右。

在 topology.json 的 exits 中填入两套真实参数。源地址必须已经配置在该接口上，网关必须可达。脚本不会自动猜测，也不会修改默认路由。

8.2 添加待测落地

在 nodes 中为每台落地写一条，例如：

测线脚本会对配置中的每个出口分别测试，不受节点当前 exit 字段影响；exit 只是最终部署时的选线结果。此时公钥仍可保留占位符，测线不需要 WireGuard，也不需要 Snell PSK。

8.3 在利群上同时测两条出口

测单台：

cd /opt/leikwan-rebuild-kit
python3 scripts/probe-exits.py --config topology.json --node BageVM-HK --trace --output BageVM-HK-results.json

测全部：

python3 scripts/probe-exits.py --config topology.json --output all-exits-results.json

默认对每个“落地 × 出口”组合 Ping 100 包、TCP 建连 30 次，超时 3 秒；多个落地逐个测试，避免并发过多干扰结果。可用 --ping-count 300 --tcp-count 60 做更长抽样（上限分别为 300 和 60）。原始数据写入 JSON，超时样本单独列出，不会被悄悄剔除。

脚本的工作方式：

• 临时创建编号从 31000 起的路由表、优先级从 13100 起的策略规则，规则同时限定源 IP 和目标 /32；
• 创建前检查是否已被占用，再用 ip route get 目标 from 源IP 确认确实走了对应出口；
• 结束后逐条清理自己创建的规则，不切换整机默认路由；已有的生产 /32 路由也不影响对照测试。

正常结束或按 Ctrl+C 后，确认 JSON 中的 cleanup_errors 为空、ip -4 rule 没有残留。如果进程被 kill -9 或机器断电，finally 来不及执行，请按 JSON／脚本中记录的精确命令逐条清理临时规则，不要清空整机路由表。

8.4 如何选线

按以下优先级评估：

1. 实际业务是否可用；
2. TCP 建连失败率与秒级卡顿；
3. Ping 丢包与抖动；
4. 成功样本的中位延迟。

两条线路只差几毫秒时，通常优先选更稳定的那条。

解读数据时注意：Ping 不通可能只是 ICMP 被禁；Ping 正常也不代表 Snell 端口建连正常。traceroute 中间跳超时不等于终点丢包，某个中间路由器 RTT 高也不等于业务延迟高；去程 traceroute 更无法证明回程路径。最终一定要经过前置做真实的 Snell 验收。

把选定的线路写回各节点的 exit。本方案按“目标 IPv4”选路，因此同一个 IPv4 上的不同 Snell 端口必须走同一出口。如果需要同 IP 按端口分出口，得换成基于连接标记（fwmark）的策略路由设计。

9. 创建密钥并配置拓扑

9.1 每台机器各自生成密钥

在利群和每台前置上分别执行：

cd /opt/leikwan-rebuild-kit
python3 scripts/setup.py keygen

命令只输出公钥；私钥保存在本机 /etc/wireguard/wg-lqr.key（权限 600），重复执行会沿用已有密钥而不是重新生成。把输出分别标注为“利群公钥”“阿里云公钥”“腾讯云公钥”，填入同一份 topology.json 对应的 public_key。

公钥可以随意复制；私钥不要出现在教程、客户端配置或任何共享压缩包里。安装时会校验本机密钥与所选角色是否匹配，角色填反会直接退出。

9.2 编辑并同步拓扑

在一份 topology.json 中补齐以下内容，然后同步到所有参与的机器：

1. 每台前置的 public_ip、local_ip、interface 和 public_key；
2. 利群的 relay.public_key，以及两个出口的真实源地址、网关和网卡；
3. 全部落地的 IP、真实端口、唯一入口端口和实测出口；
4. 互不重复、不与现有网段冲突的隧道内网地址。

格式检查与配置预览：

腾讯云使用 --role tencent。预览会输出生成的 WireGuard 配置、nftables 规则和目的路由，私钥位置显示为占位符，不会读取或打印真实私钥。preview 允许公钥是占位符，真正 install 时则要求所有公钥有效。

10. 安装前置与利群中转

安装前请确认：云端端口已放行、机器上没有旧版中转、入口端口没有被其他服务占用。用 ss -lntup 核对，尤其不要和真实 SSH 端口冲突。安装器会拒绝把 22 用作业务入口，并检查当前 TCP/UDP 监听占用；但非标准 SSH 端口和已有的 NAT 转发规则仍需你自己核对。

10.1 前置

阿里云：

cd /opt/leikwan-rebuild-kit
python3 scripts/setup.py install --config topology.json --role ali

腾讯云：

cd /opt/leikwan-rebuild-kit
python3 scripts/setup.py install --config topology.json --role tencent

只用一个前置时，执行对应的一条即可。前置的 WireGuard 不写利群 Endpoint，而是等待利群主动握手，所以刚装完没有 handshake 是正常的。

10.2 利群

cd /opt/leikwan-rebuild-kit
python3 scripts/setup.py install --config topology.json --role relay

安装器只负责首次安装，检测到本套件或旧套件已存在就会退出。以后的修改一律走“编辑配置 + reload”，不要反复运行安装器。安装失败时会停止本次新建的服务，但保留配置和备份以便排查，修正后直接启动已有服务即可。

安装完成后会生成：

服务每次启动或重载时会设置 net.ipv4.ip_forward=1、all.rp_filter=0、相关接口 rp_filter=2（宽松模式），以支持多出口回程。这些参数只在运行时应用、由服务开机恢复，不会额外写一份可能互相冲突的 sysctl 配置文件。

10.3 先验证隧道

每台机器：

systemctl is-active wg-quick@wg-lqr lq-rebuild
systemctl is-enabled wg-quick@wg-lqr lq-rebuild
wg show wg-lqr

在前置上 Ping 利群：

ping -c 20 10.204.0.254
ping -M do -s 1372 -c 3 10.204.0.254

在利群上 Ping 前置：

ping -c 20 10.204.0.1
# 腾讯云单前置改测 10.204.0.2；双前置两个都测

确认 latest handshake 时间较新、收发字节在增长。本次部署阿里云 ↔ 利群约 8 ms，仅供参考。1372 是 MTU=1400 时不分片的 IPv4 Ping 载荷（1400 − 20 − 8），改 MTU 时相应调整。

如果需要进一步测“前置 ↔ 利群”隧道的吞吐上限，可以用 iperf3（只在隧道内监听，无需对公网开放 5201）：

[!IMPORTANT] 这测的是 WireGuard 隧道本身的吞吐（受利群 100 Mbps 带宽封顶），不是完整 Snell 代理吞吐；不要把现有的 Snell 端口拿给 iperf3 测。先把隧道和 MTU 调通，再去排查 Snell。

11. 客户端接入及验收

11.1 Surge 节点

把 examples/Surge节点模板.conf 中的节点行合并到你现有的 [Proxy]，填入前置公网 IP 和每台落地的真实 PSK，再加入需要的策略组。不要用这个片段覆盖整份 Surge 配置。

实际配置中请保留策略组原有成员，只追加新节点。入口端口与落地端口不同时，客户端填 entry_port。不同落地的 PSK 不能混用。

11.2 真实业务验收

macOS 版 Surge 的 CLI 一般位于：

--check 只校验候选文件；要先把通过校验的修改写入当前正在使用的配置，reload 才会加载它。其他客户端可以用等效的代理延迟、HTTPS、UDP 与出口 IP 检测代替。

验收标准（需同时满足）：

• 节点认证成功；
• HTTPS 探测返回 204；
• UDP 测试成功；
• 出口 IP 与落地一致。

每个节点连续测 5–10 轮，关注失败次数和长尾延迟，不要拿单次最低值下结论。

11.3 验证真实出口

只看客户端出口 IP 无法区分 CN2 和 9929——两者最终都落在同一台落地上。要在利群上抓包确认，以 BageVM 为例：

ip -4 route get 192.0.2.16
ip -N -4 route show proto 186
nft list table ip lq_rebuild
tcpdump -nn -i any -c 12 'host 192.0.2.16 and tcp port 20006'

此时在客户端发起节点测试，抓包应看到 eth1 Out 10.8.1.167 → 192.0.2.16:20006，即确实走了 CN2。

首次验收完成后，建议在业务空闲时做一次重启恢复测试（会断开当前隧道连接）：

systemctl restart wg-quick@wg-lqr lq-rebuild

再次确认隧道、路由和节点业务均已恢复。套件的关键逻辑已在隔离网络中验证过，但新主机上的这一轮实际环境验收仍不可省略。

12. 新增、删除落地和切换出口

12.1 新增节点

1. 在套件目录的工作副本 topology.json 中添加目标 IP、port、entry_port，先用 probe-exits.py 测两条线路；
2. 写入选定的 exit，确认入口端口不重复、未被占用；
3. 备份每台主机的 /etc/lq-rebuild/topology.json，把更新后的同一份配置同步过去；
4. 先重载利群，再重载各前置（先让下游准备好，再打开入口）。已有隧道的公钥和地址不变时，只需重载转发服务；
5. 在云防火墙开放新的 entry_port/TCP，客户端添加节点，完成实际验收。

每台机器上执行：

12.2 切换出口

例如把 KFC 的 exit 从 9929 改为 CN2，按上面相同的备份与同步流程操作即可，客户端的地址、端口、PSK 都不用改。新连接会走新出口；旧连接可能还保留着旧的 SNAT conntrack 记录，需要在客户端断开该节点的旧连接后重连。不要全局清空 conntrack。

服务会校验路由归属后再更新 /32 路由和 SNAT。ip 命令带 -N 输出数字协议号，避免把 186 显示成名称 bgp 而误判为外部路由。仅协议号相同并不代表归本套件所有：还必须在 state.json 中有记录，且当前网关、设备、源地址都匹配。

12.3 删除节点

顺序与新增相反：先从客户端策略组移除 → 前置删除对应节点并重载 → 更新利群配置并重载 → 最后收回云防火墙的入口端口。脚本会根据旧 state 清理不再需要的目的路由；如果同一 IP 还有其他节点在用，则保留该路由。

本版要求至少保留一个落地；如果要删除最后一个，请按 15.2 停用流程 关闭整套服务。

12.4 更新失败怎么办

未通过校验的 nftables 规则不会被应用到生产表；路由或后续步骤失败时，服务会尝试恢复本次修改前的受管路由、规则和内核参数。但磁盘上的新拓扑文件需要手动恢复：

cp -p /etc/lq-rebuild/topology.before-edit.json /etc/lq-rebuild/topology.json
systemctl reload lq-rebuild

务必查看日志确认恢复结果，不能只看 is-active——oneshot 服务在 reload 失败后仍可能显示 active。掉电、进程被强杀等情况下 Python 回滚无法保证执行，重启后需要人工检查状态。

13. 阿里云与腾讯云同时做前置

从零搭建时直接使用 examples/topology-dual.json，按第 9 节为三台机器分别生成密钥并填入同一份拓扑。生成的结构如下：

• 利群：一个 WG 接口、两个 peer，各自的 AllowedIPs 为不同的 /32；
• 两台前置：各一个 peer，AllowedIPs 只指向利群隧道 /32；
• 利群分别主动连接两台前置公网的 8443/UDP，每个 peer Keepalive=25；
• 两台前置可以使用相同的 Snell 入口端口，因为公网 IP 不同；
• 利群在 DNAT 中同时允许两台前置的隧道源地址，回包经 conntrack 还原后按对应 /32 peer 返回。

安装顺序：阿里云 role=ali → 腾讯云 role=tencent → 利群 role=relay。客户端为同一落地建两个节点，分别填写阿里云和腾讯云的公网 IP，用不同前缀区分名称。

两台前置共享利群上的选线结果：如果 KFC 选了 CN2，那么无论从哪台前置进入，到 KFC 都走 CN2。本方案不支持“阿里云进来走 CN2、腾讯云进来走 9929”这种按入口区分的选线；切换前置时，已建立的 TCP 连接也不会自动迁移。

在已有单前置上追加第二台：先备份配置，填写双前置的公钥和隧道地址，部署新前置，再更新原前置和利群的拓扑与 WG 配置。注意：只改 JSON 并 reload 转发服务不会更新 WG peers。可以在每台受影响的主机上，按其 /etc/lq-rebuild/role 重新生成 WG 配置，然后在维护窗口重启：

修改本机隧道地址、接口参数或前置公网 IP 时同样需要重新生成 WG 配置，而不仅是更新转发 JSON。失败时恢复 WG 配置和拓扑这两份备份，再重新启动服务。

14. 排错、重载与重启

常用诊断命令：

只更新落地或选线时用 reload；修改 WG 地址／peer，或需要模拟故障恢复时才用 restart。不要再混装另一套同时管理这些目标 /32 的官方或第三方路由脚本。

15. 备份、回滚和迁移

15.1 保存可重建资料

建议保存：套件本身、最终拓扑、各机角色与网卡信息、云安全组规则、落地 Snell 配置、线路测量结果。拓扑只含公钥、不含 PSK；客户端配置和 WireGuard 私钥要另外作为私密资料备份。

例如在每台服务器上生成一份仅 root 可读的本地备份：

[!CAUTION] 这份备份包含私钥，绝不能放进公开教程或公开网盘。异机重建时通常应重新生成密钥、交换公钥、重新测出口并重建路由状态；不要把旧的 state.json 直接复制到网络配置不同的主机上套用。

15.2 停用新套件

每台机器先停转发、再停隧道：

systemctl disable --now lq-rebuild
systemctl disable --now wg-quick@wg-lqr

然后确认专用 nft 表已消失、本套件的目的路由已移除。停用过程不会删除其他 nft 表，也不会删除协议号相同但未登记归属的路由；如果有人手动改过受管路由，stop 会拒绝直接清理，需要先查看日志和对应目标，避免误删。

只有在没有其他转发服务依赖这些参数时，才恢复安装前的内核参数：

已删除的 WG 接口对应参数会被自动跳过。这一步不应影响之后新增的其他业务；同理，安装时备份的整机 nftables 规则仅供比对，不能直接全局覆盖回去。

如需重新运行首次安装器：先确认服务已停用、接口和专用表已清理，再把本套件的配置目录、WG 配置和 systemd unit 移到带日期的私密备份目录，执行 systemctl daemon-reload。保留密钥文件可以沿用该机器的身份；重新生成密钥则必须重新交换公钥。

15.3 从旧版部署迁移

旧版部署的配置位于 /etc/leikwan-relay，脚本为 /usr/local/sbin/lq-relay-network，服务为 lq-relay-network 和 wg-quick@wg-lq，目的路由同样使用协议号 186。

如果旧部署运行正常，无需迁移，把本文留作日后新机重建的手册即可。确实需要原机迁移时，请安排维护窗口：

1. 备份旧配置；
2. 停止旧转发和旧 WG；
3. 确认旧专用表和目的路由已清理；
4. 把旧配置目录移到备份位置；
5. 部署新套件。

验证失败时，先清理新套件，再恢复旧配置并启用旧服务。任何时候都不要让两套系统同时管理相同的目标。

16. 实测数据与参考资料

16.1 六台落地实测对比

以下是 2026-10-18 的测量记录，属于历史样本；重建时务必用当时重复测量的结果更新选线。

几点观察：

• 同一地区的落地，两条出口的表现可能完全相反（例如有些日本落地走 CN2 会先绕香港再到东京，走 9929 反而上海直达），不存在“CN2 一定更好”的通用结论；
• 初测和复测可能差异明显（RFC-JP），选线要基于多次、多时段的数据；
• 示例 JSON 保留的是实际部署时的选线，尚未执行的 KFC／Green 切线建议没有写进去。

16.2 官方脚本与本套件的关系

利群官方也提供了交互式脚本（详见 官方 IPv4 多出口教程 与 IPv6 路由与 DDNS 教程）：

• dual-route.sh（多出口调控菜单）：自动检测 9929（10.7.0.1）和 CN2（10.8.0.1）两组网关，提供交互菜单添加静态 /32 路由、DDNS 动态路由和开机自启：

  BASHCopy

  wget -O dual-route.sh http://files.leikwanhost.com/dual-route.sh
  less dual-route.sh
  chmod +x dual-route.sh
  bash dual-route.sh
  

  它只负责“利群本机到目标 IP 走哪个出口”，不包含“前置 WireGuard 隧道 + 两级 DNAT/SNAT”整条链路。如果使用本文的 lq-rebuild 服务，同一批落地路由应完全交给 lq-rebuild 管理，不要同时再用 dual-route.sh 添加这些目标。

• v6-ddns.sh / v6-mng.sh（动态 IPv6 DDNS）：用于把利群变化的电信／联通 IPv6 入站地址更新到域名。本文方案由利群主动连云前置 IPv4，不依赖利群 IPv6 入站，因此不需要安装；只有打算直接用利群 IPv6 做入口时才用得上，且不要同时启用两个脚本更新同一条 AAAA 记录。

16.3 参考链接

• 利群官方知识库 与 官方 Looking Glass
• 利群快速入门：IPv6 识别与网络约束
• 开启外部 SSH root 登录 与 IPv4 SSH 端口登录说明
• 利群 IPv4 双出口工具、IPv6 路由与 DDNS、BBR／优化脚本说明
• 利群 WireGuard 前置组网
• NodeSeek：双出口体验与脚本改进、公网前置、组网与转发、CN2／9929 测评
• MeowVPS：利群主机 CN2&9929 评测原文
• Surge Snell 配置文档 与 Snell v6 说明

17. 写在最后

利群这台机器很有意思：它把预算花在了“上海出去的 CN2 和 9929 两条出口”上，代价是没有独立 IPv4、入站只有动态 IPv6。理解了这个取舍，整个搭建思路就很自然：

1. 用国内云补齐入口短板：利群主动连阿里云／腾讯云的固定 IPv4，避开动态 IPv6、DDNS 和纯 IPv4 网络连不上的问题。
2. 职责分离：前置只管入口，利群只管选线，落地只管代理协议，每一层都能单独验证、单独替换。
3. 按目标 /32 选路而非改默认路由：CN2 不总是赢（有的日本落地走 CN2 反而绕香港），9929 也不总是输；用 Looking Glass 初筛、用 probe-exits.py 实测 Ping 和 TCP 建连，再按落地各自指定出口。
4. 任何变更都可回滚：首次安装自动备份，修改配置走 reload，路由带归属校验，失败能恢复。

希望这篇实录能帮你把这台“偏科”的出口中转机真正用起来。如果你在腾讯云或双前置场景下完成了实测，也欢迎交流你的数据。