背景

在国内网络环境下，运营商经常对 UDP 流量进行限速或直接封锁，导致 WireGuard 等基于 UDP 的 VPN 连接不稳定甚至完全无法使用。为了解决这个问题，我使用 wstunnel 将 WireGuard 的 UDP 流量封装成 WSS（WebSocket Secure over TLS） 流量。WSS 本质上是建立在 TLS 之上的 WebSocket，端口为 443，看起来和普通的 HTTPS 流量完全一样，运营商难以识别和干扰，从而保证了 VPN 连接的稳定性。

为了方便，我写了一个启动脚本 start-vpn.sh，并使用 systemd 用户服务配置了开机自启，原本一切运行正常。

问题现象：电脑重启后 VPN 无法工作

某天电脑重启后，我发现 VPN 没有正常工作。于是检查 wstunnel 服务的状态：

systemctl --user status wstunnel.service

输出如下：

● wstunnel.service - Wstunnel Client for VPN
     Loaded: loaded (/home/wangqiang/.config/systemd/user/wstunnel.service; enabled)
     Active: activating (auto-restart) (Result: exit-code) since ...
    Process: 12780 ExecStart=/home/wangqiang/start-vpn.sh (code=exited, status=203/EXEC)
   Main PID: 12780 (code=exited, status=203/EXEC)

关键信息是 code=exited, status=203/EXEC。这个退出码意味着 systemd 无法执行指定的程序。

排查 203/EXEC 错误

203/EXEC 通常由以下几种原因导致：

1. ExecStart 指定的文件不存在
2. 文件没有执行权限
3. 脚本的 shebang（如 #!/bin/bash）错误或对应的解释器不存在
4. 脚本所在文件系统被挂载为 noexec

由于之前服务是正常的，我首先想到是不是文件被移动或删除了。检查原路径：

ls -l /home/wangqiang/start-vpn.sh

结果：

ls: cannot access '/home/wangqiang/start-vpn.sh': No such file or directory

果然，文件不在了。我回想起来，之前整理目录时把脚本移到了 ~/VPN/ 下：

ls -l /home/wangqiang/VPN/start-vpn.sh

输出：

-rwxrwxr-x 1 wangqiang wangqiang 163 May 28 16:41 /home/wangqiang/VPN/start-vpn.sh

问题根源：移动了脚本，但 systemd 服务文件中的 ExecStart 还指向旧路径。重启后 systemd 尝试启动服务时找不到脚本，因此报 203/EXEC 错误并不断自动重启。

修复步骤

1. 修改服务文件中的路径

编辑用户服务文件：

nano ~/.config/systemd/user/wstunnel.service

将 ExecStart 行改为：

ExecStart=/home/wangqiang/VPN/start-vpn.sh

保存后退出（nano 中按 Ctrl+O，回车，再按 Ctrl+X）。

2. 确认脚本具有执行权限（已存在，无需修改）

ls -l /home/wangqiang/VPN/start-vpn.sh

权限中包含 x，无需额外 chmod。

3. 重新加载 systemd 并重启服务

systemctl --user daemon-reload
systemctl --user restart wstunnel.service

4. 检查服务状态

systemctl --user status wstunnel.service

现在输出变为 active (running)：

● wstunnel.service - Wstunnel Client for VPN
     Loaded: loaded (/home/wangqiang/.config/systemd/user/wstunnel.service; enabled)
     Active: active (running) since Mon 2026-06-08 14:01:52 CST; 8s ago
   Main PID: 13932 (start-vpn.sh)
      Tasks: 6 (limit: 18198)
     Memory: 3.7M
        CPU: 122ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/wstunnel.service
             ├─13932 /bin/bash /home/wangqiang/VPN/start-vpn.sh
             └─13935 /usr/local/bin/wstunnel client -L "udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0" --tls-sni-override wg.shuijingwanwq.com wss://154.21.196.249:443

并且日志中显示 wstunnel 成功启动、监听 UDP 端口、建立 TLS 连接：

6月 08 14:01:52 ... Started wstunnel.service.
6月 08 14:01:52 ... INFO wstunnel: Starting wstunnel client v10.5.5
6月 08 14:01:52 ... INFO wstunnel::protocols::udp::server: Starting UDP server listening on 127.0.0.1:51820
6月 08 14:02:00 ... INFO wstunnel::protocols::udp::server: New UDP connection from 127.0.0.1:46144
6月 08 14:02:00 ... INFO wstunnel::protocols::tcp::server: Opening TCP connection to 154.21.196.249:443
6月 08 14:02:00 ... INFO wstunnel::protocols::tls::server: Doing TLS handshake using SNI DnsName("wg.shuijingwanwq.com")

5. 验证端口监听

最后确认 UDP 转发端口已经正常监听：

ss -lun | grep 51820

输出：

UNCONN 0      0          127.0.0.1:51820      0.0.0.0:*

一切恢复正常。现在 wstunnel 客户端会随用户登录自动启动，并在意外退出时自动重试（Restart=on-failure）。

为什么用 wstunnel 来加密 WireGuard 流量？

运营商普遍对 UDP 流量实施 QoS 限速或直接丢弃，导致 WireGuard 连接经常超时或断线。wstunnel 将 UDP 数据包封装在 WSS（WebSocket Secure over TLS） 流中——WSS 使用 443 端口和 TLS 加密，从网络特征上看与普通 HTTPS 请求完全一致。运营商的 DPI 设备无法区分这是正常网页访问还是 VPN 隧道，因此不会对流量进行特殊处理，保证了连接的稳定性和带宽。

在启动命令中：

wstunnel client \
  -L "udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0" \
  --tls-sni-override wg.shuijingwanwq.com \
  wss://154.21.196.249:443

• wss:// 表示使用 WebSocket over TLS，服务器端必须配置有效的 TLS 证书。
• --tls-sni-override 用于指定 SNI 名称，使得 TLS 握手时使用 wg.shuijingwanwq.com 作为服务器名称指示，进一步模拟正常 HTTPS 请求。

通过这种方式，WireGuard 的 UDP 流量被“伪装”成标准的 HTTPS 流量，成功避免了运营商的干扰。

总结与避坑指南

特别提醒：如果你移动了脚本的位置，一定记得同步更新 systemd 服务文件中的路径，否则就会出现本文描述的 203/EXEC 错误。修改后需要执行 daemon-reload 才能生效。

另外，如果是用户服务（--user），请确保服务随用户登录启动：systemctl --user enable 服务名。用户服务依赖于用户的 systemd 实例（一般由 systemd --user 在登录时自动启动）。

参考资料

• systemd.exec 手册 – 了解 ExecStart 和退出码
• journalctl --user -u wstunnel.service -f – 实时查看用户服务日志

通过以上步骤，我快速定位并解决了因移动脚本导致的 203/EXEC 错误，恢复了 wstunnel 的自启动。希望这篇博客能帮助遇到类似问题的朋友少走弯路。

Happy tunneling!

一、问题现象

在 Android 手机上，我同时维护了两套自建 VPN 方案：

• 方案 A（Vultr + 纯 WireGuard 新加坡节点）：Play 商店页面正常打开，应用更新稳定完成，有正常下载进度条。
• 方案 B（ZgoCloud + Wstunnel + WireGuard + Clash Verge Rev 洛杉矶节点）：Play 商店页面可以打开，但一旦点击“更新”，就一直卡在“等待中”状态，没有任何下载进度，最终失败。

[截图 1：Play 商店更新界面，应用卡在“等待中”]

方案 A 能正常更新，方案 B 不行——两台服务器到 Play 商店的链路差异，让问题看起来像是服务器地域或网络质量导致的。

于是，我开始了漫长的“错误排查之旅”。

二、初始判断与错误方向

根据现象，我一开始把怀疑方向锁定在了以下几个角度：

1. 服务器地域差异：新加坡 vs 洛杉矶，猜测延迟更高导致更新失败。
2. Wstunnel 封装引入的额外延迟：Wstunnel 在 WireGuard 之上又包了一层 WebSocket + TLS，导致链路变长。
3. Google Play 对长连接敏感：认为 Play 商店的更新机制无法容忍 Wstunnel 带来的延迟波动。
4. MTU 分片问题：怀疑多次封装导致 MTU 不匹配，数据包被丢弃。

在这些判断的基础上，我甚至构思了三个“优化方案”：

最终结论：这三个方案全搞错了方向。问题的根源并不在 Wstunnel 或网络链路上。参考：自建 WireGuard + Wstunnel 在 Android 上 Google Play 更新异常的完整排查与架构优化

三、关键转折：FlClash 日志暴露了真实问题

在 Android 上，我使用 FlClash（Clash Meta 内核的 Android 客户端）查看实时请求日志，发现了一个异常：

[截图 1：FlClash 请求日志截图，显示 play.googleapis.com 等域名走了 Proxy]

日志中显示：

• play.googleapis.com → Proxy
• play-fe.googleapis.com → Proxy
• android.googleapis.com → Proxy

也就是说，Play 商店相关的流量全部经过代理链路。这排除了“直连”或“DNS 污染”的可能性。

但问题随之浮现：这些域名走代理，为什么反而导致更新卡住？

经过进一步分析，我意识到核心问题其实很简单：Google Play 的下载资源（apk 安装包）托管在全球 CDN 上，而代理节点位于洛杉矶。当下载请求经过代理时，流量绕了半个地球，速度极慢甚至超时。 这不是 Wstunnel 的锅，也不是 MTU 的问题——只是分流规则不够精细。

四、正确的解决方案：用 GEOSITE 现成规则集精细分流

Clash Meta 内核内置了 GEOSITE 规则集，它基于社区维护的域名数据库，可以自动识别哪些域名需要代理、哪些可以直连。

核心思路很简单：

4.1 修改 Clash 配置文件

在 Clash 配置文件的 rules: 部分，添加 DNS fallback-filter domain 列表 与 添加以下两条规则：

# DNS配置（优化：为国内CDN域名单独指定DNS，避免污染）
dns:
  fallback-filter:
    geoip: true
    # 新增：强制这些国内CDN域名使用nameserver，避免被fallback解析到境外IP
    domain:
      - +.googleapis.cn
      - +.gvt1.com
      - +.gvt3.com
      - +.googleusercontent.com

rules:
  # 高优先级：Wstunnel 服务器直连
  - IP-CIDR,你的Wstunnel服务器IP/32,DIRECT

  # ==== 现成规则集 ====
  - GEOSITE,google,Proxy      # Google 核心服务走代理
  - GEOSITE,youtube,Proxy     # YouTube 走代理

  # DNS 解析直连
  - DOMAIN,dns.alidns.com,DIRECT

  # 本地局域网直连
  - IP-CIDR,127.0.0.1/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT

  # 邮件端口走代理（解决 Thunderbird 发信问题）
  - DST-PORT,587,Proxy
  - DST-PORT,465,Proxy

  # 国内流量直连
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 兜底：其他全部走代理
  - MATCH,Proxy

4.2 为什么 GEOSITE,google 能解决问题？

GEOSITE,google 规则集底层包含了一组精细的子规则，它会智能地将 Google 的不同服务分流：

• 认证与 API 域名（如 accounts.google.com、android.googleapis.com）→ 走代理
• 下载 CDN 域名（如 play.googleapis.com、gvt1.com、googleusercontent.com）→ 走直连

这个“智能分流”的好处是：你不需要手动维护任何域名列表，规则集会随 Clash 内核更新自动同步。

4.3 配置要点

1. GEOSITE,google 必须在 GEOIP,CN 和 MATCH 之前，否则无法生效。Clash 规则是从上到下顺序匹配的，一旦命中就会停止。
2. GEOIP,CN 保持启用，确保国内 CDN 节点被识别为直连。
3. DNS 配置优化：在 fallback-filter 中添加 domain: 列表，强制 gvt1.com、googleusercontent.com 等国内 CDN 域名使用国内 DNS 解析，避免被 fallback 服务器解析到境外 IP。

五、验证结果

配置修改完成、重新加载 Clash 之后：

1. Play 商店页面：正常加载，浏览不受影响。
2. 应用下载：进度条正常出现，速度稳定。
3. Clash 日志：play.googleapis.com 匹配 GEOSITE,google 规则，但仍走 Proxy（因为该规则集仍会按需代理控制信令）；同时 gvt1.com 等 CDN 域名被 GEOIP,CN 识别为直连。

[截图 2：Play 商店更新界面，显示两个应用正常下载]

至此，持续数天的 Play 商店更新问题彻底解决。

六、反思总结

回过头来看，这次排查走的最大弯路是“过早把问题归因于底层网络”——Wstunnel 虽然链路较长，但并不是导致更新卡住的根本原因。真正的症结在于 Clash 分流规则不够精细：Google 相关域名的所有流量都被送入了代理隧道，导致本应直连的 CDN 下载流量也跟着绕远路。

三行配置解决三个月的问题：最终只需要在 Clash 配置中添加 GEOSITE,google,Proxy 一行（再加上相应的 DNS 优化），所有问题迎刃而解。

环境参考：Android + FlClash（Clash Meta 内核）+ 自建 Wstunnel + WireGuard + Clash Verge Rev 方案。

希望这篇博客能帮到正在为 Play 商店更新问题挠头的朋友。如果你也有类似经历，欢迎留言交流。

🧭 一、问题背景（真实使用场景）

在 Android 手机上，我同时使用了两套 VPN 网络架构：

🟢 方案A：Vultr + WireGuard（新加坡）

• 服务器：Vultr（新加坡节点）
• 协议：WireGuard（纯）
• Android 表现：
  • ✔ Play 商店正常打开
  • ✔ 应用更新有下载进度条
  • ✔ 更新稳定完成

📷（图2：Vultr WireGuard 正常更新）

🔴 方案B：ZgoCloud + Wstunnel + WireGuard + Clash Verge Rev（洛杉矶）

• 服务器：ZgoCloud（洛杉矶节点）
• 架构：
  • Wstunnel → WireGuard → Clash Verge Rev
• Android 表现：
  • ✔ Play 商店页面可打开
  • ❌ 应用更新：
    • 一直“等待中”
    • 无下载进度
    • 最终失败

📷（图1：Play 商店无法更新）

👉 初始判断：

• 是否与 **服务器地域（新加坡 vs 洛杉矶）**有关？

🌐 二、流量验证（Play 商店是否走代理）

在 Android 使用 FlClash 查看请求：

关键证据

play.googleapis.com → Proxy
play-fe.googleapis.com → Proxy

📷（图3：FlClash Google 请求）

结论

• ✔ Play 商店流量全部经过代理链路
• ❌ 不存在直连
• ❌ 排除 DNS / Clash GEOIP 规则问题

📊 三、初步分析（阶段性判断）

👉 初步结论：

更可能是 Wstunnel + 长链路质量导致下载失败

🔬 四、WireGuard 单独验证（wg1 方案）

⚠️ 4.1 触发 wg1 的原因

在 wg0（51820）环境中：

📷（图4）无“上次握手时间”

• Android WireGuard：
  • ❌ 无 handshake（无“上次握手时间”）
• 结论：
  • 51820 UDP 疑似被封锁或干扰

🧱 4.2 wg1 架构设计初衷

