虚拟主机与 VPS：你的方案能运行 VPN 服务器吗？

网站能正常运行，只能证明服务商能提供 HTTP，并不能证明你掌控了一台机器。共享方案、托管应用与自管服务器之间，账户对网络能做什么存在巨大的鸿沟。在再付一年费用之前，先想清楚你的 VPN 设计需要站在鸿沟的哪一侧。四项能力把两者分开，而它们一条都不会出现在价目表上。

每种方案实际给了你什么

有用的比较不是价格或磁盘大小，而是权限。要问：账户能启动什么、能触及哪些内核特性、哪些端口接受入站流量，以及被放行的流量能否再次转发到别处。

多数主机产品分为三种形态，只有最后一种是通用服务器：

Shell 账户是常见的混淆来源。文件传输或定时任务访问看起来像管理，可进程其实被限制在一个目录和少数允许的操作里。

决定答案的四项能力

按顺序来看，因为第一步失败，后面就都不必谈。

第一，软件必须作为长期进程运行并能挺过维护。第二，实现必须能创建自己的虚拟接口；在 Linux 上，这通常意味着用相应的管理权限打开 /dev/net/tun，正如 内核的 TUN/TAP 文档 所述，尽管并非每种 VPN 设计都使用该设备。第三，客户端必须能在公网地址上连到监听器，并使用你预期的传输方式与端口；而接受 HTTPS 的 Web 反向代理，对同一端口号上另一个无关协议毫无说明。第四，被放行的流量必须能够继续转发，路由、转发与任何真正受支持的地址转换都要具备。

服务条款就摆在那四项旁边，而且完全不是技术问题。所谓无限流量，通常指的是网页请求，而不是一条承载他人下载的隧道。围绕它做设计之前，请先读一读可接受使用条款，并为服务启动不了的那天留好恢复通道。

网站账户止步于哪里

网站方案通常在带固定入口的托管运行时里执行你的代码。即使存在隧道二进制文件，进程也可能没有权限打开设备节点、绑定特权端口或改动路由表。这些限制就是产品本身，不是疏漏。

所以一个号称提供 VPN 的插件，最后往往只是通往别处的代理。如果当前账户只给你网站层面的控制，诚实的做法是另配一台服务器，而不是去找能解锁缺失权限的模块。

当一台主机必须同时承担两件事

共用是可行的，有时也合理，但请把它当作安全决策而非便利。带上传表单的 Web 应用与隧道凭据、控制套接字放在一起，一边被攻破就会波及另一边。分开账户、分开服务单元、分开文件系统，既降低暴露面，又不必买第二台机器。

资源争抢同样重要。穿过隧道的备份与繁忙的 Web 进程争同一条上行链路和同一块磁盘，故障看起来像网站变慢，而不是隧道被占满。在事故发生前就定下哪类负载优先，并给隧道设上限，让网站还能应答。

两套服务都在跑，并不等于任何一种安排已经隔离。能放在一起托管只是设计的起点，隔离工作才让它站得住脚。

在一台试用主机上用四条命令定论

迁移之前，先按小时租下目标产品最小的实例，直接测这四项能力。照着功能表猜，比买错一年的方案省钱，却要浪费更多时间。

在试用主机上跑这几条命令，把失败当作答案而不是障碍：

ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head

前两行告诉你隧道设备究竟能不能存在。第三行报告主机能否转发数据包，第四行显示已经在监听的东西，好让端口冲突早点被发现。第二行就失败的供应商，仍可能支持用户态实现，所以问他们的客服时，请说出你需要的机制，而不是产品类别。