WireGuard 配置没错，为什么 VPS 收不到 UDP 包？一次家庭内网穿透排障复盘
折腾家庭远程访问时，最容易让人崩溃的一类问题是：配置看起来都对，但就是连不上。
这次遇到的就是一个典型案例：家里的 Windows 主机已经启用了 WireGuard 客户端，VPS 端也配置好了 WireGuard Server，防火墙、监听端口、Peer 信息看起来都没问题，但就是没有握手。
一开始很容易怀疑：
- WireGuard 配置是不是写错了？
- Endpoint 端口是不是错了？
- Windows 防火墙是不是拦了？
- VPS 的 UFW 是不是没放行？
- 要不要干脆重装系统？
但最后排下来，真正的问题并不在 WireGuard，而是在 VPS 公网 UDP 入站链路。
这篇文章就复盘一下这个排障过程，尤其适合正在搭建 WireGuard、Tailscale 替代方案、家庭内网穿透或者远程访问入口的朋友参考。
目标：让外部设备通过 VPS 回到家里
整体目标很简单：
外部设备 / 手机 / 笔记本
↓
VPS 中转
↓
家庭内网节点
↓
Windows 主机 / NAS / PVE / 旁路由这种架构的好处是：
- 家里不需要公网 IP；
- 不用在家用路由器上暴露端口；
- VPS 可以作为固定入口；
- 多台设备都可以接入同一个 WireGuard 网络；
- 后续可以扩展到 NAS、PVE、旁路由等更多内网服务。
理论上很优雅，但实际部署时，第一步就卡住了：WireGuard 没有握手。
表面现象：VPS 有 Peer，但没有握手
VPS 端 WireGuard 配置完成后，可以看到 Peer 已经存在。也就是说，服务端配置文件并不是完全没加载。
但关键问题是：
- 没有
latest handshake； - 没有 Rx / Tx 流量；
- 客户端显示已启用，但服务端没有收到任何有效通信。
这种状态通常说明：客户端要么没发出去，要么包在路上被拦了，要么 VPS 系统层没有收到。
排障不能靠猜，要一步一步把链路切开。
第一步：先确认客户端有没有真的发 UDP
在 Windows 客户端侧，用 PowerShell 做了一次 UDP 发送测试。
测试结果返回了字节数，说明本机确实向 VPS 的目标端口发出了 UDP 数据。
这一步很关键，因为它先排除了一个方向：
不是 Windows 完全没有发包。
当然，这并不代表包一定到达 VPS。它只能说明客户端本机网络栈已经尝试发送。
第二步：检查 VPS 本机 WireGuard 和防火墙
接着在 VPS 上检查：
- WireGuard 接口是否存在；
wg show是否能看到服务端和 Peer；- UFW 是否放行了目标 UDP 端口；
- 系统是否确实在监听对应端口。
这些检查都没有发现明显问题。
如果问题在 VPS 系统内部，通常至少能看到 UDP 包打到网卡，然后再被服务、防火墙或路由规则处理掉。
所以继续看最关键的一步：抓包。
第三步：用 tcpdump 看包有没有进入 VPS 网卡
在 VPS 上抓目标 WireGuard 端口：
tcpdump -ni any udp port 8512结果是：0 包。
为了避免是端口写错，又扩大范围抓所有 UDP：
tcpdump -ni any udp结果仍然是：0 包。
这个结果非常关键。
如果 Windows 已经发出 UDP，而 VPS 上 tcpdump 连任何 UDP 包都抓不到，那就说明问题大概率发生在 VPS 系统之外：
- 云厂商安全组没有真正放行；
- 公网 IP / EIP 还有单独防火墙；
- Cloud Firewall / ACL 拦截了 UDP；
- DDoS 清洗策略默认丢弃某些 UDP；
- 防火墙规则没有绑定到当前实例；
- 规则保存了，但没有 Apply / Attach / Bind 生效。
一句话：
包根本没进系统网卡，继续改 WireGuard 配置意义不大。
最容易走错的方向：重装系统
这类问题特别容易诱导人重装系统。
因为从表面看，VPS 上服务没握手，很多人第一反应就是：
- 重装 Ubuntu；
- 重新安装 WireGuard；
- 换一份配置；
- 反复开关 UFW；
- 改监听端口。
但如果 tcpdump -ni any udp 都是 0 包，重装系统通常救不了。
原因很简单：
操作系统还没看到包，问题就已经发生了。
这时候真正要查的是云平台网络层，而不是 Linux 系统层。
正确排查清单
遇到类似问题，可以按下面这个顺序查。
1. 查安全组是否绑定到当前实例
很多 VPS 控制台里，安全组规则和实例绑定是两件事。
你可能已经创建了 UDP 放行规则，但它没有绑定到真正运行 WireGuard 的那台机器。
重点确认：
- 入站规则是否是 UDP；
- 端口是否正确；
- 来源是否允许你的客户端 IP，测试阶段可临时用
0.0.0.0/0； - 规则是否绑定当前实例；
- 修改后是否需要保存、应用或重新部署。
2. 查公网 IP / EIP 防火墙
有些云厂商不仅有实例安全组，还有公网 IP 层面的防火墙。
这会导致一个很坑的现象：
- 实例安全组看起来放行了；
- 系统防火墙也放行了；
- 但公网 IP 层仍然拦着 UDP。
所以要单独检查 EIP、防火墙策略、ACL 或 Cloud Firewall 页面。
3. 换一个常见端口做对照
可以临时新增一条 UDP 51820 入站规则，然后抓包：
tcpdump -ni any udp port 51820再从客户端往这个端口发 UDP。
如果 51820 也抓不到，基本可以判断不是 WireGuard 端口配置问题，而是 UDP 入站整体没进来。
如果 51820 能抓到、原端口抓不到，那就说明原端口规则没有真正生效，或者被特殊策略拦截。
4. 确认服务商是否限制 UDP
有些低价 VPS、NAT VPS 或特殊线路机器，对 UDP 支持并不完整。
它可能不会在商品页面上写得很清楚，但实际网络层会限制、清洗或丢弃 UDP。
如果你要长期跑 WireGuard，选 VPS 时一定要确认：
- 是否支持 UDP 入站；
- 是否支持自定义安全组；
- 是否有独立防火墙；
- 是否允许 WireGuard / VPN 类用途；
- 是否有 DDoS 策略影响 UDP。
如果云厂商 UDP 不通，怎么办？
有三条路。
方案一：换一台 UDP 正常的 VPS
这是最干净的方案。
WireGuard 本身就是 UDP 协议，如果 VPS 的 UDP 入站不可靠，后面会一直踩坑。
适合目标：
- 想要完整 VPN；
- 想访问整个家庭内网；
- 想让手机、笔记本、家里节点都进同一个虚拟网；
- 后续还要扩展 PVE、NAS、旁路由管理。
推荐架构：
手机 / 笔记本
↓ WireGuard
VPS Hub
↓ WireGuard
家里常开 Linux 节点 / 旁路由
↓
家庭内网服务注意：家里的 Windows 主机如果会关机，不适合作为长期入口。更合适的入口是常开的 Linux 节点、旁路由、PVE 上的小 VM，或者专门的低功耗设备。
方案二：改用 TCP 隧道
如果暂时不想换 VPS，可以绕开 UDP，用 TCP 隧道类工具：
- frp；
- rathole；
- gost；
- cloudflared tunnel；
- 其他基于 TCP/443 的反向隧道。
这种方式更像“端口映射”或“反向代理”，不如 WireGuard 那么像完整 VPN，但胜在能绕过 UDP 被拦的问题。
适合目标：
- 只想暴露某几个管理端口；
- 只需要远程桌面、SSH、Web 管理页；
- 不需要完整访问整个家庭网段。
方案三：用 Tailscale / ZeroTier 等现成组网工具
如果不想维护太多底层配置，可以考虑 Tailscale 或 ZeroTier。
它们也会用 UDP，但具备 NAT 穿透和中继能力。即使直连失败，也可能通过中继兜底。
缺点是依赖第三方控制面或中继网络，不如自建 WireGuard 完全可控。
这次排障最大的收获
这次真正有价值的不是“某个端口怎么放行”，而是排障思路：
当 WireGuard 没握手时，不要先陷入配置文件。先确认 UDP 包有没有进入 VPS 网卡。
判断顺序可以记成一句话：
客户端是否发包 → VPS 网卡是否收到 → 系统防火墙是否放行 → WireGuard 是否处理 → 路由是否正确其中最有分水岭意义的，就是 tcpdump。
如果 VPS 能抓到 UDP 包，再去查 WireGuard 配置、密钥、AllowedIPs、路由、防火墙。
如果 VPS 连包都抓不到，就该去查云厂商网络层、安全组、EIP 防火墙、ACL 或直接换 VPS。
最后给家庭内网远程访问的建议
如果是家庭实验室、NAS、PVE、旁路由这类场景，我更建议这样设计：
- VPS 只做固定公网入口和中转；
- 家里用一台常开节点主动连 VPS；
- 不要把会关机的 Windows 主机当唯一入口；
- 先打通安全的管理通道，再考虑把整个网段路由进去；
- 所有公网入口默认最小开放，只放必要端口。
家庭网络越折腾，越要记住一点：
远程入口一定要放在稳定、常开、可恢复的节点上。
否则你会遇到一个很尴尬的问题：入口机器一关机，你连修它的路都没了。
本内容由 AI Agent 自动生成，仅供参考，不代表专业意见。