目标：

在不影响 Wstunnel 的前提下，单独验证 WireGuard 可用性

⚙️ 4.3 wg1 构建全过程（关键细节补全）

Step 1：复制配置文件

cp /etc/wireguard/wg0.conf /etc/wireguard/wg1.conf

修改：

• ListenPort → 35698
• Subnet → 10.8.0.0/24

Step 2：尝试改 wireguard.sh（失败）

原想法：

WG_CONF=/etc/wireguard/wg1.conf

但：

• ❌ 脚本不支持动态配置文件参数

Step 3：复制管理脚本

cp wireguard.sh wireguardwg1.sh
chmod +x wireguardwg1.sh

修改内容：

• WG_CONF → wg1.conf
• client storage → wg1

Step 4：生成密钥体系

wg genkey | tee privatekey_client_wg1 | wg pubkey > publickey_client_wg1
wg genpsk > psk_client_wg1

生成：

• client private key
• client public key
• preshared key

Step 5：Android 配置

[Interface]
PrivateKey = xxx
Address = 10.8.0.3/32
DNS = 8.8.8.8, 8.8.4.4

[Peer]
PublicKey = wg1_server_pub
PresharedKey = xxx
Endpoint = 154.21.196.249:35698
AllowedIPs = 0.0.0.0/0
MTU = 1240

📷（图5：wg1 handshake 成功）

❌ 4.4 wg1 测试结果

• ✔ WireGuard handshake 正常
• ❌ Play 商店无法打开
• ❌ MTU 调整无效

📷（图6：Play 商店无法访问）

结论：

WG 通，但业务层失败（Google Play 不可用）

🧨 五、wg1 方案失败总结

• WireGuard 本身无问题
• 问题来自：
  • Wstunnel 路径复杂
  • 洛杉矶节点质量
  • 长连接质量下降

🔁 六、最终验证（放弃 Wstunnel）

Step 1：修改 wg0 端口

51820 → 36425

📷（图7：端口修改）

Step 2：结果

📷（图8）

• ✔ Play 商店恢复
• ✔ 下载出现进度条

📷（图9）更新完成

• ✔ 更新完成

📌 七、最终结论

根因确认

📊 八、修正后的影响模型

🧭 九、最终架构方案（推荐）

🟢 方案1：分流架构（推荐）

Play Store → WireGuard（直连）
其他流量 → Wstunnel

✔ 稳定
✔ 简单
✔ 最少改动

🟡 方案2：iptables 多端口 WireGuard

客户端端口：20000–60000
        ↓
iptables NAT
        ↓
服务器 51820

📌 动态端口机制

• Android WireGuard：
  • 自动/手动选择端口（20000–60000）
• Wstunnel：
  • 固定 51820
• 两者互不冲突

🧪 方案3：Wstunnel 优化方向（未来）

• 降低 TLS buffer latency
• 调整 websocket frame size
• 优化 keepalive
• 减少 tunneling layer overhead
• 尝试 HTTP/2 / QUIC tunnel（如支持）

🧩 十、完整流量架构图

                Android
                   |
        -------------------------
        |                       |
  WireGuard (Play)        Wstunnel + Clash
        |                       |
     ZgoCloud               ZgoCloud
        |                       |
        --------- Internet ------
                    |
                Google Play

🧠 十一、关键经验总结

1. WG 能通 ≠ 应用可用
2. Wstunnel 会放大长连接问题
3. 洛杉矶节点对 Google Play 更敏感
4. Play Store 对“下载链路质量”非常敏感
5. 多层代理（WG + Wstunnel + Clash）极易引入隐性失败

本文可作为在 Android 手机上配置 wstunnel + WireGuard VPN 的通用参考。你需要提前准备好以下内容：

• 一台已部署 wstunnel 服务端和 WireGuard 服务端的服务器（参考 ZgoCloud + Wstunnel + WireGuard 提速 4 倍，Clash Verge Rev 自动分流与 443 端口防封实战）
• 为 Android 手机生成一个独立的 WireGuard 客户端配置，其中包含以下四项关键信息：
• ip：分配给手机的内网 IP（例如 10.7.0.3）
• public-key：客户端的公钥
• private-key：客户端的私钥
• pre-shared-key：预共享密钥（如有）

下载本文提供的 ZgoCloud-Android-VPN.yaml 配置文件模板后，请将这四项信息替换为你的实际值，其余配置（如 server: 127.0.0.1、port: 51820 等）保持不变。

然后按照下面的步骤操作，即可在你的 Android 手机上成功启用 VPN。

📌 准备工作

你需要从以下链接下载五个文件：

注意：wstunnel 文件需要从 wstunnel_10.5.5_android_arm64.zip 解压得到。解压后只保留里面的 wstunnel 文件。

以下是前四个文件对应的官方网站和下载渠道：

文件名	软件名称	官方网址/下载渠道	简要说明
com.termux_1002.apk	Termux	F-Droid 仓库	一个功能强大的Android终端模拟器和Linux环境，是运行各类命令行工具的基础。
com.termux.boot_1000.apk	Termux:Boot	F-Droid 仓库	Termux的官方插件，用于实现开机时自动运行用户的脚本。
wstunnel (无后缀)	Wstunnel	GitHub Release 页面	一个高效的隧道工具，可将任意TCP/UDP流量封装在WebSocket协议中，以绕过网络限制。
FlClash.apk	FlClash	GitHub Release 页面	一个基于Clash.Meta内核、界面简洁且易于使用的代理客户端。

💡 官方下载提示

为了方便大家，我提供了这些文件的通用官网或官方发布页。不同设备架构的兼容性可能不同，如果你需要自行下载最新版本，或希望适配特定手机型号（如 x86_64 架构），可以通过这些链接找到最新发布。

兼容性提示：我下载的通用版本（如 *_universal.apk 或 *_arm64-v8a.apk）已适配绝大多数现代Android设备。如果你不确定，可直接使用我提供的这些文件。

---

⚠️ 安全提醒

考虑到网络环境的复杂性，强烈建议大家优先从上述官方或可信赖的应用商店下载和更新软件，以确保文件来源的安全性和可靠性。这样做虽然可能会增加几秒钟的操作时间，但能为你后续的使用提供更好的保障。

希望这份整理对你有帮助。如果还需要其他协助，随时可以告诉我。

将这些文件通过微信或 QQ 发送到手机上。发送后，微信可能会给 .apk 文件加上 .1 后缀（如 com.termux_1002.apk.1），稍后我们会处理。

一、安装 Termux 和 Termux:Boot

1. 打开手机自带的「文件管理」App，找到 Download 文件夹（或微信保存文件的目录）。 【截图位置：图12 展示了 Download 目录结构】
2. 找到 com.termux_1002.apk.1 和 com.termux.boot_1000.apk.1，长按它们，选择「重命名」，删除末尾的 .1，变成 .apk 结尾。 【截图位置：图7、图8 展示了重命名前后的状态】
3. 依次点击这两个 APK 文件进行安装。安装完成后，桌面会出现 Termux 和 Termux:Boot 两个图标。 【截图位置：图9 展示了桌面图标】
4. 重要：安装完 Termux:Boot 后，请务必点击它的图标打开一次。这一步是为了让系统允许它在开机时运行。

【截图位置：图12 展示了 Download 目录结构】

【截图位置：图7、图8 展示了重命名前后的状态】

【截图位置：图9 展示了桌面图标】

二、将 wstunnel 文件放入 Termux

1. 在文件管理器中找到你发送的 wstunnel 文件（无后缀，大小约 9.5 MB）。长按它，选择「移动」，然后粘贴到 Download 根目录下（即路径 /sdcard/Download/）。 【截图位置：图13 展示了 Download 目录下的 wstunnel 文件】
2. 打开 Termux 应用，首次启动会进行初始化。然后依次输入以下命令：

   # 授权存储权限（会弹出系统窗口，点“允许”）
   termux-setup-storage

   # 创建 bin 目录
   mkdir -p ~/bin

   # 复制 wstunnel 文件到 Termux 的 bin 目录
   cp ~/storage/downloads/wstunnel ~/bin/

   # 赋予执行权限
   chmod +x ~/bin/wstunnel

   # 验证版本（应该显示 wstunnel-cli 10.5.5）
   ~/bin/wstunnel --version

【截图位置：图13 展示了 Download 目录下的 wstunnel 文件】

【截图位置：图14 展示了上述命令的执行过程和成功结果】

三、创建 wstunnel 启动脚本

在 Termux 中继续输入以下命令，创建一个脚本，用于启动 wstunnel 客户端。

# 创建 Termux:Boot 专用目录（用于开机自启，可选）
mkdir -p ~/.termux/boot

# 写入脚本内容（请将域名和 IP 替换为你的 VPN 服务器信息）
cat > ~/.termux/boot/start-wstunnel.sh << EOF
#!/data/data/com.termux/files/usr/bin/bash
termux-wake-lock
~/bin/wstunnel client -L udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0 --tls-sni-override 你的域名 wss://你的服务器IP:443
EOF

# 赋予执行权限
chmod +x ~/.termux/boot/start-wstunnel.sh

注意：请将 你的域名 和 你的服务器IP 替换为实际值（我会提供给你）。或者自行从服务器中配置中查找。可参考：ZgoCloud + Wstunnel + WireGuard 提速 4 倍，Clash Verge Rev 自动分流与 443 端口防封实战

四、安装并配置 FlClash

FlClash 是目前最稳定的 Clash Meta 安卓客户端，完美支持 WireGuard。之前安装过 Tabby，发现无法导入文件，遂放弃。如图16

1. 下载 FlClash
   访问 FlClash GitHub Releases，下载最新版的 arm64-v8a-release.apk 并安装。或者直接从本文中提供的链接进行下载。
2. 导入配置文件

• 将你收到的 ZgoCloud-Android-VPN.yaml 文件通过微信发送到手机，并保存到 Download 文件夹。
• 打开 FlClash，点击底部「配置」→ 右上角「+」→「从文件导入」。
• 浏览并选中该 YAML 文件。

1. 检查配置（关键）

• 进入「配置」→ 点击刚导入的配置 →「编辑」。
• 找到 proxies 下的 ZgoCloud-WG，确保以下字段正确：
  • server: 127.0.0.1
  • port: 51820
  • 其他密钥保持与我提供的一致。

1. 设置自动运行

• 点击底部「工具」→「应用程序」→ 开启 「自动运行」。
  （这样每次打开 FlClash 就会自动连接 VPN，无需再点启动按钮）

五、授予系统权限（保证稳定运行）

为了让 Termux 和 FlClash 能在后台正常工作，需要进行以下设置：

1. 自启动权限

• 打开手机「设置」→「应用」→「自启动管理」。
  【截图位置：图10、图21 展示了自启动列表】
• 找到 Termux、Termux:Boot、FlClash，将它们全部开启。

2. 耗电管理（允许后台活动）

• 进入「设置」→「应用」→「应用管理」→ 找到 Termux、Termux:Boot、FlClash →「耗电管理」。
  【截图位置：图20 展示了耗电行为控制】
• 选择 「完全允许后台行为」（或「不限制」）。

3. 锁定后台（防止被清理）（可选）

• 多任务界面（从屏幕底部上滑并悬停），找到 FlClash 卡片，向下滑动直到出现小锁图标，将其锁定。

六、启动 VPN

1. 确认 wstunnel 已运行
   你可以重启手机，或者直接在 Termux 中手动运行脚本：

   sh ~/.termux/boot/start-wstunnel.sh

然后执行 ps -ef | grep wstunnel 检查进程是否存在。

【截图位置：图22展示了有进程的状态（正常情况应显示进程）】

2. 打开 FlClash

• 点击底部「仪表盘」→ 确保顶部的「出站模式」为「规则」。
• 点击右下角的 「启动」 按钮。
  【截图位置：图17 展示了启动后的仪表盘界面】
• 系统会弹出 VPN 连接授权窗口，点击「确定」。

2. 验证成功

• 状态栏出现 Termux、FlClash 图标。
• 打开浏览器访问 https://ip.sb，显示的 IP 应为你的 VPN 服务器 IP。
  【截图位置：图18、图19 仅为示例，表示可以正常上网访问应用和网页】

七、日常使用说明

• 每次开机后，wstunnel 会自动运行（如果之前设置了开机自启脚本）。
• 只需手动打开 FlClash，它就会自动连接 VPN。
• 如果不想手动打开 FlClash，可以在系统「自启动管理」中开启 FlClash，但部分手机可能无效。手动打开仅需几秒，不影响体验。

八、常见问题排查

九、获取帮助

如果按照本教程操作仍无法使用，请联系我，并附上以下截图：

• Termux 中执行 ps -ef | grep wstunnel 的结果
• FlClash 仪表盘界面
• 手机「自启动管理」中相关 App 的状态

我会尽快协助解决。

祝使用愉快！

前言
在网络加速工具的选择上，很多朋友可能都在寻找一种既稳定又高效的解决方案。无论是自建 VPN 还是使用商业服务，核心目标都是获得可靠的上网体验。今天，我想和大家分享一套我自建的 VPN 架构，通过实测数据（基于北京时间 14:00，四川成都，中国移动环境）和对比测试方法，结合按时间顺序嵌入的 9 张关键截图，帮助读者直观关联操作步骤与结果，清晰了解方案表现。无论您正在使用其他自建方案或商业服务，都可以按照文中的步骤自行验证，用数据做出适合自己的选择。

晚高峰实测已更新，见第三阶段及后续综合对比
您可能关心：这套方案在流量高峰时段是否依然稳定？今晚（6月2日）21:00 左右，我将在相同环境下再次进行测试，对比白天与晚高峰的数据差异，验证其抗压能力。

一、核心技术栈揭秘

为平衡稳定性、抗干扰能力与低延迟，我选用了以下技术组合：

• 服务器节点：ZgoCloud Los Angeles, USA
  线路优势：采用洛杉矶三网优化节点（CN2 GIA + 9929 + CMIN2），针对中国大陆优化，缓解高峰拥堵。
• 传输协议：Wstunnel + WireGuard
  技术原理：WireGuard 负责核心加密传输与隧道建立，Wstunnel 则将 WireGuard 流量封装为 HTTPS 流量，兼顾隐蔽性与穿透性。
• 客户端管理：Clash Verge Rev (Ubuntu)
  功能亮点：智能分流规则，实现国内直连、国外代理的无感切换。

二、实测环境说明

测试环境如下，确保数据可复现：

• 操作系统：Ubuntu Linux (26.04)
• 物理位置：中国四川成都
• 宽带服务商：中国移动 (China Mobile)，千兆带宽
• 测试工具：Speedtest.net (Chrome 浏览器版)
• 测试时间：北京时间 14:00 左右
  备注：因系统限制未使用 Speedtest App，后续将补充 Android 端数据。
  （图1：测试环境配置截图）
  （截图说明：显示 Ubuntu 系统版本、网络适配器信息，标注测试时间与设备信息。）

备注：因系统限制未使用 Speedtest App，后续将补充 Android 端数据。如图9

打开 Speedtest 官网，切换语言为 中文（简体）。如图2

