让你的 VPN 上架之前，VPS 必须允许什么

实例能启动，软件包安装成功，服务甚至报告正在运行，可就是连不上。这种情形在虚拟专用服务器上很常见，因为一台能顺畅上网的虚拟机，仍可能无法创建你的协议所需的接口。五项检查能把真正能承载隧道的宿主与只是看起来就绪的宿主区分开，而第一项失败的检查通常能解释后面的一切。每项检查执行成本都很低，而且以决定收尾，而不是以一条备注收尾。

确认协议所需的接口

OpenVPN 跑在 TUN 之上需要字符设备和背后的内核模块；WireGuard 需要自己的内核支持，或具备相应预期的用户态实现。托管容器可能与一台从不暴露该设备的宿主共享内核，而某些平台无论装了什么，都干脆禁止创建隧道接口。

与其读支持页面，不如直接测能力，因为营销标签比底层限制变得更快。为某个套餐写的功能清单，未必描述访客真正运行的内核。两条短命令就能回答常用协议的问题，而且都会清理现场。下面的命令不会留下任何长期存在的东西，执行后立即移除。

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

第一对命令被拒绝，说明 TUN 不可用，OpenVPN 的默认模式无法启动；最后一行被拒绝，说明缺少 WireGuard 内核接口。内核的 TUN/TAP 文档 描述的正是第一项检查所用的设备。这两种失败都不是重装 VPN 软件包能修好的。

记住：入站路径有两个所有者

提供商的网络规则与访客的防火墙是两套独立系统，流量必须同时通过两者。访客上绑定的监听端口，如果被提供商的安全组丢弃就毫无意义；反过来，提供商规则开放了，访客拒绝数据包也同样无效。按监听、访客规则、提供商面板的顺序核查，并同时确认协议和端口号。一上来就打开提供商面板，正是人们开出并不需要的端口范围的原因。

UDP 是常见的牺牲品：许多平台默认放行 TCP，却把 UDP 规则当作单独条目。如果实例位于提供商的 NAT 之后、没有公网地址，提供商侧的端口转发就成为第三处需要协调的配置。

规划回程，而不只是出口

全隧道服务需要开启转发、为客户端流量准备地址转换或路由方案，并让回程能到达客户端地址池。只开一个监听端口，这些一样都不会有。隧道建得起来却不承载有效流量，问题通常就出在这里，而不在认证环节。把成功握手当作诊断的起点，而不是终点。

把计划写成三项具体决定：客户端拿到哪段源地址、它们的流量如何出网、回应如何找回路径。然后在测试客户端之前确认内核与计划一致，免得把无声的不一致误判成客户端一侧的故障。

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

明确决定 IPv6 怎么办

IPv6 会通过几种机制到来，对网关而言行为各不相同：实例上直接有地址、有可路由的前缀，或者完全没有。只有可路由的前缀才能让服务器按常规方式给客户端分配地址。以为宿主上有可用的 IPv6 地址就等于客户端有可用前缀，是日后会以半瘫连接形式暴露的错误。这类故障能躲过只用 IPv4 做的每一项测试。

如果提供商不路由任何前缀，就决定隧道是否只走 IPv4，以及要不要告知客户端。有据可查的缺失，比一份悄悄把 IPv6 目标丢进黑洞的部分配置更安全。

用外部客户端证明

本地服务状态只描述一台宿主上的一个进程。真正有用的测试，是在另一张网络上的授权客户端，用你打算分发的配置连接，然后访问应用并解析域名。还要再重连一次，因为只在首次尝试时能用的隧道，恰恰不满足实践中最要紧的那条要求。

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

把运维底线放在测试旁边：预留更新空间、限制日志、保留不依赖隧道的管理通道、准备恢复控制台，并记下实例重建、公网地址变化时客户端配置会怎样。如果所需的接口或转发模型根本不存在，客户端侧任何改动都补不出来，诚实的下一步是换一种实例类型，而不是继续堆配置。