WireGuard 每隔 2～4 天就要换端口：迁移 AmneziaWG 后的一个月实测
先说结果：之前使用 WireGuard 时，我大概每隔 2～4 天就要换一次端口；迁移到 AmneziaWG 后已经使用约一个月，没有遇到断线。Windows 端直接接入 Clash Verge，原有分流规则也继续使用。
最初的问题很直接：原来能用的连接突然不通，服务端抓不到对应端口的 UDP 包；换一个端口后又恢复。类似情况反复出现，我意识到继续改端口只能临时缓解维护压力。
这篇文章记录我的排查过程、服务端部署结构、Clash Verge 配置，以及迁移后的实际使用结果。“一个月没断过”来自日常使用反馈，不是 24 小时连续监控得出的可用率；仅凭换端口有效，也不足以断言一定存在运营商主动探测。
1. 我的环境和最初的问题
这次折腾的基础环境是：
| 项目 | 环境 |
|---|---|
| 服务器 | 搬瓦工海外 VPS |
| 系统 | Ubuntu 24.04 x86_64 |
| 原有隧道 | WireGuard |
| 本地电脑 | Windows 11 |
| 当前 Windows 客户端 | Clash Verge 2.5.2 |
| 当前内核 | Mihomo 1.19.29 |
| 服务器其他业务 | Docker Compose、Nginx 等 |
对我来说，迁移的目标很简单：减少反复换端口的维护工作，也希望保留原来的客户端分流习惯。
最有价值的排查发现，不是客户端显示“连接失败”，而是两次测试之间的对照：
| 测试 | 实际观察 |
|---|---|
| 使用原来的 UDP 端口 | VPS 抓不到对应的 UDP 包，连接不可用 |
| 更换 UDP 端口后再连接 | 连接恢复 |
这使我开始把排查重点放到端口可达性和沿途网络策略上。
2. 换端口就好，究竟说明了什么？
我的第一反应也是：“是不是被识别，然后封端口了？”
但写成经验文章，需要把观察和推测分开。
已经观察到的事实，是旧端口收不到包，换端口恢复。我的推测，是原端口的 UDP 流量可能受到沿途网络策略影响。
仅凭这些，还不能确定是谁丢弃了流量，更无法直接证明存在主动探测。客户端是否实际发出数据、云防火墙是否放行、抓包位置是否正确，也会影响判断。要进一步定位，可以在客户端和服务端同时抓包，再换一个接入网络做对照。
如果读者遇到类似情况，可以先在服务器运行下面的命令，同时从客户端发起连接：
# 51820 仅为示例，请替换为当前实际使用的 UDP 端口
sudo tcpdump -ni any 'udp port 51820'
这里的重点是观察有没有对应流量到达，而不只是盯着客户端的连接图标。抓包输出可能包含公网地址，公开截图时记得遮挡。
不同现象，对应的排查方向并不一样：
| 现象 | 优先排查方向 |
|---|---|
| 客户端尝试连接，服务器始终看不到对应 UDP 包 | 客户端发包、地址和端口、沿途网络及云防火墙 |
| 服务器能收到包，但握手不成功 | 主机防火墙、密钥、Peer、协议和参数匹配 |
| 握手成功，却无法访问目标 | 转发、NAT、路由、DNS，必要时检查 MTU |
这些是排查入口，不是单凭一个现象就能下的最终诊断。
3. 为什么我不想一直换端口？
换端口确实帮我恢复过连接，所以它是有用的临时处理方式。
在我的使用中，大概每隔 2～4 天就要修改服务端端口，再同步修改客户端。反复出现后，维护成本就变得很明显。
更关键的是，修改端口并不会改变所使用的协议。如果网络策略恰好针对协议的外部特征，换一个入口未必能解决后续的问题。当然，这也是一个条件判断，并不意味着我已经证明这次故障就是协议识别造成的。
于是我开始寻找：有没有保留 WireGuard 使用体验，同时对流量外部特征做一些处理的方案？
AmneziaWG 就进入了我的视野。
图：迁移前需要反复修改 WireGuard 端口；迁移后由 Clash Verge 通过 AmneziaWG 连接 VPS。
4. AmneziaWG 改变了什么？
可以把 AmneziaWG 理解为基于 WireGuard、增加流量混淆机制的方案。它保留 WireGuard 的核心加密机制，通过调整报文大小、类型标识和握手前的数据包等外部特征，提高协议识别的难度。不同版本的具体机制有所区别。AmneziaWG 官方说明
对这次迁移来说，我最看重的就是这个区别：换端口改变访问入口，而 AmneziaWG 还会改变部分报文特征。
不过，它仍然依赖 UDP。如果某条网络路径直接限制全部 UDP，或者服务器 IP 本身不可达，流量混淆不能自动解决这些问题。
因此，我选择它作为当前阶段的尝试，并没有把它当成“装完就永远不会断”的保证。
5. 服务端是怎么部署的
查资料时，容易把 AmneziaVPN、AmneziaWG 和服务端安装混在一起。
| 名称 | 在这件事中的作用 |
|---|---|
| AmneziaVPN 应用 | 可以通过 SSH 为自有服务器部署 VPN，并管理连接 |
| AmneziaWG | 本文迁移使用的协议及相关实现 |
| 支持 AmneziaWG 的客户端 | 使用与服务端兼容的配置建立连接 |
如果希望通过图形界面部署，官方提供的路径是：安装 AmneziaVPN，选择自建服务器，输入服务器地址及 SSH 认证信息，再选择安装方式；自动安装会部署 AmneziaWG。具体界面以所用版本为准。官方自建服务器安装说明
从服务器保留的运行痕迹看，我使用的是 Amnezia 的自建部署体系：安装目录为 /opt/amnezia/amnezia-awg2，服务端运行在名为 amnezia-awg2 的 Docker 容器中，并映射一个 UDP 端口对外服务。由于已经过去一段时间，我记不清当时是在客户端里选择“自动安装”，还是手动选择了 AmneziaWG，因此只记录能够从服务器验证的部署结构。
从容器监听情况看，AmneziaWG 使用独立的 UDP 端口；服务器上的 Nginx 继续监听 TCP 80 和 TCP 443，Sub2API 及其 Redis、PostgreSQL 容器也保持运行。两个服务没有争用同一个协议和端口。
如果服务器已经承担其他业务，部署前应确认所选 UDP 端口未被占用，新增的隧道网段也不要与现有网络冲突。TCP 443 和 UDP 443 属于不同传输协议，可以分别使用；但如果网站开启 HTTP/3，UDP 443 也可能已经被占用。
端口能否共用，要看实际监听情况，不能只看数字都是 443。
6. Windows 上，我已经直接接入 Clash Verge
我的实际用法是：在 Windows 的 Clash Verge 中配置 AmneziaWG 节点，再通过代理组和规则选择流量出口。迁移后，我继续沿用了 Clash Verge 的分流方式。
目前使用的版本是 Clash Verge 2.5.2、Mihomo 1.19.29。这就是本文配置对应的实际客户端环境；这里记录版本便于读者对照，不将其当作最低版本要求，也不推断其他版本的兼容性。
图：Clash Verge 已选择 AmneziaWG 节点，服务端容器运行 4 周，并显示本次使用的客户端与内核版本。截图只证明采集时的状态；一个月未遇到断线来自日常使用记录。
Mihomo 官方文档提供了 WireGuard 节点下的 amnezia-wg-option 配置，并区分不同协议版本的字段。照着配置前，仍应核对自己安装的内核支持哪些参数。Mihomo WireGuard／AmneziaWG 配置文档
我的配置方式
下面是根据我的实际配置整理的脱敏节选。保留节点参数和分流结构，压缩了较长的域名列表。公网地址、端口和密钥改为占位示例；混淆参数来自本次配置，仅用于展示字段，其他服务器必须使用自己生成的对应参数。
这不是开箱即用的通用配置，也不是一份经过独立连接测试的新配置。
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
ipv6: false
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 1.0.0.1
proxies:
- name: "AmneziaWG-VPS"
type: wireguard
ip: "10.8.1.4" # 本次客户端隧道地址，换成自己的地址
private-key: "REPLACE_WITH_CLIENT_PRIVATE_KEY"
server: "YOUR_VPS_HOST"
port: 51820 # 示例端口，换成实际服务端 UDP 端口
public-key: "REPLACE_WITH_SERVER_PUBLIC_KEY"
pre-shared-key: "REPLACE_WITH_PRESHARED_KEY"
allowed-ips:
- "0.0.0.0/0"
persistent-keepalive: 25
udp: true
remote-dns-resolve: true
dns:
- 1.1.1.1
- 1.0.0.1
amnezia-wg-option:
jc: 4
jmin: 10
jmax: 50
s1: 117
s2: 37
s3: 7
s4: 13
h1: "71467171-1916001461"
h2: "2010802638-2118787005"
h3: "2123817729-2139675071"
h4: "2144231848-2146441145"
i1: "<r 2><b 0x858000010001000000000669636c6f756403636f6d0000010001c00c000100010000105a00044d583737>"
i2: ""
i3: ""
i4: ""
i5: ""
proxy-groups:
- name: Proxy
type: select
proxies:
- "AmneziaWG-VPS"
- DIRECT
# 为便于阅读，仅展示原配置的部分规则，顺序保留
rules:
- DOMAIN-SUFFIX,qq.com,DIRECT
- DOMAIN-SUFFIX,taobao.com,DIRECT
- DOMAIN-SUFFIX,bilibili.com,DIRECT
- DOMAIN-KEYWORD,google,Proxy
- DOMAIN-KEYWORD,github,Proxy
- DOMAIN-KEYWORD,openai,Proxy
- DOMAIN-KEYWORD,chatgpt,Proxy
- DOMAIN-SUFFIX,cn,DIRECT
- DOMAIN-SUFFIX,microsoft.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,Proxy
这份配置使用规则模式：命中直连规则的请求走 DIRECT，命中 Proxy 规则的请求交给该代理组；使用隧道时，在组内选择 AmneziaWG-VPS。没有命中前面规则的请求，最终也交给 Proxy。
原配置还列出了微信、京东、百度、视频和生活服务等域名的直连规则。这里为阅读方便作了节选，不代表这几条就覆盖所有国内网站，也不代表所有请求都会走 AmneziaWG。
allowed-ips 中的 0.0.0.0/0 是节点的隧道配置，不能据此认定 Windows 全部流量已由它接管。实际哪些应用进入 Clash，还与系统代理、TUN 或应用自身代理设置有关；我尚未补充这一项具体开关记录。
分享 YAML 时尤其要保留缩进：jc、s1、h1 等字段都应放在 amnezia-wg-option 下面。聊天里的换行和转义可能破坏格式，本文已整理展示形式，不将粘贴排版当作原配置故障。
7. 一个月的实际使用结果
迁移前后，最直观的区别是连接稳定性：之前 WireGuard 大概每隔 2～4 天就需要换一次端口；迁移到 AmneziaWG 后，已经使用约一个月，期间没有遇到断线。
| 对比项 | 迁移前：WireGuard | 迁移后：AmneziaWG |
|---|---|---|
| 实际使用反馈 | 旧端口收不到 UDP 包，换端口恢复 | 使用约一个月未遇到断线 |
| 维护频率 | 大概每隔 2～4 天需要换端口 | 这段时间没有遇到需要因断线而换端口的情况 |
| Windows 使用方式 | 使用 Clash Verge 分流 | 直接在 Clash Verge 中接入节点，继续规则分流 |
这已经覆盖了过去多次需要换端口的时间跨度，对我的日常使用而言，是一个明显改善。
但这个结果来自个人使用反馈，没有全天候探测日志，也没有准确的累计在线小时数。因此，我记录的是“约一个月使用中未遇到断线”，而不是“连续运行 30 天、可用率 100%”。同样，没有统一条件下的测速数据，就不写速度提升比例。
目前我会继续保留这套方案。后续如果再出现异常，重点记录当时的接入网络、服务器是否收到 UDP 包，以及最终如何恢复。
8. 如果之后还出问题，我的下一步
我目前的计划是先继续使用 AmneziaWG。如果后续仍然频繁遇到类似问题，再评估 VLESS + REALITY 的 TCP 方案。
选择不同传输方式作为下一步，是为了在 UDP 可达性持续成为问题时，多一个排查和替代方向。这不等于换成 TCP 就一定不会受影响。
如果真的走到那一步，我会先处理好它与现有 Nginx 的监听端口安排，再单独记录部署和使用结果。这篇先不把尚未发生的迁移写成成功案例。
这次折腾让我最有收获的，是先找到那个可以验证的现象：服务器到底有没有收到包。它决定了下一步应该查网络路径、握手配置，还是转发和 DNS。
从每隔 2～4 天就要换一次端口，到迁移后约一个月没有遇到断线，这次调整已经减少了我日常维护的麻烦。我会继续使用 AmneziaWG，后续有新的情况，再补充到这篇记录中。