在测试期间，浏览器要求相关的位置权限，设置为允许。

三、第一阶段：本地网络基准测试（对照组）

断开代理后，三次测试结果如下：

• 本地测试 #1
  下载：549.98 Mbps，上传：95.40 Mbps → 移动宽带典型表现（下行快，上行受限）。
  （图3：本地基准测试 #1 截图）

• 本地测试 #2
  下载：533.25 Mbps，上传：95.70 Mbps。
  （图4：本地基准测试 #2 截图）
  

• 本地测试 #3
  下载：467.04 Mbps，上传：94.52 Mbps。
  （图5：本地基准测试 #3 截图）

📊 本地基准总结：

• 平均下载：~530 Mbps
• 平均上传：~95 Mbps
• 平均延迟：~45 ms

四、第二阶段：自建 VPN 实测（实验组）

连接 VPN 后，三次测试结果：

• VPN 测试 #1
  分析：虽然跨越了太平洋，但下载依然跑到了 80.03 Mbps，上传 55.53 Mbps。对于跨洋连接，这个成绩非常出色。
  （图6：VPN 测速 #1 截图）

• VPN 测试 #2
  分析：波动极小，下载 77.64 Mbps，上传 44.83 Mbps。Idle Latency（空闲延迟）控制在 173ms，这意味着浏览网页几乎没有滞后感。
  （图8：VPN 延迟测试截图）

• VPN 测试 #3
  分析：第三次测试依然稳健，上传甚至回升到了 81.05 Mbps。这证明了 CN2 GIA + 9929 线路在下午时段（非深夜）的优异表现。
  （图7：VPN 测速 #3 详细数据截图）

五、第三阶段：晚高峰压力测试（北京时间 21:00 补测）

应读者需求，在相同环境（Ubuntu + 成都移动千兆）下，于 晚间 21:00 左右 重新测试，对比日间（14:00）数据，验证方案的抗压能力。

🕘 晚高峰本地基准测试（对照组）

断开 VPN，连续测速三次：

本地晚高峰 #1
下载：450.11 Mbps，上传：95.76 Mbps，Ping：46 ms
→ 晚高峰下行从日间的 530 Mbps 降至 450 Mbps，降幅约 15%。
（图10：晚高峰本地测速 #1 截图）

本地晚高峰 #2
下载：427.54 Mbps，上传：94.60 Mbps，Ping：33 ms
（图11：晚高峰本地测速 #2 截图）

本地晚高峰 #3
下载：447.27 Mbps，上传：95.92 Mbps，Ping：34 ms
（图12：晚高峰本地测速 #3 截图）

📊 晚高峰本地基准总结（与日间对比）：

分析：晚高峰本地下载速度略有下降（约 16%），但上传速度几乎不变，Ping 甚至略有改善。说明成都移动宽带在晚高峰时段整体负载尚可，未出现严重拥塞。

🌙 晚高峰 VPN 实测（实验组）

连接 VPN 后，同一环境下连续测速三次：

VPN 晚高峰 #1
下载：62.17 Mbps，上传：54.29 Mbps，空闲延迟：185 ms
→ 相比日间 VPN 下载（72 Mbps）下降约 20%，但依然远高于 4K 流媒体需求。
（图13：晚高峰 VPN 测速 #1 截图）

VPN 晚高峰 #2
下载：54.58 Mbps，上传：73.46 Mbps，空闲延迟：187 ms
（图14：晚高峰 VPN 测速 #2 截图）

VPN 晚高峰 #3
下载：55.60 Mbps，上传：78.68 Mbps，空闲延迟：197 ms
（图15：晚高峰 VPN 测速 #3 截图）

📊 晚高峰 VPN 总结（与日间 VPN 对比）：

观察：晚高峰 VPN 上传速度（平均 68.8 Mbps）反而高于日间（60.7 Mbps）。可能是 Speedtest 测速节点的波动，或者晚高峰时上行链路资源更充裕。无论如何，这个上传速度已远超视频会议需求。

六、核心结论：日间 vs 晚高峰，方案表现如何？

📊 综合性能对比表

✅ 核心结论（三条）

1. 绝对性能：晚高峰 VPN 下载稳定在 55–62 Mbps，上传达到 55–78 Mbps。这个带宽可以轻松支持 4K 视频流、大型文件下载、多路高清视频会议。相比日间下载下降约 20%，但依然绰绰有余。
2. 相对损耗率合理：日间 VPN 相对本地损耗约 86.4%（530→72.3），晚高峰损耗约 87.0%（441.6→57.5）。隧道效率几乎完全一致，晚高峰的下载下降主要源于本地基础网络的速度衰减（530→441.6）。
3. 延迟表现稳定：晚高峰空闲延迟平均 190 ms，仅比日间（173 ms）上升约 10%。网页浏览几乎无感知差异，只有对延迟极度敏感的竞技游戏（美服）可能感受到轻微增加的操作滞后。

七、自建 VPN 实测关键参数解读（日间与晚高峰数据对比）

除了上下行速度，截图中三个延迟参数非常重要。下面结合 日间和晚高峰 的实际数据来说明：

如果你需要一边全速上传文件一边进行视频会议，建议在路由器或电脑上对上传带宽做限速（例如限制到 30 Mbps），以避免高上传延迟带来的卡顿感。

八、为什么会出现“苏州移动”和“洛杉矶”两个结果？

无论是日间还是晚高峰，本地测速和 VPN 测速指向不同节点的原理是一致的：

• 图10–12（本地）：Speedtest 自动匹配到 JSQY (Suzhou) 节点。这是中国移动在江苏省的骨干网节点，物理距离远但属于运营商内部高速通道，所以跑出了 400+ Mbps 的速度。
• 图13–15（VPN）：Speedtest 智能识别出我当前的出口 IP 在美国，于是自动匹配到 NetLab Global / ReliableSite Hosting (Los Angeles) 节点。

结论：这才是真实的跨国网速！如果你在 VPN 开启状态下还能连到苏州节点测出 400+ Mbps，那反而是数据造假（因为流量不可能瞬间绕回国内再出去）。55–62 Mbps（晚高峰）才是我真实可用的海外带宽。

九、不同运营商在高峰时段的体验差异（电信/联通用户参考）

• 移动宽带特点：晚高峰本地下载从 530 降到 442 Mbps，降幅可控。VPN 最终可用带宽约 55–60 Mbps，上传表现甚至优于日间。本文数据对移动用户有较高参考价值。
• 电信/联通潜在优势：由于 CN2 GIA / 9929 线路对电信和联通的路由优化更好，在晚高峰时段线路拥塞控制可能更优，实际可用带宽可能高于本次移动环境下的测试数据。

总结：若您使用电信或联通，晚高峰体验可能比本文移动数据更好；若同为移动用户，本文数据具备直接参考意义。

十、授人以渔：对比测试指南

为验证任何 VPN 或代理服务在高峰时段的表现，可参考以下步骤：

1. 固定测速节点
   避免自动选择服务器，手动指定同一节点（如日间用苏州 JSQY，VPN 后用洛杉矶 NetLab 或相同第三方节点）。
2. 三连测取均值
   单次结果易受波动影响，连续测 3 次取平均。
3. 关注核心指标（跨洋优秀标准）：

4. 一定要同时测本地基准
   只有知道本地网络在相同时段的真实速度，才能判断 VPN 的损耗是否合理。

十一、总结

实测数据显示（含晚高峰 21:00 补测），ZgoCloud + Wstunnel + WireGuard 方案在牺牲部分本地带宽的前提下，在高峰时段依然稳定提供 55–60 Mbps 的跨国下载带宽，上传更是达到 55–78 Mbps，延迟控制在 190 ms 以内。

• 日间可用约 72 Mbps，晚高峰约 57 Mbps，均远超 4K 流媒体（25 Mbps）和视频会议（10 Mbps）的需求。
• 隧道效率不随时段恶化，晚高峰的速度下降主要来自本地运营商的基础网络速度衰减（530→442 Mbps）。
• 适合追求稳定跨境网络体验的用户，尤其是移动宽带用户参考价值高；电信/联通用户预期可获得更好表现。

若您想自行搭建或验证其他方案，文中的测试方法可助您用数据做出自己的判断。

预告：Android 手机端的晚高峰测试（含完整配置教程）将单独成文，预计本周内发布，欢迎关注。

之前在 Windows 上一直用 ZgoCloud + wstunnel + Clash Verge Rev 的方案，用着挺稳的。最近想在 Ubuntu 26.04 上也复现一套，并且希望开机就能自动连上，不用每次手动敲命令。折腾了一下午，总算搞定了。把过程记下来，算是给自己留个笔记，万一以后重装系统也能照着来。

一、先说一下我用的组件

• VPS 服务商：ZgoCloud（已经配好了服务端的 wstunnel + WireGuard）
• 本地穿透工具：wstunnel v10.5.5（版本必须和服务端一致）
• 代理客户端：Clash Verge Rev（用它的 WireGuard 节点和分流）
• 系统：Ubuntu 26.04，笔记本是 x86_64 架构

二、安装 Clash Verge Rev

我一开始在 Ubuntu 的“软件”应用里搜“Clash”，结果出来的都不是我要的（图1）。后来去 GitHub 上看了，原来 Clash Verge Rev 只提供 .deb 和 .AppImage，没上架商店。

我下载了 Clash.Verge_2.5.1_amd64.deb（因为我电脑是 x86_64）。下载完在文件管理器里右键这个 .deb 文件，选择“打开方式” → “软件安装”（图2）。系统弹出一个安装窗口，点“安装”输密码就行了（图3）。

装完之后，应用菜单里就有了 Clash Verge Rev 的图标。

三、部署 wstunnel 客户端

wstunnel 服务端我用的版本是 v10.5.5，所以客户端也必须下这个版本，不然会连不上。去 erebe/wstunnel 下载了 wstunnel_10.5.5_linux_amd64.tar.gz。

下载后右键压缩包 → “提取到…”，我把它解压到当前目录（图4）。解压出来一个文件夹，里面只有一个 wstunnel 可执行文件。

我需要把这个 wstunnel 放到系统 PATH 里，比如 /usr/local/bin。打开文件管理器，按 Ctrl+L 输入 /usr/local/bin，发现这个目录是空的（图5）。

直接右键粘贴是灰色的，因为权限不够。我嫌图形化麻烦，直接用命令：

sudo cp /home/wangqiang/下载/wstunnel_10.5.5_linux_amd64/wstunnel /usr/local/bin/
sudo chmod +x /usr/local/bin/wstunnel

然后检查一下版本：

$ /usr/local/bin/wstunnel --version
wstunnel-cli 10.5.5

没问题（图6上半部分）。

接着我在自己的主目录下创建了一个启动脚本 ~/start-vpn.sh，内容如下（记得把服务器 IP 和域名换成自己的）：

#!/bin/bash
/usr/local/bin/wstunnel client -L udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0 --tls-sni-override wg.shuijingwanwq.com wss://154.21.196.249:443

赋予执行权限：

chmod +x ~/start-vpn.sh

用 cat 确认一下内容（图6中间部分）。

四、实现 wstunnel 开机自启（systemd 用户服务）

我不想每次开机都手动执行 nohup ~/start-vpn.sh ...，太麻烦了。所以用 systemd 的用户服务来管理。

先创建服务文件：

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/wstunnel.service

内容如下：

[Unit]
Description=Wstunnel Client for VPN
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/home/wangqiang/start-vpn.sh
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=default.target

保存后，重新加载 systemd、启用服务并立即启动：

systemctl --user daemon-reload
systemctl --user enable wstunnel.service
systemctl --user start wstunnel.service

查看状态：

$ systemctl --user status wstunnel.service
● wstunnel.service - Wstunnel Client for VPN
     Active: active (running) since ...

可以看到服务正在运行（图7）。另外检查端口监听：

$ ss -lun | grep 51820
UNCONN 0      0          127.0.0.1:51820      0.0.0.0:*

说明 UDP 端口已经起来了。

五、准备 Clash 配置文件

我在 Windows 上已经调试好了一份 ZgoCloud-VPN.yaml，里面定义了 WireGuard 节点（公钥、私钥、预共享密钥）和分流规则。直接复制到 Ubuntu 里，放在主目录下：

vi ~/ZgoCloud-VPN.yaml

把内容粘贴进去，保存。核心就是那段 type: wireguard 的代理配置。具体配置可参考：排查实录：解决Clash Verge + Wstunnel + WireGuard下“部分网站无法访问”的DNS死锁问题

六、在 Clash Verge Rev 中导入配置

打开 Clash Verge Rev 图形界面，点左侧“订阅”，然后点右上角“新建” → 选择“Local”类型（图6）。名称我填了 ZgoCloud-VPN，然后点击“选择文件”，选中 ~/ZgoCloud-VPN.yaml，保存。

导入后，在订阅列表里右键这个配置，选择“使用”。然后切换到“代理”页面，能看到 ZgoCloud-WG 这个 WireGuard 节点（图7）。

回到“首页”，打开“系统代理”开关（图8）。

这时候浏览器已经可以访问外网了（图9），网站测试通过。

七、让 Clash Verge Rev 也开机自启

在 Clash Verge Rev 的“设置” → “系统设置”里，有一个“开机自启”开关，我把它打开了（图10）。这样每次登录桌面，软件就会自动启动。

八、重启测试

设置完以上所有步骤后，我重启了电脑。重新登录桌面后：

• 检查 wstunnel 服务：systemctl --user status wstunnel.service 显示 active (running)，并且日志里有 New UDP connection 和 TLS 握手信息（图11）。
• 在 Clash Verge Rev 中测试 Google、YouTube、GitHub、Apple 四个网站，全部正常（图12）。

九、我踩过的坑

1. 不要手动安装系统的 WireGuard 包。sudo apt install wireguard 是多余的，因为 Clash Verge Rev 内置的 mihomo 内核已经用用户空间实现了 WireGuard。
2. wstunnel 版本必须匹配。服务端 v10.5.5，客户端也要下 v10.5.5，否则可能会协议不兼容。
3. systemd 服务启动失败，报 Address in use。是因为我之前手动用 nohup 跑过一个 wstunnel，占用了 51820 端口。我执行了 pkill wstunnel 杀掉手动进程，再启动 systemd 服务就好了。

十、现在每天的体验

开机 → 登录桌面 → 直接打开浏览器就能访问外网。wstunnel 和 Clash Verge Rev 都在后台自动运行，完全不需要我手动干预。国内网站直连，国外网站走 VPN，分流规则自动判断。速度足够看 YouTube 4K，443 端口 + TLS 伪装也一直没被墙过。

这套方案从 Windows 移植到 Ubuntu，虽然中间踩了几个小坑，但最终结果我很满意。把这个过程记录下来，万一以后需要重装系统或者换电脑，可以照着这篇文章自己再来一遍。

如果你也有类似的需求，希望我的这份记录能给你一些参考。不过每个人的网络环境和配置都不太一样，我写的只是我自己的做法，不保证完全通用。祝你折腾顺利～

