服务端 wg-quick up wg0 没有报错，systemctl status 是绿的，客户端界面上那个开关也显示"已连接"，浏览器却一直转圈。这套景象在 2026 年仍然是自建 WireGuard 最常见的翻车姿势。更烦的是它的反面：能上网，但一到晚高峰就从两百兆掉到几兆，重连、换节点、重启服务端全试过，没用。
这两件事看上去都是"网络问题"，实际根子完全不同：一个是转发链和 MTU，属于你自己配置里的错；另一个是协议特征与路径质量，属于你和运营商、和 DPI 之间的博弈。把两类混在一起试，结果就是无限重启 wg0，然后怀疑 VPS 商家。
本文只处理"已经搭起来之后"的部分。买 VPS 到跑通头一份配置的完整流程在2026年自建VPN全教程里；把 WG 拿来做家庭内网互访、异地设备互联，那是软路由异地组网完全指南的地盘。这里只讲三件事：为什么连不上、为什么慢、以及在流量被针对性干扰时，改端口、上 udp2raw、换 AmneziaWG 这些手段各自能救什么、救不了什么。
先说一句现实话。自建 WG 的乐趣在于可控，成本在于你得自己扛：内核升级后接口起不来、密钥轮换忘了更新对端、IP 被墙了要重买、出问题只能自己抓包。如果你要的只是每天能用的一个出口，把这件事外包给订阅更划算——瑶瑶领先 的入门档 ¥9.9/月给 384GB 流量，先跑一个月看够不够用，比先搭一台 VPS 再发现用不上要省事。两条路不冲突，本文讲的是自建这条路上真实存在的坑。
一、先把"不能用"拆成三类，判据只有握手
很多人排查 WG 的方式是看客户端界面。那个"已连接"只代表本机接口被 ip link 拉起来了，跟服务端有没有收到你的包毫无关系——网线拔了它一样显示已连接。真正的硬信号只有一个：服务端 wg show 里的 latest handshake 有没有时间戳。
# 服务端：看握手时间和流量计数
wg show
wg show wg0 latest-handshakes
wg show wg0 transfer
# 服务端：看接口层的收发、错误与丢包
ip -s link show wg0
# 服务端：确认 UDP 包真的到了网卡（不是被安全组挡在前面）
tcpdump -ni any udp port 51820 -c 20
# 转发与 NAT 是否就位
sysctl net.ipv4.ip_forward
iptables -t nat -S | grep MASQUERADE把这三类分开之后，处置顺序就清楚了。下面这张表里的"硬判据"一栏，是我建议你每次排障先看的那一眼——它比任何日志都可靠。
| 症状 | 硬判据 | 先看哪条命令 | 常见根因 |
|---|---|---|---|
| 客户端显示已连接，任何网站都打不开 | latest handshake 为空，transfer 的 received 一直是 0 | wg show wg0 latest-handshakes | UDP 端口没放行（云安全组/ufw）、密钥对不上、服务端没监听、Endpoint 写错 |
| 握手有、内网 ping 得通，外网出不去 | handshake 有值，wg0 的 RX 在涨，但 curl 超时 | curl -4 --max-time 8 https://ifconfig.me（服务端与客户端各跑一次） | ip_forward=0、FORWARD 链默认 DROP、缺 MASQUERADE、MTU 黑洞、DNS 没配 |
| 能上网，但慢、断流、晚高峰掉到底 | handshake 正常、流量在走，mtr 显示丢包集中在中段或末段 | mtr -u -c 50 <服务端IP> | UDP 被限速、路径拥塞、单核软中断打满、缓冲区太小、MTU 偏大导致重传 |
拿一个最常见的例子对号入座：云厂商控制台的入站规则只放了 TCP 22，UDP 51820 没开。这时候客户端会一直显示已连接（接口是 up 的），服务端 tcpdump 什么都抓不到，latest handshake 永远是空的。很多人在服务端反复改配置，改到怀疑人生，其实问题在云平台那一层。
反过来，如果 tcpdump 能看到包进来、latest handshake 也有值，就别再动端口和防火墙了，问题在转发或 MTU，直接跳到讲转发与 MTU 的那两节。排障最怕的就是"所有东西都改一遍"，每改一次变量都多一个。
二、WG 的流量形状本身就是指纹
WireGuard 的设计目标是把协议压到极简：没有协商阶段、没有版本协商、没有 TLS 那套证书交换，一个包就完成握手请求，一个包完成响应。这个设计让它在性能上非常漂亮，代价是没有"伪装"这一层——流量长得太规整了。
规整到什么程度？下面这几个数字是写死在实现里的（wireguard-go 的 noise-protocol.go 里就是这几个常量）：握手请求固定 148 字节、握手响应固定 92 字节、cookie 回复固定 64 字节、每个传输包的头部 16 字节再加 16 字节认证标签。每个包的起始 4 字节还是明文 type 字段（1 到 4），握手包的 DSCP 被固定成 0x88（AF41），连"优先级标记"都是可预期的。
对 DPI 设备来说，这已经足够画指纹了：不需要解密任何一个字节，只按"目标端口 + 首包长度 148 + 后续包长分布 + 双向持续大流量"就能把一条流标出来，甚至不需要知道你在连哪台机器。这也是为什么"改了端口就好了"这种经验有时成立、有时完全无效——它只对最粗糙的端口黑名单有效。
| 可观测特征 | 是否稳定 | 能怎么改 | 改造成本 |
|---|---|---|---|
| 握手包固定 148 / 92 字节 | 极稳定，协议规定 | AmneziaWG 的 S1/S2 填充 | 两端都要换实现，原生客户端连不上 |
| 传输包头部固定 16 字节 | 极稳定 | AmneziaWG 的 S4 传输填充 + H4 魔数 | 同上 |
| 起始 4 字节明文 type（1-4） | 极稳定 | AmneziaWG 的 H1-H4 魔数替换 | 四段区间不能重叠，参数必须两端一致 |
| 握手包 DSCP = 0x88（AF41） | 稳定，WG 不提供开关 | 只能靠外层改造或换协议 | 高，通常直接换 Hysteria2 或 TCP 承载的协议 |
| 单端口、长连接、双向大流量 | 取决于用法 | 多端口轮换、按时段换出口 | 低，但要写脚本 |
需要说清一件事：加密本身没有出问题，被识别的是"形状"。Noise 协议那套 Curve25519 + ChaCha20-Poly1305 目前没有现实可行的破解路径，被拦的从来不是内容，而是"这条流看起来像不像 VPN"。
这也解释了为什么商业机场基本不用裸 WG 做对外出口：TLS 承载的协议在握手阶段就能和普通 HTTPS 混在一起。SS-ID 这类纯 IEPL 机场走的是另一种思路——协议层、端口、伪装都由服务方维护，你拿到的是一条从入境到出口全程走专线的链路，不必自己跟 DPI 打补丁；代价是端口、协议、MTU 全由对方决定，你没有调优空间，也做不了自定义路由。
三、服务端最小可用配置：错都错在这三处
一份能跑通的 wg0.conf 只有十几行，但新手翻车几乎集中在三个地方：转发没开、NAT 没写、PostDown 漏了导致重启时规则冲突。下面这份可以直接抄，注意把 eth0 换成你机器真实的出口网卡名（新一点的系统上常是 ens3、enp1s0 这类）。
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.66.66.1/24, fd42:42:42::1/64
ListenPort = 51820
PrivateKey = <服务端私钥>
MTU = 1420
SaveConfig = false
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -A FORWARD -o %i -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t mangle -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[Peer]
PublicKey = <客户端公钥>
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128几个容易忽略的点。%i 会被 wg-quick 替换成接口名，写死 wg0 在改接口名时会失效。SaveConfig = false 是为了防止 wg-quick down 时把运行态写回配置文件，覆盖你手写的内容。Peer 的 AllowedIPs 在服务端只写对端的隧道地址，0.0.0.0/0 是客户端侧的写法，两边写反了会出现"能握手但路由完全不对"的怪现象。另外那条 MSS clamp 放在 FORWARD 链上而不是 OUTPUT，因为被转发的流量不经过本机 OUTPUT。
客户端那份长这样，注意 Endpoint 用真实地址替换（下面用文档保留地址占位）：
[Interface]
PrivateKey = <客户端私钥>
Address = 10.66.66.2/32, fd42:42:42::2/128
DNS = 1.1.1.1, 2606:4700:4700::1111
MTU = 1420
[Peer]
PublicKey = <服务端公钥>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25起来之后按三件事验证，缺一件都不算通：wg show 的 transfer 在双向增长；客户端 curl -4 https://ifconfig.me 拿到的地址是 VPS 的公网 IP 而不是本地出口；ping -M do -s 1392 10.66.66.1 不出现 Message too long 或全丢。这条验证是很多人省掉的，而它恰恰是"能 ping 通、网页打不开"这类故障的分水岭。
还有一个反复出现的坑：sysctl -w 只在当前运行期生效，机器重启后转发又变回 0。要么写进 /etc/sysctl.d/99-wg.conf 并 sysctl --system，要么接受每次重启后手工补一次——后者在排障时最容易把人带偏，因为你以为配置没变，其实系统状态变了。
四、抗封锁：改端口、udp2raw、AmneziaWG 各自救什么
先按"代价从小到大"排一遍，别一上来就上混淆。混淆能解决的是"被规则误杀"，解决不了"路径本身就烂"——把这两件事混在一起，你会在错误的方向上花掉整个周末。
| 处置 | 能解决 | 解决不了 | 代价 |
|---|---|---|---|
| 换端口（51820 改成 443、53、高位端口） | 只认端口的黑名单 | 包长、时序、长连接特征 | 零，改一行配置 |
| udp2raw 转 faketcp / ICMP | UDP 整体被阻断或被粗暴限速 | 大流量长连接被抽样识别、IP 段被整段限 | 多一跳、需要 root 与 raw socket、MTU 要再降 |
| AmneziaWG 混淆 | 包长与 type 魔数指纹 | DSCP 特征、IP 段级封锁 | 两端都要换实现，参数必须完全一致 |
| 换协议（Hysteria2、VLESS+REALITY） | 特征层的所有问题 | 线路本身的丢包与绕路 | 客户端生态要重建，自建成本上升 |
| 换出口（专线/中转/住宅 IP） | 路径质量与 IP 属性 | 协议特征问题 | 钱，以及失去"完全自建"的自由 |
udp2raw 的原理不复杂：把 WG 发出的 UDP 数据报塞进伪造的 TCP 或 ICMP 报文里，用 raw socket 直接发出去，中间设备看到的是"一条 TCP 连接"。因为它自己模拟了三次握手和 seq/ack，防火墙会把它当普通 TCP，但它本质上还是 UDP——没有拥塞控制、没有重传，官方 README 里也明说了这一点，所以不会有 TCP-over-TCP 那种"越丢越慢"的雪崩，代价是丢包会原样透传给你的隧道。
# 服务端（raw socket，需要 root）
./udp2raw -s -l 0.0.0.0:4096 -r 127.0.0.1:51820 \
-k 你的口令 --raw-mode faketcp \
--cipher-mode aes128cbc --auth-mode hmac_sha1 -a
# 客户端（本机监听 51820，把 wg 的包转给服务端 4096）
./udp2raw -c -l 127.0.0.1:51820 -r 203.0.113.10:4096 \
-k 你的口令 --raw-mode faketcp \
--cipher-mode aes128cbc --auth-mode hmac_sha1 -a四个必须注意的点。一是 -a 不能忘，它负责自动增删 iptables 规则，官方文档直接把"忘了加 -a"列为最常见错误，缺了它会出现"能建立连接但过一会儿就断"。二是两端的 --raw-mode、-k、--cipher-mode、--auth-mode 必须完全一致，默认值分别是 faketcp、aes128cbc、md5，改一边不改另一边就是握手失败。三是客户端的 Endpoint 要改成 127.0.0.1:51820，让 wg 以为在连本地；服务端的 WG 仍然监听 51820，只是外面套了一层。四是 MTU 要重算：外层从 8 字节的 UDP 头换成了 20 字节起的 TCP 头，加上时间戳、SACK、窗口缩放这些选项，实际可能吃到 40 字节，原来 1420 的预算要再让出 12 到 32 字节，稳妥的落点是 1380 到 1400，具体以 ping -M do 实测为准。
AmneziaWG 是 WG 的一个分支，思路是在协议层动手：握手前先发若干个随机长度的垃圾包，给握手包和传输包加随机填充，再把包里那几个固定魔数换成自定义区间，甚至可以插入模仿其他 UDP 协议的签名包。参数名字不直观，但记法很简单——垃圾包看 Jc/Jmin/Jmax，填充看 S1 到 S4，魔数看 H1 到 H4，签名包看 I1 到 I5。
[Interface]
PrivateKey = <私钥>
Address = 10.66.66.2/32
MTU = 1420
# 以下四项两端必须完全一致
Jc = 7
Jmin = 64
Jmax = 1024
S1 = 64
S2 = 64
S3 = 32
S4 = 16
H1 = 1234567891-1234568914
H2 = 1234570000-1234571023
H3 = 1234572000-1234573023
H4 = 1234574000-1234575023参数取值范围有边界：Jc 是 0 到 10、Jmin 最小 64、Jmax 上限 1024、S1 到 S3 是 0 到 64、S4 是 0 到 32，H1 到 H4 是 uint32 区间且四段不能互相重叠。不写这些参数时实现会自动随机化，对个人用户其实更安全——每台服务器指纹不同，比抄一套网上的固定值更难被批量匹配。真要用固定值，通常是为了多台机器统一配置或排查问题。
两个现实预期。AmneziaWG 需要服务端装 awg/awg-quick、客户端用支持它的 App，原生 WireGuard 客户端拿着这份配置是连不上的，这一点必须在部署前就跟所有使用者说清楚，否则你会收到一堆"连不上"的报障。另外它只是把形状改掉了，如果对方根本不看形状、直接按 IP 段或流量总量处理，混淆一点用都没有。
还有一类问题混淆完全无能为力：晚高峰的路径拥塞。跨境公网在晚上八九点的丢包和抖动是链路层的，跟你的包长成什么样无关。这时候能改善体验的是线路本身——自由猫 这类走 IEPL 专线的机场，卖点不在协议而在路径：入境到出口全程不经过公网中转，晚高峰的丢包曲线比机房直连平。自建机上再叠一层中转也能达到类似效果，但那已经是纯运维工作，和"搭个 VPN"是两码事。
五、出口 IP 的属性，比端口更容易被忽略
排完协议和 MTU，还有一个经常被跳过的维度：你这个出口 IP 在对方眼里是什么。同样是"能上网"，机房 IP、原生 IP、住宅 IP 在流媒体识别和账号风控里是完全不同的三档待遇。
| IP 类型 | 典型来源 | 流媒体识别 | 多账号风控 | 获取成本 |
|---|---|---|---|---|
| 机房 IP | 绝大多数 VPS 默认分配 | 容易被判为代理，解锁不稳定 | 差，同一段 IP 上往往已有大量用户 | 最低，随机器附带 |
| 原生 IP | 在当地注册、归属清晰的段 | 较好，取决于该段的历史记录 | 中等 | 中，需要挑商家 |
| 住宅 IP | 运营商家宽出口 | 最好，接近真实用户 | 最好，但同 IP 不能多人共用 | 最高，按条计费 |
自建 WG 有一个结构性劣势：出口就是你那台 VPS 的机房 IP，而且所有客户端共用它。一个人用没问题，一旦挂上十几个平台账号，对方看到的"十几个账号同一个出口"，关联起来几乎没有成本。更麻烦的是，机房 IP 段被整段标记时，换端口、上混淆、换协议全都无效——因为问题不在你的流量长什么样，而在你从哪儿出来。
这类需求有专门的供给：仙路湾 主打住宅 IP 与原生 IP 出口，面向的就是跨境多账号和流媒体解锁这类"IP 比速度重要"的场景。代价也要讲清楚：这类线路的价格通常高于同流量的机房线路，带宽峰值也不如 IEPL 大流量档，拿它跑下载是浪费。判断标准很朴素——你的账号价值高于流量成本时选它，反之老老实实用机房或专线。
六、MTU 与吞吐：1420 这个数字是怎么来的
很多人以为 MTU = 1420 是 wg-quick 的默认值，其实它是算出来的：wg-quick 启动时读取底层网卡的 MTU，减 80 再设给隧道（linux.bash 里的 set_mtu_up 就是这么写的），1500 减 80 正好 1420。
80 这个预算拆开是：外层 IPv4 头 20 + UDP 头 8 + WG 传输头 16 + 认证标签 16 = 60，剩下 20 字节留作余量，应付 PPPoE、VLAN、上游隧道这些叠加封装。所以链路一变，这个数字就得跟着变：PPPoE 拨号底层是 1492，隧道就变成 1412；VLAN 叠加再减 4；已经套了一层隧道再套 WG，要手动把 MTU 写小。
MTU 配大了的典型症状非常有辨识度：小请求能通，大响应卡住。DNS 能解析、TCP 三次握手能完成，但 TLS 握手到证书那一步就没下文；网页文字出来、图片加载一半；SSH 能登录，scp 传大文件卡死。原因是 ICMP 的"需要分片"消息在链路上被丢了，双方都不知道该降大小，这就是常说的 PMTU 黑洞。
# 逐级降 8 字节试探真实可通的最大包（1392 + 28 = 1420）
ping -M do -s 1392 10.66.66.1
ping -M do -s 1384 10.66.66.1
ping -M do -s 1376 10.66.66.1
# 看路径 MTU 与在哪一跳开始不通
tracepath 10.66.66.1服务端配置里那条 MSS clamp 就是给这种情况兜底的：它把经过的 TCP SYN 里的 MSS 改成按路径 MTU 计算的值，让两端的 TCP 主动把段缩小，不必依赖 ICMP。这条规则写在 FORWARD 链，是因为被转发的流量不经过本机 OUTPUT；写在 OUTPUT 上只对服务端自己发起的连接有效，对隧道里穿过去的流量一点用没有。
吞吐上不去，先分清是"链路不够"还是"机器不够"。单核软中断打满是 WG 最常见的天花板：top 里看 si 那一列，如果它顶到 100% 而 us 不高，说明包都在同一个核上处理，这时候换更大的带宽套餐没用。可以做的有几件事：网卡多队列配合 RPS/RFS 把软中断摊到多核；把 UDP 接收缓冲区放大（默认值对千兆以上的隧道偏小）；在物理网卡上挂 fq_codel 避免自己把上行塞满导致延迟暴涨。
# 缓冲区与队列（写入 /etc/sysctl.d/99-wg.conf 后 sysctl --system）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 16384
# 查看软中断分布与网卡队列
mpstat -P ALL 1
ethtool -l eth0
cat /proc/interrupts | grep eth0需要说清楚的是，本文不给速度数字。WG 本身没有拥塞控制，丢包会直接反映成掉速，任何"某某配置能跑多少兆"的说法都强依赖你的线路、机器和时段，抄别人的数字没有意义。要判断调优有没有效果，用 iperf3 在固定时段跑同一组参数对比：UDP 模式看丢包率，TCP 模式看稳定性，跑三轮取中间那轮。关于"晚高峰到底卡在哪一段"的系统性取证方法，自建节点晚高峰分段排障那篇给了五段链路的测法，和这里的参数调优是互补的两层。
七、什么时候不该用 WireGuard
排障走到尽头，有时结论是"这个场景不该用 WG"。这不是失败，是选型。下面按"你主要想解决什么"来分，比按协议优劣排序有用得多。
| 你的主要问题 | 更合适的选择 | 原因 |
|---|---|---|
| 移动网络、跨境高丢包，要抗丢包 | Hysteria2 | 基于 QUIC，自带拥塞控制与丢包恢复，弱网下比裸 UDP 稳 |
| 怕被主动探测，要求流量像正常 HTTPS | VLESS + REALITY | TLS 指纹与真实站点一致，没有自签证书特征 |
| 家庭/公司内网互访、设备互联 | WG（组网用法） | 配置简单、内核态转发、点对点延迟低，不需要伪装 |
| 只想每天稳定上网，不想运维 | 机场订阅 | 协议、线路、被封处理都由服务方承担 |
| 多账号运营、要求出口像真实用户 | 住宅 IP 出口 | IP 属性问题，协议层怎么改都没用 |
两个具体的分界。如果你的问题是"晚高峰丢包三成、视频一直缓冲"，换协议能改善，因为 Hysteria2 的拥塞控制会把可用带宽吃满而不是像裸 WG 那样一丢就掉，完整的参数与部署在 Hysteria2 协议完全指南里。如果你的问题是"新机器上线两天就被封端口、换端口也撑不过一周"，那要解决的是特征而不是速度，VLESS + REALITY 的思路是让流量在探测者眼里就是一次普通的 TLS 访问，原理和部署见 Xray REALITY 协议完全指南。
反过来说，如果你的场景是两台固定设备之间长期传数据、或者要在家里访问公司内网的 NAS，WG 仍然是这个价位上最省事的选择：内核态实现、配置几十行、断线自动重连、几乎不吃 CPU。不要因为它"容易被识别"就把它从所有场景里划掉——被识别的前提是流量要跨境穿过审查设备，纯内网互访根本不经过那一层。
八、常见问题
Q：握手成功、内网也能 ping 通，为什么浏览器打不开网页？
按顺序查三样：先看客户端有没有把 DNS 指到隧道里（DNS = 那一行，或者系统解析器还指向本地运营商），再看 MTU 是否偏大——用 ping -M do -s 1392 试，出现 Message too long 或全丢就是它，再看服务端 iptables -t nat -S | grep MASQUERADE 有没有规则。三者里 MTU 最隐蔽，因为它的症状是"部分网站能开、部分卡住"，很容易被误判成对方站点的问题。
Q：同一份配置，手机能连、Windows 连不上？
常见原因是 Windows 上装了多块虚拟网卡（VMware、Hyper-V、Docker 各挂一块），路由 metric 让流量没走隧道；也可能是客户端把 AllowedIPs 的默认路由装到了错误的接口。先在 Windows 上 route print 看 0.0.0.0/0 指向哪，再用 tracert 确认首跳是隧道地址。手机端因为只有一个默认路由，反而不容易出这个问题。
Q：WireGuard 和 Cloudflare WARP 是什么关系？
WARP 用的就是 WG 协议，只是客户端和出口都由 Cloudflare 提供，你不需要自己维护服务端，也拿不到可自由配置的密钥。它适合做"落地出口"或解锁特定服务，不适合当唯一的跨境通道——具体做法和限制在 WARP 分流解锁实战里写过。两者可以叠：WG 负责你到自己服务器的这一段，WARP 负责服务器到目标站点的这一段。
Q：把端口改成 443 有用吗？
对只认端口的黑名单有用，对看包长的规则没用。判断方法很直接：改完端口后如果立刻恢复、且能稳定用几天，说明对面只是端口过滤；如果改完还是几小时就断，或者速度照样被打到几兆，那就是特征层或 IP 段的问题，继续换端口只是换了个数字。
Q：udp2raw 会不会和 BBR 之类冲突？
不冲突，但别指望它们互相帮忙。faketcp 没有拥塞控制和重传，BBR 作用于真实的 TCP 连接，两者不在同一层。落地机上开 BBR 对"落地机自己发起的 TCP"有影响，对纯转发的隧道流量影响有限——隧道里跑的 TCP 由两端主机的拥塞算法决定，不是落地机说了算。
Q：服务端用内核模块还是 wireguard-go？
能装内核模块就用内核模块，吞吐和 CPU 占用都更好，绝大多数发行版 5.6 以后的内核已内置。wireguard-go 适合内核太老、或者跑在容器里不方便加载模块的场景，代价是用户态多一次拷贝，高带宽下 CPU 明显更高。容器里跑要注意两件事：需要 NET_ADMIN 能力，以及宿主机的 /dev/net/tun 要挂进去。
Q：一个端口被限，能不能开多个端口轮换？
WG 本身不支持端口跳跃，只能靠外部脚本定时改 ListenPort 并同步更新客户端，或者用 iptables 把多个端口 DNAT 到同一个监听。真要端口跳跃，Hysteria2 原生支持这个能力，配置里一行 server_ports 就能指定区间，比在 WG 外面自己写脚本可靠。
Q：要不要给 WG 开 IPv6？
双栈能减少一类 NAT 带来的连接问题，尤其在只有 IPv6 的网络里（比如部分移动网络）能直接建立连接。但要注意 IPv6 的最小 MTU 是 1280，v6 路径上做隧道时 MTU 要给够余量，配置不当会出现"v4 正常、v6 一直转圈"的割裂现象。不确定就先不开，等服务稳定了再加。
九、上线前自查清单
- 云平台安全组与主机防火墙都放行了 UDP 端口（两处都要开，只开一处等于没开）
net.ipv4.ip_forward=1已写进sysctl.d，重启后仍在- MASQUERADE 指向真实出口网卡，
PostDown里有一一对应的删除规则 - 握手验证过：
wg show的latest handshake有时间戳，transfer双向增长 - 出口验证过：客户端
curl -4 ifconfig.me得到的是 VPS 的公网地址 - MTU 验证过：
ping -M do -s 1392通，且大文件传输不卡死 - MTU 与端口记录在案：底层链路变了（换 PPPoE、加 VLAN、套隧道）要重算
- 如果上了 udp2raw，两端参数逐项比对过，客户端
Endpoint指向本地监听 - 如果上了 AmneziaWG，确认所有客户端都装了支持它的 App，参数完全一致
- 出口 IP 属性评估过：机房段是否够用，是否有多账号共用同一出口的风险
把这些过一遍，绝大多数"连不上"和"慢"的问题会在十分钟内定位到具体一层，而不是靠反复重启碰运气。WG 本身足够简单，麻烦的从来是它外面那圈东西——转发规则、路径 MTU、链路质量，以及审查设备怎么看这条流。
推荐阅读
- 主流协议到底有什么区别——把 WG 和 Trojan、VLESS、Hysteria2 放在同一张表里对比，看清"特征、性能、可维护性"三个维度各自的代价。
- VPS 被墙了怎么办——IP 封锁的诊断与救活路径。本文讲的是"能连但不稳"和"被识别"，那篇处理的是更彻底的"整台机器失联"。
- 自建 VPN 进阶管理——多节点热备、流量监控与成本控制。单节点 WG 跑通之后，下一步通常就是这套东西。