酒店 Wi-Fi：VPN 还没连到服务器就失败了

VPN 客户端一直转圈，随后提示无法连接服务器，于是所有人都认为酒店封锁了 VPN。通常并没有那么戏剧性：网络还没放你出去。强制门户会拦下所有连接直到你登录，而登录页在拦截它的数据包时，隧道根本无法完成。先把登录流程走完，再怪隧道。

迷思：酒店会封锁 VPN

大多数酒店网络并不会专门过滤隧道。它们会拦截网页流量直到客人完成认证，还可能限制设备数量、让会话过期或限速。这些都会产生一种从 VPN 客户端内部看起来像被封锁的故障。

在这里隧道是很差的诊断工具，因为在门户未授权期间，它是唯一必然失败的应用。普通网页访问才是更好的指标，因为它能让你看到登录页本身。

这个顺序还有另一个原因：带终止开关或始终开启模式的客户端会拒绝加载门户，用户就会以为是网络坏了，而不是设置问题。两件事同时成立，而在酒店里只能改变其中一件。用客户端自带的控制关闭保护，登录后再打开。其他做法都是掩盖真实顺序的绕路。

先走完门户，再测试普通 HTTPS

向工作人员确认官方网络名称和登录方式。看起来可信的 SSID 并不等于归属证明，同名或近似的第二个网络在公共场所很常见。优先使用操作系统自带的登录提示，其次才是酒店提供的页面。

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

第一个请求通过明文 HTTP 询问一个已知的强制门户检测端点；如果出现跳转或意外内容，说明你仍在门户后面。第二个请求测试普通 HTTPS 站点。如果第一个显示被拦截而第二个失败，说明登录没有完成，与 VPN 无关。

在个人设备上，可能需要通过客户端支持的控制关闭终止开关或始终开启的 VPN，门户才能加载。在这段时间里关闭敏感应用，随后立刻恢复保护。在公司管理的设备上，按管理员批准的做法操作，不要自行移除策略。

不要为了上网而绕过证书警告，也不要安装来源不明的证书或辅助程序。如果门户要求意料之外的东西，请与工作人员确认；设备属于雇主时，还要与管理员确认。

保留原始配置文件及其报错

普通访问恢复后，连接原始配置文件并记录准确的报错。认证被拒是账号问题，协商阶段超时是链路问题，而能建立却什么都传不过去的隧道是路由或策略问题。

这三种情况的下一步各不相同，而报错的截图比描述更有价值。同时记录时间，因为酒店的会话限制可能在一小时内到期，制造出看似随机的故障。如果客户端提供日志，只保留第一次故障前后的片段，而不是整个文件。这段摘录通常足够让配置文件的持有者判断卡在哪一步。

如果普通访问正常而协商仍然超时，询问酒店是否支持这种流量，并在设备与配置不变的前提下与可信热点对比。在热点上能跑通，只能说明问题更可能在酒店链路上，并不能证明配置本身有问题。

只使用运营方提供的替代方案

匹配的 TCP 配置可能在被提供的 UDP 路径走不通时成功，但前提是服务器确实在该传输与端口上监听。TCP 443 端口不会自动被当作普通 HTTPS，也不保证能穿过限制严格的网络。

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

以更高详细级别运行提供的配置，可以让第一条有用的报错保持可见，而不是被压成通用的失败弹窗。使用运营方给出的文件，不要自行修改端口或协议，因为本地改动无法在对端生成匹配的监听。

如果隧道反复重置，记录门户是否重新出现、本地信号是否下降，并按稳定性检查逐步推进，而不是同时切换多个协议。然后再测试真正需要的应用，并恢复常规的隐私控制。只通一个站点而不通另一个，是路由或策略问题，不是门户问题。

最后，检查笔记本休眠后的恢复情况。门户授权可能独立于隧道过期，因此自动重连的设备可能回到一个已经忘记它的网络。重新打开门户页面是正常步骤，不代表 VPN 坏了。