问题背景
在《ZgoCloud + Wstunnel + WireGuard 提速 4 倍，Clash Verge Rev 自动分流与 443 端口防封实战》 一文发布后，整体代理方案运行稳定，但一个诡异的问题悄然浮现：部分国外网站可以正常访问（如 GitHub、Cloudflare），而另一些则直接报错无法打开。

浏览器给出的错误信息是 `ERR_CONNECTION_CLOSED`，Clash Verge 日志中则反复出现 `context deadline exceeded`。经过一系列排查，最终定位到 DNS 解析死锁——这几乎是此类“部分通、部分不通”问题的典型元凶。本文完整记录从现象到修复的全过程，供遇到类似问题的读者参考。

1. 问题现象
– 可正常访问：`github.com`、`cloudflare.com` 等站点，速度正常。
– 不可访问：`www.google.com` 提示 `ERR_CONNECTION_CLOSED`；`chatgpt.com`、`v2ex.com` 提示 `ERR_CERT_COMMON_NAME_INVALID`（HSTS 导致的证书错误）（如图1）（如图2）。

– Clash 日志特征：`[TCP] dial Proxy … error: context deadline exceeded`，请求在代理层就已超时（如图3）。

– 其他现象：所有被阻断的网站都拥有 HSTS 预加载 特性，而正常的网站则没有。

初步判断：问题不在代理隧道本身的连通性（毕竟 GitHub 能走），而更像是在 DNS 解析或 TLS 握手环节被某种机制干扰了。

2. 第一阶段排查：MTU 与 IPv6
2.1 调整 MTU（无效）
由于报错是超时，我首先怀疑是 Wstunnel 封装的 MTU 分片问题。将 WireGuard 客户端的 MTU 从默认 1420 逐步下调至 1100，问题依旧。部分网站仍然无法访问，说明 MTU 并非主因。

2.2 关闭 IPv6（部分缓解，出现证书错误）
在 Clash Verge 的设置中关闭 IPv6 支持（`ipv6: false`）后，部分网站的连接超时问题减轻，但 `chatgpt.com` 等站点开始报 `ERR_CERT_COMMON_NAME_INVALID` 证书错误。证书错误是 DNS 污染的直接表现：浏览器尝试连接 DNS 污染后的错误 IP，对方返回的证书域名与请求不匹配，因此被 Chrome 拦截。

这说明系统 DNS 返回了被污染的结果，且这些请求并未经过代理隧道。原因是 Clash 的 DNS 功能此前被我关闭了（`dns: false`），所有解析都直接使用本地网络提供的 DNS，而这些 DNS 对敏感域名普遍存在投毒。

3. 第二阶段：启用 Clash DNS 并陷入死锁
既然 DNS 污染是主因，最直接的方案就是启用 Clash 内置 DNS，并让境外域名通过代理隧道查询无污染的 DNS 服务器。

3.1 初始 DNS 配置（失败）

dns:
  enable: true
  ipv6: false
  nameserver:
    - https://dns.alidns.com/dns-query    国内域名
  fallback:
    - https://dns.google/dns-query         国外域名，这里埋下隐患
  proxy: ZgoCloud-WG

重启 Clash 后，所有境外网站全部超时，日志显示：

[DNS] resolve ... from https://dns.google:443/dns-query
re-creating the http client due to requesting ... context deadline exceeded

`dns.google` 自身的查询超时了。这就是经典的 DNS 解析死锁：Clash 需要通过 `ZgoCloud-WG` 代理去连接 `dns.google`，但要连接 `dns.google`，首先得解析出它的 IP 地址，而这个解析请求本身又被配置为走 `dns.google`……形成了一个无限的死循环。

3.2 尝试 IP 形式的 DoT（失败）
为了避免域名解析死锁，我将 fallback 改为 Google 的 DNS over TLS (DoT)，使用 IP 地址直接访问：

fallback:
  - tls://8.8.8.8:853

然而，日志显示 `dial tcp 8.8.8.8:853: i/o timeout`。这说明 Wstunnel 隧道对 非 HTTP 的 TLS 流量（即 DoT） 转发存在问题——Wstunnel 本质上是 WebSocket 隧道，它擅长封装 HTTP/HTTPS，而对纯 TLS 流（端口 853）可能由于封包方式或防火墙限制而无法正常工作。

3.3 最终成功方案：Cloudflare DoT
既然 Google DoT 不通，我换用 Cloudflare 的 `1.1.1.1:853`，并同时做两个关键调整：

1. 保留 IP 直连的 DoT 服务：`tls://1.1.1.1:853`，消除域名解析依赖。
2. 明确指定 DNS 请求走代理节点：使用 `proxy: ZgoCloud-WG`，而非代理组（`Proxy` 或 `Auto`），避免 url-test 误选直连导致超时。
3. 删除直连 dns.google 的规则：原 `rules` 中有一条 `DOMAIN,dns.google,DIRECT`，这会强制 Clash 让 `dns.google` 的解析走直连，与我们的需求相悖，必须移除。
4. 补充排查：Wstunnel 隧道稳定性
在调整 DNS 的过程中，曾一度出现 Clash 日志完全空白的情况，这通常表示 Clash 内核根本没有成功启动。最终发现是不小心导致的乌龙：
– 日志记录被手动暂停：Clash Verge 的日志面板右上角有一个“暂停/继续”按钮，排查时不小心触碰，导致所有日志停止刷新（如图4）。

5. 最终效果
修改后重启 Clash 内核，观察日志：

[DNS] chatgpt.com --> [104.18.2.161 104.18.3.161] A from tls://1.1.1.1:853

所有之前报证书错误或超时的网站（`chatgpt.com`、`v2ex.com`、`google.com`）均能正常打开，`github.com` 等原本正常的网站依然保持快速。问题彻底解决（如图5）。

在 Clash Verge – 首页 – 网站测试 – 测试全部，测试通过（如图7）。

6. 技术总结：为什么你的代理“部分通部分不通”？
– 现象：能打开 GitHub 但打不开 Google，且后者常报证书错误或超时。
– 本质：DNS 污染 + 代理链 DNS 解析死锁。
– 关键点：
1. 不要将 Clash 的 fallback DNS 设置为需要自身解析的域名（如 `dns.google`），应使用 `tls://1.1.1.1` 这类 IP 直连的加密 DNS。
2. DNS 代理策略应精确到节点，避免使用 `url-test` 等可能误判的代理组。
3. Wstunnel 更适合承载 HTTPS 流（DoH），而非纯 TLS 流（DoT）——但实测 Cloudflare 的 `1.1.1.1:853` 可以通过，可能与特定路径有关，可灵活切换。
4. 关闭 IPv6（如图7） 和调整 MTU 是辅助手段，但并非根本解药。

5. 检查 HSTS 错误：当浏览器报 `ERR_CERT_COMMON_NAME_INVALID` 时，首先怀疑 DNS 被投毒，而非代理隧道故障。

7. 最终参考配置（完整版，保留所有注释）
以下是我最终使用的订阅配置文件，所有注释均已保留，方便理解每项含义。请务必将密钥、IP 等信息替换为你自己的实际值。

# ==============================================
# 你的自定义订阅配置，会和Clash Verge自带的基础配置自动合并
# ==============================================

# 新增：配置持久化（保存你手动选择的代理组，重启后不会重置）
profile:
  store-selected: true

# DNS配置（自带config没有DNS部分，保留你的原有配置）
dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  default-nameserver:
    - 114.114.114.114
  nameserver:
    - https://dns.alidns.com/dns-query # 国内域名用阿里 DoH
  fallback:
    - tls://1.1.1.1:853 # 国外域名用 Cloudflare 的 DoT（推荐，相对更快）
  # 直接指定代理节点，不要用 url-test 组
  proxy: ZgoCloud-WG
  fallback-filter:
    geoip: true
    ipcidr:
      - 240.0.0.0/4

# 代理配置（修复了缩进错误，修改了remote-dns-resolve）
proxies:
  - name: "ZgoCloud-WG" # 代理的名字，不用改
    type: wireguard # 代理类型，WireGuard
    server: 127.0.0.1 # 本地的wstunnel客户端的地址，不用改
    port: 51820 # 本地的wstunnel客户端的端口，不用改
    ip: 10.7.0.2 # 你的WireGuard客户端的IP，从client.conf里拿到的
    public-key: a4DvxU7LgW0069MbHpMMhcc... # WireGuard的公钥，从client.conf里拿到的
    private-key: yBdtV4+0CxvTFvXWrPS+sM... # WireGuard的私钥，从client.conf里拿到的
    pre-shared-key: 3glNI413OnTF2mAJLo9JSFG... # WireGuard的预共享密钥，从client.conf里拿到的
    remote-dns-resolve: false # 关闭远程解析：server是本地IP，不需要远程解析
    udp: true # 开启UDP转发，支持游戏之类的UDP流量
    mtu: 1100 # 调整MTU，适配wstunnel的封装，避免分片丢包

# 代理分组（保留你的原有配置）
proxy-groups:
  - name: "Proxy" # 手动选择的分组，你可以手动切换直连还是VPN
    type: select
    proxies:
      - ZgoCloud-WG # 走VPN
      - DIRECT # 直连

  - name: "Auto" # 自动选择的分组，自动判断国内国外
    type: url-test
    proxies:
      - ZgoCloud-WG
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

# 完善后的分流规则（补充了缺失的规则，所有缩进都改成了空格）
rules:
  # 1. 最高优先级：Wstunnel 服务器直连（解决代理循环）
  - IP-CIDR,154.21.196.249/32,DIRECT

  # 2. DNS 域名必须直连（解决你现在的 DNS 解析失败）
  - DOMAIN,dns.alidns.com,DIRECT

  # 3. 本地局域网直连
  - IP-CIDR,127.0.0.1/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT

  # 4. 国内流量直连
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 5. 其他全部走代理
  - MATCH,Proxy

结语
这次排查耗时虽长，但最终聚焦到一个简单的 DNS 死锁问题上。对于自建代理而言，DNS 的配置往往比隧道本身更容易踩坑。希望本文的记录能帮助同样在“部分网站打不开”的迷雾中摸索的朋友，少走一些弯路。如果你也有类似的 Clash + WireGuard + Wstunnel 组网经验，欢迎在评论区交流。

核心说明：本流程完全匹配我之前 Vultr、DMIT 的操作习惯，重点突出 ZgoCloud 优势——国内无需翻墙、支持支付宝支付、洛杉矶三网优化（CN2 GIA+9929+CMIN2）、一键部署防封 WireGuard，步骤简洁，全程5-10分钟搞定。当前所有套餐（Starter、Standard、Pro、Premium）均显示 Out of stock（缺货），结合 ZgoCloud 套餐补货规律，补充补货提醒和可替代优化套餐，帮我快速完成部署。
最近在 ZgoCloud 的洛杉矶服务器上部署 VPN，解决了之前 Vultr 新加坡节点遇到的两个痛点：原生 WireGuard 分流配置复杂、端口换了无数个还是被运营商封禁。最终选择了Wstunnel+Clash Meta的方案，兼顾最强的防封能力和自动分流的便利性，这篇文章把整个过程和傻瓜式部署流程整理出来，你跟着一步步操作就能完成。

一、注册 ZgoCloud 账号（国内直接操作，不用翻墙，比Vultr更便捷）
1. 直接打开 ZgoCloud 官网（国内无需翻墙，复制链接即可访问：https://zgovps.com ）。
2. 进入 ZgoCloud 官网首页后，先点击页面上的「Client Portal」（客户门户），进入新页面后，再点击该页面右上角的「Register」（注册）按钮，即可进入注册页面，无需手机号，仅需3步完成（如图1）：

3. 输入我的常用邮箱（和我注册 Vultr、DMIT 的邮箱一致即可，方便记忆）；
4. 设置账号密码（建议和之前的密码一致，要求8位以上，包含字母+数字，提升安全性）；
5. 勾选「I agree to the Terms of Service and Privacy Policy」（同意服务条款），完成简单的人机验证（滑块验证，无需复杂操作），点击「Create Account」（创建账号）。
6. 注册完成后，系统自动登录后台，同时会向我的邮箱发送一封验证邮件，点击邮件中的验证链接，完成邮箱验证（仅需1次，确保账号正常使用，避免后续无法充值、部署服务器）。
7. 验证完成后，返回官网后台，无需再次登录，直接进入控制台（Dashboard），准备部署服务器。

二、部署洛杉矶优化服务器（先部署，再充值，解决类似 DMIT 的充值提示问题）
重点提醒：ZgoCloud 和 DMIT 一样，需先创建「有效订单」（部署服务器），再进行充值，避免出现“无有效订单无法充值”的提示，操作顺序和我之前调整后的 DMIT 流程完全一致。在 Check our amazing offers 页面搜索 GIA，选择 Los Angeles AMD Optimised VPS，当前所有套餐（Starter、Standard、Pro、Premium）只有 Premium 显示有货（如图4），

不过，当我 2 小时后刷新页面，发现当前所有套餐（Starter、Standard、Pro、Premium）均显示 Out of stock（缺货）（如图5），

结合 ZgoCloud 套餐补货规律（特价/热门套餐会不定期补货，每天补货时间不固定），补充可操作方案和补货提醒。
1. 第一步：在后台控制台（Dashboard）首页，直接点击「Order more」按钮，点击后即可跳转至服务器套餐选择及配置页面；
2. 第二步：若仍未找到入口，直接访问 ZgoCloud 套餐订购页面（无需额外翻墙）：https://zgovps.com ，在官网首页点击 Price，在 Check our amazing offers 页面搜索 GIA，选择 Los Angeles AMD Optimised VPS，点击「Select」，直接进入选择套餐页面（与后台部署入口一致，配置步骤不变）。
3. 当前无货解决方案（重点，贴合实际情况）：

3.1. 方案一：等待补货（优先推荐）：ZgoCloud 热门优化套餐（含 Premium 及之前的 Starter/Standard/Pro）会不定期补货，根据平台过往补货规律，特价和高端优化套餐每天会有不固定时段补货，且补货后库存有限（我遇到的2小时内从有货到缺货就是典型情况），建议每1-2小时刷新配置页面，留意库存变化，补货后立即部署，避免再次缺货；
3.2. 方案二：选择可替代优化套餐：若不想等待补货，可选择 ZgoCloud 洛杉矶节点其他中国优化套餐（均标注 China Optimised），如Los Angeles Ryzen9 Performance VPS（AMD Ryzen9 7950X，9929&CMIN2优化）、Los Angeles Intel Performance VPS（Intel® Xeon® Platinum 8452Y，9929&CMIN2优化），这类套餐虽非 Premium 级别，但同样支持国内优化，延迟40-80ms，可满足日常谷歌搜索/翻译、国外浏览需求，且偶尔会有补货，价格折算月付16美元左右，贴合我的预算，配置和操作流程与Premium套餐完全一致，同样支持一键部署防封 WireGuard；
3.3. 方案三：选择其他优化节点套餐：ZgoCloud 香港、东京、大阪节点同样有 China Optimised 优化套餐（如香港AMD VPS、东京Intel VPS），均支持国内优化，延迟表现良好（香港节点延迟40-60ms，东京节点延迟50-70ms），且库存相对充足，可作为备选，配置选择和操作流程与洛杉矶节点一致，仅节点选择不同即可，支持支付宝支付和一键部署 WireGuard。

