为什么 OpenVPN 配置在家能用，到了酒店却失败

办公室的 Wi-Fi 和酒店房间可能给同一台笔记本两个截然不同的网络，而夹在中间的配置对此一无所知。在家能用的前提是上行链路足够宽松、名称解析正常、本地子网不与隧道承载的任何地址冲突。这些前提中的每一个都可能单独失效。

排查这个问题的有用办法，是把网络看成四个相互独立的事实，然后按顺序检验。先猜配置通常会带来一个什么都修不好、还把证据遮住的变化。

四种网络事实会随地点改变

第一个事实是本地网络到底放不放你出去。强制门户会把设备引到登录页，并在该页完成之前挡住其他一切，也就是说无论配置多正确，隧道都无法启动。

第二个是名称解析。拦截 DNS 的门户会用自身地址回答每个查询，于是 VPN 主机名被解析到门户，客户端试图向一个网页建立隧道。

第三个是传输过滤。只想允许浏览的网络会放行通往任意目标的 TCP 443，并丢弃几乎其他所有流量，包括 UDP。

第四个是地址分配。本地子网可能与隧道后方的网络重叠，或者上行链路根本不提供可用的 IPv4 路径。

把配置里的主机名换成服务器的数字地址再试一次。如果 IP 能连、名字不能连，问题就在名称解析，配置本身没有问题。

在动 VPN 之前，先打开浏览器试一个普通 HTTP 页面。跳到登录页说明门户还没完成；把它走完，然后重新连接。很多酒店还会在几小时后让会话过期，看起来像中午掉线，而不是登录问题。

如果数字地址也失败，名称解析就不是原因，接着查传输。把测过的地址留着，因为它能告诉下一项检查数据包到底有没有离开这台机器。

走 UDP 1194 的 OpenVPN 流量在酒店防火墙眼里不像任何已知协议，于是被静默丢弃。客户端一直重试到超时，用户看到的是永远建立不起来的连接，而不是被拒绝。这样行事的防火墙很少把丢弃记录在你看得见的地方。没有拒绝本身就是线索。

TCP 443 是可靠的备选，因为网络无法把它和普通 HTTPS 区分开。有运营商提供的 TCP 配置就用它，因为服务器也必须在该传输和端口上监听；只改客户端会产生另一种失败。如果没有 TCP 配置，去问运营商，而不是改个端口自己造一个。服务端必须同意，不匹配看起来又会像防火墙问题。

性能代价要有预期。TCP 套 TCP 会在有丢包的链路上放大重传，所以能用的 TCP 隧道在拥挤的酒店网络里仍可能很慢。这是为可达性做的交换，不是需要追查的故障。

隧道可以建立起来却什么都不传。当本地 LAN 与远端网络共用 192.168.1.0/24 这样的前缀时，客户端会把远端主机当作直连，把数据包发到本地链路而不是隧道。症状是一个子网不通的成功连接，很容易被误读成服务端路由问题。

永久的修法是把远端 LAN 挪到不常见的私有网段。选一个家里没人用的网段，比如 10.42.0.0/24，就能为今后每个地点而不只是一处提前挡住问题。本地绕行办法是避开那家酒店、热点或路由器，那根本算不上修复。

移动上行链路还带来两种变化。运营商级 NAT 意味着入站连接到不了，这对自建服务器有意义，对出站客户端没有。配置成仅 IPv6 并做 NAT64 转换的 APN 会让坚持真实 IPv4 路径的客户端失败，通常的补救办法是把 APN 协议改成 IPv4 或双栈。

连上之后又没声音的隧道通常是 keepalive 或 MTU 问题，而不是端口被封。连接在固定分钟数后掉线，指向 keepalive 或重新协商的计时器。把客户端设成探测对端、没有回应就重启，并在 ping 通而大流量卡住时试更小的隧道 MTU。

求助之前先把三件事写下来：试过的地址以及它有没有回应、用过的传输和端口、失败网络的本地子网。这三样能一起把名称解析、传输过滤和地址冲突分开，而那正是经得起证据检验的原因。