4. 若找到可部署套餐（补货后或替代套餐），按以下配置选择（贴合我的预算和需求，直接选择即可，无需多余操作）：
5. Location（节点）：优先选择「Los Angeles, USA（CN2 GIA+9929+CMIN2）」（洛杉矶三网优化节点，延迟30-60ms，和 DMIT 洛杉矶 Premium 网络体验一致，晚高峰不绕路、不丢包，完美替代我之前的 Vultr 新加坡节点），不要选择其他节点（其他节点虽有 China Optimised 国内优化，但缺少 Premium 级别的高端优化，延迟和稳定性不如洛杉矶三网优化节点，整体体验偏差）。若洛杉矶节点无货，可选择香港、东京节点的优化套餐作为备选。
6. Server Type（服务器类型）：选择「Shared CPU」（共享CPU，和我之前 Vultr、DMIT 选择的一致，日常浏览、谷歌搜索/翻译完全足够，优化套餐默认搭载高性能 CPU，贴合 ZgoCloud 高端硬件配置标准，如AMD EPYC™、AMD Ryzen9、Intel Xeon系列处理器）。
7. Plan（套餐选择）：若 Premium 套餐补货，优先选择（价格58.00美元/季度，折算月付约16美元，配置：1核/2G内存/40G NVMe/200Mbps带宽/1.5T月流量，三网全优化）；若 Premium 无货，选择洛杉矶其他优化套餐（如Ryzen9 Performance、Intel Performance）或其他节点优化套餐，价格均贴合我的预算，配置可满足日常使用需求，支持一键部署 WireGuard。三天后，发现 「Los Angeles, USA（CN2 GIA+9929+CMIN2）」 Pro 有货，点击 Continue（如图6）。

8. 进入必填项填写页面（核心需填写 Hostname），（必填项，标记*，命名规范及推荐名称如下，简单好记、合规即可，不影响后续部署和使用），命名为 WireGuard，点击 Continue（如图7）；

9. 进入 购物车 页面，Choose payment method 默认选择 Stripe Alipay，还需要填写客户信息（可在帐户的 Account details 中进行编辑），点击 Checkout。（如图8）。

10. 支付成功后，进入 Billing 页面，如图9

11. 点击 Services – Los Angeles AMD Optimised VPS，可查看已经购买的 VPS。如图10

12. 进入 详情页面，点击 Access Control Panel – Click here to access Control Panel。如图11

13. 进入 Server Setup… 页面，Hostname （WireGuard 2026 0509），Timezone 保持默认的「(UTC-08:00) America/Los_Angeles」，重点选 Operating System，务必选「Ubuntu 22.04 x64」（和我之前 Vultr、DMIT 使用的系统完全一致，兼容性最好，避免后续 WireGuard 部署出现兼容问题，不用额外学习新系统操作）。如图12

14. 点击 Install with Ubuntu Server 22.04 LTS (Jammy Jellyfish)，弹出对话框 Are you sure you want to install the server without any SSH keys? 点击 Install Without。如图13

15. 部署完成后，找到刚部署的服务器；找到后，记录3个核心信息（后续无需用到，仅作备用）：
15.1. Network – IPv4 Addresses ，公网IP：服务器的对外IP（后续测试速度会用到）（如图14）；

15.2. Username：默认登录账号为「root」；
15.3. Password：部署成功后，会收到邮件（Your Server is Ready!，其中包含密码）。如果未收到，Options – Password – Reset Password，重置服务器登录密码（邮件中会收到新密码）（如图15）。

ZgoCloud 避坑细节（仅针对本步骤，补充部署入口+套餐缺货避坑）：
1. 节点必须选「洛杉矶三网优化」（补货后优先选），不要选洛杉矶普通节点，否则延迟会偏高（180ms以上），失去优化优势；其他节点优化套餐可作为备选，同样支持国内优化；
2. 系统务必选「Ubuntu 22.04 x64」，和我之前的操作一致，避免后续 WireGuard 部署失败；
3. 当前所有套餐均缺货时，无需反复尝试点击缺货套餐，优先按“等待补货”或“选择替代套餐”操作，避免浪费时间；ZgoCloud 特价和优化套餐补货频率较高，可重点留意官网套餐页和配置页面的库存变化，也可关注平台促销活动，促销期间补货量会增加；

三、我遇到的问题（Vultr 新加坡节点部署 WireGuard）
之前用原生 WireGuard 的时候，遇到了两个非常头疼的问题：
1. 分流配置太麻烦
原生 WireGuard 的分流只能靠手动配置 AllowedIPs，国内的 IP 段要自己排除，国外的走 VPN（国外的 IP 段要自己加），每次规则更新还要手动改配置，非常繁琐，而且没有一键开关，切换起来很不方便。
2. 换了无数端口还是被封
我一开始以为是端口的问题，把 WireGuard 的端口在 20000-60000 之间来回换，结果没过几天还是被运营商封了。后来才发现，运营商根本不是封端口，而是通过 DPI（深度包检测）识别到了 WireGuard 的流量特征，只要检测到是 WireGuard 的流量，直接就给你封了，普通的改端口根本没用。并且在一些关键时候，比如说视频会议期间，突然被封，太影响体验。

四、所有防封方案的分析对比

WireGuard 作为新一代高性能 VPN 协议，默认使用 UDP 协议传输，在部分网络环境中可能会被运营商或防火墙通过端口封锁、DPI（深度包检测）等方式阻断。以下是目前主流的 WireGuard 防封方案的详细对比，帮助你根据自身网络环境选择合适的方案：

方案选择建议

1. 宽松环境：如果你的网络只是简单的端口封锁，没有深度检测，直接使用非标准端口的原生 WireGuard即可，性能最优，配置最简单。
2. 基础封锁环境：如果 ISP 会封禁单个端口，或者有基础的 DPI 检测，可以选择端口跳跃或者wg-obfuscator + WireGuard，配置简单，性能损耗小。
3. UDP 被禁用的环境：如果你的网络完全禁用了 UDP 协议，只能使用 TCP，那么可以选择Phantun + WireGuard或者Stunnel + WireGuard，将 UDP 转为 TCP 传输。
4. 严格 DPI 环境：如果网络有严格的深度包检测，需要伪装成正常网页流量，推荐使用wstunnel + WireGuard或者Shadowsocks + WireGuard，可以很好的绕过 DPI 检测。
5. 强封锁环境：如果是国家级的强封锁，源站 IP 很容易被封禁，那么推荐使用防封 CDN 中转 + WireGuard，可以隐藏源站，自动轮换入口，最大程度避免被封锁。

最终方案选择：wstunnel + WireGuard + Clash Meta

针对中国大陆当前的网络环境，运营商的 DPI 检测强度不断提升，普通的轻量混淆方案（如 Phantun + WireGuard、AmneziaWG）已经无法应对，这类方案的流量特征在强 DPI 下仍会被识别，通常使用几天就会被封锁。

而 wstunnel + WireGuard 方案可以将 VPN 流量完全伪装成正常的 HTTPS 网页访问流量，运营商无法识别出这是 VPN 流量，防封能力在所有方案中最强，稳定性最高，可长期使用不会被封。

同时该方案完美兼容 Clash Meta，你可以继续使用 Clash 的自动分流功能，无需手动配置 WireGuard 的 AllowedIPs，还可以使用 Clash 的一键开关等功能，完美解决了传统 WireGuard 方案的分流配置复杂的痛点。

五、傻瓜式部署流程
你跟着下面的步骤一步步操作，复制粘贴命令就能完成，不用懂任何复杂的原理。
前置准备
1. 你需要有一个自己的域名（用来申请 SSL 证书，免费的域名也可以，比如 freenom 的）
2. 把你的域名解析到 ZgoCloud 洛杉矶服务器的公网 IP，解析完成后，等个 10 分钟生效（如图16）

3. 用 SSH 登录你的 ZgoCloud 服务器，用 root 用户登录（如果不是 root，前面加 sudo 就行）

第一部分：服务端部署（在 ZgoCloud 服务器上操作）
步骤 1：更新系统
先把系统更新一下，避免有旧的依赖问题：

apt update && apt upgrade -y

步骤 2：一键安装 WireGuard
用官方的一键脚本，自动安装 WireGuard，不用你手动配置：

wget -O wireguard.sh https://get.vpnsetup.net/wg
bash wireguard.sh --auto

这个脚本会自动帮你安装 WireGuard，配置好服务端，生成密钥，不用你做任何操作，等它运行完就可以了。
运行完之后，它会给你输出 WireGuard 的配置信息，你把这些信息记下来（客户端配置文件路径：/root/client.conf），后面客户端要用：
– 服务端的公钥：public-key后面的那串字符
– 客户端的私钥：private-key后面的那串字符
– 客户端的 IP：10.7.0.2 这个（如果你的不一样，就用它输出的）

root@wireguard-2026-0509:~# cat client.conf
[Interface]
Address = 10.7.0.2/24
DNS = 8.8.8.8, 8.8.4.4
PrivateKey = yBdtV4+0CxvTFvXWrPS+sMaWD...

[Peer]
PublicKey = a4DvxU7LgW0069MbHpMMhcc16e...
PresharedKey = 3glNI413OnTF2mAJLo9JSFG/Hb/jZpgEqR5z9Gc8x9g=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 154.21.196.249:51820
PersistentKeepalive = 25

步骤 3：安装 [acme.sh](acme.sh)，申请 SSL 证书
我们需要一个合法的 SSL 证书，用来伪装成 HTTPS，用 [acme.sh](acme.sh) 一键申请免费的 Let’s Encrypt 证书：

# 安装acme.sh（shuijingwanwq@gmail.com 需要换为你自己的邮箱地址）
curl https://get.acme.sh | sh -s email=shuijingwanwq@gmail.com
# 把acme.sh加入环境变量
source ~/.bashrc

然后申请证书，把下面的你的域名（wg.shuijingwanwq.com）换成你自己的域名（就是你之前解析到服务器 IP 的那个）：

acme.sh --issue -d wg.shuijingwanwq.com --standalone

这个命令会自动帮你申请证书，等它运行完，证书就生成好了，默认存在/root/.acme.sh/你的域名/下面（如图17）。

[Mon May 11 02:21:15 PDT 2026] Your cert is in: /root/.acme.sh/wg.shuijingwanwq.com_ecc/wg.shuijingwanwq.com.cer
[Mon May 11 02:21:15 PDT 2026] Your cert key is in: /root/.acme.sh/wg.shuijingwanwq.com_ecc/wg.shuijingwanwq.com.key
[Mon May 11 02:21:15 PDT 2026] The intermediate CA cert is in: /root/.acme.sh/wg.shuijingwanwq.com_ecc/ca.cer
[Mon May 11 02:21:15 PDT 2026] And the full-chain cert is in: /root/.acme.sh/wg.shuijingwanwq.com_ecc/fullchain.cer
[Mon May 11 02:21:16 PDT 2026] ARI suggestedWindow: 2026-07-25T23:59:59Z to 2026-07-27T23:59:59Z
[Mon May 11 02:21:16 PDT 2026] Next renewal time picked from ARI window: 2026-07-26T09:21:15Z

步骤 4：安装 wstunnel
wstunnel 就是用来把 UDP 流量封装成 HTTPS 的工具，我们下载它的二进制版本：

# 下载wstunnel
wget https://github.com/erebe/wstunnel/releases/download/v10.5.2/wstunnel_10.5.2_linux_amd64.tar.gz
# 解压
tar xzf wstunnel_10.5.2_linux_amd64.tar.gz
# 把它放到系统路径，方便运行
mv wstunnel /usr/local/bin/
# 加执行权限
chmod +x /usr/local/bin/wstunnel

升级至 v10.5.5

# 先停掉wstunnel
systemctl stop wstunnel
# 下载v10.5.5的压缩包，和你之前的格式一样
wget https://github.com/erebe/wstunnel/releases/download/v10.5.5/wstunnel_10.5.5_linux_amd64.tar.gz
# 解压
tar xzf wstunnel_10.5.5_linux_amd64.tar.gz
# 放到系统路径
mv wstunnel /usr/local/bin/
# 加执行权限
chmod +x /usr/local/bin/wstunnel
# 启动wstunnel
systemctl start wstunnel

步骤 5：配置 wstunnel 开机自启
我们要把 wstunnel 配置成系统服务，开机自动启动，不用你每次手动开：

# 创建systemd服务文件
vi /etc/systemd/system/wstunnel.service

按 I 键，然后把下面的内容粘贴进去，把我的域名（wg.shuijingwanwq.com）换成你自己的：

[Unit]
Description=Wstunnel service
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/wstunnel server --tls-certificate /root/.acme.sh/wg.shuijingwanwq.com_ecc/fullchain.cer --tls-private-key /root/.acme.sh/wg.shuijingwanwq.com_ecc/wg.shuijingwanwq.com.key --restrict-to 127.0.0.1:51820 wss://0.0.0.0:443
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

粘贴完之后，按Esc键，然后输入:wq，回车就可以保存退出了。
然后启动服务，设置开机自启：

# 重新加载systemd配置
systemctl daemon-reload
# 启动wstunnel
systemctl start wstunnel
# 设置开机自启
systemctl enable wstunnel

然后检查一下服务是不是正常运行：

systemctl status wstunnel

如果看到 active (running) 就说明没问题了（如图18）。

步骤 6：配置防火墙
放行 443 端口，因为 wstunnel 用的是 443 端口：

# 检查ufw是否在运行
root@wireguard-2026-0509:~# ufw status
Status: inactive

服务器没有启用防火墙！ufw 是 inactive 状态，说明服务器所有端口都是默认开放的，不用配置防火墙了，直接就可以用了，跳过防火墙的配置步骤就行。

第二部分：客户端部署（在你自己的电脑上操作）
步骤 1：安装 Clash Verge 客户端
原来的 Clash Verge 原作者已经归档停更了，不过现在社区接手了，做了Clash Verge Rev，这个是继续维护更新的版本，一直在更新，比原来的版本更新更快，支持最新的 Clash Meta（现在改名叫 mihomo），Windows、Mac、Linux 都有：
https://github.com/clash-verge-rev/clash-verge-rev/releases
下载对应你系统的版本，Windows 就下 win 的（Clash.Verge_2.5.0-rc_x64-setup.exe），Mac 就下 mac 的，安装好之后打开。
现在安卓的最新的 Clash Meta 客户端，是 Tabby，去这里下载最新版本：https://github.com/Goooler/Tabby/releases （Tabby-3.0.0-arm64-v8a-release.apk）
步骤 2：安装 wstunnel 客户端
同样，你本地也要装 wstunnel 客户端，用来把本地的 WireGuard 流量转发到服务端：
下载这个：https://github.com/erebe/wstunnel/releases
根据操作系统下载对应的版本就行。Windows 就下 wstunnel_10.5.5_windows_amd64.tar.gz。Android 就下 wstunnel_10.5.5_android_arm64.tar.gz。注：此处必须下载 10.5.5 版本，以与服务端版本保持一致。
解压之后，把 wstunnel 放到你能找到的地方，比如 Windows 的话，放到 C:\wstunnel\ 下面。
然后，创建一个启动脚本，Windows 的话，新建一个文本文件，把下面的内容粘贴进去，把你的ZgoCloud服务器IP换成你自己的（即 154.21.196.249），把你的域名换成你自己的（即 wg.shuijingwanwq.com），然后把文件后缀改成.bat（如图19）：

@echo off
taskkill /f /im wstunnel.exe >nul 2>&1
C:\wstunnel\wstunnel.exe client -L udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0 --tls-sni-override wg.shuijingwanwq.com wss://154.21.196.249:443
pause

Mac/Linux 的话，新建一个 shell 脚本：

#!/bin/bash
./wstunnel client -L udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0 --tls-sni-override wg.shuijingwanwq.com wss://154.21.196.249:443

然后给它加执行权限，以后你只要双击这个脚本，就能启动 wstunnel 客户端了，启动成功后，这个窗口不能关，最小化到后台就可以了，关了的话 VPN 就断了。
输出里显示：
wstunnel client v10.5.5 正常启动了
UDP server 已经在 127.0.0.1:51820 正常监听了
没有任何报错，说明 wstunnel 已经正常连接到你的服务器了，现在你就可以启动 Clash Verge，然后打开系统代理，就可以正常上网了，所有的自动分流、防封的功能都已经生效了！

步骤 3：配置 Clash Meta 的分流

新建配置文件，ZgoCloud-VPN.yaml，内容如下：

# ==============================================
# 你的自定义订阅配置，会和Clash Verge自带的基础配置自动合并
# ==============================================

# 新增：配置持久化（保存你手动选择的代理组，重启后不会重置）
profile:
  store-selected: true

# DNS配置（自带config没有DNS部分，保留你的原有配置）
dns:
  enable: false # 【关键修复】关闭内核DNS，避免解析死循环，使用系统DNS
  listen: 0.0.0.0:53
  default-nameserver:
    - 114.114.114.114 # 国内默认DNS
    - 8.8.8.8 # 谷歌备用DNS
  nameserver:
    - https://dns.alidns.com/dns-query # 阿里国内DNS，用来解析国内域名
  fallback:
    - https://dns.google/dns-query # 谷歌国外DNS，用来解析国外域名
  fallback-filter:
    geoip: true
    ipcidr:
      - 240.0.0.0/4

# 代理配置（修复了缩进错误，修改了remote-dns-resolve）
proxies:
  - name: "ZgoCloud-WG" # 代理的名字，不用改
    type: wireguard # 代理类型，WireGuard
    server: 127.0.0.1 # 本地的wstunnel客户端的地址，不用改
    port: 51820 # 本地的wstunnel客户端的端口，不用改
    ip: 10.7.0.2 # 你的WireGuard客户端的IP，从client.conf里拿到的
    public-key: a4DvxU7LgW0069MbHpMMhcc16e... # WireGuard的公钥，从client.conf里拿到的
    private-key: yBdtV4+0CxvTFvXWrPS+sMaWD... # WireGuard的私钥，从client.conf里拿到的
    pre-shared-key: 3glNI413OnTF2mAJLo9JSFG/Hb/jZpgEqR5z9Gc8x9g= # WireGuard的预共享密钥，从client.conf里拿到的
    remote-dns-resolve: false # 关闭远程解析：server是本地IP，不需要远程解析
    udp: true # 开启UDP转发，支持游戏之类的UDP流量
    mtu: 1100 # 调整MTU，适配wstunnel的封装，避免分片丢包

# 代理分组（保留你的原有配置）
proxy-groups:
  - name: "Proxy" # 手动选择的分组，你可以手动切换直连还是VPN
    type: select
    proxies:
      - ZgoCloud-WG # 走VPN
      - DIRECT # 直连

  - name: "Auto" # 自动选择的分组，自动判断国内国外
    type: url-test
    proxies:
      - ZgoCloud-WG
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

# 完善后的分流规则（补充了缺失的规则，所有缩进都改成了空格）
rules:
  # 1. 最高优先级：Wstunnel 服务器直连（解决代理循环）
  - IP-CIDR,154.21.196.249/32,DIRECT

  # 2. DNS 域名必须直连（解决你现在的 DNS 解析失败）
  - DOMAIN,dns.alidns.com,DIRECT
  - DOMAIN,dns.google,DIRECT

  # 3. 本地局域网直连
  - IP-CIDR,127.0.0.1/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT

  # 4. 国内流量直连
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 5. 其他全部走代理
  - MATCH,Proxy

然后在 订阅 – 新建，选 Local 类型，然后：
名称填：ZgoCloud-VPN
描述留空
然后点击选择文件，选择你刚才保存到桌面的 ZgoCloud-VPN.yaml
然后点击保存，就导入好了！
导入完之后，你就会在订阅列表里看到这个 ZgoCloud-VPN 的配置了，右键 – 使用，代理页面里就会出现 ZgoCloud-WG 这个代理了，然后启用系统代理，浏览器就能正常打开 google.com了！

需要确保首页 – 当前节点 – ZgoCloud-VPN 是 绿色状态（如图25）。

（此配置文件 Windows 与 Android 可共用同一份了）：

第三部分：使用方法
我给你整理好完整的使用步骤，你跟着一步步来就可以了：

3.1. Windows电脑的使用步骤
3.1.1. 先启动wstunnel客户端（这个是防封的核心，必须先开）双击 wstunnel.bat 这个脚本，就能启动 wstunnel 客户端

3.1.2. 然后启动 Clash Verge
– 从开始菜单打开 Clash Verge
– 点击左侧的首页，然后把系统代理的开关打开（如图22）

– 搞定了！现在你就可以正常上网了：
– 国内的网站、APP，会自动直连，速度和你平时一样
– 国外的网站、APP，会自动走VPN，不用你手动切换
– 想要关掉 VPN 的话，直接把首页的系统代理开关关掉就可以了，一键开关，很方便。

3.2. 安卓手机的使用步骤
3.2.1. 先安装你下载的`Tabby-3.0.0-arm64-v8a-release.apk`，安装完打开它
3.2.2. 把我们的配置文件（就是带注释的那一段）保存成`config.yaml`，传到你的手机里
3.2.3. 打开Tabby，点击导入配置，选择你传到手机里的`config.yaml`
3.2.4. 然后启动安卓版的wstunnel客户端，用同样的命令连接你的服务器
3.2.5. 然后打开Tabby的系统代理开关，就可以用了，和电脑一样，自动分流，一键开关。

整个过程就是这样，你只要先开wstunnel，再开Clash，打开系统代理，就全部搞定了，所有的自动分流、防封的功能都生效了。

第四部分：注意事项

4.1. 如果发现 首页 – 当前节点 ZgoCloud-VPN 显示 Timeout，google.com 打不开，订阅 – 查看运行时订阅（如图24）。此订阅的内容，是自带的加上我自己添加的配置项，合并后的内容。需要仔细检查配置项。

4.2. 开机自启的设置

启动顺序必须是：先启动 wstunnel，再启动 Clash Verge，因为 Clash 要用到 wstunnel 的 51820 端口，如果先开 Clash，wstunnel 还没准备好，Clash 就会连接失败（启动顺序不需要严格遵守了，因为我已经解决）。

Windows的开机自启设置方法，很简单：
4.2.1. 右键点击你改好的wstunnel的bat文件，选择创建快捷方式
4.2.2. 按下键盘的`Win+R`，输入`shell:startup`，回车，就会打开开机启动的文件夹
4.2.3. 把你刚才创建的wstunnel的快捷方式，拖到这个启动文件夹里，这样开机的时候wstunnel会自动启动
4.2.4. 然后打开Clash Verge的设置，找到开机自启的开关，把它打开，这样Clash也会开机自动启动

这样设置完之后，开机的时候，系统会先自动启动wstunnel，等wstunnel准备好，再启动Clash，两个都会自动后台运行，不用你手动开了，开机就能直接用VPN。

Mac/Linux的开机自启
可以用systemd或者launchd来配置，把wstunnel和Clash都加到自启里，顺序也是先启动wstunnel，再启动Clash，就可以了。

四、常见问题
1. 证书过期了怎么办？
[acme.sh](acme.sh) 会自动帮你更新证书，不用你管，它会在证书过期前 30 天自动更新，wstunnel 会自动加载新的证书。
2. wstunnel 客户端启动不了怎么办？
检查一下你的服务器 IP 有没有填错，还有服务器的 443 端口有没有开放，有没有被防火墙挡住。
3. 分流不对怎么办？
Clash 的规则会自动更新，你可以在 Clash Verge 里点击更新规则，就会拉取最新的规则了。

这样部署完之后，你就有了一个防封能力最强的 VPN，而且自动分流，不用手动配置，一键开关，完美解决你之前的所有问题。

五、测试效果（命令行量化测速 · 纯数据客观验证）

前置说明：测速选型逻辑
1. 放弃 ping www.google.com 测速
Google 全站默认封禁 ICMP Ping 请求，即便隧道完全正常，ping 也会直接超时，无法反映线路真实质量，无任何参考价值。
2. 选定标准测速靶机 www.gstatic.com
该域名为谷歌官方静态资源节点，专为连通性、TCP 延迟探测设计；不屏蔽 443 端口探测、全球节点覆盖与 Google 主站完全一致，也是 Clash 内核官方默认延迟测速地址（generate_204 轻量接口），适配所有隧道架构，原生WireGuard / wstunnel 封装 WireGuard 可公平对比。
3. 测试统一标准
节点本机延迟用 ICMP Ping 测 VPS 机房直连延迟；外网业务延迟用 HTTP 204 接口请求耗时量化，不受域名封禁、协议差异影响，两套节点共用一套测试规则，数据具备可比性。

1. 测试环境与测试对象
测试终端：Windows PowerShell
优化节点：154.21.196.249 ZgoCloud 洛杉矶（CN2 GIA+9929+CMIN2 三网精英线路）
对比节点：139.180.154.26 Vultr 新加坡常规国际线路
固定测试目标：国外标准测速域名：www.gstatic.com

2. 节点本机直连延迟对比测试
测试时间：北京时间 23:00，同一网络环境、同一时段无带宽抢占（四川成都移到宽带）。

2.1 Vultr 新加坡常规节点

Pinging 139.180.154.26 with 32 bytes of data:
Reply from 139.180.154.26: bytes=32 time=281ms TTL=44
Reply from 139.180.154.26: bytes=32 time=251ms TTL=44
Reply from 139.180.154.26: bytes=32 time=274ms TTL=44
Reply from 139.180.154.26: bytes=32 time=257ms TTL=44
Reply from 139.180.154.26: bytes=32 time=253ms TTL=44
Reply from 139.180.154.26: bytes=32 time=253ms TTL=44
Reply from 139.180.154.26: bytes=32 time=252ms TTL=44
Reply from 139.180.154.26: bytes=32 time=247ms TTL=44
Reply from 139.180.154.26: bytes=32 time=260ms TTL=44
Reply from 139.180.154.26: bytes=32 time=258ms TTL=44

Ping statistics for 139.180.154.26:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 247ms, Maximum = 281ms, Average = 258ms

实测数据与分析
– 延迟区间：247ms–281ms，平均延迟 258ms
– 丢包率：0% 无丢包，基础链路连通性正常
– 抖动表现：极值波动 34ms，相比优化节点抖动更大
– 线路评价：常规国际公网线路，虽无丢包但基线延迟偏高，链路冗余一般，高峰时段易出现延迟飘高、网页加载变慢情况。

2.2 ZgoCloud 洛杉矶优化节点

Pinging 154.21.196.249 with 32 bytes of data:
Reply from 154.21.196.249: bytes=32 time=174ms TTL=42
Reply from 154.21.196.249: bytes=32 time=174ms TTL=42
Reply from 154.21.196.249: bytes=32 time=174ms TTL=42
Reply from 154.21.196.249: bytes=32 time=176ms TTL=42
Reply from 154.21.196.249: bytes=32 time=176ms TTL=42
Reply from 154.21.196.249: bytes=32 time=175ms TTL=42
Reply from 154.21.196.249: bytes=32 time=198ms TTL=42
Reply from 154.21.196.249: bytes=32 time=177ms TTL=42
Reply from 154.21.196.249: bytes=32 time=179ms TTL=42
Reply from 154.21.196.249: bytes=32 time=192ms TTL=42

Ping statistics for 154.21.196.249:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 174ms, Maximum = 198ms, Average = 179ms

实测数据与分析
– 延迟区间：174ms–198ms，平均延迟 179ms
– 丢包率：0% 全量接收，无任何丢包
– 抖动表现：极值波动仅 24ms，多数请求稳定落在 174–179ms 区间，抖动极小
– 线路评价：三网优化专线优势明显，低延迟、低抖动、零丢包，链路稳定性极强，适配谷歌生态、海外网页、轻量流媒体等低延时需求场景。

2.3 节点本机延迟横向对比结论
ZgoCloud 洛杉矶三网优化节点平均 179ms，相较 Vultr 新加坡常规节点 258ms，基线延迟降低约 79ms，延迟优化幅度达 30.6%；
且抖动更小、走势更平稳，专线优化带来的低延迟、高稳定性优势非常直观。

3. 不同时段外网业务连通耗时测试
采用统一命令：请求谷歌 generate_204 轻量接口，以完整请求耗时模拟真实网页访问延迟，同时兼容 Vultr 原生 WireGuard、ZgoCloud wstunnel + WireGuard 双架构，做到完全公平对比。
本次共覆盖三个典型时段，完整呈现高峰/平峰的性能差异：

3.1 晚高峰时段（北京时间 23:00）
Vultr 原生 WireGuard：外网标准接口完整请求耗时：1352ms

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.gstatic.com/generate_204 -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 352
Ticks             : 13521147
TotalDays         : 1.56494756944444E-05
TotalHours        : 0.000375587416666667
TotalMinutes      : 0.022535245
TotalSeconds      : 1.3521147
TotalMilliseconds : 1352.1147

ZgoCloud wstunnel + WireGuard：外网标准接口完整请求耗时：348ms

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.gstatic.com/generate_204 -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 348
Ticks             : 3480620
TotalDays         : 4.02849537037037E-06
TotalHours        : 9.66838888888889E-05
TotalMinutes      : 0.00580103333333333
TotalSeconds      : 0.348062
TotalMilliseconds : 348.062

对比：ZgoCloud 请求耗时仅为 Vultr 的 1/4，访问效率提升近4倍。

3.2 下午平峰时段（北京时间 14:30）
Vultr 原生 WireGuard：单次请求耗时：1526ms

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.gstatic.com/generate_204 -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 526
Ticks             : 15267882
TotalDays         : 1.76711597222222E-05
TotalHours        : 0.000424107833333333
TotalMinutes      : 0.02544647
TotalSeconds      : 1.5267882
TotalMilliseconds : 1526.7882

ZgoCloud wstunnel+WireGuard：单次请求耗时：446ms

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.gstatic.com/generate_204 -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 446
Ticks             : 4460668
TotalDays         : 5.16281018518519E-06
TotalHours        : 0.000123907444444444
TotalMinutes      : 0.00743444666666667
TotalSeconds      : 0.4460668
TotalMilliseconds : 446.0668

对比：对比：ZgoCloud 请求耗时仅为 Vultr 的 1/3，访问效率提升近3倍。随着国际出口开始逐步拥堵，Vultr 延迟已经开始飘高，ZgoCloud 依旧保持稳定。

3.3 业务耗时整体对比结论
外网真实业务场景下，ZgoCloud 线路在高峰时段优势极其明显，请求耗时仅为 Vultr的 1/4，访问效率提升近4倍；平峰时段差距虽有缩小（3倍），但 ZgoCloud 依旧保持更优的稳定性，不会出现 Vultr 的延迟突发冲高问题。
反映到实际使用中：谷歌搜索、Gmail、YouTube等海外站点首屏加载更快、切换页面无卡顿、延迟感知极低。

4. 隧道连通性判定标准
4.1. 两条 WireGuard 隧道均可正常解析国外域名，www.gstatic.com 请求无超时、无失败；
4.2. 路由链路经VPS隧道出口转发，全程走代理专线，未出现流量本地直连泄露；
4.3. 延迟走势平稳、无突发冲高，满足日常网页浏览、搜索、图文/短视频访问需求；

六、国内直连、国外走VPN的分流效果验证

前置说明：本次测试核心目标，是验证两套方案能否实现“国内流量本地直连、国外流量走VPN隧道”，解决原生 WireGuard 靠手动维护 AllowedIPs 补国外IP段、永远补不全、误杀服务的痛点。
本次测试仅选取国内个人站点 www.shuijingwanwq.com 作为唯一靶机，通过不同时段的访问耗时，直观验证国内流量是否被强制绕路海外隧道。
测试方法：午间平峰采用批量请求10次取平均的方式，过滤单次波动；下午时段为单次精准测试，保证数据客观准确。

1. 批量请求 + 自动算平均延迟（直接复制运行）（北京时间 13:00）

function Test-AvgSpeed {
    param(
        [string]$url,
        [int]$times = 10
    )

    $total = 0
    $success = 0

    Write-Host "`n正在测试: $url" -ForegroundColor Cyan
    Write-Host "请求次数: $times`n" -ForegroundColor Gray

    for ($i = 1; $i -le $times; $i++) {
        try {
            $time = Measure-Command {
                Invoke-WebRequest -Uri $url -UseBasicParsing -TimeoutSec 10
            }
            $ms = [math]::Round($time.TotalMilliseconds)
            Write-Host "第 $i 次: $ms ms"
            $total += $ms
            $success++
        }
        catch {
            Write-Host "第 $i 次: 失败/超时" -ForegroundColor Red
        }
    }

    if ($success -gt 0) {
        $avg = [math]::Round($total / $success)
        Write-Host "`n✅ 成功 $success 次 | 平均延迟: $avg ms`n" -ForegroundColor Green
    }
    else {
        Write-Host "`n❌ 全部超时/无法访问`n" -ForegroundColor Red
    }
}

2. 打开 PowerShell，粘贴上面整个脚本，然后用下面命令测试：

# 测试国内域名
Test-AvgSpeed "https://www.shuijingwanwq.com"

3. 午间平峰时段（北京时间 13:00）

Vultr 原生 WireGuard：批量10次平均请求耗时：7377ms

PS C:\Users\Thinkpad> Test-AvgSpeed "https://www.shuijingwanwq.com"

正在测试: https://www.shuijingwanwq.com
请求次数: 10

第 1 次: 6325 ms
第 2 次: 4815 ms
第 3 次: 6633 ms
第 4 次: 6894 ms
第 5 次: 8680 ms
第 6 次: 7461 ms
第 7 次: 7995 ms
第 8 次: 7548 ms
第 9 次: 9210 ms
第 10 次: 8205 ms

✅ 成功 10 次 | 平均延迟: 7377 ms

ZgoCloud wstunnel+WireGuard+Clash：批量10次平均请求耗时：1998ms

PS C:\Users\Thinkpad> Test-AvgSpeed "https://www.shuijingwanwq.com"

正在测试: https://www.shuijingwanwq.com

第 1 次: 2784 ms
第 2 次: 1768 ms
第 3 次: 1866 ms
第 4 次: 1884 ms
第 5 次: 1993 ms
第 6 次: 1955 ms
第 7 次: 1800 ms
第 8 次: 1775 ms
第 9 次: 2001 ms
第 10 次: 2151 ms

✅ 成功 10 次 | 平均延迟: 1998 ms

对比：ZgoCloud 国内访问速度是 Vultr 的 3.7 倍，国内流量无需全量绕海外隧道。

4. 下午平峰时段（北京时间 14:30）
Vultr原生WireGuard：单次请求耗时：20231ms（超过20秒）

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.shuijingwanwq.com -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 20
Milliseconds      : 231
Ticks             : 202312869
TotalDays         : 0.000234158413194444
TotalHours        : 0.00561980191666667
TotalMinutes      : 0.337188115
TotalSeconds      : 20.2312869
TotalMilliseconds : 20231.2869

ZgoCloud wstunnel+WireGuard+Clash：单次请求耗时：2646ms

PS C:\Users\Thinkpad> Measure-Command { Invoke-WebRequest -Uri https://www.shuijingwanwq.com -UseBasicParsing }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 646
Ticks             : 26466631
TotalDays         : 3.06326747685185E-05
TotalHours        : 0.000735184194444444
TotalMinutes      : 0.0441110516666667
TotalSeconds      : 2.6466631
TotalMilliseconds : 2646.6631

对比：随着国际出口拥堵加剧，Vultr 的国内访问延迟直接爆炸，超过20秒，完全无法正常使用；而 ZgoCloud 的国内访问依旧保持在2.6秒的可用水平，速度是 Vultr 的 7.6倍。

5. 分流效果核心结论
5.1. Vultr 原生 WireGuard 的本质问题
原生 WireGuard 无智能分流能力，只能靠 AllowedIPs 控制路由，手动补国外IP段永远补不全，最终被迫国内国外所有流量全部强制走海外隧道。
平峰时段国内访问延迟就高达7秒，一旦国际出口开始拥堵，延迟直接冲到20秒以上，国内网站完全打不开，体验极差。

5.2. ZgoCloud + Clash 分流方案的优势
依靠 Clash 的 域名/GeoIP 规则实现智能分流，国内流量优先本地直连调度，不用全部挤海外隧道，完美规避了手动维护海量国外IP段、IP重叠、误杀服务的痛点。
平峰时段国内访问延迟就比 Vultr 快3.7倍，拥堵时段差距直接拉大到7.6倍以上，国内站点访问体验提升极其明显。

七、整体测试总结

1. 基线延迟：ZgoCloud 洛杉矶CN2 GIA+9929+CMIN2 优化节点平均 179ms，较 Vultr 新加坡常规 258ms 延迟大幅优化，零丢包、低抖动，线路稳定性碾压常规公网线路；
2. 外网业务：海外标准接口请求耗时，高峰时段 ZgoCloud 仅 348ms，远低于 Vultr 的 1352ms，访问速度提升近3倍；平峰时段 ZgoCloud 依旧保持更优的稳定性，不会出现延迟突发冲高；
3. 国内分流：ZgoCloud + Clash 的智能分流方案，完美解决了原生 WireGuard 国内流量部分绕路的问题，国内访问速度最高比 Vultr 快7.6倍，彻底解决了手动补国外IP段补不完、误杀服务的痛点；
4. 测试规范性：全程采用固定测试目标、统一命令行量化标准，不受 ICMP 封禁、隧道架构差异影响，数据可复现、可横向对比，不靠主观体感下结论；
5. 性价比：ZgoCloud 洛杉矶优化节点的外网访问速度约为 Vultr 新加坡常规节点的 3-4倍，国内访问速度最高可达7.6倍以上；价格方面，ZgoCloud 月费约为 Vultr 的3.2倍，属于典型的“提速加价、物有所值”的优化线路定价，可长期作为主力海外隧道节点使用。

八、后续维护（操作轻量化，上手无学习成本）

1. 服务器续费管理
   ZgoCloud 所有洛杉矶优化线路套餐均支持季付/半年付/年付多周期选择，适配个人长期自用节奏。服务器到期前，平台会通过注册邮箱主动发送到期提醒，避免疏忽停机。

续费操作流程简洁易懂：登录会员后台，进入「Billing」账务板块选择「Add Funds」充值余额，再进入「Services」我的服务列表，选中对应云主机点击「Renew」即可一键完成续费。平台原生支持支付宝、PayPal 主流支付方式，无需翻墙、无需外币信用卡，完全贴合国内用户支付习惯。

平台会不定期推出限时促销活动，活动期间不仅有套餐折扣、续费优惠，还会补货热门 Premium 优化机型，日常可多留意平台公告，合理选择年付囤货、活动续费，长期节省使用成本。

2. WireGuard 配置文件重置
   若不慎泄露客户端配置、密钥存在安全风险，无需手动重装系统或复杂命令行操作。直接进入服务器详情管理页，重新部署安装 WireGuard 服务，平台会自动生成全新密钥与配置文件，旧配置、旧密钥即时失效，杜绝账号冒用风险，全程可视化操作，小白也能独立完成。
3. 日常故障排查与技术支持
   日常使用出现连接异常时，遵循简易排障逻辑：优先检查本地 Clash、WireGuard 客户端运行状态，确认是否正常握手连接；未连通则重启客户端、重新激活隧道即可恢复。

若遇链路卡顿、隧道不通等疑难问题，可直接通过后台「Support」工单入口提交问题，平台支持中文沟通，客服响应及时、排障效率高，无需语言沟通障碍。

硬件与底层稳定性方面，ZgoCloud 企业级机房采用 1+1 冗余电源、RAID1 磁盘阵列架构，搭配异地容灾备份机制，从硬件层面规避单点故障，保障服务器长期稳定在线，极少出现硬件宕机、数据丢失问题，故障可快速定位修复。

4. 热门套餐补货与选购建议
   目前洛杉矶 Premium 三网优化套餐常年处于缺货状态，属于市场刚需机型的正常供需情况。参考平台补货规律，可固定在上午10点、下午3点、晚间8点多时段刷新配置选购页面，热门补货库存数量有限，建议看到可下单状态后立即部署，避免再次断货等待。

若不愿长期蹲守补货，可选择同线路替代优化套餐，底层线路（CN2 GIA+9929+CMIN2）、一键部署流程、网络体验、后台维护操作均与 Premium 版本完全一致，可完全满足日常外网访问、网页浏览、轻量流媒体等使用需求，无需纠结特定机型。

整体维护总结
ZgoCloud 整套后台操作逻辑、续费流程、服务管理方式，与我长期使用的 Vultr、DMIT 平台操作习惯高度契合，无需重新学习新流程、无需适应陌生后台。

同时精准避开国内用户核心顾虑：无需翻墙访问后台、原生支持支付宝便捷支付、套餐定价贴合个人预算、一键部署防封 WireGuard 省心省力。无论是日常续费、配置重置、故障排查，还是套餐补货选购，流程都简单轻量化，兼顾稳定性、便捷性与性价比，完全可以替代传统国际云厂商，作为长期主力优化节点使用。

前言
最近有不少朋友问我一个很奇怪的问题：WireGuard 客户端显示「上次握手时间」明明是正常的，说明 VPN 连接已经建立成功了，但不管是国内还是国外网站，全都打不开，这到底是怎么回事？
我自己也遇到了完全一样的问题：排查了半天，AllowedIPs 配置没问题，防火墙规则也没出错，服务器状态也正常，握手包能正常通，但是一打开网页就卡着不动，半天加载不出来。
后来我才搞明白这个现象的根源：小数据包和大数据包的通行能力是完全不一样的。WireGuard 的握手包只有几十字节，属于极小的控制包，哪怕网络拥堵到快断了，这种小数据包也能挤过去，所以客户端会显示握手正常；但一旦你要打开网页，传输的就是几百 KB 甚至几 MB 的业务数据包，这时候拥堵的网络就根本传不动这些大包，直接就卡成了白板。
那为什么会拥堵？其实就是你用的 VPS 线路太差了。普通的国际线路，一到国内晚高峰（20:00-23:00），全中国的用户都挤在同一条国际出口上，直接就堵成了停车场，这时候别说看视频，连打开个谷歌首页都要等半天。
之前我也想过调整 AllowedIPs 来解决国内网站走 VPN 的问题：把国内的 IP 段都排除掉，让国内流量直连，国外流量走 VPN。但试了之后才发现，这个问题根本没法完美解决 —— 国内和国外的 IP 段太多太杂，还有很多重叠的，你永远补不完，补到最后还会误杀很多国内的常用服务，反而得不偿失。
所以要从根源上解决这个问题，只有一个办法：找一条足够稳定、哪怕晚高峰也不会拥堵的高端线路，也就是我们常说的中国电信 CN2 GIA 线路。只有用了这种线路，才能保证不管什么时候，你的 VPN 连接都能流畅跑起来，不会再出现「握手正常但打不开网站」的奇葩问题。

一、先搞懂：三大主流 VPS 线路到底有什么区别？为什么我们非要 CN2 GIA？
很多新手朋友买 VPS 的时候，都会被商家宣传的「BGP」「CN2 GIA」「CMIN2」这些名词搞晕，不知道到底选哪个。其实这三个线路，就像是普通国道、省道、和 VIP 高速公路的区别，体验天差地别。

1. 普通国际 BGP：最基础的 “国道”
   普通国际 BGP 线路，就是最基础的互联网路由，没有针对国内运营商做任何专门的优化，所有用户的流量都挤在同一条国际出口上。
   延迟表现：国内到美国洛杉矶的延迟通常在 180-220ms 左右；
   晚高峰表现：一到晚上 20 点之后，拥堵非常严重，丢包率能到 5%-20%，打开网页动辄要等几十秒，甚至直接超时；
   适合场景：仅适合临时过渡用，或者对网络要求极低的场景，日常用的话体验非常差。
   这就是为什么之前的 Vultr 这种服务商，虽然价格便宜，但是我只把它当成备用过渡款，因为它的线路就是这种普通 BGP，只能凑合用，没法长期用。
2. CMIN2：移动用户的 “省道”
   CMIN2 是中国移动的国际优化线路，是针对移动用户的回国流量做了专门的优化，相当于移动用户的专属半 VIP 通道。
   延迟表现：移动用户用的话，延迟能降到 70-90ms，比普通 BGP 好很多；但电信用户用的话，其实还是走普通的优化路由，延迟大概 60-80ms，不如 CN2 GIA；
   晚高峰表现：比普通 BGP 好很多，但是还是会有轻微的拥堵，丢包率大概 1%-3%，日常浏览没问题，但是大流量下载或者看高清视频的话，还是会有点卡；
   适合场景：适合移动用户，或者预算有限、对稳定性要求不是极高的用户，性价比不错，但是不如 CN2 GIA 稳定。
   我们之前提到的 Racknerd、CloudCone 这些服务商的低价优化套餐，其实用的就是这种 CMIN2 或者 CN2 GT（半程 CN2 优化）线路，它们的价格刚好贴合我们的 20 美元预算，但是它们的电信线路并不是真正的 CN2 GIA，晚高峰的稳定性还是差了一点。
3. CN2 GIA：电信用户的 “VIP 高速公路”
   CN2 GIA 是中国电信的高端全程优化线路，是目前能拿到的最好的民用国际线路，没有之一。它就像是专门给你开了一条 VIP 专用高速公路，从你国内的省级节点开始，全程走电信的 CN2 高速骨干网，全程没有普通的拥堵节点。
   延迟表现：国内到美国洛杉矶的延迟能稳定在 30-60ms，沿海地区甚至能到 20ms 以内，和访问国内网站的延迟差不多；
   晚高峰表现：因为 CN2 GIA 有专门的 QoS 优先级，哪怕晚高峰全网拥堵，电信也会优先保证 GIA 用户的流量通行，晚高峰丢包率能做到低于 0.5%，几乎无感，不管是看 4K 视频、打游戏还是大文件下载，都完全不会卡；
   怎么识别真假 CN2 GIA：很简单，你做个路由追踪，如果所有的核心节点都是以 59.43 开头的，那就是真的 CN2 GIA；如果出现了 202.97 开头的节点，那就是假的，要么是 CN2 GT，要么是普通线路。
   这就是为什么我们非要找 CN2 GIA 线路的原因 —— 只有它能保证，不管什么时候，你的 VPN 都能流畅运行，不会再出现「握手正常但打不开网站」的问题。
   为什么在 20 美元预算内，只有 DMIT 和 ZgoCloud 才是真 CN2 GIA？
   很多商家都会宣传自己有 CN2 线路，但是大部分都是假的，要么是半程的 CN2 GT，要么是把 CMIN2 包装成 CN2 来忽悠人。而且真正的 CN2 GIA 成本非常高，大部分服务商的 CN2 GIA 套餐价格都远超我们的 20 美元预算。
   而我们筛选下来，在这个预算内能拿到真正 CN2 GIA 线路的，只有两家：
   DMIT：它的 Premium 网络就是自营的 CN2 GIA 线路，官方自己就明确标注了包含中国电信下一代承载网 CN2 GIA，而且是自营带宽，不是转售，线路质量非常有保障，之前的 12.98 美元 / 月的 LAX.AN5.Pro.TINY 套餐，就是这个线路，可惜现在缺货了（注：我大概等了2周左右，也没有等到补货）。
   ZgoCloud：它新出的洛杉矶三网优化套餐，就是电信走 CN2 GIA、联通走 9929 联通高端优化、移动走 CMIN2，刚好三个运营商的用户都能用到各自的高端线路，而且它的入门款年付才 58 美元，折算月付才 5 美元，远低于我们的预算，就能拿到真正的 CN2 GIA 线路，性价比拉满（注：低价套餐也经常缺货，我家是成都移动宽带，最后仍然选择了高价套餐，且等待了几天。）。
   其他的比如 Racknerd、CloudCone，虽然价格也贴合预算，但是它们的线路是 CMIN2 或者 CN2 GT，不是真正的全程 CN2 GIA，晚高峰的稳定性还是差了一点，所以只能作为备选。

二、注册账号（国内直接操作，不用翻墙）

1. 直接打开 DMIT 注册页面：https://www.dmit.io/register.php （国内不用翻墙就能直接打开，就算我 VPN 坏了也能访问）（如图2）

1. 输入我的邮箱，设置密码，完成滑块人机验证后，点击「注册」按钮（不用手机号，和 Vultr 注册一样简单）
2. 注册完成后，系统会自动登录我的账号，无需手动输入账号密码再次登录，后续只需完成邮箱验证即可（验证邮件会发送到我注册的邮箱，确保账号正常使用）（如图3）。

三、部署基础服务器（先创建有效订单，解决充值提示问题+全节点现状说明+替代服务商详解）
重点说明：DMIT 要求必须有「有效订单」（已部署的服务器），才能进行充值（否则提示“You must have at least one active order before you can add funds”），因此先部署服务器，再充值，和我之前 Vultr 流程略有调整，但操作完全一致。
全节点现状说明：目前 DMIT 核心节点均存在缺货或价格偏高的情况，完全贴合我观察到的现状，具体如下：

1. 洛杉矶节点：Premium、Eyeball、Tier 1 三种网络类型下所有实例均处于缺货状态，包括我能勉强接受的 LAX.AN5.Pro.TINY（Premium 网络，12.98美元/月），该节点 AN5 系列已告罄（如图6）；

1. 东京节点：所有网络类型、所有实例全部缺货，无任何可部署库存，与洛杉矶节点补货规律一致，短期难以有大量库存释放（如图4）；

1. 香港节点：仅 Eyeball 网络有部分实例有货，月付价格29.90美元，Premium 网络最便宜的套餐（39.90美元/月）也处于缺货状态，且即便有货，两个网络类型的价格均远超我能接受的12.98美元/月预算，性价比不足，不推荐选择（如图5）。
   补充说明：DMIT 洛杉矶节点低价套餐缺货，核心原因是全球硬件成本持续上涨，商家已暂停洛杉矶 AN5 系列售卖；同时商家计划对 AS3（LTS）平台进行扩容升级，未来该平台将作为核心高性价比产品线，有望维持类似12.98美元级别的低价，但目前暂未上线，具体上线时间待定。
   根据行业现状及 DMIT 官方公告，目前洛杉矶低价 Premium 套餐（12.98美元/月）短期（1-2个月内）大概率难以补货，仅偶尔会有少量用户退订的闲置库存释放，且补货后几分钟内就会被抢空；香港 Eyeball 套餐价格偏高，远超我的预算，不建议勉强选择，优先考虑以下高性价比替代服务商（均支持一键部署 WireGuard、支付宝/微信支付，操作流程与DMIT、Vultr 基本一致）。

四、适配我预算的解决方案（按优先级排序，重点优化替代服务商，贴合12.98美元预算预期）：

1. 方案一（优先推荐，贴合我的预算）：精准监控洛杉矶低价库存+设置到货通知，抢占少量补货库存。可打开 DMIT 库存监控页面（https://stock.qixi.me/），该页面会实时同步 DMIT 所有网络类型、所有实例的库存状态，无需手动刷新官网（如图7）。同时可关注 DMIT AS3（LTS）平台扩容动态，该平台上线后有望维持低价，可多留意官方公告。

1. 方案二（重点推荐，替代香港高价节点，优先选择）：选择同类型高性价比替代服务商（适配我的操作习惯，支持一键部署 WireGuard、支付宝/微信支付，价格贴合12.98美元预算，无需接受香港29.90美元高价），以下为3个主流、稳定的服务商，按性价比排序，均能满足日常使用需求，操作流程与 DMIT 基本一致，可直接参考本指南后续步骤操作：

补充说明：以下4个替代服务商，均无需翻墙即可访问官网，注册、部署服务器、充值、部署 WireGuard 的操作流程，与本指南中 DMIT 的操作完全一致，仅官网界面、套餐命名略有差异，可直接参考后续步骤操作，无需额外学习新流程。

2.1 ZgoCloud（zgovps）：目前有洛杉矶三网优化VPS补货，性价比极高，贴合我的预算预期。核心优势：机房位于美国洛杉矶，搭载中国高级优化网络（CN2 GIA+9929+CMIN2三线路优化），延迟30-60ms，与 DMIT 洛杉矶 Premium 网络体验基本一致，稳定性强，晚高峰不绕路、不丢包；支持一键部署 WireGuard（带 TLS 防封），无需 SSH 登录、不用跑脚本；支持支付宝/微信支付，国内直接访问官网，不用翻墙。推荐套餐：入门款年付仅58美元（折算月付约5美元），配置为1核（AMD EPYC）/1 GB内存/10G NVMe，日常浏览国外网站、谷歌搜索/翻译完全足够，若需更高配置，可选择月付12-15美元的进阶款，配置升级为1核2G内存、1T月流量，完全贴合我的预算，且价格比香港29.90美元低一半以上。
2.2 Racknerd：主流高性价比服务商，与 DMIT 定位接近，稳定性有保障。核心优势：洛杉矶节点有廉价优化线路套餐（类似 DMIT Premium 体验），偶尔有补货，月付价格12-15美元，贴合我的预算；支持一键部署 WireGuard，支持支付宝支付，国内可直接访问官网；线路为 CMIN2 优化，延迟60-80ms，晚高峰稳定性良好，比我之前 Vultr 新加坡节点体验好太多；目前有货的入门款套餐（1核2G内存、1T月流量），月付12.99美元，与我能勉强接受的DMIT 12.98美元价格基本持平，无需超预算。
2.3 CloudCone：小众但稳定的服务商，主打高性价比优化线路，适合临时过渡或长期使用。核心优势：洛杉矶优化线路套餐（类似 DMIT Eyeball 体验），月付价格13-16美元，偶尔有促销活动可低至12美元/月；支持一键部署 WireGuard（带防封配置），支持支付宝/微信支付，操作流程与 DMIT 完全一致；线路延迟70-90ms，日常浏览、办公完全满足，无明显卡顿，且价格远低于香港29.90美元，不用勉强接受高价。
2.4 备用过渡款：ColoCrossing（CC）：若上述3个服务商暂时无补货，可选择该服务商作为临时过渡，目前有货且价格稳定。核心优势：洛杉矶节点常规套餐，月付13美元左右，贴合我的预算；支持支付宝支付，国内可直接访问官网；线路为国际BGP普线，延迟180-220ms，虽速度不如优化线路，但日常浏览国外网站可满足，支持一键部署 WireGuard，操作简单，避免因等待补货影响使用。

3. 方案三（不推荐，仅作参考）：若短期内急需使用，且可临时接受大幅超预算，可考虑 DMIT 香港 Eyeball 网络有货实例（29.90美元/月），该节点三网优化，延迟30-70ms（电信30-60ms、联通20-40ms、移动40-70ms），稳定性良好，晚高峰基本不卡顿，支持一键部署 WireGuard 带 TLS 防封，完全能满足日常使用，但价格远超我的预算，且性价比远低于方案二的替代服务商，建议仅在所有替代服务商均无货时临时选择。

自建 WireGuard VPN 最头疼的问题：UDP 端口每 2 天左右就失效，客户端 无 上次握手时间 ，反复更换57586、2096、443等端口，改完 VPS 配置还要改 Vultr 防火墙、改客户端，来回折腾巨麻烦。

根本原因：运营商 DPI深度包检测 ，WireGuard 原生数据包特征固定，不管换哪个单独UDP端口，都会被识别标记，周期封禁。

本文采用 服务端 iptables 多端口转发 最简方案：不换 WireGuard 原生客户端、不装混淆 APP、不折腾TCP隧道，一次配置永久生效，后续只需改客户端端口数字即可，新手零折腾。

原理说明

1. 把 WireGuard 服务端监听端口 固定为 51820，永不修改 ；
2. VPS 通过 iptables 做端口段转发：20000~60000 全部UDP端口，统一转发到本机 51820；
3. Vultr 防火墙只需放行 20000~60000 端口段 ，不用逐个添加单端口规则；
4. 电脑、手机客户端可自由选用区间内任意端口，端口失效仅需修改客户端端口，不用动服务器、不用登Vultr后台。

步骤1：修改 WireGuard 配置，固定监听端口
登录Vultr VPS，编辑wg0配置文件：

vi /etc/wireguard/wg0.conf

找到配置项：
ListenPort = 原来的端口（如2096、57586）
修改固定为：
ListenPort = 51820
按 ESC，输入 :wq 保存退出。如图1

步骤2：重启 WireGuard 服务生效

root@vultr:~# wg-quick down wg0
[#] ip link delete dev wg0
[#] iptables -D INPUT -p udp --dport 57586 -j ACCEPT
[#] iptables -D FORWARD -i enp1s0 -o wg0 -j ACCEPT
[#] iptables -D FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE
[#] ip6tables -D FORWARD -i wg0 -j ACCEPT
[#] ip6tables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE
root@vultr:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.66.66.1/24 dev wg0
[#] ip -6 address add fd42:42:42::1/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -I INPUT -p udp --dport 57586 -j ACCEPT
[#] iptables -I FORWARD -i enp1s0 -o wg0 -j ACCEPT
[#] iptables -I FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
[#] ip6tables -I FORWARD -i wg0 -j ACCEPT
[#] ip6tables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE

步骤3：验证监听端口是否生效

root@vultr:~# wg show
interface: wg0
  public key: XZ2LNJxO7RqjGKHyubFw35eR7AkRa1iHqltQJYdsY3g=
  private key: (hidden)
  listening port: 51820

peer: QnBvrNGpbGs+9JxCgZvT16sVr1g735JMgWGFIdqmsz8=
  preshared key: (hidden)
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128

peer: TX/hWjKXFoDyhQncE6M5DuC7d4DffzjJWHL+errBsTU=
  preshared key: (hidden)
  allowed ips: 10.66.66.3/32, fd42:42:42::3/128

看到输出 listening port: 51820 即为配置成功。

步骤4：VPS 配置 iptables 多端口转发
直接逐条复制执行：

# 将20000-60000所有UDP端口转发到WireGuard固定端口51820
root@vultr:~# sudo iptables -t nat -A PREROUTING -p udp --dport 20000:60000 -j REDIRECT --to-port 51820

# 安装iptables规则持久化工具
root@vultr:~# sudo apt install -y iptables-persistent
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
iptables-persistent is already the newest version (1.0.16).
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.

# 保存规则，重启服务器不失效
root@vultr:~# sudo netfilter-persistent save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save

步骤5：Vultr 后台防火墙配置（必做）

1. 登录 Vultr 后台，找到对应 VPS，进入左侧 Firewall Groups ；
2. 删除原有单独放行的57586、2096、443等单条UDP规则 ；
3. 新增一条防火墙规则：

• 协议：UDP
• 端口类型：端口范围
• 端口区间：20000 – 60000
• 备注：WireGuard 多端口分流

1. 保存规则，无需额外添加其他端口。如图2

步骤6：客户端配置使用规则

1. 电脑、手机原生 WireGuard 客户端无需重装、无需改动其他配置；
2. Endpoint格式：你的 VPS IP:区间内任意端口
   示例：
   Endpoint = 1.2.3.4:32567
3. 多设备可使用不同端口 ：电脑用3xxxx，手机用5xxxx，同时在线互不影响；如图3
   
4. 端口失效无握手时： 仅修改客户端端口数字 ，在 20000~60000 之间随便换一个即可，服务器和防火墙无需任何改动。

避坑优化建议

1. 不要按顺序挨个用端口（20001、20002…）， 随机跳号使用 ，降低运营商识别规律；
2. 避免 7×24 小时常驻挂机，闲置时（晚上睡觉时）手动断开，减少风控概率；
3. 固定 WireGuard 监听端口 51820，后续永远不要再修改；
4. 只适合不想折腾混淆、不想换客户端的用户，极简够用，个人长期自用稳定。

方案总结
这是 最简单、零额外软件、不改客户端 的终极折中方案，一次配置永久定型，告别频繁修改 VPS 和防火墙配置，端口失效1秒换号即可使用，完全满足日常自用需求。